[Waiting for user confirmation] Custom post type archive template breaks on translation URL

Thank you for all your help with this.

It was pointed out that the *single post* on the *translated* custom post type *archive* shows correctly if no Punjabi characters (unicode characters) are used in its slug. In other words, the "critical error" message of the single post on the archive page goes away when no Punjabi characters are used in the post's slug. This applies to the post listing itself in the query loop, not the design of the entire custom post type archive *template*, which remains broken. Previous screenshots show what is meant by this, if this explanation is confusing.

As a test, I changed all the Punjabi translations of the individual posts to use English characters in their slugs. Then the custom post type archive page appeared correctly. If one of the posts uses Punjabi characters in its slug, then the *custom post type archive page* breaks.

However, I feel this does not explain everything because the translations of other posts appear correctly when using Punjabi characters in their slugs. E.g. hidden link

Why is it only the custom post type posts that can not use Punjabi characters in their slugs, to avoid this issue? And, why do Punjabi characters in the single post slugs cause the *custom post type archive page* to break, but not the single posts themselves?

The 'break' only happens on the custom post type archive page when any of the single posts of that custom post type use Punjabi characters. All other pages of the entire site appear correctly when using Punjabi characters in the slugs (i.e. for pages and posts).

Also, this issue does not happen on category archives of native WordPress posts when the posts use Punjabi characters in their slugs: hidden link

Could our issue be related to the known issue described here: https://wpml.org/forums/topic/archive-custom-slug-translation/ ?

We purposely did not add a translation under WPML > Settings > Post Types Translation > "Set different slugs in different languages for [custom post type name]" because we read that it a known issue with WPML that if we do set a translation in this field, it will cause a break. (See screenshot). We were not made aware that the *single posts* also could not not use translations.

Given that it is a known WPML issue to not be able to translate custom post type slugs at the moment, and all other slugs of native posts can use Punjabi unicode characters, can you confirm that unicode characters in custom post type single post slugs is definitely not a WPML issue?

Although its not completely understood, would this documentation be a solution for us? https://wpml.org/errata/incorrect-links-for-custom-post-types-and-taxonomies-sharing-the-same-slug/

Thank you very much for your help.

Thank you again for all you're doing to help us find the root cause of the issue. It is appreciated.

I copied the default code exactly as it is without changing anything.

I pasted it at the bottom of the Twenty theme functions.php file in the sandbox site you set up for me.

I went to create a new post in that custom post type, so that I could test the URLs with Punjabi characters in them.

However, no editing box showed up at all for me to be able to do this.

I also tried the same code on a test site of our own site, with our theme, and got the same result.

So I went back to the default code creator (hidden link) and started adding options.

This allowed me to add a post on the sandbox site. However, once I left the post editing screen, I could no longer see the post to be able to view its url or change its taxonomies or edit anything any further. I also could not add any translations (the translation of the custom post type archive is the only place where the break happens on our site).

But when I created a new post and tried to view it by clicking the link on its editing screen, I reached a page that said "nothing here." I got the same message when trying to visit the archive page.

I tried to re-save permalinks on the sandbox site, but it did not fix the issue.

So I went back to default code creator again and made more customizations by entering names into the field boxes, this time creating a "Team Members" Custom post type.

I added the "Team Members" Custom post type to the functions.php file of the sandbox site.

I got the same results. I can not edit or re-view the posts that are created. I also get messages that say "nothing here" on the front end. No post has a translation option on it.

As a final test, I added the "Team Member" custom post type code from the default code creator to our test site. I added a team member post and used Punjabi characters in the URL.

After conducting other troubleshooting tests, I have narrowed down the issue to this part of our archive template (which was noted earlier):

	
$loop .= sprintf( '<a href="%s" class="more-link">%s</a>', get_permalink(), __( 'See bio', 'genesis' ) );


printf($loop);

If I take out one or both of those lines, the "Critical error" message goes away. However, the design of the template breaks in other ways (the posts change their size and lose formatting).

I am wondering if anything in those lines stands out to you, which would make Punjabi characters not work well in the context of WPML translation post urls and the custom archive post template?

It looks like that code is trying to get "%s", which is trying to get the URLs with Punjabi characters in them. It can't seem to do this without creating the "critical error" and breaking the page's appearance.

In your expert opinion, if the above theory is true, do you think this is specific to this one template, or do you think the "%s" usually has a hard time in cases like this, with WPML translated posts?

You did speak to the URL issue earlier. I'm curious if you know if this common with the use of "%s" trying to grab Punjabi characters?

Is there another way to get the url of the posts that would not cause this issue?

If it is something the host can help with, can you let me know how to word a question to them? I would be lost trying to explain all this to them.

I added screenshots to this response to describe the issues noted above when trying to test the default code.

Thank you again.