Hi all - we're having some problems on a new Umbraco install. The site forces all users to go over HTTPS / SSL, even for the backend. When you click on any page that contains any macro (XSLT/.NET), the page takes exactly 100 seconds to load in the backend. This is with both umbracoUseSSL=true or forcing SSL in the IIS configuration. There has been a codeplex workitem raised that mentions something similar but I can still say this is happening in the latest release (4.0.4.2).
Why does the back end need to by by HTTPS? If they need that kind of security for the site wouldn't it be better to run a separate CMS instance inside a DMZ and then publish using the web services to live?
Do you have any visibility as to what's taking so long to respond? Have you looked at the Http traffic with Charlse (or fiddler) to see what is taking so long.
Are you getting CPU spikes?
Does it work at optimal speeds if you're on a page with no macro's in the WYSIWYG? Can you implement a solution where you don't need macros in the WYSIWYG? (I only use macros that way if I desperately need the CMS editors to be able to add the macro to any page, otherwise it just adds unnecessary overhead)
1) It's government so it all needs to be SSL :) An emergency option is to setup a SSL reverse proxy that then speaks HTTP to the server in the DMZ, but really Umbraco should be able to do SSL in the backend (thats more fun to fix :)
2) Watched the request with Charlie, and form initial request to the end of the response is exactly 100 seconds. There is only one HTTP GET request. At the SQL end, all the data is returned in the first 500ms or so. CPU does nothing. There are no other HTTP requests to the server.
3) Remove the Macro from the content, page loads fine. Add it back, page loads slow. Used both .NET and XSLT macros. If you go over HTTP all Macros load fine.
4) Added a clean new Macro that just output Hello, and worked fine. Then added one that loops over a few nodes, and page load is back to exactly 100 seconds.
There are lots of technical solutions to work around the problem, but the reality is the problem shouldn't exist :) I'm surprised no one else uses the backend with HTTPS?
Update - for XSLT Macros, seems like checking the "Render content in editor" property causes the issue. So far, in the .NET controls, this property has no effect.
It's probably something to do with the inefficiencies at loading the XML into the WYSIWYG macro. Unless you need to see it I'd have it not render in the editor.
Although not a real fix it'll get you live I'm sure.
And like I said I hardly ever allow macros in the editor, I don't have enough faith in the users to not break things :P
I know this is an old thread, but we also have this issue. We've been playing around with the back end and basically this is the scenario:
We have umbraco set up with https so that we can edit from home (it has no ip restriction). Editing any page as long as it doesn't have a macro on is fine. If you click to edit a page containing a macro it takes ages to load locally. If you close the brower and re-open, everything is fine and quick until you click to edit a page with a macro then the same thing happens.
We've turned on https by changing "enablessl" to true.
Just got bitten by the same bug as well. As a temporary workaround I've added URL Rewrite directives to just send umbraco/login.aspx to SSL, and then send the resulting umbraco/umbraco.aspx page to regular HTTP.
I too have lots of macros in the wysiwyg editor and would prefer to keep it that way. Any official guidance from a HQ team member?
UPDATE
Turns out I've misunderstood the problem. It's still possible to use macros in the editor with 'Use in Editor' checked; it's the other box, 'Render content in editor' that must be UNchecked to not cause these problems with the backend. This works for me and will hopefully help others.
Macro rendering in backend over HTTPS / SSL
Hi all - we're having some problems on a new Umbraco install. The site forces all users to go over HTTPS / SSL, even for the backend. When you click on any page that contains any macro (XSLT/.NET), the page takes exactly 100 seconds to load in the backend. This is with both umbracoUseSSL=true or forcing SSL in the IIS configuration. There has been a codeplex workitem raised that mentions something similar but I can still say this is happening in the latest release (4.0.4.2).
http://umbraco.codeplex.com/workitem/14966
This is holding up our live deployment so any advice would be greatly appreciated...
Why does the back end need to by by HTTPS? If they need that kind of security for the site wouldn't it be better to run a separate CMS instance inside a DMZ and then publish using the web services to live?
Do you have any visibility as to what's taking so long to respond? Have you looked at the Http traffic with Charlse (or fiddler) to see what is taking so long.
Are you getting CPU spikes?
Does it work at optimal speeds if you're on a page with no macro's in the WYSIWYG? Can you implement a solution where you don't need macros in the WYSIWYG? (I only use macros that way if I desperately need the CMS editors to be able to add the macro to any page, otherwise it just adds unnecessary overhead)
1) It's government so it all needs to be SSL :) An emergency option is to setup a SSL reverse proxy that then speaks HTTP to the server in the DMZ, but really Umbraco should be able to do SSL in the backend (thats more fun to fix :)
2) Watched the request with Charlie, and form initial request to the end of the response is exactly 100 seconds. There is only one HTTP GET request. At the SQL end, all the data is returned in the first 500ms or so. CPU does nothing. There are no other HTTP requests to the server.
3) Remove the Macro from the content, page loads fine. Add it back, page loads slow. Used both .NET and XSLT macros. If you go over HTTP all Macros load fine.
4) Added a clean new Macro that just output Hello, and worked fine. Then added one that loops over a few nodes, and page load is back to exactly 100 seconds.
There are lots of technical solutions to work around the problem, but the reality is the problem shouldn't exist :) I'm surprised no one else uses the backend with HTTPS?
Update - for XSLT Macros, seems like checking the "Render content in editor" property causes the issue. So far, in the .NET controls, this property has no effect.
Actually I lie - if you uncheck render in editor for the .NET controls as well, they load quickly...
So it's only a problem with macros which are interacting with the XML cache (either node factory or via XSLT)?
It's probably something to do with the inefficiencies at loading the XML into the WYSIWYG macro. Unless you need to see it I'd have it not render in the editor.
Although not a real fix it'll get you live I'm sure.
And like I said I hardly ever allow macros in the editor, I don't have enough faith in the users to not break things :P
Going to raise a ticket in CodePlex....
Hi,
I know this is an old thread, but we also have this issue. We've been playing around with the back end and basically this is the scenario:
We have umbraco set up with https so that we can edit from home (it has no ip restriction). Editing any page as long as it doesn't have a macro on is fine. If you click to edit a page containing a macro it takes ages to load locally. If you close the brower and re-open, everything is fine and quick until you click to edit a page with a macro then the same thing happens.
We've turned on https by changing "enablessl" to true.
Are there any solutions to this so far?
Thanks,
Tom
Same issue still exists in 4.5.2, only solution is to deactive the "Render content in editor" property
Just got bitten by the same bug as well. As a temporary workaround I've added URL Rewrite directives to just send umbraco/login.aspx to SSL, and then send the resulting umbraco/umbraco.aspx page to regular HTTP.
I too have lots of macros in the wysiwyg editor and would prefer to keep it that way. Any official guidance from a HQ team member?
UPDATE
Turns out I've misunderstood the problem. It's still possible to use macros in the editor with 'Use in Editor' checked; it's the other box, 'Render content in editor' that must be UNchecked to not cause these problems with the backend. This works for me and will hopefully help others.
- Andrew
Thanks for the 'Render content in editor untick' suggestion this was causing us grief on one of our sites!
I assume this has been fixed? if so which version is it fixed in? is there a you-track issue? I coudn't find one.
Cheers.
Hrm, ok it's still broken in v6.0.0-RC
I've created a youtrack issue here: http://issues.umbraco.org/issue/U4-1532
is working on a reply...