Fatal error when I upgrade a 4.7 dev site with plugins

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.

gomedia · 2018-03-11 21:42:40

Bloke wrote #309804:

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

As I’ve said before, at the moment they seem to be loaded regardless, but you mention adi_matrix as an example and this is where things start to get complicated. It uses events “adi_matrix_admin” for the admin panel and “adi_matrix_matrix_1, adi_matrix_matrix_2 …” for the matrix panels. As the latter ones are generated automatically, adi_matrix will have to use the “admin-side” event. You’ll see this with smd_tabber as well.

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.

I’ve got 200+ adi_language_strings. Many specific to certain plugins, some used by all, some used by more than one, some “public”, many “admin-side” … you get the picture. All non-English strings are available to adi_plugin_users in a separate downloadable Textpack file for ease of management and to save having to reissue a plugin everything a new language set comes in.

The permutations are mind-bending. What was simple (for me) is now complicated.

… Whether any of that works or means that deleting one of your plugins removes the strings from all of them, I can’t recall. … before we enforce the lang strings to load on their designated panels only.

In the situation where a string used by several plugins, will this mean that deleting one plugin will affect another?

Owner “gomedia”, event “common” is looking very attractive at the moment.

colak · 2018-03-12 13:11:19

gomedia wrote #309911:

As I’ve said before, at the moment they seem to be loaded regardless, but you mention adi_matrix as an example and this is where things start to get complicated.

Indeed. I am checking it now. Number of articles loaded does not work. Also, strangely enough the numbers at the bottom of the page read: 12, 24, 48, 96 instead of 15, 25, 50, 100 in the stable txp release but I’ll check this again as the dev site does not have all the articles present in the live one.

Bloke · 2018-03-12 14:25:57

gomedia wrote #309911:

events “adi_matrix_admin” for the admin panel and “adi_matrix_matrix_1, adi_matrix_matrix_2 …” for the matrix panels. As the latter ones are generated automatically, adi_matrix will have to use the “admin-side” event. You’ll see this with smd_tabber as well.

Yes, that’s a bind. But if you want the tab name to appear in “all menus” as you navigate any panel on the admin side, there’s no neat alternative than to put them in a group that is loaded on all panels. Or go back to how we had it, and load all strings everywhere, which is a memory and performance hog.

I’m exploring alternatives though. For example, making sure that shortcuts exist so that the owner, event and language headers are retained when you switch between them as packs are installed. That way you don’t need to keep specifying the full set each time. I think it does that already but I need to check that and make it happen if not.

Also, how about permitting a “group” as part of the owner string? go_media.adi_matrix, go_media.adi_form_links, … you could then assign strings to go_media. (note: trailing dot) to have plugin-less strings installed, that are still “owned” by you. Bit of a hack, but it does mean that we can split on dot, treat owners as now when deleting plugins but leave any strings alone that don’t match the owner. Then, perform an additional check on plugin deletion to see if there are any strings left with your owner. If there are, leave everything. If not, well, the last plugin by that owner has just been deleted so any “shared” (plugin-less) strings can also be removed.

Not sure if that solves anything. Plugins wouldn’t have to use it. And you’d still have to bundle all strings – shared or not – with each plugin, and/or provide a separate machanism as you do now to install them from a third party server.

Just note that “install” now doesn’t necessarily mean “put in txp_lang table” – it means “put in textpack column of plugin table”. Because then they are available to automatically install when new languages are added/deleted.

Note also that installing from a third party server won’t work as expected for plugins running from file (cache). The strings can’t be “installed” anywhere in the database, since there’s no “plugin textpack” column to house all current translations. You could inject them direcly into the txp_lang table and it’ll work, you just have no core way (currently) of cleaning up unless you do it by hand in all of your plugins somehow.

I’ve got 200+ adi_language_strings. Many specific to certain plugins, some used by all, some used by more than one, some “public”, many “admin-side” … you get the picture. All non-English strings are available to adi_plugin_users in a separate downloadable Textpack file for ease of management and to save having to reissue a plugin everything a new language set comes in.

