After updating from Pro 5, native WPML language defaulted to English - Part 2

[Misho]

Hi @charlie,

Unfortunately the original thread got closed because I was fixing other websites and only now got back here.

Pro 6.1.9: After updating from Pro 5, native WPML language defaulted to English

Okay 6.2.0 will have the new migration for the WPML custom layout types issue. Run it in a staging with Pro5 data and let me how it goes on your end. I’ll be checking out the translation issue with WC layout types as well next week. Have a good weekend!

I just performed an update from Pro 5 to 6.2.2. The layouts were broken but after a while they started working. The WPML issue was not fixed but also after a while it started working. These new Pro versions are much more Caching sensitive than what they used to be. Nevermind, it is important that it is working now.

One issue remains though: When I launch Cornerstone, Archive and Single layouts are not listed. I can go to a certain layout and edit it, but it is not listed.

Thanks!

[charlie]

Hey that’s great. Sites looking good on my end. If it started working after a certain time, I think that’s because entering Cornerstone kinda self heals it. I have a feeling for WPML we’ll need to run the migration twice as WPML filters out posts from the default language in this particular post grab at first. And then running again after the default language is moved to get the translations. Thanks for confirming this.

I actually couldn’t access this site with the credentials. I don’t remember seeing this issue on your site when I ran the migration, but I’ll gladly checkout what’s up with your document list.

[Misho]

Hi @charlie ! Sorry about the login, not sure why it didn’t worked. I reset the password, it works now.

Yeh, the documents list still lacks Archives and Singles.

Thanks!

[charlie]

So I don’t think you have an Archive layout. Which brings up an interesting UX point that it should definitely show you all types even if you have none. It also leads this to this other feature that was requested to have a “+” button next to each post type.

For the reason why you’re not seeing a better list I’d check out this post. I think we also need to just remove external filtering from plugins or have an option to turn it off. The list is also different in my local, so I’m guessing it’s some plugin I don’t have. Grabbing every post individually by post type would also ensure you’d at least see data for each post type. There’s a couple of things we can do to spruce up that list and it’s definitely on my horizon. I don’t think I can give you anything right now though unfortunately.

https://theme.co/forum/t/6-2-1-pages-missing-from-docs-list/104514/6

[Misho]

Hi @charlie!

Thanks! I didn’t understand the part where I don’t have an Archive layout.

This is the screenshot from the layout builder on the live website where Pro 5 is active:

Those should still be appearing after updating Pro on the staging website, but they are all missing, apart from the “Cart layout” that is newly created. Disabling all plugins except WooCommerce hasn’t helped. In addition, staging copy has the same plugins as the live site.

There is no Blog index archive, that’s true. I created one quickly and that hasn’t changed anything either. When I’m on the Blog page, I can click “Edit Layout” and it is all fine, but it is still not listed. The whole “Archive layouts” section is missing from the list, as well as “Single layouts”, WooCommerce Singles" etc.

I updated the secure note with the live website access.

Thanks!

[charlie]

I think the following filter in the child theme is cutting out posts and thus post types from your document list. Is there a reason that’s there? It looks like you were profiling the locator at one point. How did it go? I bumped the number to 100 on the staging. The default is 100 for reference. Let me know if this info helps.

add_filter( 'cs_locator_limit', function( $count ) {
  return 15;
});

[Misho]

Hi @charlie, Wow, that was it.

The said code was added by Alexander while he was solving a different issue a while ago:

Preview/Conditions with Page post type stopped working

Thanks @Misho, I’m making progress here, but still haven’t cracked it. Here’s what I’m discovering, some of this might not be useful to know and I’m talking aloud a bit here. Some very interesting things going in. Thanks to some additional testing after having FTP I was able to determine it is running out of memory on those calls. I’ve added this code: add_filter( 'cs_locator_limit', function( $count ) { return 15; }); Thats lowers the number of posts to find from 50 to 20. When I tried it …

I think this entire code was added by him:

Alexander's code

add_filter( 'cs_locator_limit', function( $count ) {
  return 100;
});


function profile_locator( $offset = 0 ) {
  $before = memory_get_usage();
  echo "--------</br></br></br>";
  echo "Begin: " . $before / (1024 * 1024) . "</br>";

  $args = [
	'search' => '',
	'cursor' => $offset,
    'post_types'  => [ 'page' ],
    'post_status' => 'any'
  ];

  $posts = CS()->component('Locator')->query_posts( $args );

	var_dump(array_map( function($post ) {
		return $post['id'];
	}, $posts ));
  
  $end = memory_get_usage();
  echo "End: " . $end / (1024 * 1024) . "</br>";
  echo "Delta: " . ($end - $before) / (1024 * 1024) . "</br>";
	
}

add_action('cs_output_debug', function() {
  profile_locator(0);	
});

Maybe the newest Pro doesn’t need it anymore, I have no idea.

[charlie]

Very interesting and that explains a lot thanks. I don’t think any of that debug is going to run without the developer plugin or dev build so you can remove especially if your document list is fine. I see new code in 2022 related to this part of the code so it’s possible some of the memory issues are handled here, but let me know if you see issues there. I’ll keep this code available for us internally.

[Misho]

All right!

I removed the code and made a full update.

Patience was again the key after the update. Translations were not working, layouts were broken at first. Clearing the Cornerstone System cache didn’t helped immediately, but resaving permalinks did. The site gradually fixed itself after the update.

WPML has integrated what used to be the Translation Management addon into the main plugin. Now if I click a page to edit it, it offers all the strings side-by-side.

I have no intention of using this method since we have the Cornerstone flags that we can click and edit the translations that way. One thing that is interesting is that, when the page is translated by switching Cornerstone flags, the Translation Management doesn’t see any translations. It thinks that the page is not translated and it offers an option to start translating.

This is a bit conflicting and potentially confusing for users. I guess the rule would be “Just don’t touch the Translation management part when working with Cornerstone pages”.

On the other hand, when translating stuff such as the Cart page, then the Translation management is the right way to do it.

I don’t even know what is my question here. Just an observation, lol.

Thanks!

[charlie]

Happy to help Misho and thank you for your patience. I don’t think I’ve seen it where WPML wouldn’t show you translations you have. I had to disable something on their end early on as they were not ready for Pro6, but I’m told those updates are live so we’ll take another couple of passes at locking down our WPML integration. At least we’re successfully migrating the custom layouts now, although it could be smoother for sure. I feel like ideally we’d like you to use either their editor or ours for translations, but that’s not always possible when dealing with different designs. Anyways always like your thoughts and let us know if you encounter any other WPML issues!