Compatibility issue with WPML and Algolia

[alfgundersen]

One of our sites uses both WPML (multi-language) and Algolia (site search), along with X Theme and Cornerstone. The problem: When attempting to index the posts, only the posts in the currently selected language gets indexed.

Apparently Algolia attempts to fetch the posts using WP_Query with ‘suppress_filters’ => true, in order to bypass filters like WPML’s language filter. My findings however suggest that this parameter is being overridden, and when I disable Cornerstone the problem goes away and all language versions get indexed.

My guess, based on my understanding of how Cornerstone stores content, is that it overrides the parameter to ensure that the content gets served from Cornerstone’s database fields instead of the default Content field. Am I right? What can be done to solve this?

Note: I initially approached WPML’s support with this problem. You may view the ticket for additional details here: https://wpml.org/forums/topic/suppress_filters-true-is-being-overridden/

[christopher]

Hi @alfgundersen,

The Cornerstone Classic Elements use the WordPress shortcode system and go the same route of the function:

the_content()

But the new elements use a completely separate architecture, and the information is stored as meta options in the database. Having said that we do expose the data to standard sweeping methods that plugins such as Yoast use, that is why if the plugin uses the conventional content scanning of the WordPress it should work correctly.

I am not sure how the Algolia plugin works but as you mentioned it seems that the plugin can not capture the meta options of the Cornerstone.

I am afraid you are in a tough situation here as the architecture of the Cornerstone is already established and new functionalities to come including the Archive builder, etc. will be based upon this architecture and we will not be able to change that to accommodate to a third party plugin. Having said that, if you ask the Angolia support to give detailed information on how they scan for content and for example what is their solution for scanning the WP Bakery Page Builder content we will have a better understanding of the case and can provide a report to our development team. That does not mean it will be a guarantee of compatibility with the plugin in question.

Thank you for your understanding.

[alfgundersen]

Thank you for your response. As mentioned in the ticket I linked to, Algolia uses WP_Query with ‘suppress_filters’ => true, as can be seen on https://github.com/algolia/algoliasearch-wordpress/blob/master/includes/indices/class-algolia-posts-index.php (lines 293 and 315). To my understanding, this is a valid method to use and the expectation that the filters will indeed be suppressed a reasonable one.

I will however forward your query to Algolia and refer to this ticket, so that we may hopefully find a solution together.

[christian]

Hey @alfgundersen,

Thanks for forwarding this to Algolia support. It would also be best though that you perform the test that Christopher mentioned which is how Algolia and WPML works if you use WP Bakery Page Builder or even Gutenburg or Classic Editor content. Also test those content types with and without Cornerstone.

Thanks.

[alfgundersen]

As mentioned I already tested disabling Cornerstone, which resulted in all language versions of the posts being indexed as intended. Additionally, the indexed posts only included Cornerstone’s shortcodes in the content field. E.g. the page http://ferdedev.wpengine.com/om-oss/hardangerbrua/?lang=nn got indexed with the following content:

[cs_content][cs_element_section _id="1"][cs_element_row _id="2"][cs_element_column _id="3"][cs_element_breadcrumbs _id="4"][cs_element_headline _id="5"][cs_element_text _id="6"][/cs_element_column][cs_element_column _id="7"][cs_element_image _id="8"][/cs_element_column][/cs_element_row][/cs_element_section][cs_element_section _id="13"][cs_element_row _id="14"][cs_element_column _id="15"][cs_element_headline _id="16"][cs_element_text _id="17"][cs_element_nav_collapsed _id="18"][/cs_element_column][/cs_element_row][/cs_element_section][/cs_content]

With Cornerstone enabled, only the posts in the currently selected language were indexed, and additionally the content field of the same indexed post shown above was now empty, meaning the shortcodes had been processed but no results returned.

WPBakery stores content the traditional way, that is in the content field along with its shortcodes, as shown in this (partial) example:

