Performance

Problem:
The client is experiencing a decrease in page speed after installing WPML on their website.
Solution:
We recommend the following steps to improve your site's performance:
1. Disable "Adjust IDs for multilingual functionality" under WPML -> Languages -> Make themes work multilingual, especially if you are using well-known themes like Astra.
2. Reduce the overall page size by compressing media files using plugins like EWWW.
3. Install and configure a page caching plugin such as Super Cache, W3 Total Cache, or WP-Rocket.
4. Implement object caching with Redis to enhance backend performance. This requires support from your hosting or VPS and can be set up using the Redis Cache plugin. Note that some caching plugins like W3 Total Cache also provide object caching.
5. Ensure that the Query Monitor plugin is only active during testing phases to identify slow queries and not enabled in production as it can degrade performance.

If these steps do not resolve the issue or if the solution seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Should the problem persist, please open a new support ticket.

Problem:
After upgrading from WPML 4.6.3 to 4.6.11, a significant performance regression was observed, specifically with the 'WPML Multilingual CMS' and 'WPML String Translation' plugins. This issue was evident in REST API calls, where the time to execute 7 queries increased from approximately 10 seconds to 55 seconds.
Solution:
We recommend implementing a workaround by modifying the logic in the plugin files to exclude REST requests. Specifically, in the file

wp-content/plugins/acfml/classes/Strings/FieldHooks.php

, modify the

add_hooks

method to check for REST requests before executing hooks. Here is the suggested change:

public function add_hooks() {
    if (!strpos($_SERVER['REQUEST_URI'], 'wp-json')) {
        add_action('acf/update_field_group', [$this, 'registerGroupAndFieldsAndLayouts']);
        add_filter('acf/load_field_group', Fns::withoutRecursion(Fns::identity(), [$this, 'translateGroup']));
        add_filter('acf/load_field', [$this, 'translateField']);
        add_action('acf/delete_field_group', [$this, 'deleteFieldGroupPackage']);
    }
}

Important: Please ensure to make a full site backup (files and database) before implementing this workaround.

Update!

We are soon to release a new version of ACF Multilingual, version 2.1.4. The update will overwrite the fix suggested in this ticket. (In the file: wp-content/plugins/acfml/classes/Strings/FieldHooks.php). Our developer suggests a better workaround that will work with version 2.1.4. Add the following function.

add_action( 'rest_api_init', function() {
    if ( wp_is_serving_rest_request() ) {
        add_filter( 'acfml_should_translate_acf_entity', '__return_false' );
    }
}, 5 );

It is important to note that the above snippet will only work with ACF Multilingual version 2.1.4

It's recommended that the snippet be added as a Must-Use plugin. Alternatively, you can add the function to the functions.php file of your theme.

**** Important! Please make a full site backup (files and DB) before you proceed with those steps****

Note: wp_is_serving_rest_request introduced in WP 6.5 relies on the REST_REQUEST global. But keep in mind that standard HTTP requests could also call REST endpoints internally (to pre-load REST request results with the normal request). The client might want to disable the ACF entity translation on a wider scope.

If this solution does not resolve your issue, or if it seems outdated or irrelevant to your specific case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Should you need further assistance, please do not hesitate to open a new support ticket at WPML support forum.