Fatal error when I upgrade a 4.7 dev site with 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!

gomedia · 2018-03-09 04:41:17

Bloke wrote #309804:

Language strings are now only loaded if their event matches the current panel’s event name.

I’m seeing strings loaded on an admin tab regardless – see following scenarios

#@some-event is missing completely
#@some-other-valid-event is used 
#@public
#@nonexistant-event

Seems to occur both with cached & installed plugins.

Bloke · 2018-03-09 10:20:01

gomedia wrote #309811:

a plugin that creates it’s own menu doesn’t get translated

Hmm yeah that’s because tabs are in the admin-side group so they appear “everywhere” on the admin side. Bit annoying I guess to have to put just that string in the admin-side group in your plugin; hadn’t thought about that. Might have to relax the plugin string loading rules further in the interim. Will see what can be done.

gomedia wrote #309813:

any chance you could initialise $textarray to an empty array on the public side as well?

Sure, shouldn’t be an issue.

gomedia wrote #309814:

I’m seeing strings loaded on an admin tab regardless

If these strings are inside a plugin, I’d have said that it’s probably to do with the fact all non-empty owner strings are loaded on every panel. But if that was the case, you’d see the plugin’s tab string too, so maybe something’s amiss here. I’ll do some more testing over the weekend, thanks for your patience here.

gomedia · 2018-03-09 11:12:47

Bloke wrote #309844:

… thanks for your patience here.

No problem – you’re doing all the work … I’m just picking holes!

BTW, have I got the syntax right? for example:

#@owner gomedia
#@admin-side
#@language en

A #@xxx by itself is an event?

Bloke · 2018-03-09 11:13:49

gomedia wrote #309851:

BTW, have I got the syntax right? A #@xxx by itself is an event?

Yep, that’s how it’s supposed to work… let us know if it differs from this plan :-)

gomedia · 2018-03-09 21:49:45

Bloke wrote #309794:

The language designators have all changed. Most are much shorter with only two chars.

Apologies for bombarding you with queries but I just thought of another one. Regarding the language designators, now that two character ones are being used does that mean current textpacks might not be forward compatible (i.e. TXP 4.7 is not backward compatible)? Not sure if I’m coming or going there, but hopefully you get my drift.

At the moment my current textpack that uses longer codes, for example fr-fr, seems to load successfully.

phiw13 · 2018-03-10 00:03:36

gomedia wrote #309863:

Regarding the language designators, now that two character ones are being used does that mean current textpacks might not be forward compatible (i.e. TXP 4.7 is not backward compatible)?

As far as I understand it, based on what Stef mentioned in another thread, TXP 4.7 can deal with those 4 character code correctly, but the “correct“ way to specify the language code is the 2-character set.

Textpattern CMS support forum

#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

#25 2018-03-09 04:41:17

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

Bloke wrote #309804:

#26 2018-03-09 10:20:01

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

gomedia wrote #309811:

gomedia wrote #309813:

gomedia wrote #309814:

#27 2018-03-09 11:12:47

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

Bloke wrote #309844:

#28 2018-03-09 11:13:49

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

gomedia wrote #309851:

#29 2018-03-09 21:49:45

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

Bloke wrote #309794:

#30 2018-03-10 00:03:36

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

gomedia wrote #309863:

Board footer