Fatal error when I upgrade a 4.7 dev site with plugins

gomedia · 2017-12-08 23:33:17

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?

Bloke · 2017-12-09 08:54:08

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.

gomedia · 2018-03-08 22:30:30

Hi Stef,

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

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

Bloke · 2018-03-08 23:23:10

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:

The language designators have all changed. Most are much shorter with only two chars.
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)

gomedia · 2018-03-08 23:34:48

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

gomedia · 2018-03-08 23:46:24

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?

Bloke · 2018-03-09 00:00:19

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.

Bloke · 2018-03-09 00:13:48

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.

gomedia · 2018-03-09 01:20:53

Bloke wrote #309804:

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

Ah, that explains the “event” comment in the zem_plugin.php.

Oops “admin” was a typo, I’ve changed it to “admin-side” viz:

#@admin-side
#@language en
adi_admin_plugin_admin => An Admin Plugin std

and still no joy. Tried using the plugin’s event to no avail. What am I missing?

gomedia · 2018-03-09 01:31:50

I’ve found the issue. The language string is translated on the plugin’s event page but not in the Extensions menu.

gomedia · 2018-03-09 01:45:36

… and a plugin that creates it’s own menu doesn’t get translated either (even though it’s using a standard language string):

register_tab('plugin_help','adi_plugin_help_admin',gTxt('plugin_help'));

- menu appears as “tab_plugin_help”.

gomedia · 2018-03-09 04:22:16

A favour please … any chance you could initialise $textarray to an empty array on the public side as well? I’ve got a couple of plugins that’ll break websites – big time!

Textpattern CMS

Textpattern CMS support forum

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

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

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

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

gomedia wrote #308195:

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

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

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

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

gomedia wrote #309784:

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

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

Bloke wrote #309794:

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

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

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

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

gomedia wrote #309798:

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

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

gomedia wrote #309800:

#21 2018-03-09 01:20:53

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

Bloke wrote #309804:

#22 2018-03-09 01:31:50

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

#23 2018-03-09 01:45:36

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

#24 2018-03-09 04:22:16

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

Board footer