Change History (121)

In r41806 we added caching to the list of files fetched from themes, this means any changes to the filesystem won't instantly show up, it can take as long as an hour for them to show up.

It was originally intended for the code editor screen, but I'm not entirely sure it's bad that it also affected the selector for page templates, if a theme has a lot of files that part of the backend could be slowed down by the need to iterate over files often.

I'm also not sure caching was a good idea there, at least this can be explicit option (in wp-config for example). Otherwise it would be a surpise for any WP developer how to edit/add theme template files in the nearest future). We should be bumping the version of the theme!

If you're adding a whole new page template, I would respectfully suggest that the theme version must be bumped. However, in development, this would be confusing the first time it were encountered.

Most systems with caching should have a "flush all the caches" button somewhere.

A "flush all caches" could be a good feature but for now these patches seems good.
For a "flush all" we should think about wp_object_cache and the cases we do it with transient (like this case - are there another cases?) and maybe create ways to cache plugins be flushed in same button (so we are not just adding one more button to users).

For a "flush all" we should think about wp_object_cache and the cases we do it with transient (like this case - are there another cases?) and maybe create ways to cache plugins be flushed in same button (so we are not just adding one more button to users).

Yes its a wider thing really. Would be most excellent if there was one WP trigger to flush caches; transients which (may) no longer apply; and "everything" that could be a one process cache clear-ify. Hmm, wonder if this idea exists anywhere!?

There definitely needs to be a way to disable this completely as it makes theme development a chore. Having to bump version number, or the suggestion of having to clear the cache manually, every time a new template is added is not a solution.

Please add the option to disable this. I just wasted a bunch of time trying to figure out what I was doing wrong. Thanks to the people who suggested changing the version number... but what a pain while developing.

The WP_DEBUG should be enough if you ask me for local development. If someone uploads a new template through FTP, let's say, their live/staging site with a disabled WP_DEBUG, the page templates won't be refreshed.

Maybe we could also add a button that could delete the cache on request. This button could be under Appearance > Themes on the active theme block. Something like this: ? But that could be a little too intrusive to regular users? Not sure.

There definitely needs to be a way to disable this completely as it makes theme development a chore. Having to bump version number, or the suggestion of having to clear the cache manually, every time a new template is added is not a solution.

Agreed. I can't believe this was overlooked. I just wasted a bunch of time because of this!

We'll definitely not add any buttons to the UI that will rarely, if ever, see use by actual users.

If we do decide to keep the transient in place, I do like the WP_DEBUG check, with it in use there's no need for the extra functions to clear things, as the version bump invalidation should take care of things for end users, but the patch needs refined a little.

I looked at 42573.3.patch​ and it just checks if WP_DEBUG is true or false, it also needs a check if it's defined altogether.

On a side note, I agree with adding the transient here, now that we recursively scan through the whole theme directory the operation can become heavy when we take into account 3rd party premium themes as well which are known for bundling plugins and other large code bases making them substantially more time consuming than they used to be.

If we do decide to keep the transient in place, I do like the WP_DEBUG check, with it in use there's no need for the extra functions to clear things, as the version bump invalidation should take care of things for end users, but the patch needs refined a little.

I don't think the WP_DEBUG check is enough here. Plenty of users that create custom templates never heard of WP_DEBUG, and bumping the theme version is not an obvious step either.

Could we disable the caching for files in the theme's root directory (which seems to be where most users upload custom templates), and only use it for subdirectories?

If we do decide to keep the transient in place, I do like the WP_DEBUG check, with it in use there's no need for the extra functions to clear things, as the version bump invalidation should take care of things for end users, but the patch needs refined a little.

I don't think the WP_DEBUG check is enough here. Plenty of users that create custom templates never heard of WP_DEBUG, and bumping the theme version is not an obvious step either.

Could we disable the caching for files in the theme's root directory (which seems to be where most users upload custom templates), and only use it for subdirectories?

