I've just upgraded to Umbraco 6.0.7 (assembly version 1.0.4927.24052). Since after the completion of the operation I am unable to fully edit a Template inside the Umbraco back-end.
Specifically, if I open an existing Umbraco Template (aka a masterpage), I try to change the value of the "Master Template" field and I try to save the changes, Umbraco says "Template successfully saved" but neither the left tree is updated nor the "master" field record in the table cmsTemplate gets updated.
I am quite sure it is not a problem of permissions and access privileges as I can actually modify all other data and see them effectively updated (I can also modify the name of the masterpage and the masterpage filename is consequentelly changed).
Is this an unfortunate bug that has been introduced in this new release?
I have just done a clean install of 6.1.5 and all went well until I tried saving my first template. This is a clean install, no packages and no starter site.
The Template will just no save, no error just not saving. Is this a newly introduced bug?
I have done some more investigation: I can edit the template outside of Umbraco and save it, so I can get round the problem if I REALLY have to but it is still a bug.
I have checked the permissions and they are fine as far as I can see.
The logs in \App_Data\Logs\UmbracoTraceLog.txt show no errors
I have tried saving with the simplest change, just adding a
test
so it is not related to the content being a problem (no scripts, not broken code, not odd characters)
When I click the Save button I get no warning, no error and no "Change saved" dialog - zilch
CSS and XSLT files save fine
I am about to try a reinstall - sigh.
PS I examined using Firebug and I get a 405 on SaveTemplate so it looks like maybe something is not installed correctly. I tried Chrome and it is the same
Thanks Alessio, I'll try that before I give up and either go back to ver 4 or ship all my stuff over to a Win 7 machine which would be a nightmare. Don't these guys road-test this stuff or is it a case of "yup the starter kit installs ok, and we have all that cool new shit in it so it's good to ship" o è solo schifezza?
Hooray. Thanks Alessio. 6.1.4 Installed fine and the Template saved - no errors. Maybe someone in Umbraco can pick this up. First I would like to say I LOVE Umbraco but having spent around 10 years fighting the direction of travel that Dot Net Nuke took it really worries me when I see the stuff going on here.
It is not a case of it ain't broke - don't fix it because while it may not be entirely broken there are big issues with Umbraco that (in my opinion) are not satisfactorily addressed.
mainly security.
In May we all had a wake up call when we received an email from Niels stating "During one of our regular security audits of the core, a severe security vulnerability was found in the integration web services of Umbraco and we recommend everyone to take immediate action to prevent any exploit."
Regular, meaning what? Built into the design process, once a year, once a month, what?
The admin address domainname.com/umbraco/ is to all intents and purposes fixed (correct me if I'm wrong, I've been away from Umbraco for a while) the argument being because 3rd part vendors build to that address and packages might fail if you change the directory name. The answer is surely to parameterise the admin area and tell 3rd party package builders to allow for that. But of course there is near zero guidance for 3rd part builders, let alone rules. If it's cool and it works (at least on some machines) then its good to ship and fit to be included on the Projects page.
Permissions I can't be the only one that has done due diligence and locked down all directories and then tried to install a package for it to fail on permissions somewhere. This happened yesterday when I installed the excellent uLess. I had to allow write permissions to /config/trees.config and /config/applications.config but the only way I could know that was to try to install the package, hit the fail, fix the permission, delete the install and the entry in the web.config and try again repeating for each permission failure - it's nuts.
A simple rule - do NOT include any package on the Projects downloads unless the vendor/developer has included a list of permissions needed. It is also not rocket science to build in a permission check on the install and to fail the install gracefully if permissions fail. Umbraco HQ would do us all a favour if, along with other essential (but missing guidlines) they supplied a simple slug of code that devs can add to their package install that checked for permissions required for the package and failed gracefully if not correct.
If this is not addressed then I suspect developers, using Umbraco to earn a living, will simply allow Modify rights to the whole web root - because it is easier and their time is short - who's isn't?
For anyone interested, I have a .bat file which I use and tweak as I need it, it covers cacls (XP and win 2000) and icacls (the rest). It can be downloaded from http://www.etymonda.com/software/umbraco/files.aspx
It is all very well being advised that updates are available but who actually updates with out going through a complete install of the later version? I'm sure this upgrade process could be made easier. I'd be interested to hear people's experience.
You'd think after the Ver 5 fiasco some sense might prevail, what we need is robust, safe, reliable and easy-to-use CMS. Don't add bells and whistles if all they add is "cool". You can be the most stunning peacock in the zoo but if your cazzo doesn't work it means little.
I can just add, that I am experiencing exactly the same 404-issue (Umbraco/RestServices/SaveFile/SaveTemplate) as Alessio, upon template save, on an IIS 7.0 with version 6.1.6. It's a clean install with no startkits.
Probably this have been solved by the previous poster since it has been a lot of time, but I think it is good to close the thread with a solution when there is one:
Adding this mapping will let IIS know how to treat the extension-less requests like the "Umbraco/RestServices/SaveFile/SaveTemplate" invoked to save templates. Otherwise IIS won't know what to do, since there is no a default document in that path, that it is not even a folder, so it replies with a 404.
Parent template not being saved on edit
Hi folks.
I've just upgraded to Umbraco 6.0.7 (assembly version 1.0.4927.24052). Since after the completion of the operation I am unable to fully edit a Template inside the Umbraco back-end.
Specifically, if I open an existing Umbraco Template (aka a masterpage), I try to change the value of the "Master Template" field and I try to save the changes, Umbraco says "Template successfully saved" but neither the left tree is updated nor the "master" field record in the table cmsTemplate gets updated.
I am quite sure it is not a problem of permissions and access privileges as I can actually modify all other data and see them effectively updated (I can also modify the name of the masterpage and the masterpage filename is consequentelly changed).
Is this an unfortunate bug that has been introduced in this new release?
Thanks in advance,
Gianluca
Hi Gianluca
Do you see any error messages in the browser console window if you open it and monitor the log when you edit the template?
Also it may be a good idea to check the log file in /app_data/logs and see if there are any usefull information available.
/Jan
I have just done a clean install of 6.1.5 and all went well until I tried saving my first template. This is a clean install, no packages and no starter site.
The Template will just no save, no error just not saving. Is this a newly introduced bug?
I have done some more investigation: I can edit the template outside of Umbraco and save it, so I can get round the problem if I REALLY have to but it is still a bug.
I have checked the permissions and they are fine as far as I can see.
The logs in \App_Data\Logs\UmbracoTraceLog.txt show no errors
I have tried saving with the simplest change, just adding a
so it is not related to the content being a problem (no scripts, not broken code, not odd characters)
When I click the Save button I get no warning, no error and no "Change saved" dialog - zilch
CSS and XSLT files save fine
I am about to try a reinstall - sigh.
PS I examined using Firebug and I get a 405 on SaveTemplate so it looks like maybe something is not installed correctly. I tried Chrome and it is the same
PPS I Lied this is 6.1.6 not 6.1.5
Just done a clean install and it is the same. I get: "NetworkError: 405 Method not allowed - http://localhost/umbraco/RestServices/SaveFile/SaveTemplate"
I'm running IIS 5.1 so it may be to do with the Web service itself. Just about to try a clean install of 6.1.5
6.1.5 is the same. I'm now investigating if it is an IIS issue.
It looks like it is an IIS 5.1 issue. Has anyone successfuly run a late (and secure) version of Umbraco on an XP machine and if so what is the trick?
Same problem with 6.1.6 and 6.1.5 with iis 7.5..
6.1.4 work fine
In chrome console i've a 404 for Umbraco/RestServices/SaveFile/SaveTemplate
Thanks Alessio, I'll try that before I give up and either go back to ver 4 or ship all my stuff over to a Win 7 machine which would be a nightmare. Don't these guys road-test this stuff or is it a case of "yup the starter kit installs ok, and we have all that cool new shit in it so it's good to ship" o è solo schifezza?
Hooray. Thanks Alessio. 6.1.4 Installed fine and the Template saved - no errors. Maybe someone in Umbraco can pick this up. First I would like to say I LOVE Umbraco but having spent around 10 years fighting the direction of travel that Dot Net Nuke took it really worries me when I see the stuff going on here.
It is not a case of it ain't broke - don't fix it because while it may not be entirely broken there are big issues with Umbraco that (in my opinion) are not satisfactorily addressed.
mainly security.
In May we all had a wake up call when we received an email from Niels stating "During one of our regular security audits of the core, a severe security vulnerability was found in the integration web services of Umbraco and we recommend everyone to take immediate action to prevent any exploit."
Regular, meaning what? Built into the design process, once a year, once a month, what?
The admin address domainname.com/umbraco/ is to all intents and purposes fixed (correct me if I'm wrong, I've been away from Umbraco for a while) the argument being because 3rd part vendors build to that address and packages might fail if you change the directory name. The answer is surely to parameterise the admin area and tell 3rd party package builders to allow for that. But of course there is near zero guidance for 3rd part builders, let alone rules. If it's cool and it works (at least on some machines) then its good to ship and fit to be included on the Projects page.
Permissions
I can't be the only one that has done due diligence and locked down all directories and then tried to install a package for it to fail on permissions somewhere. This happened yesterday when I installed the excellent uLess. I had to allow write permissions to /config/trees.config and /config/applications.config but the only way I could know that was to try to install the package, hit the fail, fix the permission, delete the install and the entry in the web.config and try again repeating for each permission failure - it's nuts.
A simple rule - do NOT include any package on the Projects downloads unless the vendor/developer has included a list of permissions needed. It is also not rocket science to build in a permission check on the install and to fail the install gracefully if permissions fail. Umbraco HQ would do us all a favour if, along with other essential (but missing guidlines) they supplied a simple slug of code that devs can add to their package install that checked for permissions required for the package and failed gracefully if not correct.
If this is not addressed then I suspect developers, using Umbraco to earn a living, will simply allow Modify rights to the whole web root - because it is easier and their time is short - who's isn't?
For anyone interested, I have a .bat file which I use and tweak as I need it, it covers cacls (XP and win 2000) and icacls (the rest). It can be downloaded from http://www.etymonda.com/software/umbraco/files.aspx
It is all very well being advised that updates are available but who actually updates with out going through a complete install of the later version? I'm sure this upgrade process could be made easier. I'd be interested to hear people's experience.
You'd think after the Ver 5 fiasco some sense might prevail, what we need is robust, safe, reliable and easy-to-use CMS. Don't add bells and whistles if all they add is "cool". You can be the most stunning peacock in the zoo but if your cazzo doesn't work it means little.
William,
your thoughts are very interesting,
I think that the umbracohq team is very attentive to safety issues.
we greatly appreciate the work done every day to grow our favorite cms.
unfortunately the conditions of operation of a CMS based on asp.net are very varied and depend on many factors.
however, the ideas that are primarily on the management of extensions seem to me very good, I hope to be taken into care
Ciao
Alessio
I can just add, that I am experiencing exactly the same 404-issue (Umbraco/RestServices/SaveFile/SaveTemplate) as Alessio, upon template save, on an IIS 7.0 with version 6.1.6. It's a clean install with no startkits.
Probably this have been solved by the previous poster since it has been a lot of time, but I think it is good to close the thread with a solution when there is one:
https://support.appzone.com/kb/a194/setting-aspnet_isapi_dll-for-wildcard-applications.aspx
Adding this mapping will let IIS know how to treat the extension-less requests like the "Umbraco/RestServices/SaveFile/SaveTemplate" invoked to save templates. Otherwise IIS won't know what to do, since there is no a default document in that path, that it is not even a folder, so it replies with a 404.
Hope this helps.
is working on a reply...