Skip Navigation


Resolved in: WPML Multilingual CMS 3.9.3

Overview of the issue

If you recently upgraded the Divi theme to the 3.0.99 version, you have probably seen the HTTP error 500 page or the following PHP error in your PHP debug log:

Fatal error: Call to undefined function et_builder_register_layouts() in .../plugins/sitepress-multilingual-cms/compatibility/divi/class-wpml-compatibility-divi.php on line 71


After making a full backup of your site, please add the following code to the functions.php file found in the Divi theme folder.

if ( ! function_exists( 'et_builder_register_layouts' ) ) {
    function et_builder_register_layouts() {
        require_once ET_BUILDER_DIR . 'feature/Library.php';

You can edit the functions.php file of the child theme, if you’re using one, instead of the parent theme.

This prevents losing the change if the parent theme gets updated, until a fix is provided in the next version of WPML.

16 Responses to “Fatal error: Call to undefined function et_builder_register_layouts() after upgrading to Divi 3.0.99”

    • Thank for the heads up. We will be implementing a solution on our next WPML release although we don’t have a date for it. For the moment, please add again in your functions.php file the workaround here provided.

  1. Same issue here with the Elegant themes “Extra” theme. The functions.php solution mentioned above fixed the problem on Extra as well.


      • Noted. Anyway, I place at main divi theme, and again the same error occur after the latest divi 3.X.100 update. Hence, now I place at child divi theme, which works again.

        My main concern for placing them in child theme, is that once WPML has updated its code to resolve this issue, would there be any impact with the extra code placed in the child divi theme ?

        • It should have no impacts, as the workaround first checks is the function does not exists and then makes sure to not require the missing file more than once.

          The same logic is used in the fix we are going to provide.

          After updating WPML to the new version, I would remove the workaround anyway, but only to avoid keeping code you don’t need.