This feel like a half measure and would not help with themes that put template in subfolders. WP_DEBUG along with documenting this somewhere would be a good first step. An option somewhere in the UI to flush the template cache would also help non-developers. But WP_DEBUG at a minimum.

This way we are covering the 3rd party premium themes and not being a problem to users who creates files into your (child) themes.

Not sure about that. I have seen a lot of child themes having much more templates than the parent themes. Some of the parent themes are just used as frameworks such as the Genesis Framework.

I would consider maybe adding a simple (?) tooltip next to Page Template (?) which on hover would say that the templates are cached and if new templates were added, they should bump the theme/child theme version? It seems logical to bump the version since new templates were added.

What exactly is the benefit of this? If a theme has so many templates that it would benefit from caching the admin meta box I think there's probably a bigger problem than some cache is going to solve...

Reverting this would be a win for sane theme authors. Why improve things for authors who choose to do ridiculous things?

What exactly is the benefit of this? If a theme has so many templates that it would benefit from caching the admin meta box I think there's probably a bigger problem than some cache is going to solve...

Reverting this would be a win for sane theme authors. Why improve things for authors who choose to do ridiculous things?

Agreed. I'd yet to see a theme that has anywhere near 100 levels deep of a folder structure. If that's the case, the theme is the problem.

Again we've introduced unintended consequences to core by fixing a problem that never needed to be solved in the first place.

+1 to revert any form of caching around this and maybe revisit the changes in r41806 to see what problem they're solving and if this is even appropriate.

Nobody should be forced to use WP_DEBUG, nor should another useless button to purge this unnecessary transient be added somewhere in wp-admin.

As a developer, if I deploy a file update to a client site (live or staging) I should be able to use that template right away. Not be forced to wait up to an hour just for the cache to expire to select it. Think of the poor experience that a user is going to experience if they update a file in a theme and can't select it? That goes against the goals of the project plain and simple.

@ryanduff if it were very simple to flush the caches, would you still have an issue with this being present? I like caching things that do not (normally) change, particularly if it can speed up admin pageload in poor and shared hosting... otherwise "WordPress is slow" will be the user takeaway.

Surely here we're talking about a surprise to a developer in their workflow versus slow(er) admin performance for *all* users of WordPress.

Assuming developers get a solution as a result of this conversation, that would be a win win? Without reverting anything?

@ryanduff if it were very simple to flush the caches, would you still have an issue with this being present? I like caching things that do not (normally) change, particularly if it can speed up admin pageload in poor and shared hosting... otherwise "WordPress is slow" will be the user takeaway.

Surely here we're talking about a surprise to a developer in their workflow versus slow(er) admin performance for *all* users of WordPress.

Assuming developers get a solution as a result of this conversation, that would be a win win? Without reverting anything?

No. Again, r41806 got "clever" by introducing a max depth of 100 levels to the file list function. This is not needed nor is caching around it. Find me a bug where someone complained the page editor screen was too slow because their theme was bloated with files. What does this fix? Nada.

If you have slow admin performance it's because (a) Core changed to scan 100 levels deep in your theme folder and (b) you're using a theme so bloated it's now affected by this change and you should probably find a new theme.

This is not just a developer issue. It's only a matter of time before end users run into this issue as well (if they haven't already reported it in the forums).

The bigger issue here is template files not being available because the list is cached, not that the editor now supports editing theme files 100 levels deep.

This is not just a developer issue. It's only a matter of time before end users run into this issue as well (if they haven't already reported it in the forums).

Yes, one thing I noticed is the page template list being cached when trying to assign a custom field group to a specific page template in the Advanced Custom Fields plugin. End users could definitely run into this without any idea of how to fix it.

I don't think the WP_DEBUG check is enough here. Plenty of users that create custom templates never heard of WP_DEBUG, and bumping the theme version is not an obvious step either.

Could we disable the caching for files in the theme's root directory (which seems to be where most users upload custom templates), and only use it for subdirectories?

