Just recently, we've encountered a problem trying to edit the content of our Home Page. Our site works fine for end users, but when a content editor clicks on the Home Page, they are unable to see the content and eventually the page times out: [HttpException (0x80004005): Request timed out.] The site has been operational since 2007, performing well for us, with many changes to the site.
I'm hoping for some help as to what areas to look into. Especially, whether there are any tools that can look at the integrity of the site if that's where I need to look. Here are some additional details.
Looking at the log, I see these two error lines after the Open log entry:
Macro Parsing Error: System.Threading.ThreadAbortException: Thread was being aborted.
at umbraco.editorControls.tinyMCE3.webcontrol.TinyMCEWebControl.parseMacrosToHtml(String input)
Our test site works correctly. It is on a different web server and uses a different SQL Server. The initial response time for the Home Page in the content editor is lengthy (over a minute) but the page does eventually display.
We will be upgrading our site later this year, but can't do it now.
Wow, that's a really old site! I suppose it features quite an amount of content now...
So the editors can't access the content nodes but are they able to log into Umbraco and see the content tree and expanding the content nodes in the tree?
If so perhaps try and see if you can find the node with the id 2037 by using the search field in the search field in the top, right to the "Create" button in the top left corner (If I remember the old Umbraco UI correctly) - Does this match any nodes? Unfortunately I think that there was a bug in the search back then, which made it 50/50 whether it found the node (Even though the node existed).
If the node is found try to see if you can right click it and unpublish it from the context menu that appears.
If this was succesfull are you then now able to access any of the other nodes?
If not...then perhaps you should try to have a look directly in the database and see if you can somehow delete the node or the node's content this way. It will of course have to be re-created so perhaps browse to it from the frontend and save the content so it can be re-created later. Just to see if it's a macro or some badly formatted content containing some weird characters that might be the cause of the issue. Unfortunately I can't remember what exactly to do in the database to safely remove content / delete a node this way. This is an article from 2014 (V7 area of Umbraco), which may provide some inspiration on how to do it http://thesitedoctor.co.uk/blog/quickly-delete-umbraco-nodes-by-document-type-in-sql/ - But be aware that the table structure might be different in v4.5...I can't remember if this changed but something tells me that some things probably have.
Thanks for the quick response, Jan. I will track down your suggestions, but I wanted to clarify something you said at the outset of your response.
First of all, yeah it's an old site, but has been extremely serviceable.
The correction to my description of this issue is this: We are able to see all the nodes under the Home Page if I expand the page, but don't try to edit the page. We are able to edit other pages within the site just fine, just not the home page. And this behavior did not exist the last time the page was edited, about a month ago.
Yeah but it's awesome that it has been running for so long, that just shows that Umbraco is a solid product in my humble opinion :-)
Ok so it's the Home Page that's the issue...perhaps you can use the rollback function and see if you can roll the version back to before the latest change to the home page was made?
That would be easier than to have to do stuff in the database, which is not recommended but sometimes necessary.
However the part about optimizing the indexes is probably a good idea since it should speed up the backoffice.
Yes, rollback is only for the specific page where you choose to rollback to another revision of that page.
This feature may also be the cause of some of the slowness and increasing database size since a new revision is made everytime the page is changed.
Matt Brailsford once created a package called "UnVersion" so it was possible to make sure only the latest 5 revisions where stored in the database for instance. But that's a bit off topic for now but might be handy for maintaining the site until you start fresh on a new version of Umbraco.
But of course it would be a good idea to make a backup of the database just to be safe in case something weird happens all of the sudden. But using the Rollback feature should be safe :-)
Well... no joy with the sql code in the various links, except to discover that our database seems to be in good shape. I added some of the suggested indexes in my test database, but it had no noticeable effect on load times.
I did note two other items of interest in looking at the database.
The home page has a lot of versions -- maybe 400+.
The log has a lot of entries -- 12,000,000 -- although I don't see how that could make a difference in the loading of a page.
I will rollback tonight when customer usage is low.
After looking at a lot of information from logs and database and file content, I found a number of interesting anomalies in our website, but no solution.
Eventually, after determining that the error from tinyMCE was happening as it rendered an umbraco-supplied macro that we used for listing news on the home page, decided to not have the macro rendered in the content editor.
This solved the timeout issue, and our editors can edit content again.
Still not known, but not worrying about it for now:
Why doesn't our staging site not timeout?
What is causing the inability to render in the content editor? It's not configuration.
Has this macro ever displayed properly in the content editor?
Since the content is not edited directly on the page, but is provided by underlying content, our editors don't need to see it -- so this case is solved!
Happy to hear that you managed to find a workaround, which solves the issues for the editors.
Is the content on staging and live the same?
What kind of content can be inserted in the macro? Perhaps it could have been a hidden weird bad character copied from a word document for instance, which may broke it
Perhaps the type of macro works fine but because of the content placed in it this time it went bunkers maybe?
Please don't hesistate to post about any further progress on this if you continue to investigate :)
Can't edit Home Page in v 4.5.2 site
Just recently, we've encountered a problem trying to edit the content of our Home Page. Our site works fine for end users, but when a content editor clicks on the Home Page, they are unable to see the content and eventually the page times out: [HttpException (0x80004005): Request timed out.] The site has been operational since 2007, performing well for us, with many changes to the site.
I'm hoping for some help as to what areas to look into. Especially, whether there are any tools that can look at the integrity of the site if that's where I need to look. Here are some additional details.
Looking at the log, I see these two error lines after the Open log entry:
Macro Parsing Error: System.Threading.ThreadAbortException: Thread was being aborted. at umbraco.editorControls.tinyMCE3.webcontrol.TinyMCEWebControl.parseMacrosToHtml(String input)
At /umbraco/editContent.aspx?id=2037 (Referred by: https://www.tvwd.org/umbraco/login.aspx?redir=/umbraco/editContent.aspx?id=2037):
Our test site works correctly. It is on a different web server and uses a different SQL Server. The initial response time for the Home Page in the content editor is lengthy (over a minute) but the page does eventually display.
We will be upgrading our site later this year, but can't do it now.
Hi Jim and welcome to our :)
Wow, that's a really old site! I suppose it features quite an amount of content now...
So the editors can't access the content nodes but are they able to log into Umbraco and see the content tree and expanding the content nodes in the tree?
If so perhaps try and see if you can find the node with the id 2037 by using the search field in the search field in the top, right to the "Create" button in the top left corner (If I remember the old Umbraco UI correctly) - Does this match any nodes? Unfortunately I think that there was a bug in the search back then, which made it 50/50 whether it found the node (Even though the node existed).
If the node is found try to see if you can right click it and unpublish it from the context menu that appears.
If this was succesfull are you then now able to access any of the other nodes?
If not...then perhaps you should try to have a look directly in the database and see if you can somehow delete the node or the node's content this way. It will of course have to be re-created so perhaps browse to it from the frontend and save the content so it can be re-created later. Just to see if it's a macro or some badly formatted content containing some weird characters that might be the cause of the issue. Unfortunately I can't remember what exactly to do in the database to safely remove content / delete a node this way. This is an article from 2014 (V7 area of Umbraco), which may provide some inspiration on how to do it http://thesitedoctor.co.uk/blog/quickly-delete-umbraco-nodes-by-document-type-in-sql/ - But be aware that the table structure might be different in v4.5...I can't remember if this changed but something tells me that some things probably have.
Perhaps this article on finding orphaned nodes can help too? http://blog.degree.no/tag/umbraco/
Oh and before I forget maybe you can optimize the database index on both your test and live sites to see if this solves anything - Back in 2013 I had a v4.7 site that was reeeaaally slow at loading the nodes in the backoffice so I asked for some help here https://our.umbraco.org/forum/developers/extending-umbraco/42361-This-is-a-bit-dirtybut-I-need-to-mess-with-the-database - The advice from Mikkel Johansen helped a lot so make sure to read all the instructions and SQL code examples Mikkel writes in that thread starting from here https://our.umbraco.org/forum/developers/extending-umbraco/42361-This-is-a-bit-dirtybut-I-need-to-mess-with-the-database#comment-153824 - I marked one of the first answers from Steve as the solution by a mistake and unfortunately there is no way of undoing that. But in later versions of the our forum you can mark another post as the solution as well...so 2 marked solutions in that one :)
I realize that some of these suggestions are longshots but I hope that some of it might actually help in making you progress on the issue.
Looking forward to hearing from you.
/Jan
Thanks for the quick response, Jan. I will track down your suggestions, but I wanted to clarify something you said at the outset of your response.
First of all, yeah it's an old site, but has been extremely serviceable.
The correction to my description of this issue is this: We are able to see all the nodes under the Home Page if I expand the page, but don't try to edit the page. We are able to edit other pages within the site just fine, just not the home page. And this behavior did not exist the last time the page was edited, about a month ago.
Again, thank you, and I'll post results.
Hi Jim
Yeah but it's awesome that it has been running for so long, that just shows that Umbraco is a solid product in my humble opinion :-)
Ok so it's the Home Page that's the issue...perhaps you can use the rollback function and see if you can roll the version back to before the latest change to the home page was made?
That would be easier than to have to do stuff in the database, which is not recommended but sometimes necessary.
However the part about optimizing the indexes is probably a good idea since it should speed up the backoffice.
Cheers, Jan
Not having used rollback, will it only apply to the Home Page and none of the pages underneath it, when I perform the rollback?
Thanks!
Hi Jim
Yes, rollback is only for the specific page where you choose to rollback to another revision of that page.
This feature may also be the cause of some of the slowness and increasing database size since a new revision is made everytime the page is changed.
Matt Brailsford once created a package called "UnVersion" so it was possible to make sure only the latest 5 revisions where stored in the database for instance. But that's a bit off topic for now but might be handy for maintaining the site until you start fresh on a new version of Umbraco.
But of course it would be a good idea to make a backup of the database just to be safe in case something weird happens all of the sudden. But using the Rollback feature should be safe :-)
/Jan
Well... no joy with the sql code in the various links, except to discover that our database seems to be in good shape. I added some of the suggested indexes in my test database, but it had no noticeable effect on load times.
I did note two other items of interest in looking at the database.
I will rollback tonight when customer usage is low.
Reporting back on final solution.
After looking at a lot of information from logs and database and file content, I found a number of interesting anomalies in our website, but no solution.
Eventually, after determining that the error from tinyMCE was happening as it rendered an umbraco-supplied macro that we used for listing news on the home page, decided to not have the macro rendered in the content editor.
This solved the timeout issue, and our editors can edit content again.
Still not known, but not worrying about it for now:
Since the content is not edited directly on the page, but is provided by underlying content, our editors don't need to see it -- so this case is solved!
Hi Jim
Happy to hear that you managed to find a workaround, which solves the issues for the editors.
Please don't hesistate to post about any further progress on this if you continue to investigate :)
Have a nice day!
/Jan
is working on a reply...