The issue we are seeing was supposedly resolved in 7.15.1, and the resolution seems to have helped judging by the lack of follow up on that issue.
However, I am still seeing this behavior in our production environment. For any page on the site, I get a yellow screen when I attempt to preview. The message reports that the XML cache is corrupt. A health check doesn't fix it. A workaround listed in the issue does: I can turn on the Legacy mode for preview to fix it.
My question: is there any security risk in using the legacy mode? As Shannon Deminick said in the ticket, "It's called 'Legacy' for a reason." So, I don't want to be imprudent by turning it on if that's not advisable.
The other possibility would be to apply a fix for this, but I'm at a loss as to how to troubleshoot. I made a full copy of the website on my local machine and it works fine there, so I've had to debug in the production environment.
I do see timeouts in the logs. Maybe there's an index that didn't get applied during one of the upgrades?
Essentially when I've run into this problem as an upgrade, it's been a result of the in memory preview cache being out of sync with the database preview cache.
If that's the same for you then a brand new item, should preview ok, and it explains why working locally 'works' as those items haven't been previewed before on your machine.
There does appear to be a fix for this, earmarked for 7.15.8:
I do think it is related to the upgrade(s), too. And maybe MariaDB/MySQL.
I changed back to the newer preview mode and tried the secret URL twice. It just spins forever. The network tab in Chrome showed the request as pending for as long as I had the patience to wait (at least 15 minutes). The preview mode continues to show errors. I've switched back to the legacy mode for now.
I'm guessing the failure to load at the republish URL is indicative of some deeper issue perhaps with the data structure in the database or with the queries being used to pull the information.
During the upgrades that led to this issue, I had to hunt down and manually apply a couple of the SQL updates because they weren't compatible with the MySQL variation of the SQL language. I'm wondering if I missed something...
But then I return to the fact that it works locally.
You're response answered my primary question -- the legacy mode seems fine to use from a security standpoint, so I'll mark it as the answer. It would just be nice to figure out why it won't work the other way.
My guess is there is something not quite write with preview database table content, but you say it works locally? - is that with the same database or a copy?
Issue #5921 revisited: Preview mode doesn't work
I have a site running on 7.15.6. We are seeing the issue described in this closed issue:
https://github.com/umbraco/Umbraco-CMS/issues/5921
The issue we are seeing was supposedly resolved in 7.15.1, and the resolution seems to have helped judging by the lack of follow up on that issue.
However, I am still seeing this behavior in our production environment. For any page on the site, I get a yellow screen when I attempt to preview. The message reports that the XML cache is corrupt. A health check doesn't fix it. A workaround listed in the issue does: I can turn on the Legacy mode for preview to fix it.
My question: is there any security risk in using the legacy mode? As Shannon Deminick said in the ticket, "It's called 'Legacy' for a reason." So, I don't want to be imprudent by turning it on if that's not advisable.
The other possibility would be to apply a fix for this, but I'm at a loss as to how to troubleshoot. I made a full copy of the website on my local machine and it works fine there, so I've had to debug in the production environment.
I do see timeouts in the logs. Maybe there's an index that didn't get applied during one of the upgrades?
Hi George
Essentially when I've run into this problem as an upgrade, it's been a result of the in memory preview cache being out of sync with the database preview cache.
If that's the same for you then a brand new item, should preview ok, and it explains why working locally 'works' as those items haven't been previewed before on your machine.
There does appear to be a fix for this, earmarked for 7.15.8:
https://github.com/umbraco/Umbraco-CMS/issues/6472
When I had the issue after my upgrade, I was able to rebuild the preview cache by visiting the following 'secret' Url, and clicking to rebuild:
/umbraco/dialogs/republish.aspx?previews=true
so that might be worth giving a try! rather than switching back to legacy.
(The rationale for the new preview is here: https://github.com/umbraco/Umbraco-CMS/issues/5059 so it's more of a performance thing, particularly on larger sites, if you can get it to work! ;-))
regards
Marc
Marc,
Thanks for your response.
I do think it is related to the upgrade(s), too. And maybe MariaDB/MySQL.
I changed back to the newer preview mode and tried the secret URL twice. It just spins forever. The network tab in Chrome showed the request as pending for as long as I had the patience to wait (at least 15 minutes). The preview mode continues to show errors. I've switched back to the legacy mode for now.
I'm guessing the failure to load at the republish URL is indicative of some deeper issue perhaps with the data structure in the database or with the queries being used to pull the information.
During the upgrades that led to this issue, I had to hunt down and manually apply a couple of the SQL updates because they weren't compatible with the MySQL variation of the SQL language. I'm wondering if I missed something...
But then I return to the fact that it works locally.
You're response answered my primary question -- the legacy mode seems fine to use from a security standpoint, so I'll mark it as the answer. It would just be nice to figure out why it won't work the other way.
Thanks!
Hi George
My guess is there is something not quite write with preview database table content, but you say it works locally? - is that with the same database or a copy?
regards
Marc
The local site is a complete copy (files and database), so not the same database. I ran a mysqldump and applied it to a fresh local copy.
is working on a reply...