This feel like a half measure and would not help with themes that put template in subfolders. WP_DEBUG along with documenting this somewhere would be a good first step. An option somewhere in the UI to flush the template cache would also help non-developers. But WP_DEBUG at a minimum.

I meant disabling caching in the theme's root directory in addition to the WP_DEBUG check, not instead of it. A UI option seems like a non-starter though, as it contradicts the WordPress' philosophy of "decisions, not options".

That said, I agree with @ryanduff in comment:36, caching should not be necessary here at all.

This should 100% be disabled by default.. with a setting somewhere that allows you to enable it.
I don't understand the logic behind this feature at all.. if your theme is built properly, than there should never be an issue here.
Just wasted over an hour tearing my hair out trying to figure out why my templates weren't showing.

@ryanduff am not even playing devil's advocate on this... I did not like the original implementation nor did I see it as necessary. BUT there was presumably some thinking behind it which may not need to be thrown out?

I am working on a solution to postmeta slowness for which the proposed fix was also caching. Also in that case, I did not think caching would be a good solution.

Caching is not a band aid to fix inefficient code.

That said, we should not just scrap something because it raises tickets - if it is the right thing to do. In this case, what was the original ill being fixed?

Thank you @westonruter for making the fix into a plugin. It is working for me.

I think this is a bigger problem than just fixing bugs in a new release, because the 4.9 wordpress update essentially disabled a core wordpress feature with no explanation or way to fix it for the average user. It honestly makes me wonder how something like this was able to make it into the release in the first place. Like what is the decision making process to allow a change like that without appropriate review of the consequences for users. Any user like myself would have no idea that now, after creating a new page template, we will not see it appear for up to an hour, so for all intents and purposes custom page templates is now non functional. I spent a lot of time trying to figure out why my page templates didn't show up anymore, when I was doing exactly the same thing a few days ago with no problems. Literally copying the code of an existing page template (which showed up in the template list dropdown) and saving to a new renamed template would not show up in the list. It was a completely bizarre and frustrating situation. I really hope this gets looked at as a systematic issue beyond just fixing the bug because it I feel it undermines the trust in the excellence in wordpress with users and the expectation that new releases will improve things for the user.

I see the advantages of applying file list caching here, but breaking things for end users and developers through the unintended consequences is something that can be avoided without much fuss... My suggestions:

Identify what events could clear the file list cache for a theme when in the admin side? Maybe something simple like clearing the theme-specific file list in the function get_page_templates so at least it doesn't affect the standard UI selection etc.? eg.

I'm not sure why this transient key structure? Seems to have come from the plugin file list side? But it's a bit of a mismatch to the rest of the theme class transient keys, otherwise it could be more simply cleared using WP Theme clear_cache method - which in any case is the other place where the theme file list could (and probably should) be cleared.

Add a filter to disable file caching for a particular theme, this way theme developers could set the filter in an mu-plugin or something locally and not have to worry about the theme file list cache while they are developing. eg. in WP Theme method get_files instead of $all_files = get_transient( $transient_key ); just:

Also as a sidenote going from just a few subdirectory levels to 100 levels seems like going from one extreme to the other... Sure it's well beyond time that it increased, but it seems it's this extreme swing that then required the caching for performance, which then caused this problem. 10 would have been a safe maximum depth, with a filter for anyone really wanting more if needed in a particular plugin / theme.

On a related note, only using a depth of 1 for searching page templates in the WP Theme method get_post_templates method while the levels are now cached 100 deep seems a bit bizarre. Doesn't it precludes template directory structures as simple as /content/post/ ? Any reason not to simply bump this value up to 2 or 3?

Just a thought that I had ... what if an ENVIRONMENT variable was introduced (in some form). Then the code to cache the file listing could do a check of this ENVIRONMENT variable and only cache the listing if the value was set to "production" (or something along those lines).

