gbp_permanent_links

radneck · 2010-09-10 06:28:36

I’ve stumbled on an issue that I haven’t seen before, which is strange because I’ve used this great plugin quite freqently.

I’m using the pretty standard /section/category/title rule for my permanent links, but enabled for only 1 section (we’ll call it section3).

Works great, except when I’m viewing a category or article under section3, the URLs in the top level navigation of my site (generated using section_list) change from:
example.com/section1/
example.com/section2/
example.com/section3/

to:
example.com/section1/current_category/
example.com/section2/current_category/
example.com/section3/current_category/
current_category being the category currently being viewed, or the category of the article currently being viewed.

Anyone know how to stop this?
I can disable join_pretext_to_pagelinks but that stuffs up the second level navigation in section3, i.e. it becomes:
example.com/category/category1/
example.com/category/category2/
example.com/category/category3/

instead of (the correct):
example.com/section3/category1/
example.com/section3/category2/
example.com/section3/category3/

Any tips would be great. I don’t particularly want to hard code it in the plugin.
Also, I hope this wasn’t too confusing.

Last edited by radneck (2015-11-04 07:48:45)

andreas · 2010-09-14 14:44:52

With graeme’s help I found a solution to my problem.

Using the tag <txp:gbp_disable_permlinks> … </txp:gbp_disable_permlinks> you can tell the plugin to leave certain sections of your site alone.

I enclosed the relevant vdh_flicks tags with the above tags and all works fine.

hablablow · 2010-09-14 15:03:07

Andreas you saved my day with your post…
This is also the solution to my problem
Thanks !

hablablow · 2010-09-14 15:12:25

There’s an issue I have come across using this plugin. In the Permanent Links tab: List, Build, Preferences, and Edit, they all point to siteurl/textpattern/…
In a multisite setup the path is siteurl/admin/…
Links have to be changed manually in your browser to reach the links…
Anyone came across this ?
And knows which values to change in the library and the plugin ?
Thanks !

radneck · 2010-09-15 01:17:21

Thanks very much Andreas, perfect.

radneck · 2010-09-24 04:18:27

Graeme,

I’ve got a little bug, which I think has to do with gbp_permanen_links.

Problem can be reproduced by:

Starting with fresh 4.2.0 install
Upload and activate gbp_permanen_links (and gbp_admin_library obviously)
Add the site-wide rule section/category/title
Add a new article called ‘about’ in the section ‘about’ and give it a category
Go to your new site, and click the section link ‘About’

Provided you’re using the stock Pages and Forms, you should see some errors regarding <txp:link_to_next>, which I think is caused by the <txp:if_individual_article> tag returning true incorrectly (it should return false because you are viewing the section, not the individual article). This seems to be a case when there is an article with the same title (and therefore URL part) as a section – something to do with algorithms in gbp_permanen_links perhaps?

Its worth noting that disabling the plugin and refreshing will get rid of all the errors.

Edit: It almost definitely has to do with the logic in the cleaver partial match tests.

I’ve implemented a rough hack to disable it in the mean time, but is there any chance this could be added as a pref so it can be disabled if necessary?

Your thoughts would be appreciated.

Last edited by radneck (2015-11-04 07:45:25)

jodeci · 2010-10-01 09:36:25

Sorry if this has been asked before, but the only search result that came back was in German!

After installing gbp_permanent_links, I get 404 errors when I “preview” articles that are not of “live” status.
Preview as in: http://domain.com/section/id/?txpreview=id.timestamp

Any suggestions? Thanks!

smd_ksu · 2010-11-03 22:47:53

Is there a trick to using <txp:gbp_disable_permlinks>? I am trying to use it around upm_date_menu with no luck.

els · 2010-11-14 22:29:28

Since Txp 4.3.0: using the standard section/category/title rule, going to a section/category URL made <txp:if_category> return false (see post JanDW).

radneck · 2010-11-23 04:47:24

Els wrote:

Since Txp 4.3.0: using the standard section/category/title rule, going to a section/category URL made <txp:if_category> return false (see post JanDW).

Post 546 related.

maniqui · 2010-12-01 22:18:09

I’ve reported some issues (and workarounds) between gbp_permanent_links and smd_short_url.

Both plugins played nicely together (smd_short_url v0.11). But for smd_short_url v0.2 release, Bloke changed a callback and plugins stopped playing nicely together.

Of the few attempts I did while trying to solve the issue, one of the workarounds involved doing the following change on gbp_p_l: around line 1961, change register_callback(array(&$gbp_pl, '_textpattern'), 'textpattern'); to register_callback(array(&$gbp_pl, '_textpattern'), 'txp_die', 404);.
(see details on the first link of this post).

Being that gbp_p_l is a big beast, I didn’t know if that change would have any other consequences in its functionality, besides making it to play nice with smd_short_url, so I reverted back the change and opted to use the other workaround that worked (again, take a look at first link on this post).

