Textpattern 4.8.2 is nearly ready

phiw13 · 2020-07-18 06:19:49

etc wrote #324636:

I am for replacing Категория with category though, but rather in 4.9.

Bloke wrote #324638:

+1

-100…

People actually use non-ASCII category and author URI. On real-world sites, pages that are referenced (linked-to) by other sites.

Bloke wrote #324660:

It will be fixed. For now, from 4.8.2, you can use either IF you build the links by hand. But the tags will still generate localized URLs (for now). We’ll probably introduce a pref in future to ease transition for those that want to migrate away from the localized URLs.

You had some interesting propositions on the relevant Github thread. Since I am on a different device and not in the mood to go through the silly make-believe GH authentification checks, I’ll post an answer here.

b) permit both English and localized hooks, and either:
—> permlinks are generated in one of the two schemes depending on a pref (which requires new translation strings and a new pophelp: kinda late in the day to be doing this for 4.8.2).
—> defer the decision on which scheme to use to the tag level, e.g. introduce a lang attribute on <txp:category_list> and <txp:author_list> and all such tags that create hard-coded links via pagelinkurl(). Passing this $lang forward to pagelinkurl() would enable us to override the URL component to a given language. Default: front-end site language, same as today.

The first option has one plus, that is the simplicity of it (click a radio button, save and done). At the same time it is a weakness, solved by your second option, the introduction of a lang attribute. This offers the (tantalising !) possibility of fine grained control, e.g. localised category but author and file_download are in English. I kinda like the chaos that this offers. :-)

BTW – how about flipping the logic: default is English, an eventual lang attribute would use the $site_language.

PS. And, that is stuff for TXP 4.9, I would humbly suggest. May I suggest to try land a fix relatively quickly, leaving time to thoroughly test the new possibilities? TY.
And broadcast it in advance, so that sites that do like / use internationalised URI have time to adjust (adding the attribute in their templates or evaluate the pref and see how to adjust)

Last edited by phiw13 (2020-07-18 06:23:22)

Bloke · 2020-07-18 11:09:14

phiw13 wrote #324671:

The first option has one plus, that is the simplicity of it (click a radio button, save and done). At the same time it is a weakness, solved by your second option, the introduction of a lang attribute. This offers the (tantalising !) possibility of fine grained control, e.g. localised category but author and file_download are in English. I kinda like the chaos that this offers. :-)

I initially thought about one or the other, but you’re right that both is actually way better.

Project (far) into the future when we have true multilingual content. Having a lang attribute for each *_list tag would mean we could actually serve the default case as “the language you are currently viewing” (in today’s world, that’s just one: the current site language). Thus if you choose to view the site content in German, when you browse the category list, your category URL hooks are, by default, in German IF:

You have the Use localized language hooks pref (or whatever it’ll be called) switched on; and
You have not overridden the language explicitly with your own lang attribute in your <txp:category_list> tag.

Is that desirable? Maybe. You’re potentially serving a different list of articles (maybe not all articles are translated; maybe they all are) in a different language so having a different URL make sense from a search perspective. Search engines can index the different language versions with their unique URLs in a local language if you wish. No harm, no duplicate content.

Of course, you may elect to serve example.org/de/category/some-cat instead, but that’s your choice. The point is, as you say, it allows a greater degree of control over your content and URL handling without too much burden on the admin’s behalf.

You want localized URLs per language content? Fine. Set the pref to localized, done.
You want English URLs for language content? Fine. Set the pref to English, done.
You want just author URLs to be in Italian? Fine, set the lang attribute of the <txp:authors> tag accordingly (or build the links yourself in its container).

how about flipping the logic: default is English, an eventual lang attribute would use the $site_language.

That would work, but break existing sites. The softly-softly approach is:

For upgrades: set the use localized pref ON. Thus, no change from what we have now because the lang attribute in all tags uses current site language by default. Flick pref if desired to switch to English.
For new installs: set the use_localized pref OFF. i.e. English URLs by default. Opt-in if you want them all localized.

And for both the above, individual lang attributes permit you to choose on a per tag basis.

May I suggest to try land a fix relatively quickly, leaving time to thoroughly test the new possibilities?

Yes, definitely. It always gets to this stage in testing and we go “D’oh, forgot about it. Too late to fix it now”. I’ll make it a priority for dev 4.9 branch as soon as 4.8.2 is out the door.

phiw13 · 2020-07-20 04:35:45

Bloke wrote #324675:

Project (far) into the future when we have true multilingual content. […]

