Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,625
Website

change how the URL for file dowload is generated?

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/

Offline

#2 2018-02-28 09:37:53

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: change how the URL for file dowload is generated?

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:

  1. (simplest) Alter the use of the file_download language string in core and call the key something else.
  2. 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.
  3. 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.
  4. 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?


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2018-02-28 10:22:51

etc
Developer
Registered: 2010-11-11
Posts: 3,122
Website

Re: change how the URL for file dowload is generated?

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?


etc_[ query | search | pagination | date | tree | cache ]

Offline

#4 2018-02-28 10:37:49

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: change how the URL for file dowload is generated?

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#5 2018-02-28 11:18:29

etc
Developer
Registered: 2010-11-11
Posts: 3,122
Website

Re: change how the URL for file dowload is generated?

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#6 2018-02-28 11:33:22

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: change how the URL for file dowload is generated?

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#7 2018-02-28 11:58:14

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,625
Website

Re: change how the URL for file dowload is generated?

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

Offline

#8 2018-02-28 12:13:18

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,620
Website

Re: change how the URL for file dowload is generated?

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#9 2018-02-28 12:17:50

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 1,625
Website

Re: change how the URL for file dowload is generated?

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

Offline

#10 2018-02-28 13:16:09

etc
Developer
Registered: 2010-11-11
Posts: 3,122
Website

Re: change how the URL for file dowload is generated?

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

Board footer

Powered by FluxBB