Complete rewrite

[Chouby]

Fixes #9 Fixes #10 Fixes #11 Replaces and Closes #13

This PR is a complete rewrite of the plugin. This was an opportunity to use more modern coding standards and is compliant to PSR-4.

The migration process is splitted in several actions:

1. Create languages
2. Assign post languages and translations (*)
3. Assign term languages and translations (*)
4. Assign menu locations
5. Process post and terms without language
6. Migrate strings translations (*)
7. Migrate options

Given that these actions may have to process a huge amount of data, the actions marked by an asterisk may be splitted themselves in several processes (called steps) if necessary.

The user launches the first action, which launches the second step in ajax, which to its turn launches the third action and so on until the end.

Each action is handled by one class. This class is also responsible to provide a status (percentage completion) displayed in ajax.

The size of the data processed in each step is controlled by the constant WPML_TO_POLYLANG_QUERY_BATCH_SIZE as proposed in #13. However not all queries are limited by this constant (when data are expected to be small enough or when the query is limited by the results of a previous query).

Various optimizations have been made either to speed up the process (e.g avoid using WPDB::prepare() when int type cast can do the job as proposed in #13) or to limit the memory usage (NB: the usage of time_nanosleep() after unset() used in #13 had zero impact in my tests so I did not retain the idea in this PR).

The strings translations usually included in mo files are no more imported. This can drastically reduces the migration time and should have no negative impact as these strings are not used by Polylang.

Errors before import are now displayed using the usual WordPress notices format. Passed checks are no more displayed.

The PR fixes the languages order as proposed in #13. It also fixes the media translation setting and the nav menu locations per language which were not correctly migrated.

Known limitations:

• There are still no error management.
• Language switchers are still not migrated (as far as I understood, the settings are stored as serialized objects).

[Chrystll]

After running the import I get a 404 error when the language code is displayed in the url (/fr/) for the taxonomies, the CPT book. See the rewrite rules that need to be flushed: 20220909.twentytwentyone.rewriterules.zip

I didn't notice any other issue.

[Chouby]

Nice catch.

[Chrystll]

With your modification, as soon as I activate Polylang Pro I get this notice twice:

PHP Notice: Function map_meta_cap was called <strong>incorrectly</strong>. The post type shop_order is not registered, so it may not be reliable to check the capability "read_post" against a post of that type. Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. (This message was added in version 4.4.0.) in /app/wp-includes/functions.php on line 5831

Some rewrite rules are still not flushed, the ones for my CPT book 20220912.twentytwentyone.rewriterules.zip :

Note that I tested the translated static front page and the translated Page for posts. They are working are expected after the migration.