<p>[vc_row width="full" content_placement="middle" columns_type="boxes" boxed_columns="medium"][vc_column animate="afb"][ultimate_heading main_heading="Fast Docking™ - for increased repair productivity" heading_tag="h5" el_class="uppercase" main_heading_font_family="font_family:|font_call:" main_heading_style="font-weight:bold;" sub_heading_font_family="font_family:Montserrat|font_call:Montserrat" main_heading_font_size="desktop:18px;"][/ultimate_heading][/vc_column][/vc_row][vc_row width="full" color_scheme="footer-bottom" content_placement="middle" el_class="dimmedlightblue"][vc_column width="1/12" offset="vc_hidden-xs"][/vc_column][vc_column animate="afb" width="5/12"][us_separator][vc_column_text]The efficiency of docking, launching and repair operations of ships is influenced by which solutions are used.</p>

It is therefore likely that indexing WPBakery-infused posts would result in a content field containing either

• (with WPBakery enabled) all content, possibly including those within shortcode attributes, but without the shortcodes themselves, or
• (with WPBakery disabled) all content, including the shortcodes themselves

[christian]

Hey @alfgundersen,

Thank you for providing more details. I believe Cornerstone’s now deactivated in your site as I’ve searched for “harda” and it showed up in the search results in all languages.

Would you mind activating Cornerstone so we could check the search results again. Or, you can take a screenshot or you could give us WordPress Admin access so we could grab setup information in your site and then we’ll note this case in our issue tracker.

I’m sorry for being repetitive but it’s important to clear stuff.

Thanks.

[alfgundersen]

Cornerstone was enabled again, but I hadn’t reindexed yet. I’ve done this now.

Note that only the post type Page makes use of Cornerstone (if I recall correctly).

If you look now you’ll see that no results are returned on either English or Nynorsk. On Bokmål you’ll see the following:

The highlighted result corresponds to the first one in your screenshots. As you can see the content is gone, including the shortcodes. The remaining results are of other post types that do not make use of Cornerstone.

[ruenel]

Hey @alfgundersen,

I am just wondering. How did you translate your pages built with Cornerstone? Did you follow the steps provided by WPML to translate Cornerstone built pages? If the pages built by Cornerstone were indexed with Algolia and then those translated pages were not, then most probably the way the pages have been translated caused an issue.

Please review this documentation:

• https://wpml.org/documentation/theme-compatibility/xtheme/

[alfgundersen]

WPML’s Translation Editor didn’t support Cornerstone’s new elements at the time, so we had to duplicate the pages to the other languages, deactivate the pages’ auto-sync, and edit/translate the duplicates manually through Cornerstone.

I tested creating a new Page now with a Cornerstone Text element, together with translations using both the Translation Editor and the old method described above, and interestingly both translations are now being indexed along with the original. Unfortunately, the content is still missing, as can be seen if you try to search for “test” (http://ferdedev.wpengine.com/?s=test&is_v=1) and look at the first result:

[christian]

Hey @alfgundersen,

Thanks for further testing and giving us more details. Regarding your latest screenshots, Algolia returned those pages because they all have the word “Test” in the title. If you actually search for the content of those pages, Algolia could not find them. Specifically, Algolia could not find contents of V2 Elements maybe due to their dynamic nature.

I found out though that if you’ll use Classic Elements, Algolia could find it like this Gravity Form fields.

Regarding the search result output, please try using a Classic Text element and not a V2 (non-classic) Text element.

Algolia integration V2 elements integration would need to be reviewed and/or researched by our development team if they’re going to add Algolia support in the future. I’ll post this to our issue tracker now. Please just note that we could not promise anything at this point.

Thanks.

[christian]

UPDATE: I confirm that V2 elements could not be found unlike the Classic ones.

If you need a nice search result output though, I’d recommend that you place your content in a Classic Text element because as you can see in the screenshot, the Accordion Headline and Accordion Content are jammed together. That’s even if you place a Classic Text before it.

[alfgundersen]

Thank you for investigating this. I will report back to the client, though replacing all V2 elements with Classic elements on all pages (and all languages) is likely too much work.

Feel free to close this ticket for now if you don’t have anything further to add. I would appreciate any updates you might have in the future regarding this issue though.

[Prasant]

Sure, I would also suggest you to keep an eye on Changelog page as product related announcements are communicated from there.

https://theme.co/changelog/