Make WordPress Core

Opened 4 months ago

Last modified 3 months ago

#59834 new defect (bug)

While we update wordpress to version 6.4 getting wrong templates loaded

Reported by: gregoiresailland's profile gregoiresailland Owned by:
Milestone: Future Release Priority: normal
Severity: blocker Version: 6.4
Component: General Keywords: reporter-feedback close
Focuses: template Cc:

Description

Exemple with woocommerce and polylang:
The cart pages is front-page.php instead of page.php
Same for checkout
Also some custom post type pages
I had no time to test more as I had to fix a live website and overrided wordpress with 6.3.2
I think also translations were reporting as 404 template

Change History (12)

#1 @web360pl
4 months ago

Same error for me, also with the polylang plugin. Pages with the primary language display the wrong template file and pages with translations return a 404 error.

#2 @Pirenko
4 months ago

Hi,
I'm having the same issue on different websites with Polylang. And not just with WooCommerce cart.
Thanks!

This ticket was mentioned in Slack in #core by jorbin. View the logs.


4 months ago

#4 @Clorith
4 months ago

  • Keywords reporter-feedback added

Hiya,

I wasn't able to reproduce your issue based on the information we have right now, but I do see that Polylang rolled out a fix ~2 weeks ago for some 404 issues in multisite settings, and I'm wondering if this may be related?

If not, could you share some more details about your setup that may help us replicate the problems, please, as well as information about what plugins you have installed and their versions (did you for example update Polylang at the same time, it's quite common for folks to update many things at once when a new core release is out).

#5 @rebasaurus
4 months ago

Also seeing the incorrect template loaded with tagDiv Composer plugin.

#6 follow-up: @joemcgill
4 months ago

Hi all, I have a suspicion that the issues being reported here could be related to the same problems being reported in #59847 and something with the way Polylang calls get_stylesheet_directory() and/or get_template_directory is causing the wrong paths be saved to global variables prior to the theme being setup.

I would be grateful if someone can test the PR from that ticket to see if it addresses this issue as well.

#7 in reply to: ↑ 6 @web360pl
4 months ago

Replying to joemcgill:

Hi all, I have a suspicion that the issues being reported here could be related to the same problems being reported in #59847 and something with the way Polylang calls get_stylesheet_directory() and/or get_template_directory is causing the wrong paths be saved to global variables prior to the theme being setup.

I would be grateful if someone can test the PR from that ticket to see if it addresses this issue as well.

Hi joemcgill. I changed the /wp-includes/theme.php file according to both ways you suggested in that thread and neither solved the problem. Still all pages run the main page template (front-page.php) and the translation pages (except the main page) return a 404 error. Downgrading the wordpress version to 6.3.2 solves the problem.

#8 @web360pl
4 months ago

I noticed another interesting thing. In my case (tested on several sites) if I restore version 6.3.2 and then re-isntal version 6.4 the problem no longer occurs.

#9 @rajinsharwar
4 months ago

Hi @web360pl, thanks for testing this out. Can you try applying the patch of #59847, and then try flushing the Permalinks? And then check if it resolves?

#10 @rebasaurus
4 months ago

FYI, anything under Polylang 3.5 is not compatible with WP 6.4 due to https://github.com/polylang/polylang/pull/1345.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


3 months ago

#12 @jorbin
3 months ago

  • Keywords close added
  • Milestone changed from Awaiting Review to Future Release

Hi @gregoiresailland, WordPress 6.4.2 included a fix for #59847 which is similar to the issue you reported. Can you confirm if this issue is still affecting you and also check to see if it still appears when you deactivate all plugins?

I'm adding the close keyword since if there is no response, the assumption will be made that this is a duplicate of #59847 and also moving it to Future Release since this has been triaged.

Note: See TracTickets for help on using tickets.