smd_short_url: tiny/canonical URLs

Bloke · 2009-09-17 07:35:58

v0.21 is posted thanks to The Blue Dragon letting me diagnose this one. It appears that under some circumstances (as yet undetermined) the header() function is just ignored. Until I can find out why I’ve issued 0.21 as a kludgefix which simply does some extra header setting to keep IE happy and then falls back on a stupid HTML redirect in the event the header method fails.

If anyone knows why header() fails sometimes and is simply skipped over, please feel free to enlighten me. Ta!

Gocom · 2009-09-17 15:34:44

Bloke wrote:

If anyone knows why header() fails sometimes and is simply skipped over, please feel free to enlighten me. Ta!

From URL perspective, if there is encoded special chars. But as it is non-messy url, there shouldn’t be anything to encode. Altho permlinkurl_id() outputs encoded URLs.
Fcgi + ob_ + redirect +/- space somewhere + trying to reset the status.
ob_end_clean()/ob_start() problems.

Um, does it work if you directly redirect w/o ob_end_clean()?

Bloke · 2009-09-17 22:25:47

Gocom wrote:

if there is encoded special chars… permlinkurl_id() outputs encoded URLs.

Didn’t know that; worth knowing thanks. In this case it wasn’t that, but it might be that in future on someone else’s system.

Fcgi + ob_ + redirect +/- space somewhere + trying to reset the status.

Could be. What confused me was that it worked on my dev site but not on my live stefdawson.com site; both on the same server. Thus I think it’s something in the way TXP is set up that’s triggering it to work or not. On my live site it may be the tonne of .htacess rules so I can’t really test it properly there.

does it work if you directly redirect w/o ob_end_clean()?

Nope. I tried that :-( Even tried hard-coding it like this with nothing else in the plugin:

header("Location: http://site.com/articles/article-name");

and no dice. Freaky. I tried flushing the buffer afterwards as well. I totally don’t get it…

brendstrup · 2009-11-04 09:08:00

This is a great plugin! One small request:

Is there any way to easily make it generate www-free URLs? I’d like to continue using www.domain.com for the actual site, but to generate the shortest short-URLs possible, I’d like to use only domain.com for that. I already have the server setup to redirect to www, so that should work fine.

Gocom · 2009-11-04 10:46:19

brendstrup wrote:

Is there any way to easily make it generate www-free URLs?

You can just simply link to example.com/article-id.

brendstrup · 2009-11-04 14:36:36

Gocom wrote:

You can just simply link to example.com/article-id.

I have tried that, but it doesn’t work, oddly enough. I think it might be a problem with the site’s .htaccess rules. I just discovered that if I edit an url like www.domain.com/section/page to domain.com/section/page (i.e. remove the subdomain), the page that loads is www.domain.com/index.php/page, which gives an error.

This isn’t a Textpattern error that any of you know about, is it? I assume it’s local .htaccess trouble, in which case I’ll have to tinker a bit.

Edit 10.11.20009: I fixed the .htaccess-problems and now I can indeed just link to example.com/article-id. Thanks for the help!

Last edited by brendstrup (2009-11-10 12:57:30)

monkeyninja · 2010-03-21 17:07:13

Just because this plugin is great and a number of people asked for it I’ve added support for smd_short_url to the latest release of arc_twitter.

Christoph · 2010-06-21 14:07:39

I found out that using smd_short_url together with MLP causes problems.
Using http://domain.com/35 won’t redirect to the article with ID 35.
I’m using the languages English and German and as every article has a unique ID I thought it shouldn’t be a problem. Is there a way to fix it?

maniqui · 2010-12-01 18:28:46

(Not so) quick and (not so) short report:

smd_short_url & gbp_permanent_links (gbp_p_l from now on) are not playing nicely together anymore.
Probably, the friendship broke on smd_short_url v0.2 release, when the register_callback changed from textpattern to txp_die.

I would say that the fix probably should be addressed on gbp_p_l side, but anyway, I’ll start reporting it here, and then linking here from gbp_p_l thread.

Background

On a TXP 4.3.0 installation, we’ve both plugins running from plugin_cache_dir.
When trying to access to a short URL (ie. domain.com/45), nothing happens, and we got stuck on the homepage. A 404 is not issued, so we know “something” is happening/working on the background, but not in the proper way.

First attempt to fix it: renaming smd_short_url to be loaded before gbp_p_l. (FAIL)

As plugins are running from filesystem, the order option is not available. The workaround to this lack of ordering is renaming one of the plugins to be alphabetically loaded before the other.
Thus, I renamed smd_short_url to aaa_smd_short_url, but no luck.

Second attempt: adding a register_callback to aaa_smd_short_url. (SUCCESS)

Now, with the plugin already loading before gbp_p_l, I tried (as per this post) by adding this line, below the other line for register_callback (for txp_die):
register_callback('smd_short_url', 'textpattern');

Yeah, this worked!
Now an smd_short_url will properly redirect to the corresponding TXP built-in URL (ie: domain.com/45 to domain.com/section/title).
At this point, it’s important to clarify something. Our friend pieman reported that adding the register_callback made smd_short_url play nicely with gbp_p_l. But, as per a quick chat I’ve got with him, I think it’s important to clarify this: as far as he can recall, at that time, smd_short_url will just redirect to the TXP built-in URL, not to a gbp_p_l crafted URL. In other words, pieman’s report at that time wasn’t totally accurate. Yeah, the plugins worked together, but smd_short_url didn’t go as far as redirecting to a gbp_p_l URL.

That’s ok, that’s not a problem, imho. I wouldn’t expect smd_short_url to be too clever. In the other hand, gbp_pl doesn’t work that way either: it can be used to handle rewrites and redirects, but won’t do a redirect by default.
No problem is you don’t follow me here: taming gbp_p_l is a science on its own.

Third attempt: renaming aaa_smd_short_url back to smd_short_url (FAIL)

Now that I’ve got the register_callback in place, and things were working as expected, I tried renaming the plugin back to its original name. But that didn’t work.

Fourth attempt: addressing this on gbp_p_l

Then, I tried to address this issue directly on gbp_p_l, while keeping smd_short_url using its original name (that is, smd_short_url_v0.21.php)

The only working combination I found was:

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); and…
on smd_short_url, keep the added line (register_callback('smd_short_url', 'textpattern');, see Attempt n.2 above)

