[Escalated to Compatibility team] Translation complete on backend but not showing front end

Hi, and thanks for the access details.

I can see that the translation exists in WPML's Advanced Translation Editor but does not appear at the form end.

However, something is still unclear to me. When I edit the English page, I only see page settings, not the content itself. Please see the attached screenshot.

Can you please explain to me how to see this page's content?

I want to check if there is a compatibility problem by seeing which elements/modules you are using. The problem might be related to this known issue.

https://wpml.org/errata/x-theme-cornerstone-certain-widgets-are-untranslatable-using-advanced-translation-editor-ate/

Thanks,
Itamar.

Thanks.

I can see the translations when editing with Cornerstone. Please see the attached screenshot cornerstone.jpg. But indeed, they still don't show on the front end. I'm consulting our second-tier supporters about this.

However, I can also see that the Pro theme by Themeco has not been updated to its latest version on your site. Please see the attached screenshot pro.jpg.

While I consult our second-tier supporters, can you please update the theme to its latest version and see if that fixes the issue?

Thanks,
Itamar.

Hi,

Thanks for updating the theme.

Our second-tier supporter found out that the problem on your site is known. It is happening because you are using Cornerstone's Classic Text widgets. Please see the attached screenshot. We explain it in the following link and share two suggested workarounds. Please read the errata, choose one of the proposed workarounds, and apply it to your site.
https://wpml.org/errata/cornerstone-classic-widgets-translations-not-displayed-on-front-end/

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

Regards,
Itamar.

Hi,

I'm glad that it helped!

Thanks for reporting the subheadline problem. I could replicate it on a test page on your site here: hidden link. I'm consulting our second-tier supporter about this and will update you here when I have news.

Please note that my weekend is Friday-Saturday, and I'll be able to continue to check this issue and help you on Sunday.

I appreciate your patience.
Itamar.

Hi,

Here is the workaround suggested by our second-tier supporter.

1. Take a backup of your site in case something goes wrong.

2. Open this file with a code editor: .../sitepress-multilingual-cms/addons/wpml-page-builders/classes/Integrations/Cornerstone/class-wpml-cornerstone-register-strings.php

3. Look for line 13.

4. Change:

			if ( isset( $data['_type'] ) && ! Utils::typeIsLayout( $data['_type'] ) ) {
				$this->register_strings_for_node( Utils::getNodeId( $data ), $data, $package );
			} elseif ( is_array( $data ) ) {
				$this->register_strings_for_modules( $data, $package );
			}

To:

			if ( isset( $data['_type'] ) && ! Utils::typeIsLayout( $data['_type'] ) ) {
				$this->register_strings_for_node( Utils::getNodeId( $data ), $data, $package );
				if ( $data['_type'] == "accordion" || $data['_type'] == "accordion-item-elements" ) {
					$this->register_strings_for_modules( $data, $package );
				}
			} 
			elseif ( is_array( $data ) ) {
				$this->register_strings_for_modules( $data, $package );
			}

5. Save the change.

6. Open this file with a code editor: .../sitepress-multilingual-cms/addons/wpml-page-builders/classes/Integrations/Cornerstone/class-wpml-cornerstone-update-translation.php file.

7. Look for line 8.

8. Change:

	public function update_strings_in_modules( array &$data_array ) {
		foreach ( $data_array as $key => &$data ) {
			if ( isset( $data['_type'] ) && ! Utils::typeIsLayout( $data['_type'] ) ) {
				$data = $this->update_strings_in_node( Utils::getNodeId( $data ), $data );
			} elseif ( is_array( $data ) ) {
				$this->update_strings_in_modules( $data );
			}
		}
	}

To:

	public function update_strings_in_modules( array &$data_array ) {
		foreach ( $data_array as $key => &$data ) {
			if ( isset( $data['_type'] ) && ! Utils::typeIsLayout( $data['_type'] ) ) {
				$data = $this->update_strings_in_node( Utils::getNodeId( $data ), $data );
				if ( $data['_type'] == "accordion" || $data['_type'] == "accordion-item-elements" ) {
					$this->update_strings_in_modules( $data );
				}
			} elseif ( is_array( $data ) ) {
				$this->update_strings_in_modules( $data );
			}
		}
	}

9. Save the change.

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

This should solve the accordion content issue.
Please let us know how it goes.

Thanks,
Itamar.

Hi,

The subheadline issue

I agree that the suggested workaround is not optimal.

I could retrieve the following information about this problem from our internal records.

This issue will appear in every widget using the subheadline. The problem is related to the cs_element_headline shortcode. If we register the cs_content_seoshortcode, we get the content available for translation with the \n\n. However, we'll still have the already available fields duplicated, and we will affect other shortcodes, such as cs_element_button, which are correctly working. Cornerstone handles all this information on the _cornerstone_data. Therefore, they need to fix it on their side. This issue has been reported to the Themeco developers. They are responsible for fixing this, as we can not fix it only from our side.

The content of the accordion issue

I've passed on your question and findings to our second-tier supporter and will let you know his reply when I have it.

Thanks,
Itamar.