Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2017-12-08 02:54:09

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,226
Website

Re: Fatal error when I upgrade a 4.7 dev site with plugins

I thought my ears were burning!

etc wrote #308123:

I guess we’d better leave global $textarray there for one more dev cycle, the time to test possible solutions.

Thank you throwing me a lifebelt.

Bloke wrote #308121:

Adi’s plugins – as far as I recall – all bundle Textpacks inside the plugin in a different manner to the way core handles them. That’s the crux of the issue. When you install the plugin, he uses the internal strings to give you a working UI and then encourages you to install the strings “properly” from his site via the plugin Options.

The pertinent bit being “he uses the internal strings to give you a working UI” – and most importantly both for cached and “installed” plugins.

Now (from 4.7.0) core support has evolved somewhat. So in future, Adi won’t – at least, shouldn’t – need to do the self-install Textpack dance, because core will load all known (at the time) Textpacks into the database and keep them there, just in case.

Could you clarify this bit please? Does it mean that text strings in cached plugins will now be loaded automatically?

Offline

#12 2017-12-08 10:56:33

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

Re: Fatal error when I upgrade a 4.7 dev site with plugins

gomedia wrote #308180:

The pertinent bit being “he uses the internal strings to give you a working UI” – and most importantly both for cached and “installed” plugins.

Yes, that’s something we need to test more. Installed plugins might need a bit of extra thought here, but if they contain the Textpack translation strings in the header area of the plugin, we should be able to extract those and inject them into the local language table on an as-needed basis when the plugin runs.

Does it mean that text strings in cached plugins will now be loaded automatically?

Here’s what happens now:

  1. Plugin author writes a plugin and bundles all known Textpacks into the plugin at that time, in $plugin['textpack']. Each lang block must be prefixed by a valid ‘@language’ code — all of which have changed in this release to “super-short” codes where possible, e.g. ‘da-dk’ => ‘da’. But variants still retain their full designation (e.g. ‘en-gb’ is distinct from ‘en-us’).
  2. People install the plugin into the database.
  3. The entire Textpack array – for all languages that the plugin has packs for – is stored internally in the txp_plugin table (a new column). For safekeeping.
  4. Any language that is currently installed in Txp – for front of house, or for admin side – will be automatically updated at plugin install time. So strings matching those languages from the plugin Textpacks are installed right out of the gate automatically.
  5. If at any point in future an admin installs a new language or updates an existing language, all installed plugins are checked at that point. If there are any strings that were bundled with the plugin in that language, they will be automatically installed too.
  6. If you install a language that does not have a representation inside the plugin, its strings obviously can’t be brought into the database. BUT we now have the notion of fallback strings so if the language isn’t installed, the strings from the default language (as defined in config.php – or en if not specified) will be used instead for that language. So if you installed Norwegian, any strings that weren’t defined would be in English. This may apply to plugins too, but I’m not sure yet if that bit’s taken care of. Limited test data. It’s certainly the plan.

I want the above to apply to ‘installed’ plugin cache files too, so when it loads the plugin it’ll see the lang strings in $plugin['textpack'], but instead of ‘installing’ them in the database it just adds the ones from the current language to the Lang object on-the-fly, so the system knows about them and can therefore render the UI properly. It might do that already, I haven’t checked recently.

Howzat?


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

#13 2017-12-08 23:33:17

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,226
Website

Re: Fatal error when I upgrade a 4.7 dev site with plugins

Just to confirm – at the moment (latest 4.7.0-dev) plugins loaded from the Plugin Cache don’t have their textpack strings loaded and available … but it’s something that you’re looking to implement?

Offline

#14 2017-12-09 08:54:08

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

Re: Fatal error when I upgrade a 4.7 dev site with plugins

gomedia wrote #308195:

Just to confirm – at the moment (latest 4.7.0-dev) plugins loaded from the Plugin Cache don’t have their textpack strings loaded and available … but it’s something that you’re looking to implement?

Yes. I’ll get onto it once I’ve fixed the language auto-update thing. Thanks for testing.


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

#15 2018-03-08 22:30:30

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,226
Website

Re: Fatal error when I upgrade a 4.7 dev site with plugins

Hi Stef,

Just playing with 4.7.0-beta & Textpacks & cached plugins.

Should it be loading language strings “on-the-fly” from cached plugins?

Offline