I personally don't set WP_DEBUG to true while I'm developing my themes and plugins, unless I'm troubleshooting an issue. But it would be easy for me to set up an ENVIRONMENT variable in the wp-config.php file when I'm setting up my local development environment or a staging environment.

I've seen thing kind of variable in CodeIgniter and in Laravel. And I can imagine that it would be useful in other situations moving forward than just this one.

What exactly is the benefit of this? If a theme has so many templates that it would benefit from caching the admin meta box I think there's probably a bigger problem than some cache is going to solve...

Reverting this would be a win for sane theme authors. Why improve things for authors who choose to do ridiculous things?

Exactly, it also moves away from what Wordpress was all about, a default which you extend by using plugins. If someone requires this then there are plenty of options to add functionality via plugins. No need to have something like this in the core.

As a business owner of a maintenance service where we do our best to keep things as stable as possible for our clients, two things are really surprising to me here:

How could a feature like that be proposed, accepted and introduced into core without anyone noticing it? I did not see any information about this in the release notes or in the documentation. Did I miss anything? I truly hope it was documented somewhere and I missed it.

Some people propose a patch, to add a button in the UI, to consider looking for WP_DEBUG, ... And then suddenly decisions are made to remove this functionality based on no real explanation. I totally agree with @ryanduff about the fact that it "seems" to be solving a non-issue. Is it really ? As if the most used web software in the world could accept code in its core without anybody noticing it and remove it in a heartbeat.

Can anybody from the core team step up and let us know:

Why was this feature introduced ? What problem does it solve? If any...

What is the status on their thoughts now that this seems to cause more trouble than good?

What will be done in the future to make sure we don't break things with functionalities like this ?

I just want to be clear, I'm not trying to point a finger at anyone. I'm looking for a long-term solution because it seems unacceptable to me that a software like WordPress, used by hundreds of millions of websites, have issues like this.

Why was this feature introduced ? What problem does it solve? If any...

See above. It's related to changes in the file editor in #6531 via r41806. In previous version of WordPress, files would only be listed 2-levels deep. In 4.9, the entire directory tree for a theme is now listed regardless of depth. Recursively gathering a list of files can be expensive for large themes, so that is why caching was enabled. An unintended side effect of the caching is that the same directory listing function get_files is used both for the theme editor and for gathering page templates.

One change could be to only use caching when calling get_files with a $depth greater than 1. Note that get_post_templates will explicitly call get_files with a $depth of 1 already. I believe the only place where infinite depth of -1 is used is for the theme editor, and in that low-traffic'ed place, caching may be overkill anyway. So as long as we can confirm that infinite depth calls to get_files is limited to file editor, I would +1 removal of the caching.

+1 for removal or at least better error handling when the cached files are no longer found to explain what happened. Perhaps that would be a good place to put a "Clear File Cache" link if no where else.

+1 for removal or perhaps a message on the theme editor saying the files there are being cached and a link or button to clear as desired or even better deactivate it while on development to have more control of it.

I wouldn't mind seeing the cache being used in template functions such as locate_template().

Initially, I was all in favor of just using WP_DEBUG as the enable/disable flag for caching theme files until I realize that on live sites, I still keep WP_DEBUG and WP_DEBUG_LOG enabled to take care of any issues that crop up. So I would need to make a choice, what's better for this live site, caching the theme files or being able to log any potential issues that may crop-up upon plugin / theme updating?

I like the functionality but I don't like ( along with many others ) it interfering with my development speed. I'm in favor of an additional wp-config flag to enable / disable this type of caching functionality; that's my vote.

I have been watching this ticket #42573 because customizer fails to load since the WP 4.9 upgrade on a one page site using [Avata Pro] template I have been trying to complete an update for ​http://evolutioncovers.com but have NO access to edit widgets or cover page sections etc since 4.9 was installed via WP update. Jumping in to inform that I tried two different [clear cache patches] without resolve in my case. Appreciate all of your work on this because - PHP (I know not} Will continue to watch and hope for a resolution.