Having all plugin strings in one humungous pack is something that we support. We just need to find a decent way to segregate them in your pack. See above. You could distribute the “latest” adi mega pack in each released plugin so that installing from cache worked on-the-fly. Bit of a wate of space, but there’s probably enough overhead in the table to do it… maybe. Depends if you reach MySQL row limits.

If your plugins retain the ability to download the latest adi mega pack as part of its internal logic, note (as I mentioned above) the best way to do so is to insert them in the plugin’s textpack column if you can. That way, if someone deletes or installs a new language and it’s one your pack supports, it gets loaded for free by core.

That still leaves cache plugins a little out in the cold. If you offer them a “download latest mega pack” feature, how do you currently install them? Just inject them directly into txp_lang? If so, that’ll probably interfere with the current “load strings from cache on the fly” facility, as the ones read from the cached plugin may override the (newer) ones in the lang table. Not sure, haven’t tried that. We probably need to be a bit more clever here when things are merged.

Also, as you surmised, plugins that share an owner will be deleted when you delete a plugin. That’s by design so it’s easy to clean up when a plugin is removed and not leave floating strings around. Introducing some dotted sub-owner notation system as above would help here I think for plugins that form part of a suite or whose authors wish to manage all strings for all plugins as one pack.

colak wrote #309915:

the numbers at the bottom of the page read: 12, 24, 48, 96 instead of 15, 25, 50, 100

That’s by design. Those values are more grid friendly.

Last edited by Bloke (2018-03-12 14:30:10)

gomedia · 2018-03-12 23:49:57

Bloke wrote #309917:

Yes, that’s a bind. But if you want the tab name to appear in “all menus” as you navigate any panel on the admin side, there’s no neat alternative than to put them in a group that is loaded on all panels. Or go back to how we had it, and load all strings everywhere, which is a memory and performance hog.

But now that TXP itself is not a hog, then maybe us smaller plugin hogs don’t have to worry about it ;-)

I’m exploring alternatives though. For example, making sure that shortcuts exist so that the owner, event and language headers are retained when you switch between them as packs are installed. That way you don’t need to keep specifying the full set each time. I think it does that already but I need to check that and make it happen if not.

Also, how about permitting a “group” as part of the owner string? go_media.adi_matrix, go_media.adi_form_links, … you could then assign strings to go_media. (note: trailing dot) to have plugin-less strings installed, that are still “owned” by you. Bit of a hack, but it does mean that we can split on dot, treat owners as now when deleting plugins but leave any strings alone that don’t match the owner. Then, perform an additional check on plugin deletion to see if there are any strings left with your owner. If there are, leave everything. If not, well, the last plugin by that owner has just been deleted so any “shared” (plugin-less) strings can also be removed.

Is there an issue/complication with introducing a new entity “owner”? Bearing in mind that a suite of plugins, by the same author, probably only uses a plugin author-owned textpack – would it be better to make the owner the plugin prefix?

Not sure if that solves anything. Plugins wouldn’t have to use it. And you’d still have to bundle all strings – shared or not – with each plugin, and/or provide a separate machanism as you do now to install them from a third party server.

I, personally, would prefer to manage my plugin strings in one big chunk. Embedding my English within the plugin works great (both with installed & cached methods). Supplying non-English alternatives via a downloadable file has worked well for me too – especially as non-English translations appear in an adhoc fashion, suiting my system of updating an online text file. At least then I don’t have to reissue the plugin every time.

Just note that “install” now doesn’t necessarily mean “put in txp_lang table” – it means “put in textpack column of plugin table”. Because then they are available to automatically install when new languages are added/deleted.

Note also that installing from a third party server won’t work as expected for plugins running from file (cache). The strings can’t be “installed” anywhere in the database, since there’s no “plugin textpack” column to house all current translations. You could inject them direcly into the txp_lang table and it’ll work, you just have no core way (currently) of cleaning up unless you do it by hand in all of your plugins somehow.