In any case, and tangentially related, I wonder if gbp_p_l would also benefit of using that txp_die callback, and hopefully, get officially updated by Mr. G. Porteous.
Just to clarify again: that only change on gbp_p_l won’t fix your issues with smd_short_url (which needs to have both register_callbacks: textpattern and txp_die, don’t ask me why), and also, I don’t have idea if it would have any undesired consequences.

maniqui · 2010-12-02 17:30:25

Another report.
On gbp_admin_library_v.0.4.669.php, I think there is a bug.

This is the code between lines 497 and 520:

if (empty($_SERVER['FCGI_ROLE']) and empty($_ENV['FCGI_ROLE'])) {
  header('HTTP/1.1 '.$status.' '.$status_definitions[$status]);
  header('Status: '.$status);
  header('Location: '.$url);
  header('Connection: close');
  header('Content-Length: 0');
  exit(0);
  } else {
  global $sitename;
  $url = htmlspecialchars($url);
  echo <<<END
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
      <title>$sitename</title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <meta http-equiv="refresh" content="0;url=$url" />
    </head>
    <body>
      <a href="$url">{$status_definitions[$status]}</a>
    </body>
  </html>
END;
}

On my local server, this conditions if (empty($_SERVER['FCGI_ROLE']) and empty($_ENV['FCGI_ROLE'])) evaluate to true, so the redirect was done by sending the correct headers.
On the other hand, on a client’s server, those conditions evaluated to false, so the request is redirected using a classic “old school” HTML redirect/refresh.
No problem with that: it may certainly be that the client’s server doesn’t pass that test, and so, it used the classic redirect instead of the one done by PHP headers (quick note: I’ve forced the header() method by removing the conditional statement and it worked… so this FCGI_ROLE testing may be some really old legacy stuff…).

But the issue is this: when effectively doing this classic redirect, the short redirect HTML code (see above between <<<END and END) was being concatenated with a full HTML page (which corresponded to the page that was being redirected from).
In other words, you would get something like this, in the output.

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
      <title>The site name</title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <meta http-equiv="refresh" content="0;url=http://example.com/somepage" />
    </head>
    <body>
      <a href="http://example.com/somepage">Moved permanently</a>
    </body>
  </html>
<!DOCTYPE ...>
<html ...>
  <head>
  ...
  </head>
  <body>
  ... the HTML for the page being redirected...
  </body>
</html>

As you can see, two pages were sent together. Of course, this was just wrong, and it looked bad on the front-end (it quickly flashed the two pages together, and then the redirect was done: it look awful).

I think this happened because an exit() is missing on the second branch of the conditionals.
The fixed code that worked for me:

bc. if (empty($_SERVER['FCGI_ROLE']) and empty($_ENV['FCGI_ROLE'])) {
  header('HTTP/1.1 '.$status.' '.$status_definitions[$status]);
  header('Status: '.$status);
  header('Location: '.$url);
  header('Connection: close');
  header('Content-Length: 0');
  exit(0);
  } else {
  global $sitename;
  $url = htmlspecialchars($url);
  echo <<<END
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
      <title>$sitename</title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
      <meta http-equiv="refresh" content="0;url=$url" />
    </head>
    <body>
      <a href="$url">{$status_definitions[$status]}</a>
    </body>
  </html>
END;
  exit(0); // Adding this exit() (to "cut" the output buffer, am I saying it correctly?)
}

That’s it.

Alternatively, you may want to test if your server supports header() redirects (be sure to test in IE browsers, as I think the whole header() problem is related to IE behaving wrong, as usual).
If so, you may want to code the code, removing the classic redirect, and just left the header() one:

header('HTTP/1.1 '.$status.' '.$status_definitions[$status]);
      header('Status: '.$status);
      header('Location: '.$url);
      header('Connection: close');
      header('Content-Length: 0');
      exit(0);

Textpattern CMS

Textpattern CMS support forum

#541 2010-09-10 06:28:36

Re: gbp_permanent_links

#542 2010-09-14 14:44:52

Re: gbp_permanent_links

#543 2010-09-14 15:03:07

Re: gbp_permanent_links

#544 2010-09-14 15:12:25

Re: gbp_permanent_links

#545 2010-09-15 01:17:21

Re: gbp_permanent_links

#546 2010-09-24 04:18:27

Re: gbp_permanent_links

Edit: It almost definitely has to do with the logic in the cleaver partial match tests.

#547 2010-10-01 09:36:25

Re: gbp_permanent_links

#548 2010-11-03 22:47:53

Re: gbp_permanent_links

#549 2010-11-14 22:29:28

Re: gbp_permanent_links

#550 2010-11-23 04:47:24

Re: gbp_permanent_links

#551 2010-12-01 22:18:09

Re: gbp_permanent_links

#552 2010-12-02 17:30:25

Re: gbp_permanent_links

Board footer