But being that gbp_p_l is a far more complex plugin than smd_short_url, I decided to keep the solution on Attempt n.2, as I don’t know if the change on gbp_p_l won’t be breaking other gbp_p_l stuff.

I’m happy that, at least, things are working and smd_short_url and gbp_p_l are playing nice together again.
But I’m not too happy about having to run a modded&renamed version of smd_short_url. Not happy either about knowing that I may probably have lose some performance by adding (not changing) back the register_callback('smd_short_url', 'textpattern'); to smd_short_url code.

Now, let’s head to the gbp_p_l thread.
BTW: while doing all this R&D jugglery, I found out that it’s possible to recreate smd_short_url behavior using “just” some gbp_p_l rules (well, one rule per section, so it’s not as good as smd_short_url…).

Edit: fixing some content missing because of wrong use of Textile.

Last edited by maniqui (2010-12-04 18:59:32)

maniqui · 2010-12-01 23:42:35

I’ve also noticed, by playing with wget in the command line, that a second request to a smd_short_url, on a site running asy_jpcache, gets a shor file with the <html><head><META... /></head><body></body></html>.

It seems then, that even if header() is working (which I previously confirmed by commenting out the corresponding code on smd_short_url, that is, the fall back to a classic redirect), the plugin execution reaches the fall back code, and it generates the HTML code, which then is cached (and serverd) by jpcache.

Thus, on a second request to the same page, I’m not sure if the redirect is being done by header() on smd_short_url, or by the short HTML file served by asy_jpcache (which contains the classic redirect code generated by smd_short_url).

