gbp_permanent_link and meta_keywords does not work together

planeth · 2016-07-24 08:58:13

Hello dear developers,
I’ve been upgrading a plugin heavy site to Textpattern 4.6 and this is what I found :

1. I use gpl to construct link in the form of mysite.com/section/year/month/day/title
2. All articles have Keywords
3. When displaying an article, keywords are always the same : the one corresponding to an article which ID is 2016 …
4. It appears that meta_keywords are set in the pretext step with a global $id_keywords (kind of weird from my POV..) so no chance ever to get get back the real value after gpl has done its thing.

From your perspective, what would be the best option to make this work. ?

For now, I quite lean toward “use <txp:keywords /> anyway”.
And by the way, there are also other places where parsing <txp:meta_keywords /> returns nothing because pretext has not run.

Bloke · 2016-07-24 09:14:01

planeth wrote #300379:

When displaying an article, keywords are always the same : the one corresponding to an article which ID is 2016 …

Without trying this myself, it seems that gbp_pl (or core) is interpreting /section/year as /section/id and serving the keywords for that article.

Not quite sure how to fix that at the moment since gbp_pl will probably be doing rewrites prior to Txp’s involvement. Presumably it’s cognisant of Txp’s permlink mode as set in prefs.

Any code suggestions on a way forward?

meta_keywords are set in the pretext step with a global $id_keywords

It’s always been that way. No idea why that variable name was chosen. Perhaps to avoid possible clashes with a $keywords variable, or some potential PHP variable of the same name or something. *shrug*

there are also other places where parsing <txp:meta_keywords /> returns nothing because pretext has not run.

Is this specific to gbp_pl or in general? Care to give a few examples so I can track this down and try to fix it? Thanks.

planeth · 2016-07-24 10:27:00

Bloke wrote #300380:

Without trying this myself, it seems that gbp_pl (or core) is interpreting /section/year as /section/id and serving the keywords for that article.

From what I understood, I’d say it’s the other way around. First Textpattern run its pretext and grab the wrong article, then gpl kicks in and find the right one, and return what is necessary to grab the corresponding data.
Because all other fields like body, custom_field, etc.. are OK, except for the keywords. And if using the deprecated <txp:keywords /> you get the right keywords.

Any code suggestions on a way forward?

Er,… this is why I went here :)
From the top of my head : force gpl to re-assign $id_keywords ? Not very practical…
Is there an historical reason why there is 2 ways to retrieve keywords ? One during pretext step (which is cached) and one grabing the keywords index in $thisarticle ?

Is this specific to gbp_pl or in general? Care to give a few examples so I can track this down and try to fix it?

Inside a plugin where I define a tag

function plh_some_tags($atts, $thing='')
{
// some code 
$val = txpspecialchars(parse($thing));

And then, BAM, returns empty string… It happens only with <txp:meta_keywords />

Textpattern CMS

Textpattern CMS support forum

#1 2016-07-24 08:58:13