Skip Navigation
Home » WPML Blog – News and Updates for the WordPress Multilingual Plugin » Compatibility » Yoast SEO Multilingual 1.2.0 – improved compatibility with Yoast’s Indexables feature

Yoast SEO Multilingual 1.2.0 – improved compatibility with Yoast’s Indexables feature

Compatibility
13

Today we released Yoast SEO Multilingual 1.2.0. This release includes bug fixes related to Yoast’s new Indexables feature.

Fixing issues related to Yoast’s new Indexables feature

Yoast recently introduced Indexables, a new architecture that provides a speed boost for your site and readies Yoast for an expanse of features. This was a major update for Yoast, and our team has been working hard to fix some bugs that appeared as a result.

This release includes fixes to the following bugs:

  • An issue caused when customers translate Indexables with the Classic Translation Editor
  • Yoast SEO breadcrumbs showing the wrong URL for the homepage in secondary languages
  • Undesired redirects when creating a new page
  • Duplicated sitemaps in language folders

Also included in this release is a new feature to synchronize the primary category of a post with its translations.

For the full list of changes, see the Yoast SEO Multilingual changelog.

Download and Update

You will receive this update automatically to all your registered sites. You can also download and install it manually from your WPML account.

Check our detailed guide that explains the process of optimizing your multilingual site using Yoast and WPML.

Feedback

If you have any questions, leave your comments here, and we’ll get back to you.

How can we make WPML better for you?

Share your thoughts and comments about our plugin, documentation, or videos by booking a Zoom call with Agnes, our Client Advocate. Your feedback matters and helps us improve.

Book a call with Agnes

13 Responses to “Yoast SEO Multilingual 1.2.0 – improved compatibility with Yoast’s Indexables feature”

  1. Still buggy.
    {“message”=>”2020/07/21 06:42:06 [error] 31#31: *64 FastCGI sent in stderr: “PHP message: PHP Warning: include(/data/htdocs/wp-content/plugins/wp-seo-multilingual/vendor/composer/../../classes/Utils.php): failed to open stream: No such file or directory in /data/htdocs/wp-content/plugins/sitepress-multilingual-cms/vendor/composer/ClassLoader.php on line 444PHP message: PHP Warning: include(): Failed opening ‘/data/htdocs/wp-content/plugins/wp-seo-multilingual/vendor/composer/../../classes/Utils.php’ for inclusion (include_path=’.:/usr/local/lib/php’) in /data/htdocs/wp-content/plugins/sitepress-multilingual-cms/vendor/composer/ClassLoader.php on line 444PHP message: PHP Fatal error: Uncaught Error: Class ‘WPML\WPSEO\Utils’ not found in /data/htdocs/wp-content/plugins/wp-seo-multilingual/classes/class-wpml-wpseo-should-create-redirect.php:29”}]

  2. Hi I would like to update my payment method by do not see the ‘Modify’ link on my Account.

    Please help.

    Thanks

    Johan

  3. I’ve faced the same problem mentioned here and on other websites, with several tickets opened. After hours of looking for a solution I noticed that the file Utils.php in wp-seo-multilingual/classes/Utils.php was renamed from utils.php(lowercase u) to Utils.php(uppercase U) Which wasn’t detected by source control as a change, and might not be detected by some operating systems if no source control is used.

    How I solved it:

    1- Rename Utils.php file to anything else, I renamed it to “Utilsx.php”
    a – if you’re using source control (git) commit your changes and push them for them to take effect.
    b – if not, just rename the file on the server.
    2- Rename the file back to “Utils.php” (uppercase U)

    • Hi Mahmoud,

      Thanks for your comment.

      I believe you are using a version control system to manage your plugins on your sites, right?
      In that case, I am not sure there’s something we can do on our side.

      • Hello Pierre,

        That’s correct, I’m using a version control system.

        I posted my comment here just as a reference for people who faced the same problem as there’re multiple tickets opened that’re caused by this.

        It is true that nothing can be done from your side concerning the file name, since changing it back to what it was will break on websites that got it fixed.

        What might be a solution is putting some fallback in the code that includes the Utils.php file, to check for the file’s name in lowercase if the file doesn’t exist. Something along the lines of


        if (!file_exists($file)) {
        includeFile(strtolower($file)); // if "Utils.php" doesn't exits look for "utils.php"
        }

        • Thanks for sharing your workaround Mahmoud, it will surely help!

          The classes are automatically loaded with an autoloader, I don’t think it’s a good idea to have this kind of fallback.

          But it’s good to know this, at least as a reminder of possible effects of changing only the case of a class file name.