[Waiting for user confirmation] WPML bug with the pagebuilder Cornerstone

The problem might be that the CSS is not validated correctly, which seems to be related to the fact that in the last rule, an empty string is passed as background URL.

If I use the following CSS markup, which uses background: none;, it seems to work:

.site {
  animation-name: fade-in;
  animation-duration: 2s;
  animation-delay: 1s;
  animation-fill-mode: backwards;
}

.x-root {
  animation-name: hide-logo;
  animation-delay: 2s;
  animation-fill-mode: both;
  background-size: 300px !important;
  background-repeat: no-repeat !important;
  background-position: center !important;
  background-attachment: fixed !important;
}

@media not all and (min-resolution:.001dpcm) { 
	@supports (-webkit-appearance:none) {
    .site {
      animation-name: none !important;
    }
    .x-root {
      animation-name: none !important;
    }
	}
}

@keyframes fade-in {
  from {opacity:0}
  to {opacity:1}
}

@keyframes hide-logo {
  from {
    background: url('<em><u>hidden link</u></em>');
    background-color: #002d4c;
  }
  to {background: none}
}

Could you please give this a test?

Indeed, I see now the issue occurs again after refreshing the page.

It seems what actually solves the issue is going to WPML > Paramètres > Traduction de champs personnalisés > Afficher les champs du système and setting the field _cornerstone_settings to "Copy".

Now, if you create a translation, WPML will copy the original settings directly to the translated page.

Please give this another test and let me know if you need further assistance.

I have tested your approach on a local dev site, and your patch essentially does the same thing: it copies the CSS over to the translated page. I cannot recommend this kind of bugfix to our developers, and I’d like to explain why in detail.

WPML’s Custom Fields Translation settings (WPML → Settings) define whether a meta key is set to Copy, Translate, or Ignore. These settings apply globally, and WPML respects them during the translation workflow.

Theme and plugin developers can provide defaults for WPML by adding a wpml-config.xml file to their root directories. Since such a config does exist inside the PRO Theme, but it does not choose a default setting for the _cornerstone_settings field, which is why this field defaults to Ignore. That means WPML’s logic does not touch it.

This is why I suspect the actual wp_slash() issue originates in Cornerstone’s save routine, not in WPML. WPML has no influence over Cornerstone’s UI development.

About your patch:

The filter wpml_pb_copy_meta_field is part of WPML’s Page Builder integration layer. When you hook into it, you intercept the meta field value after WPML has already applied its default logic. If your filter returns a different $value, you override WPML’s configured behavior for that meta key.

Such behavior changes the hierarchy of authority: instead of WPML’s settings being primary, the filter becomes primary. That’s why other users might not expect it: they assume the UI rules are always respected, and a bugfix shouldn’t silently override them.

The Custom Fields Translation settings in the UI are supposed to be the authoritative source of truth. If a field is set to Translate, Copy, or Ignore, users expect that behavior to be respected consistently. If we patch WPML’s Page Builder logic by always running apply_filters( 'wpml_pb_copy_meta_field', ... ), we essentially override WPML’s internal handling of meta fields. That means fields configured as Translate or Ignore could suddenly behave like Copy.

From a site owner’s perspective, this feels like WPML is “ignoring my settings.” Even if the patch fixes the Cornerstone CSS corruption, it introduces a mismatch between what the UI says and what actually happens, and this is why I can not propose this patch to our devs.

In summary: WPML respects the Ignore setting and does not touch _cornerstone_settings. The corruption arises when Cornerstone saves CSS in a translated page without properly slashing values before update_post_meta().

The fix:

While your patch works around the issue by forcing WPML to copy the field, it overrides WPML’s settings and risks unexpected behavior for other meta keys. The correct fix should be implemented in Cornerstone’s translation layer, not in WPML’s core.

The proper fix for this issue belongs in \wp-content\themes\pro\cornerstone\includes\functions\helpers.php on line 1269 inside the function cs_update_serialized_post_meta().

Search the original function:

function cs_update_serialized_post_meta( $post_id, $meta_key, $meta_value, $prev_value = '', $allow_revision_updates = false, $filter = '' ) {


	if ( is_array( $meta_value ) && apply_filters( 'cornerstone_store_as_json', true ) ) {
		$meta_value = wp_slash( cs_json_encode( $meta_value ) );
	}

  if ( $filter ) {
    $meta_value = apply_filters( $filter, $meta_value );
  }

  if ( $allow_revision_updates ) {
    return update_metadata('post', $post_id, $meta_key, $meta_value, $prev_value );
  }

	return update_post_meta( $post_id, $meta_key, $meta_value, $prev_value );

}

Replace it with:

function cs_update_serialized_post_meta( $post_id, $meta_key, $meta_value, $prev_value = '', $allow_revision_updates = false, $filter = '' ) {

	if ( is_array( $meta_value ) && apply_filters( 'cornerstone_store_as_json', true ) ) {
		$meta_value = cs_json_encode( $meta_value );
	}

	$meta_value = wp_slash( $meta_value );

  if ( $filter ) {
    $meta_value = apply_filters( $filter, $meta_value );
  }

  if ( $allow_revision_updates ) {
    return update_metadata('post', $post_id, $meta_key, $meta_value, $prev_value );
  }

	return update_post_meta( $post_id, $meta_key, $meta_value, $prev_value );

}

This bugfix was tested successfully on my local dev site and clarifies that the issue here is not WPML; it is coming from the Cornerstone UI.

I suggest you report this issue to the PRO Theme author. I will further escalate to our compatilbity team, which will try to reach the PRO Theme to address this issue.

Thank you very much for reaching out to Themeco about this matter already!

Indeed, your fix will work. It has the same effect as setting _cornerstone_settings to "Copy". I can not recommend this as a development approach for WPML, as it will overwrite WPML's settings programmatically and cause unexpected outcomes for other users.

Example: Field is set to "Ignore", "Translate", or "Copy once" but is getting copied instead.

This issue has now been escalated to our compatilbity team for further review, and I will reach out to you once I get their feedback.