I wonder if plugin would benefit for doing some conditionals to test if header works/worked, and thus, avoiding the unnecessary output of the classic redirect (and, also, avoiding jpcache cacheing it).
I’ve seen other plugins (gbp_admin_library, zem_contact_reborn) that test for the presence/emptiness of some $_SERVER variables related to FCGI, to decide if they should use header() or classic HTML redirect.
But I must also say that I’ve noticed some false positive in a certain server: the header() redirect would work, but because of the testing I mentioned returned false, the classic redirect was taking place.

Bloke · 2010-12-02 00:24:48

Thanks for the detailed reports, maniqui.

Yep, gbp_pl and smd_short_url may need to climb in bed together and sleep soundly. How that happens I’m not not best placed to understand since I’m a true novice at gbp_pl.

You’re right that smd_short_url is not very bright. It purely runs when a 404 is triggered and checks to see if the URL matches site.com/some-numeric-id. If not it bails out. If so, it looks up the article ID, grabs the official TXP permlink and redirects to it.

Now, the redirect itself is interesting as you found out in your second post. In theory it should only require a call to header(). But for some reason, even after flushing the buffers, the headers are occasionally already sent or (usually in the case of IE) the header() call fails for reasons best known to Micro$oft. I tried to be as defensive as I could, adding unnecessary headers and things to try and make all browsers happy but this is perhaps false nirvana. Hence the fallback of a classic redirect.

In theory, if the header() succeeds the fallback should never run so a cache won’t ever see the code and thus the document will never be cached. The problem with theory is that it always finds a way to catch you out in practice. Unfortunately for us, header() returns void so there’s no way to gauge success or not. The only way to know it failed is if it executes the next line of code :-|

So, to summarise, I don’t know if there’s much I can do about either issue right now, sorry. Nor can I advise if your mods will have any adverse effects, due to my lack of permanent-link-fu. Certainly running smd_short_url on the textpattern event isn’t particularly efficient because it’ll unnecessarily run the regex on every URL hit. But it will work just fine and simply fail silently on 98% of calls. I have no idea why you need to register the callback on both events though. From what I can tell the error pages are processed after the textpattern callback point: they bail out immediately afterwards. Will need to check the core more thoroughly to figure it out.

I’ll see if I can bash heads with graeme on this one.

maniqui · 2010-12-04 19:03:13

Hi Bloke
thanks for the reply.
Please, if possible, take a second read at my original post because it wasn’t until today that I noticed it was badly mangled (I used h3. which seems to be hidden here at forum).
So, a new read may give you a more few insights, because my post now probably makes more sense.

Another discovery: smd_short_url won’t test if the article is live/status/draft/hidden/pending, so visitor may get redirected to a 404 page (which is correct), and in the URL bar, the article_url_title will be displayed (which may not be desirable at all…).

Thanks.

Textpattern CMS

Textpattern CMS support forum

#25 2009-09-17 07:35:58

Re: smd_short_url: tiny/canonical URLs

#26 2009-09-17 15:34:44

Re: smd_short_url: tiny/canonical URLs

#27 2009-09-17 22:25:47

Re: smd_short_url: tiny/canonical URLs

#28 2009-11-04 09:08:00

Re: smd_short_url: tiny/canonical URLs

#29 2009-11-04 10:46:19

Re: smd_short_url: tiny/canonical URLs

#30 2009-11-04 14:36:36

Re: smd_short_url: tiny/canonical URLs

#31 2010-03-21 17:07:13

Re: smd_short_url: tiny/canonical URLs

#32 2010-06-21 14:07:39

Re: smd_short_url: tiny/canonical URLs

#33 2010-12-01 18:28:46

Re: smd_short_url: tiny/canonical URLs

Background

First attempt to fix it: renaming smd_short_url to be loaded before gbp_p_l. (FAIL)

Second attempt: adding a register_callback to aaa_smd_short_url. (SUCCESS)

Third attempt: renaming aaa_smd_short_url back to smd_short_url (FAIL)

Fourth attempt: addressing this on gbp_p_l

#34 2010-12-01 23:42:35

Re: smd_short_url: tiny/canonical URLs

#35 2010-12-02 00:24:48

Re: smd_short_url: tiny/canonical URLs

#36 2010-12-04 19:03:13

Re: smd_short_url: tiny/canonical URLs

Board footer