Replying to Clorith:
I have been watching this ticket #42573 because customizer fails to load since the WP 4.9 upgrade on a one page site using [Avata Pro] template I have been trying to complete an update for ​http://evolutioncovers.com but have NO access to edit widgets or cover page sections etc since 4.9 was installed via WP update. Jumping in to inform that I tried two different [clear cache patches] without resolve in my case. Appreciate all of your work on this because - PHP (I know not} Will continue to watch and hope for a resolution.

DISREGARD any changes made by my reply re{: Version changed from 4.9 to trunk} did not see until after submitting

If the caching is only effectively used in the file editor, I vote for removal.

Another option to opt-in to caching for larger themes with loads of folders. If a developer makes such a big theme it should be his or her consideration to implement this kind of caching. This way it ain't an inconvenience for small themes.

+1 for removing caching. There has to be a better way for improving admin page loading times. The consequences of going this route have probably cost the planet 10s of thousands of hours. @ryanduff 's comments are salient.

Reduce the cache time to a slightly more reasonable 5-15 minutes (instead of an hour), which seems plenty for a low-traffic area to me.

Additionally these thoughts came to mind, based on the ticket feedback here:

Consider disabling the cache completely when WP_DEBUG is set - this seems like a bad idea. It'd effectively cause the cached template issue to not exist when a developer started debugging.

Consider only caching the data when fetching it takes longer than a threshold - Does it take 5seconds? Cache it. 50ms? Just query it every time - This could have unintended consequences, an issue which only happens sometimes, gone as soon as they start trying to fix it.

Thinking out loud here, Filesystem caching has always been a minefield, the FS includes a cache already, unfortunately the act of accessing those directories can be slow even if the FS is caching information.

The idea of only having the cache kick in if the speed of looking up this information was slow is an interesting one to me, it would effectively mean that there is no cache, but the moment that the hosts disk is overloaded or you have a 100-folder-deep theme then it starts to cache it for a short amount of time - hopefully long enough to let you do whatever you're doing without further delays.
In this scenario the page templates would still be cached, but only if it was slow in the first place.

An issue I'm not seeing explicitly mentioned is that the 4.9 update effectively frelled live sites that are not under development and have not made recent template changes. Also, if the template cache is supposed to update every hour or so, I’ve not seen any evidence of that.

I updated my sites several days ago and am now receiving emails about pages that were fine before updating to 4.9 – WordPress still has not gotten around to noticing the collection of page templates included in my parent theme. For example, the 4.9 update failed to notice any of my parent theme page templates except for the 'default' template. Pages using the default template or a child theme template were fine, but any pages using one of the optional parent theme templates were reset to the 'default' template. I couldn’t even fix the pages until after finding one of the custom plugins especially developed to clear this new cache.

In addition to clearing the cache, I first had to copy all of the parent theme page templates into my child theme folder in order to get WordPress 4.9 to notice optional page templates included in the parent theme. Arrrghhh...

I'll be spending the rest of the day copying template files, clearing the template cache on ten different websites and looking at pages to see which ones I need to manually reset to use the proper template.

Until this is fixed - it’s probably worth noting that instead of adding a temporary plugin or bumping your style.css version (which you might not want to do until releasing), if you’ve got wp-cli installed you could run wp transient delete —all.

Until this is fixed - it’s probably worth noting that instead of adding a temporary plugin or bumping your style.css version (which you might not want to do until releasing), if you’ve got wp-cli installed you could run wp transient delete --all.

Please make this caching stop. I spent the better part of an hour asking myself if I'd finally pushed myself over the edge. In the middle of a development sprint. I guess I can't imagine a world in which cached template lists are useful, at all.

@Otto42 For the file lists in the editors, as we don't control the structure that will get parsed and the depth that will need to be traversed, this can potentially take minutes to complete. The caching is a kind of safeguard to not enable people to bring the entire server down because they totally trash IO bandwidth.

