gbp_permanent_links

maniqui · 2009-11-02 16:26:04

Weird. I’ve had some gbp_p_l “insights” today at morning, while I was chit-chatting (no technical questions involved) with graeme at #xpat channel.

As I mentioned before, things get fixed for me by doing any or all of this things:

Switched to messy URL mode and then back to /section/title mode
momentarily reverted to 0.14.4 and then back to 0.14.5
created a few rules, deleted them, created them again, and so on…

Not sure what, but something made TXP and/or gbp_p_l “click”.

Regarding your issue, have you checked the “precedence” value? If no precedence value, then tags like txp:permlink aren’t affected. You taught me that one, cowboy!

pieman · 2009-11-02 16:33:16

I tried doing the messy/clean flip as suggested, but no luck so far. Will try reverting to older version and see if it works for me.

Normally if txp:permlink doesn’t output the gbp_pl url then it is indeed a matter of clucking around with the precedence. But I’ve never found a situation where it works in one place and not another – normally it either works universally for that kind of link or it doesn’t. This is a new one for me.

graeme · 2009-11-02 17:38:20

pieman wrote:

Normally if txp:permlink doesn’t output the gbp_pl url then it is indeed a matter of clucking around with the precedence.

Is that behaviour desirable or confusing? Sounds like a bug because as far as I’m aware txp:permlink should be outputting a gbp_pl url regardless of the precedence.

Also maniqui: I’ll have a fix for the file downloads urls out later.

pieman · 2009-11-02 17:43:35

graeme wrote:

Is that behaviour desirable or confusing?

Confusing. With the necessary precedence assigned txp:permlink normally outputs the gbp_pl URLs using all native tags in all situations. This is the first time I’ve seen it vary according to which page template it’s used in. Definitely a bug – but I’ve used this plugin loads before and not come across it so it’s quite strange. Not a big problem in this case though – it’s a small site and easy enough to work around.

graeme · 2009-11-02 18:17:17

New release which fixes two problems:

Problem with rule conditions not being used – see this post
File download URLs are now formatted correctly

gbp_permanent_links v0.14 patch 6 (Compressed / Minified)

graeme · 2009-11-02 18:19:04

pieman wrote:

Confusing. With the necessary precedence assigned txp:permlink normally outputs the gbp_pl URLs using all native tags in all situations. This is the first time I’ve seen it vary according to which page template it’s used in. Definitely a bug – but I’ve used this plugin loads before and not come across it so it’s quite strange. Not a big problem in this case though – it’s a small site and easy enough to work around.

I will add this to the list of things to look at. I had thought I would do away with precedence values in the next version but I’m not sure that’ll be possible any more.

pieman · 2009-11-03 10:38:38

pieman wrote:

Used in the News section, this returns the gbp_pl defined (section/yyyy/mm/dd/title) url:
<txp:article_custom section="news"><a href="<txp:permlink />" rel="bookmark"><txp:title /></a></txp:article_custom>
But used in any other section, exactly the same code returns a /section/title url instead – even though I have prefs=messy (!)

Graeme

With fresh eyes this morning I saw that the culprit wasn’t gbp_pl, but in fact me (shome mishtayke shurely).

I was trying to be clever and pointing tru_tags to the News section and somehow that was sinking the ship. All is well now. Apologies for the false alarm.

maniqui · 2009-11-03 12:37:31

Ops. I wrote a post last night, but it seems I forgot to submit it.

Is there any chance that, after upgrading, all the gbp_p_l rules have been deleted by the upgrade process?

I upgraded, but didn’t check the gbp_p_l tab until a few hours later. I was surprised to see that there weren’t any rules, like if they were deleted.
FYI, I run gbp_p_l from the plugin_cache_dir, and to upgraded I simple switched old version file for new one.

I wonder if it was gbp_p_l the culprit of this deletion. Next time I’ll backup :)

graeme · 2009-11-03 13:08:15

maniqui wrote:

I wonder if it was gbp_p_l the culprit of this deletion. Next time I’ll backup :)

No changes were made to the plugin which would of caused the deletion. It’s very strange. the plugin stores it’s setting in the txp_prefs table so you may want to check your other settings to make sure everything is still set up correctly.

maniqui · 2009-11-03 13:16:45

While here, a minor wish:

If you generate the “typical” /section/category/title permlink, when you visit an article permlink (/my-section/the-category/my-great-article), the txp:if_category tag will return true for the “page context”, which I consider an “erroneous behaviour”.

I think it would be “in harmony” with standard TXP behaviour [1] if it would return false, as we are not on a category list (article_list context), but already visiting the permlink of an article (individual_article context).

Of course, if this change is possible and it’s applied, it may break backwards compatibility. I won’t worry about that, anyway! :D

[1] From if_category Textbook entry: “The tag will execute the contained statements if the name attribute matches a category search value, or the list is an article list by category (?c=category) “

maniqui · 2009-11-03 13:57:07

OK, after a quick chat with graeme, he made me notice that that’s how thing work on the inner cogs of TXP, because:

because /section/category/title effectively means /?s=section&c=category&id=someid

And also:

/section/title?c=category is valid (returns true)

Even if the above URLs may not match any real use case, that’s how things works on the background. TXP evaluates if the &c=name ($c variable) is set, and so, if_category returns true, even if on an individual article.

The possible “workarounds”:

test for if_individual_article instead of testing for if_category
test for if_article_list first and then nest a if_category (aka “if_category_list” tag, yet to be invented).

Thanks, graeme!

uli · 2009-11-03 23:30:32

Thanks for letting us know, Julián!

aswihart · 2009-11-08 22:26:56

One issue I’m having for end-users, not sure if it’s specific to Txp 4.2: even wtih Freelancer privileges, I can see and edit the settings of this plugin in the Admin tab.

uli · 2009-11-08 23:07:09

Funny I never remarked that. Thanks for the heads-up!

~~In the gbp library look for:~~
~~@var $permissions = ’1,2,3,4,5,6’;@ (two instances)~~
~~change to the user levels that you need there.~~

See graeme’s post

Last edited by uli (2009-11-10 14:49:49)

aswihart · 2009-11-10 02:16:49

Thanks mate! Yeah, I think it’s probably prudent to make it default to at least 1,2,3, if not just 1!?

Textpattern CMS

Textpattern CMS support forum

#511 2009-11-02 16:26:04

Re: gbp_permanent_links

#512 2009-11-02 16:33:16

Re: gbp_permanent_links

#513 2009-11-02 17:38:20

Re: gbp_permanent_links

#514 2009-11-02 17:43:35

Re: gbp_permanent_links

#515 2009-11-02 18:17:17

Re: gbp_permanent_links

#516 2009-11-02 18:19:04

Re: gbp_permanent_links

#517 2009-11-03 10:38:38

Re: gbp_permanent_links

#518 2009-11-03 12:37:31

Re: gbp_permanent_links

#519 2009-11-03 13:08:15

Re: gbp_permanent_links

#520 2009-11-03 13:16:45

Re: gbp_permanent_links

#521 2009-11-03 13:57:07

Re: gbp_permanent_links

#522 2009-11-03 23:30:32

Re: gbp_permanent_links

#523 2009-11-08 22:26:56

Re: gbp_permanent_links

#524 2009-11-08 23:07:09

Re: gbp_permanent_links

#525 2009-11-10 02:16:49

Re: gbp_permanent_links

Board footer