Improve multisite support

[swissspidy]

We recommend using Traduttore Registry in a mu-plugin when on Multisite. The reason is that your plugin might not be loaded during update requests in that case, but must-use plugins are always guaranteed to be loaded.

This works on our own projects, but not when someone wants to use Traduttore for their commercial plugins where they don't have to control over the environment.

I wonder if we can come up with a good solution to this problem. Off the top of my head I would have thought about writing some code that moves everything to a mu-plugin under the hood.

[grappler]

We recommend using Traduttore Registry in a mu-plugin when on Multisite.

We recommend adding the config as a mu-plugin on multisites. Traduttore Registry is just a package.

This is only needed for plugins that are not network activated.

Off the top of my head I would have thought about writing some code that moves everything to a mu-plugin under the hood.

My solution would be to save the configs to the database and use that when running the updates.

[swissspidy]

We recommend adding the config as a mu-plugin on multisites. Traduttore Registry is just a package.

That's what I was saying 🙂

My solution would be to save the configs to the database and use that when running the updates.

And how would you use that when running the updates when your plugin isn't being loaded during that process?

I mean, ideally we would just append our available translations to the option stored in the database, but it's not really possible because that part of core isn't easily extensible.

Traduttore Registry currently filters the cached translations_api calls for a reason.

[grappler]

I mean, ideally we would just append our available translations to the option stored in the database, but it's not really possible because that part of core isn't easily extensible.

Would that not be possible with 'pre_set_site_transient_' . $type . 's'?

I mean, ideally we would just append our available translations to the option stored in the database, but it's not really possible because that part of core isn't easily extensible.

If we created a mu-plugin or even a standard plugin plugin that is network activated it work.

$projects = get_option( 'traduttore_translation_config' );
foreach ( $projects as $project) {
    \Required\Traduttore_Registry\add_project(
    	$project['type'],
    	$project['text-domain'],
    	$project['url']
    );
}

[swissspidy]

Would that not be possible with 'pre_set_site_transient_' . $type . 's'?

Last I checked, that transient is updated multiple times during update checks to add and remove data, which means it's not very reliable to hook into it...

If we created a mu-plugin or even a standard plugin plugin that is network activated it work.

That could work, yes. However, I was trying to see this from the point of another (commercial) plugin developer who uses Traduttore. They cannot ask users to install another plugin just so their translations are being downloaded properly.

In that case the only option is creating a new mu-plugin on the fly upon plugin activation with the code you described. But that's super hacky.