I've added a new patch 42573.5.patch that disables the caching for theme files if the requested depth is 1 or less. The template files are all being scanned with a requested depth of 1 for the PHP files and 0 for the CSS file. So, this should effectively disable caching in regards to the templating completely, while still keeping it as a safeguard for the code editor.

Also, I reduced the expiration of the cache from 1 hour to 5 minutes. This will still throttle I/O usage, while reducing the negative side effects of caching.

@schlessera I get that file IO is a thing, but the previous editor didn't have this cache, and I don't recall any reports of people having issues with it trashing their IO. Yes, you could conceivably make a plugin nest so deeply that a simple scandir takes forever and breaks the site, but realistically, PHP only has 30 seconds to run and it will get killed off before that happens. Also, we'd remove the plugin from the directory for being stupid like that.

So, again, what *actual* problem does this solve? Not theoretical, but is there any real instance of a plugin that takes more than a few seconds to do a scandir of? Jetpack is the biggest most complex plugin I'm aware of, and it works just fine.

So, yeah, I'm still voting to just remove the transient entirely. It's creating problems, not solving them. Your patch for 5 minutes is great and all, but it's probably better to not have a cache than to cache preemptively for no real reason.

@Otto42 Yes, the previous editor didn't have that problem, but that editor also limited the folder recursion to two levels deep. Therefore, it didn't run the risk of getting caught in endless node_modules hierarchies or similar.

With the new editor, the recursion limit was lifted (technically, it still stops at 100 levels deep), so the risk is much bigger that something bad will happen.

Oh, what I should mention as well: This is not about plugins, they are not part of this ticket. This is about the get_files() function that is being used for themes.

A lot of themes nowadays contain custom JavaScript code, that relies on dependencies pulled in via npm/yarn. Given that the code editor is meant to be used for live coding of themes on the server, this will in turn mean that the node_modules folder will also need to reside on that server, and it can typically contain tens of thousands of files.

@schlessera I think that what you basically say is that with themes that follow modern development practice (and actually plugins do that as well, so not sure why the separation at all), the whole editor thing is "false advertisement", as you can not actually edit a JS or CSS file and see results as either the theme has a build process that needs to run (JS) or you better do the change at SASS/LESS files to have them properly apply everywhere.

I agree with otto42, the impact of the caching should first be measured against a proper setup with a complex theme on a typical hosting server, not a local dev machine, as it has too many processes running to be able to deduct anything from testing on it. Then you can compare performance of cached version to non cached, and different caching intervals. My gut feeling, is that since we are talking here about human scale response times, 5 minutes will be too short and it will feel like there is no caching at all.

IMO for 4.9.1 caching should just be scrapped. This is the path of least resistance and least risk. Then if some complex themes create an actual problems to users you will be able to have a judgment call on whether it is a theme problem that is not worthy of being handled in core.

In any case, for people that have the editor disabled, caching should never be triggered, or better, have the caching limited to the context of the theme/plugin editor.