I’m not fussed about non-embedded (i.e. non-English) strings not being available automatically with cached plugins. I don’t need them for the UI or for development and can always download the textpack file on a properly plugin-installed site anyway for checking. I think they get loaded in anyway – I’m sure I’ve done it, changed the dev site language & seen the translations. Housekeeping is not so much of an issue on a dev site.

Having all plugin strings in one humungous pack is something that we support. We just need to find a decent way to segregate them in your pack. See above. You could distribute the “latest” adi mega pack in each released plugin so that installing from cache worked on-the-fly. Bit of a wate of space, but there’s probably enough overhead in the table to do it… maybe. Depends if you reach MySQL row limits.

As I mentioned before I like a big chunk and to manage it separately from plugins. In my case it’s a downloadable textpack file, but there’s always the dedicated “lang” plugin method – as used in the old zen_contact_reborn plugin. With an online file, however, I can wilfully disregard version numbers etc etc.

If your plugins retain the ability to download the latest adi mega pack as part of its internal logic, note (as I mentioned above) the best way to do so is to insert them in the plugin’s textpack column if you can. That way, if someone deletes or installs a new language and it’s one your pack supports, it gets loaded for free by core. Regarding segregation – see below.

Yep, now that $textarray is no more, I’ll do 4.7 versions of my plugins using the $plugin['textpack'] thang.

That still leaves cache plugins a little out in the cold. If you offer them a “download latest mega pack” feature, how do you currently install them? Just inject them directly into txp_lang? If so, that’ll probably interfere with the current “load strings from cache on the fly” facility, as the ones read from the cached plugin may override the (newer) ones in the lang table. Not sure, haven’t tried that. We probably need to be a bit more clever here when things are merged.

See above – I’m content with English-only strings automatically available with cached plugins.

Also, as you surmised, plugins that share an owner will be deleted when you delete a plugin. That’s by design so it’s easy to clean up when a plugin is removed and not leave floating strings around. Introducing some dotted sub-owner notation system as above would help here I think for plugins that form part of a suite or whose authors wish to manage all strings for all plugins as one pack.

I like the “plugin bulk textpack owner” idea.

As a plugin author, it’s the organising & maintenance of language strings that I’m concerned at. Maybe the primary indexing for the strings in the textpack is the issue. At the moment it seems to be done by language. Perhaps it should be done by string – and then for each one a set of language translations, the plugin & the event?

jakob · 2018-03-13 08:51:21

gomedia wrote #309926:

… suiting my system of updating an online text file. At least then I don’t have to reissue the plugin every time. … As I mentioned before I like a big chunk and to manage it separately from plugins … As a plugin author, it’s the organising & maintenance of language strings that I’m concerned at.

Not an answer to the specific question at hand, but could Jukka’s little suite of plugin management plugins help in easing the administrative aspect of handling the updating and serving of many plugins:

rah_blobin works like the plugin cache but allows you to keep docs, code and textpacks separate and supports the plugin lifecycle handling.
rah_plugcompile is a class that compiles the plugin txt files from this format and can handle many at once.

I’m sure he once wrote about the workflow he uses these to keep his site downloads up to date with his release repositories but I can’t find it now.

gomedia · 2018-03-14 06:49:01

jakob wrote #309927:

Not an answer to the specific question at hand, but could Jukka’s little suite of plugin management plugins help in easing the administrative aspect of handling the updating and serving of many plugins:

Not sure – but thanks anyway.

Textpattern CMS support forum

#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:

#31 2018-03-11 21:42:40

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

Bloke wrote #309804:

#32 2018-03-12 13:11:19

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

gomedia wrote #309911:

#33 2018-03-12 14:25:57

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

gomedia wrote #309911:

colak wrote #309915:

#34 2018-03-12 23:49:57

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

Bloke wrote #309917:

#35 2018-03-13 08:51:21

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

gomedia wrote #309926:

#36 2018-03-14 06:49:01

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

jakob wrote #309927:

Board footer