Of course, you may elect to serve example.org/de/category/some-cat instead, but that’s your choice. The point is, as you say, it allows a greater degree of control over your content and URL handling without too much burden on the admin’s behalf.

I knew there was something on the back of my mind with that lang attribute, but did not want to admit it to myself or certainly not voice it, even softly softly. somewhere we are on the same wavelength there.

I initially thought about one or the other, but you’re right that both is actually way better.
[…]

Yes, definitely. It always gets to this stage in testing and we go “D’oh, forgot about it. Too late to fix it now”. I’ll make it a priority for dev 4.9 branch as soon as 4.8.2 is out the door.

good, so there we have good starting point for TXP.next. And it will make some people happy.

gaekwad · 2020-07-20 09:06:15

So, getting us back to the gist of the thread…

Textpattern 4.8.2 is nearly ready. The issue queue for it shows zero outstanding issues. Anything mentioned here that needs to be fixes for 4.8.2 needs to go into that queue so we can track it.

Barring any blockers or outstanding stuff, we will then release Textpattern 4.8.2 and you can all compose the best gosh darned content ever. Deal?

colak · 2020-07-20 09:25:34

I’m still testing section specific searches but the desired results are not returned. Give me another couple of days on this. Re yield, all works fine in the way I use it.

gaekwad · 2020-07-20 09:51:02

colak wrote #324700:

I’m still testing section specific searches but the desired results are not returned.

What are you trying, and what are you getting?

colak · 2020-07-20 10:20:01

I’m trying to get section specific results only. See here

zero · 2020-07-20 14:07:28

Might be relevant to 4.8.2

In 4.8.1 I did this:

altered four-point-eight theme forms, pages and styles to my needs
then changed the name of the theme to mytheme
exported mytheme to disk
copied it to a themes folder in a new install
imported it no problems

But returning to original install, when trying to open any form, page or style, I get a blank page.

Yes I shouldn’t have changed the name and should have created a new theme as a duplicate of four-point-eight at the start and edited that one.

But perhaps there should be some safeguard against deleting the four-point-eight theme.

Last edited by zero (2020-07-20 14:07:58)

gaekwad · 2020-07-20 14:11:02

zero wrote #324713:

In 4.8.1 I did this:

altered four-point-eight theme forms, pages and styles to my needs

then changed the name of the theme to mytheme

[…]

But returning to original install, when trying to open any form, page or style, I get a blank page.

Did you change the name back on the original site? Is it looking for four-point-eight and not finding it?

zero · 2020-07-20 14:14:33

gaekwad wrote #324714:

Did you change the name back on the original site? Is it looking for four-point-eight and not finding it?

No I didn’t change the name back. I’ve now re-imported mytheme from the new site and now I can see both themes’ pages, forms and styles – mytheme and mytheme2 (had to change json manifest themename for it to work)

colak · 2020-07-21 18:08:19

I just installed the latest dev from github and noticed a lot of errors on debugging mode and some on testing. It’s getting late here so I’ll have to come back with more details tomorrow.

philwareham · 2020-07-21 22:12:21

Pretty sure you need to be testing 4.8 not Dev branch?

Textpattern CMS

Textpattern CMS support forum

#25 2020-07-18 06:19:49

Re: Textpattern 4.8.2 is nearly ready

etc wrote #324636:

Bloke wrote #324638:

Bloke wrote #324660:

#26 2020-07-18 11:09:14

Re: Textpattern 4.8.2 is nearly ready

phiw13 wrote #324671:

#27 2020-07-20 04:35:45

Re: Textpattern 4.8.2 is nearly ready

Bloke wrote #324675:

#28 2020-07-20 09:06:15

Re: Textpattern 4.8.2 is nearly ready

#29 2020-07-20 09:25:34

Re: Textpattern 4.8.2 is nearly ready

#30 2020-07-20 09:51:02

Re: Textpattern 4.8.2 is nearly ready

colak wrote #324700:

#31 2020-07-20 10:20:01

Re: Textpattern 4.8.2 is nearly ready

#32 2020-07-20 14:07:28

Re: Textpattern 4.8.2 is nearly ready

#33 2020-07-20 14:11:02

Re: Textpattern 4.8.2 is nearly ready

zero wrote #324713:

#34 2020-07-20 14:14:33

Re: Textpattern 4.8.2 is nearly ready

gaekwad wrote #324714:

#35 2020-07-21 18:08:19

Re: Textpattern 4.8.2 is nearly ready

#36 2020-07-21 22:12:21

Re: Textpattern 4.8.2 is nearly ready

Board footer