Ug another vote to disable this - why on earth would caching this list be useful? I am developing a theme that will need to add several templates - this literally makes it a nightmare to do one of the most basic things in WordPress :(

Theme/Plugin Editor: Remove the caching added in [41806] as it causes more problems than it fixes.

While caching here seemed like a good idea in theory, in practice the cache would be often stale causing development issues.
We exclude common folders (such as node_modules) from the scanning to avoid directories which are not useful to the end-user, so as long as those exclusion lists are held up this shouldn't cause too much of a degredation in the future.
We may consider adding caching here again in the future if it's determined that it is really needed.

Props precies, ibenic, mariovalney, schlessera, and all the others who commented on the ticket(s).
This partually reverts [41806].
See #6531.
Fixes #42573.

Theme/Plugin Editor: Remove the caching added in [41806] as it causes more problems than it fixes.

While caching here seemed like a good idea in theory, in practice the cache would be often stale causing development issues.
We exclude common folders (such as node_modules) from the scanning to avoid directories which are not useful to the end-user, so as long as those exclusion lists are held up this shouldn't cause too much of a degredation in the future.
We may consider adding caching here again in the future if it's determined that it is really needed.

Props precies, ibenic, mariovalney, schlessera, and all the others who commented on the ticket(s).
This partually reverts [41806].
Merges [42242] to the 4.9 branch.
See #6531.
Fixes #42573 for 4.9.

It's working here. And as I said, I confirmed it in one fresh install after 4.9.1.
So... I guess it could be a problem in your instalation/theme and shouldn't be reopen.

I'm glad it works for you. It's great, super even!

However that doesn't mean that @simonp303 doesn't have a problem with this functionality. In my view the best qualities of open source is, well, open source, and collaboration, and WordPress is especially famous for an inclusive, welcoming, and collaborative tone, so all problems, regardless of the reporter's level of technical expertise or language capabilities (English as a second language, etc) can get help and are not discouraged from future participation by people who shoot them down. Hope that's fair :).

Going back to the issue. Downgrading back to 4.8.3 makes the template appear. Using 4.9.1 doesn't. There is a genuine problem here. It warrants further examination.

I wonder if you are using a child theme? When this bug first appeared, only my child-theme templates and the parent theme's default page template appeared as options in an edit window. I had to copy all my parent theme page templates to my child theme folder and then clear the cache (I used the 'WP Clear File Cache' plugin by Seismic).

If WordPress is still not registering parent-theme templates the problem may not be totally fixed...

I wonder if you are using a child theme? When this bug first appeared, only my child-theme templates and the parent theme's default page template appeared as options in an edit window. I had to copy all my parent theme page templates to my child theme folder and then clear the cache (I used the 'WP Clear File Cache' plugin by Seismic).

If WordPress is still not registering parent-theme templates the problem may not be totally fixed...

It is a parent theme - so no child theme. I have cleared all caches and transients that I was able to with WP-CLI. It is a very very basic theme as well. Nothing unusual about it and no unusual plugins (only Yoast and ACF).

The issue is that I would not be here had I not tried many many many things :) Hence why I feel this is still an issue. The whole point of WordPress is to develop it and make your own themes. Its no good saying it works in a different setup. That just sounds like a developer response like "well it works fine for me" etc :p

The issue is that I would not be here had I not tried many many many things :) Hence why I feel this is still an issue. The whole point of WordPress is to develop it and make your own themes. Its no good saying it works in a different setup. That just sounds like a developer response like "well it works fine for me" etc :p

That's true...but so is, "It's not working for me," without providing any information on how to duplicate the problem. Nobody is going to be able to help unless the issue can be duplicated, and so far there are no steps, links or downloads on how to do so.

When you do decide to provide these steps, please be as detailed as possible, as if you are writing for someone without experience with WP (within reason of course!). I have found more than once that the act of writing the duplication steps in this way reveals the true source of the issue. And make sure you're using no plugins and a core theme to start :)

As it turns out, there still exists some caching ability of page template names in WordPress, which has been there for over 6 years - r20029
However, WordPress specifically does not enable the caching of page templates, a plugin would need to specifically enable that.
If you're still experiencing issues here, I'd suggest looking at whether you have any caching plugins installed, or a wp-content/object-cache.php file in place.

As it turns out, there still exists some caching ability of page template names in WordPress, which has been there for over 6 years - r20029
However, WordPress specifically does not enable the caching of page templates, a plugin would need to specifically enable that.
If you're still experiencing issues here, I'd suggest looking at whether you have any caching plugins installed, or a `wp-content/object-cache.php file in place.

I tried to disable all plugins and not found any objects-cache.
This issue reproduced only on one quick-built site for friend...
If you interested in I can give you temp access (FTP+admin panel) and you can see it your self.
Contact me on ​facebook