#16 2018-03-08 23:23:10

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

Re: Fatal error when I upgrade a 4.7 dev site with plugins

gomedia wrote #309784:

Should it be loading language strings “on-the-fly” from cached plugins?

Yes. I take it you aren’t seeing that?

A few gotchas:

  1. The language designators have all changed. Most are much shorter with only two chars.
  2. You can no longer get away with leaving the first language “empty” (no language designator) and have it pick up the currently in-use language. You must specify a designator for each language in the pack. But (in theory) all strings should “fall back” on en so ensure you have strings for that language defined.

It was working for me a few weeks ago, but I haven’t tried it since. Guess I should, just in case we broke something.

EDIT: The jury’s out on what happens if you’ve overridden the default fallback language in config.php, btw. It should fall back on that language if the strings are defined in the plugin in that language. If not, well, you’ll get raw strings out.

Last edited by Bloke (2018-03-08 23:26:28)


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

#17 2018-03-08 23:34:48

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,226
Website

Re: Fatal error when I upgrade a 4.7 dev site with plugins

Bloke wrote #309794:

Yes. I take it you aren’t seeing that?

Not working for me so far, but all’s to play for. Leave it with me.

Tried adding “#@language en-gb” didn’t seem to help – I didn’t use it initially coz com_connect didn’t have one. Assumed that it would “assign to default language”.

Offline

#18 2018-03-08 23:46:24

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,226
Website

Re: Fatal error when I upgrade a 4.7 dev site with plugins

Have realised that I should probably be using “en” anyway. But this is not working for a cached plugin:

$plugin['textpack'] = <<<EOT
#@admin
#@language en
adi_admin_plugin_admin => An Admin Plugin std
EOT;

If I load the plugin normally, the language string is loaded into txp_lang and used.

BTW is #@admin, #@public compulsory?

Offline

#19 2018-03-09 00:00:19

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

Re: Fatal error when I upgrade a 4.7 dev site with plugins

gomedia wrote #309798:

I didn’t use it initially coz com_connect didn’t have one.

com_connect’s wrong and needs updating!

Assumed that it would “assign to default language”.

See, this is where things get tricky. What’s the “default language” in a multi-user setup where each user can have the UI in their own language? There isn’t a default. Hence, we made it so you have to specify one for every pack.

Well, okay, it’s not hardcore enforced and it might silently default to either a) your current admin-side language, or b) the fallback language, or it might just ignore the pack completely without a language designator. Honestly, I’ve flip-flopped on this so many times over the past six months I’ve forgotten what actually happens now :-) Will have to look it up, sorry.


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

#20 2018-03-09 00:13:48

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

Re: Fatal error when I upgrade a 4.7 dev site with plugins

gomedia wrote #309800:

BTW is #@admin, #@public compulsory?

Yes, it’s the event to which the plugin string is defined. There’s one other gotcha I forgot to mention above: Language strings are now only loaded if their event matches the current panel’s event name.

So if you want them to appear on the adi_matrix panel they MUST be in the ‘#@adi_matrix’ group. If you specify ‘#@admin’ they’ll only be loaded on the users (a.k.a. authors) panel (yeah, I know, legacy naming conventions pffftt).

There are special events:

  • ‘#@public’ are loaded on the public site only.
  • ‘#@admin-side’ are loaded on all admin panels.
  • ‘#@common’ are loaded on the public site and the all admin panels, i.e. everywhere.

Given those limitations, you might think it safe to stick them all in ‘common’ and be done with it. Well, yes, you could. But the whole point of doing this is to try and limit the amount of memory usage on each page. In 4.6, every page loaded 1100+ strings from the database. In 4.7, it’s a fraction of that. So in the interests of performance, we’ll be encouraging plugin authors to stick the strings in the appropriate groups.

There’s a lifeline at the moment insofar as all plugin strings – those with an owner – are loaded everywhere. So stick an ‘#@owner’ designator and give it your plugin’s namespace (or, heck, just give them all adi as an owner if you want them all to be owned and managed by you as a big group). Whether any of that works or means that deleting one of your plugins removes the strings from all of them, I can’t recall. We really need to document this stuff…

Right now I can’t say if this lifeline will stick, but it’ll be here for probably the next version at least before we enforce the lang strings to load on their designated panels only.


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

Board footer

Powered by FluxBB