change how the URL for file dowload is generated?

phiw13 · 2018-02-28 09:02:20

For the background, see the last few post on the phw_sandspace thread

For a long time in the above thread, I’ve used the URL (TXP generated) domain.tld/file_download/1. But now we discovered that the generated URL is domain.tld/file+download/1. (substitute the actual ID for the file instead of “1”)

Before: /file_download/ and now /file+download/

Bloke · 2018-02-28 09:37:53

It’s a bug. It needs to be file_download or it won’t match downloads in publish.php and will serve 404s as you’ve witnessed.

What’s happened is that, somewhere along the line during the language changes, we’ve either introduced or unwittingly reused the file_download language string. For reasons I cannot recall, we pass file_download in the URL through gTxt() so it’s getting replaced into the local lingo, which includes a space, thus encoded as ‘+’.

I think this all stems back to our original premise that we just carried on from the inception of Txp: that a “localized” URL is somehow friendlier than one in English.

In today’s world of “nobody cares about the URL, just use a search engine” (however misguided that may be) is there a case to be made for going back on our vision and forcing all built-in URL components into English?

Problems:

a) Massively non-backwards-compatible.
b) Affects SEO. Suddenly after upgrade, all URL components change from (e.g.) example.org/kategorie/some-category to example.org/category/some-category.

Either way, we need a solution now. Options, either on their own or in combination:

(simplest) Alter the use of the file_download language string in core and call the key something else.
Don’t run URL file_download keys through gTxt(). See (a) and (b) above, although in this case I don’t think we ever had a gTxt() string defined for this in core, so the impact should be minimal-to-non-existent.
In tandem with option (1), introduce a setting “Localize built-in URL components”. Set it off by default for new installs. Leave it as-is for upgrades. Then perhaps encourage people to move away from them over time. SEO implications up to the administrator to manage.
Something else…?

Changing to non-localized strings for core URL components affects the following:

example.org/author
example.org/category
example.org/category/{context} (where context = localized version of ‘article’, ‘image’, ‘file’, or ‘link’)
example.org/file_download
example.org/section (I think this is actually a holdover from an ancient version: nobody uses the word section verbatim any more, right?)
plugins that rely on any localized URL fragments defined above (e.g. possibly smd_tags).

Thoughts?

etc · 2018-02-28 10:22:51

If I get it right, the problem arises for admin-side file download links when the admin user language is different from the public site language. Probably, the easiest solution is to accept both localized string and file_download in URL, and use file_download on the admin side?

Bloke · 2018-02-28 10:37:49

Well I’ve removed file_download from the textpacks for now. This string didn’t exist in previous versions and should not have been introduced, imo.

But the problem still remains that if someone does add it in future, or doesn’t delete it from their 4.7.0-dev, then file download links that are manually created will potentially break. Also, imagine if someone changes a translation of file_download for some reason. Or a translator for one of the new languages, adds the string. All links for everyone’s downloads (public and admin) in that language are changed immediately. SEO problem, plus breakage as jpdupont found with manually-created links.

I do agree however, that we should probably allow both translated and untranslated strings – at least for the time being – for all our built-in URL components. Then, at least it stops broken links being generated if a system uses a mixture (albeit it’s still a pain to have two potential download locations to the same file, but we have that now anyway with the /id and /id/filename ending up at the same point).

If you have an idea how to introduce a dual system without breaking anything and has minimal impact on processing time, then that’s porobably best. Failing that I’m fine with a pref as detailed above (although that’s another string to translate…).

Last edited by Bloke (2018-02-28 10:41:26)

etc · 2018-02-28 11:18:29

I’ve patched it temporarily for early 4.7 adopters, and agree that we should switch to some canonical URLs, especially if we make the public side multilingual one day.

Bloke · 2018-02-28 11:33:22

Nice, thanks. So simple.

We could extend this idea to category and author right now at minimum (still baffled what the section case is for) so people can at least use fixed-string URLs instead of being forced to use the translations. Would that cause problems, do you think?

Incidentally, the translation strings are in sentence-case: Category and Author in English, so URLs will get those unless we strtolower() them internally already. Haven’t checked.

Not sure what to do about the 4 type contexts. Would be nice to offer dual options for those too somehow. That gives us a nice migration path when we eventually switch to canonical URLs in future.

phiw13 · 2018-02-28 11:58:14

etc wrote #309505:

I’ve patched it temporarily for early 4.7 adopters, and agree that we should switch to some canonical URLs, especially if we make the public side multilingual one day.

Ok, so now when I look at the URL form the Files panels, I see /file_download/. But from the public side /file+download/. If I understand correctly, I need to go hunting in the DB to get rid of that ?

Bloke wrote #309506:

Nice, thanks. So simple.

We could extend this idea to category and author right now at minimum (still baffled what the section case is for) so people can at least use fixed-string URLs instead of being forced to use the translations. Would that cause problems, do you think?

Hmm, may need to get creative in the htaccess eventually. Not sure.

Incidentally, the translation strings are in sentence-case: Category and Author in English, so URLs will get those unless we strtolower() them internally already. Haven’t checked.

I get lowercase URLs domain.tld/author/Narcissus+Maximus and domain.tld/category/junk/ (en-gb).

Bloke · 2018-02-28 12:13:18

phiw13 wrote #309508:

Ok, so now when I look at the URL form the Files panels, I see /file_download/. But from the public side /file+download/. If I understand correctly, I need to go hunting in the DB to get rid of that?

Remove the file_download entry from the textpack(s) of your choice. Or just do it all in one go from your MySQL client of choice:

delete from txp_lang where name='file_download';

I get lowercase URLs domain.tld/author/Narcissus+Maximus and domain.tld/category/junk/ (en-gb).

Good to know, thanks. So we do lower-case stuff internally. That’s something.

phiw13 · 2018-02-28 12:17:50

Bloke wrote #309510:

Remove the file_download entry from the textpack(s) of your choice. Or just do it all in one go from your MySQL client of choice:

delete from txp_lang where name='file_download';…

Ok. will do when my head is a bit more rested :-)

ref lowercase URLs:

Good to know, thanks. So we do lower-case stuff internally. That’s something.

Check the links inside the article or in the article footer: https://emps.l-c-n.com/development/phw_sandSpace

etc · 2018-02-28 13:16:09

Should we switch to canonical URLs right now, still allowing for dual access? I would, but don’t know how that looks from the SEO POV.

Bloke · 2018-02-28 13:31:30

I’d like to use canonical URLs now too internally. Introducing localized contexts was something I wish I could go back in time and erase.

I guess search engines will quickly catch up – and the good news is that this only affects list pages. How many people allow search engines to cache them? If my sites do, it’s only by accident – if I remember, I turn search engine spidering off on landing pages.

We might just get away with it. But then, I’m an English-speaker so I’m biased. What say a few members of the international community?

phiw13 · 2018-02-28 23:40:12

Now update the Live site and all work fine with the good old /file_download/ URLs. And I successfully updated the txp_lang table in the DB to remove the file_download string.

Bloke wrote #309522:

I’d like to use canonical URLs now too internally. Introducing localized contexts was something I wish I could go back in time and erase.

Yeah, that would probably be nice. From a search engine perspective, I’m not sure how bad that would be for non-English users. It would not affect me, I think (or if needed it would probably be something that can be solved with a permanent redirect in the .htaccess, I’d have to check). But that is only one user…

Textpattern CMS

Textpattern CMS support forum

#1 2018-02-28 09:02:20