Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

radneck
Plugin Author
Registered: 2005-07-03
Posts: 109

Re: gbp_permanent_links

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)

Offline

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

andreas
Member
Registered: 2004-02-28
Posts: 453
Website

Re: gbp_permanent_links

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.

Offline

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

hablablow
Member
From: Paris
Registered: 2004-12-13
Posts: 309
Website

Re: gbp_permanent_links

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


_
_I plant seeds for future visions. Farmer of your eyes. Subliminal engineer of your minds. eion founder__

Hablablow + Webdesignofficina

Offline

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

hablablow
Member
From: Paris
Registered: 2004-12-13
Posts: 309
Website

Re: gbp_permanent_links

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 !


_
_I plant seeds for future visions. Farmer of your eyes. Subliminal engineer of your minds. eion founder__

Hablablow + Webdesignofficina

Offline

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

radneck
Plugin Author
Registered: 2005-07-03
Posts: 109

Re: gbp_permanent_links

Thanks very much Andreas, perfect.

Offline

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

radneck
Plugin Author
Registered: 2005-07-03
Posts: 109

Re: gbp_permanent_links

Graeme,

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

Problem can be reproduced by:
  1. Starting with fresh 4.2.0 install
  2. Upload and activate gbp_permanen_links (and gbp_admin_library obviously)
  3. Add the site-wide rule section/category/title
  4. Add a new article called ‘about’ in the section ‘about’ and give it a category
  5. 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)

Offline

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

jodeci
Member
From: Taipei
Registered: 2008-01-13
Posts: 38
Website

Re: gbp_permanent_links

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!

Offline

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

smd_ksu
Member
Registered: 2008-12-23
Posts: 25

Re: gbp_permanent_links

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

Offline

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

els
Moderator
From: The Netherlands
Registered: 2004-06-06
Posts: 7,458

Re: gbp_permanent_links

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).

Offline

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

radneck
Plugin Author
Registered: 2005-07-03
Posts: 109

Re: gbp_permanent_links

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.

Offline

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

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: gbp_permanent_links

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.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

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

maniqui
Member
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 3,070
Website

Re: gbp_permanent_links

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);

La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB