Textpattern Forum

You are not logged in. Register | Login | Help

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

maniqui
Moderator
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 2,985
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
Moderator
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 2,985
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

#553 2010-12-08 05:32:08

mericson
Member
Registered: 2004-05-24
Posts: 121
Website

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

I’m encountering the same problem, anyone investigating a patch? I sure hope I don’t have to go through my site pages and forms to accomplish the workaround.

Offline

#554 2010-12-08 05:57:19

cain-mi
Plugin Author
Registered: 2005-07-03
Posts: 101
Website

Re: gbp_permanent_links

mericson wrote:

I’m encountering the same problem, anyone investigating a patch? I sure hope I don’t have to go through my site pages and forms to accomplish the workaround.

Well I’ve been using this replacement for if_category.
Install, activate and replace instances of <txp:if_category></txp:if_category> with <txp:esq_ifcategory /></txp:esq_ifcategory>.

Bit of a hack, but works for me (I’m using /section/category/title).

No guarantee, but let me know how you go.

Cheers,
cain-mi

Last edited by cain-mi (2013-10-10 05:46:26)

Offline

#555 2010-12-08 06:27:04

mericson
Member
Registered: 2004-05-24
Posts: 121
Website

Re: gbp_permanent_links

cain-mi wrote:

Well I’ve been using this replacement for if_category.
Install, activate and replace instances of <txp:if_category></txp:if_category> with <txp:esq_ifcategory /></txp:esq_ifcategory>.

I realized that I could accomplish the same with a plugin I already have installed, smd_if and it works around the issue also.

Odd and frustrating that the gbp_permanent_links breaks standard tag if_category, but not this plugin tags that you would think are doing the same thing.

Offline

#556 2010-12-08 06:37:14

cain-mi
Plugin Author
Registered: 2005-07-03
Posts: 101
Website

Re: gbp_permanent_links

mericson wrote:

Odd and frustrating that the gbp_permanent_links breaks standard tag if_category, but not this plugin tags that you would think are doing the same thing.

I think it only stopped working with the update from 4.2.0 to 4.3.0 due to some deprecated functionality in TXP.
The plugin I posted is essentially the same as the core functionality, but still checks the deprecated variable (can’t be sure, but IIRC $pretext[‘c’]) as well.

gbp_pl didn’t break it, it just doesn’t fix (for want of a better word) it with 4.3.0.

Its my (vague) understanding that a new version of this plugin is being worked on at the moment, not sure when it will be released however.

Offline

#557 2010-12-17 18:55:49

maniqui
Moderator
From: Buenos Aires, Argentina
Registered: 2004-10-10
Posts: 2,985
Website

Re: gbp_permanent_links

Quick tip:
you can recreate the smd_short_url functionality just creating, at least, two rules with gbp_permanent_links.

These tutorial is based in that you use/like the /section/title/ style of permanent links, but it should work for other URL schemes too.
Here are the steps:

1) Build a permanent link rule with just the section/ and title/ components. Under the “Settings” panel, name it: Z: basic permlink.

Of course, you can use any other name you like. The important part is that it should begin with a Z (or any other letter that would put this rule at the very bottom on the list of permanent link rules).
This is because it seems that the name sorting of your permanent link rules have effect on how the rules are applied.
In any case, this should matter only if you have other redirects that may not get executed if this redirect we are creating comes first on the list of permanent link rules.

2) Build another permanent link rule. This time, there is just one component you need: id/. Now, to finish, On the “Destination” panel, you need to click on the “Permanent link” drop down menu (under Redirect this permanent link to…)
There, you have to select the permanent link we created in step 1 (Z:…). Save it.

That’s all!
Test it: if you visit an URL like http://www.example.com/5, you should be redirected to the correspondent permanent link (http://www.example.com/section/title) for that article.


La música ideas portará y siempre continuará

TXP Builders – finely-crafted code, design and txp

Offline

#558 2011-02-10 06:02:09

jwoldan
New Member
Registered: 2011-02-10
Posts: 4

Re: gbp_permanent_links

Hi. I’m relatively new to Textpattern and trying to use this plugin to prevent overlapping URLs in a fairly simple URL scheme.

The scheme I’d like to use is /section/year/month/title- this ought to be sufficient to prevent any two articles with the same title from sharing the same URL. The problem I’m finding is that the URLs for two different articles with the same title, even in different months, are pointing to the same article content.

Is there a way to fix this?

In case these details help with a diagnosis: I’m currently using the /section/id/title permanent link mode in the standard Textpattern preferences, and to test this, I’ve manually set a timestamp to the past month on one of the articles. I’ve also been using the asy_jpcache plugin, but it’s disabled at the moment.

I’ve skimmed through a bunch of this thread and haven’t seen anyone addressing this issue, sorry if I missed it.

Any help would be much appreciated.

Offline

#559 2011-02-11 01:55:42

jwoldan
New Member
Registered: 2011-02-10
Posts: 4

Re: gbp_permanent_links

Just a quick followup to my last post- got some help from the folks on #textpattern today, and for the time being, I’m using the build-in /year/month/day/title scheme for a couple sections on the site, and using the plugin to implement /section/title for other, more static sections.

Still trying to figure out how to use the redirect feature.

I’d love to customize more if the plugin could handle multiple articles with the same url-title better.

Offline

#560 2011-02-13 03:50:20

jwoldan
New Member
Registered: 2011-02-10
Posts: 4

Re: gbp_permanent_links

Ok, last post for now, but this is an exciting one: I’ve updated the plugin to support duplicate url-titles where a unique article can be determined by the date components of the URL. For example you could now have two articles as follows:

/section/2011/02/12/article
/section/2011/02/11/article

Previously the two permalinks would both map to the article content of only one of the two articles.

I’ve forked Graeme’s code on github, and I hope he can incorporate my code into the master, but until then you can download mine here: https://github.com/jwoldan/gbp_permanent_links

I should note that my version also restricts access to the plugin to privilege levels one and two (Publisher and Managing Editor).

Offline

Board footer

Powered by FluxBB