Polylang issue

Using WPML on a live site that´s already using Polylang isn´t really an option.
Seems like this is something that needs to be fixed urgently.

Yes, I think this is now urgent as many people are being left unable to edit any pages in Cornerstone and this thread is over two weeks old already


Hi @Rad @alexander and @christian_y, please update us on this issue

Hi there,

We forwarded your concern to our development team. The matter of the translation with the new system of the builder hit the wall in some places but our team is doing their best to fix things around. Unfortunately, we can not give an ETA regarding this but rest assured that our team is aware of the situation and work on that.

At the moment we do not have any more suggestion other than using the WPML plugin.

Thank you for your understanding and patience.

1 Like

This is a serious Issue, as it left us unable to edit our page. Switching to WPML also ins’t a possibility for an already deployed site.

I understand that fixes can sometimes take a bit, but at the very least please make the last version of theme (+cornerstone) which is not affected available for download, that way we can downgrade while a fix is implemented.

1 Like

Hi everyone,

I’m sorry about the issues you’re having here. We recently released improved WPML integration. Pro and Cornerstone now tightly integrate with WPML and utilize many WPML functions and filters. The conflict here is that PolyLang tries to assist with migrating away from WPML and they implement many filters that are native to WPML. Because PolyLang adds WPML filters and functions in a way that isn’t identical to WPML, it conflicts with many ares of our WPML integration.

For those of you who are stuck on the “Create Translation” screen and can no longer work with your content, please add this custom code to functions.php of a child theme:

function remove_polylang_wpml_filter_from_cornerstone() {
  add_filter('wpml_active_languages', '__return_empty_array', 999 );

add_action( 'cornerstone_before_boot_app', 'remove_polylang_wpml_filter_from_cornerstone' );

This will reset the WPML filter that PolyLang modifies. This can’t be an official fix because it will break our WPML integration. To be perfectly honest, this is not going to be easy to untangle from what I can tell right now. We’re first committed to our WPML integration, and that will always have priority moving forward. Getting PolyLang working will involve modifying the WPML integration to somehow account for both plugins.

Hopefully this workaround helps for now. Once our Template Manager release is out we can revisit a more polished solution. Best case scenario is that our WPML integration features (language switcher in builder) could be repurposed to work for PolyLang as well. Worst case is that we won’t be able to support PolyLang for translations, but we will release an official solution to resolve conflicts that make the builder unusable when PolyLang is active.


Thanks Alex,
that worked for me.

@freshman66 thanks for confirming!

Update: I found a better way to prevent PolyLang from hijacking our WPML integration internally. With the next release you won’t see that “Create Translation” screen. I’d still like to spend some time seeing if the mechanics of our WPML integration can be multi-purposed to work with PolyLang so it can be better supported, but at least this the builder won’t be inaccessible while PolyLang is active.

1 Like


thank you for looking into this!

Unfortunately I can’t confirm the fix. After adding the code to our child theme the “Create Translation”, does no longer pop up, instead i get stuck with the loading symbol:

I will revert the changes to the child theme for now and wait for the official fix you are working on. Thansk again.

Thanks for providing a temporary fix. It did fix the issue of editing English posts. However, when editing posts in other languages, it doesn’t work.

More specifically, the error I get is “The preview could not load due to the iframe response being incomplete. This is most often related to a plugin conflict, or customizations introducing a PHP error.”

I did some debugging and it seems that Cornerstone fails to find the loaded iframe because of a 301 redirect from domain.com/{post} -> domain.com/{lang_code}/{post} and the response it gets doesn’t contain cornerstone’s signature (“CORNERSTONE_FRAME”).

We would highly appreciate Polylang’s support in Cornerstone. Looking forward to receiving the update.

Hey everyone,

We have a release coming out tomorrow to address a MEJS compatibility issue with the WordPress 4.9 update. The fix to prevent PolyLang from activating the WPML integration screen (the one saying “Create Translation”) is included. Once you update you won’t be blocked from the content builder anymore.

@mokha Right, it’s a fix for the issue that’s occurred since the WPML update, but we still don’t have full PolyLang compatibility.

1 Like

Now after updating WP to 4.9, X to 5.2.5 and Cornerstone to 2.17 I can confirm having the following nag screen when trying to edit pages with cornerstone:

“The preview could not load due to the iframe response being incomplete. This is most often related to a plugin conflict, or customizations introducing a PHP error.”

Hi there @FriggJarkko,

If you could open up a new thread/topic and our support team will be right along to assist with that issue.


I can also confirm that the update doesn´t fix the bug.
now we get this error message
“The preview could not load due to the iframe response being incomplete. This is most often related to a plugin conflict, or customizations introducing a PHP error.”

Hey There,

I have informed Alex about the issue you are still having after the updates X 5.2.5/Cornerstone 2.1.7 and Pro Theme 1.2.7. He will be responding shortly.

Please bear with us.

For us its actually working now after the upgrade of cornerstone (haven’t updated the theme yet).

  • Cornerstone: Version 2.1.7
  • X-theme: Version 5.2.4
  • Wordpress: Version 4.8.3
  • Polylang Version 2.2.5

Thank you!

Glad it’s working for you @u_oculyze.

Hi just a small update to help you you guys hunt down the bug:

As I mentioned we are able to edit the site, though we now sometimes get the error message described above.
It seems to vary also based on the browser and computer how often it happens (I basically never get it, but a colleague gets it in chrome most of the time, but very rarely in firefox quantum).

Maybe something to do with the rendering speed of the client browser?

Hi There @u_oculyze

Not sure whether it is related to rendering speeds. However our developers will check your feedback as well with regard to the original issue.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.