Loving ublogsy as always but i wanted to make some changes to the razor script files but it seems i dont have any access to them?
Each time i try to save i get the message "Scripting file could not be saved". Also when i right click the ublogsy scripting folder I dont get the menu to create either...
I've set all the permissions correctly so not sure whats going on...
Yes, I've seen the same issue using Tea Commerce in 4.7.1 where they have a couple of scripts in a sudirectory that cannot be saved. I've not discovered the cause and like you, had moved them to the parent folder.
Confirmed that moving all uBlogsy scripting files out of the uBlogsy sub-folder, and up into the main parent "macroScripts" folder, will allow you to edit (and most importantly save!) these files through the administrative backend.
NOTE: If you do this, here are some other related changes you will need to make:
[] Edit all Macros and update the script file path (to remove the /uBlogsy/ subfolder)
[] Edit all scripting files and look for any "@RenderPage" instances --- edit these to also remove the /uBlogsy/ folder.
All-in-all, this should only take you a few minutes at most.
I am having problems saving certain changes to JS files in a subfolder. It is not the file perms... it is something in the file when certain changes are pasted in. I have no desire to waste time tracking it down, only to report it and wait for 3 more years for an HQ member to pay attention to it....
Create a blank JS file in a folder called JS and then paste in the latest lytebox code. It will not save, but older versions of lytebox will...
Like the rest of the crap still lingering around 5 years later, fix it already instead of working on new features or spending time polishing this turd of a website.
Umbraco! Bult on Microsoft .NET but can't be authored or administered in IE. Laughable!
The only way to make sure that the Umbraco world knows about a bug is to file it on the issue tracker. I don't know if this specific bug has been filed. If it has not...well then odds are very low that something is done.
If it has...well then this bug might be one of those that members of this community could fix - keep in mind that this is OSS and ressources are in fact limited with all the other stuff HQ has to deal with as well. But luckily if one has the right skillset it's actually possible to give something back to the project by helping out fixing bugs for instance.
I know that in some cases it can be neccesary to edit files form the backoffice but it really should be in rare circumstances. File editing should be done in proper editors outside of Umbraco imho, since Umbraco or any other CMS is not a a file editor and never should be the first pick to edit files.
It's fair that you feel frustrated - this happens to all of us once in a while but then we try to do someting about it if we can :)
Please don't take my open frustration as anything personal. I have been using Umbraco since the very early releases and love it. I also highly appriciate all of the talent, time and effort that go into both the product and this site.
At the same time, I have to openly say that the way this project is managed and presented leaves a lot to be desired.
Jan, the fact that this is OSS with a "core team" or "HQ" behind it should be leveraged as an advantage from a workflow and management standpoint. One of the key tenants SHOULD be dedicated interaction with the "community" to identify and prioritize the bugs. The product would be better, bug fixes quicker and workflows much more efficient.
Also, it appears that each time umbraco "fails" at something, the failure is attributed to Umbraco not being designed for that role.
The "spell checker" is still not fixed, and the excuse has been that "umbraco is not a word processor". Yet the entire premise is to allow content editors to build content. Silly, at best.
The code editor worked fine until it was upgraded to highlight tags. If it is not MEANT to edit code directly, then why BREAK IT by adding features SPECIFIC to direct editing of code? Again, silly.
If the script editor and xslt editor were not meant to directly edit code, then why are they context sensative to a flaw? Why not just a plain old editor so that users can "touch up" files built in "proper" editors. Again a contradiction in logic.
We both know that the three examples above are actually not contradictions in logic, they are simply excuses for bugs that nobody has taken the time to prioritize and fix.
The most "comfortable" projects to work with are those that have clearly defined goals with clearly defined milestones meant to reach those goals and a well designed user experience designed to compliment both the timeline and the goals. The "Umbraco" experience feels poorly organized and ever widening, not well organized and focused.
So again, this is nothing personal toward any member of the project. I just happen to think it is time for some very deep reflection. A "feature freeze" and project "reset" if you will. This was to have happened when U5 was dumped, but many of us feel nothing has changed. At many level the project appears to be right back in the same rut it was stuck in before.
I think it's only fair that people get the stuff of their chest and there is no reason to be religous and having flame wars. That's not going to benefint anyone.
In the above post you have some very valid points. Stuff that used to work is broken and that's really annoying and creates a lot of frustration since it should just work. These things do also frustrate me very much on daily basis since it's really hard to explain to editors..."Yeah well, this USED to work...but now it does not...".
That's a weird and frustrating situation to be in - What arguments have been used for one or the other I can't remember. But bugs unfortunately do happen and my impression during the last year has been that many bugs have gotten fixed very quickly and I'm sure that if these mentioned bugs are in the issue tracker the core team will get to them at some point and get them fixed. But if there are people out there who knows how to do it by any means feel free to contribute and make the life easier on all of us. If I had the right skillset (and the time) I would love to contribute way much more to the core getting rid of the silly bugs. Currently I don't have the skills but I'm considering to have a look and see if I can fix some of them.
I have no idea how much has changed under the helmet but I can imagine many things have been rewritten and unfortunately not all scenarioes have been tested. Unfortunately the core team does no longer build actual wesbites so therefore they don't catch the same bugs as those who do. Maybe some efforts should be put into doing some real beta-testing instead of just relying on unit testing before a release so minor bugs (which usually causes the most frustrations) is getting caught and fixed before a stable release. I'm sure the core team would love to get some input on that.
It's not my impression that the project is at the state that V5 where in - but I might be biased but I have not heard or experienced this myself. I did when V5 was in the works. But I could be wrong.
Umbraco should be easy, flexible and fun to work with...That is what we should aim for.
I just hope that anyone who loves to build wesbites on Umbraco will do whatever they can to contribute to the project to make it he most fun it can be.
...Oh btw regarding the issues of editing files from the backoffice.
I've worked with other CMS'ses than Umbraco, which where commercial and their code editors worked like crap and at a certification course we got told not to use the inline editor ever since it messed up some user controls if you did. It did so no matter the browser. I know it does not fix this issue but it's just to say that it's not just an Umbraco thing and if one has the option of using a proper external editor no matter the CMS that should be encouraged at all times imho.
Scripting file could not be saved
Loving ublogsy as always but i wanted to make some changes to the razor script files but it seems i dont have any access to them?
Each time i try to save i get the message "Scripting file could not be saved". Also when i right click the ublogsy scripting folder I dont get the menu to create either...
I've set all the permissions correctly so not sure whats going on...
TIA,
Stephen
Hi Stephen
How have you set the permissions? Has it been set for both network service and iusr?
Otherwise have you tried to access the files outside of Umbraco?
/Jan
Hey Jan,
Permission have been checked and are correct, I have tried accessing the files via VS2010 and can make the changes and save...wierd one.
I can create scripts in the parent "Scripting Files" folder within the umbraco UI just not in the ublogsy folder.
S
I've actually got the same problem
It seems Umbraco doesnt like the cshtml files being in a folder.
If you copy a file to the /macroScripts/ you'll have normal access to it.
Has anyone else seen this issue before?
Yes, I've seen the same issue using Tea Commerce in 4.7.1 where they have a couple of scripts in a sudirectory that cannot be saved. I've not discovered the cause and like you, had moved them to the parent folder.
Confirmed that moving all uBlogsy scripting files out of the uBlogsy sub-folder, and up into the main parent "macroScripts" folder, will allow you to edit (and most importantly save!) these files through the administrative backend.
NOTE: If you do this, here are some other related changes you will need to make:
[] Edit all Macros and update the script file path (to remove the /uBlogsy/ subfolder)
[] Edit all scripting files and look for any "@RenderPage" instances --- edit these to also remove the /uBlogsy/ folder.
All-in-all, this should only take you a few minutes at most.
It's an umbraco bug. Hopefully it will be fixed soon. I prefer to edit using visual studio because of intellisense.
Like many similar bugs.... it is not fixed. 6.0.x
I am having problems saving certain changes to JS files in a subfolder. It is not the file perms... it is something in the file when certain changes are pasted in. I have no desire to waste time tracking it down, only to report it and wait for 3 more years for an HQ member to pay attention to it....
Create a blank JS file in a folder called JS and then paste in the latest lytebox code. It will not save, but older versions of lytebox will...
Like the rest of the crap still lingering around 5 years later, fix it already instead of working on new features or spending time polishing this turd of a website.
Umbraco! Bult on Microsoft .NET but can't be authored or administered in IE. Laughable!
Hi William
The only way to make sure that the Umbraco world knows about a bug is to file it on the issue tracker. I don't know if this specific bug has been filed. If it has not...well then odds are very low that something is done.
If it has...well then this bug might be one of those that members of this community could fix - keep in mind that this is OSS and ressources are in fact limited with all the other stuff HQ has to deal with as well. But luckily if one has the right skillset it's actually possible to give something back to the project by helping out fixing bugs for instance.
I know that in some cases it can be neccesary to edit files form the backoffice but it really should be in rare circumstances. File editing should be done in proper editors outside of Umbraco imho, since Umbraco or any other CMS is not a a file editor and never should be the first pick to edit files.
It's fair that you feel frustrated - this happens to all of us once in a while but then we try to do someting about it if we can :)
Cheers,
Jan
William I share your frustrations from time to time. Then I remind myself that with all it's flaws, it's still the best free open source .net cms.
The best thing to do is report issues here: http://issues.umbraco.org
Speaking of bug fixes, Cogworks ran a bug fixing hackathon last year. We fixed 35 Umbraco bugs. We're running another one in November:
http://our.umbraco.org/events/umbraco-bug-bashathon
Hop on a plane and join us :)
ps. Out of all the .net devs I know, I think 2 of them use IE. All the rest use Chrome :)
Jan and Anthony,
Please don't take my open frustration as anything personal. I have been using Umbraco since the very early releases and love it. I also highly appriciate all of the talent, time and effort that go into both the product and this site.
At the same time, I have to openly say that the way this project is managed and presented leaves a lot to be desired.
Jan, the fact that this is OSS with a "core team" or "HQ" behind it should be leveraged as an advantage from a workflow and management standpoint. One of the key tenants SHOULD be dedicated interaction with the "community" to identify and prioritize the bugs. The product would be better, bug fixes quicker and workflows much more efficient.
Also, it appears that each time umbraco "fails" at something, the failure is attributed to Umbraco not being designed for that role.
The "spell checker" is still not fixed, and the excuse has been that "umbraco is not a word processor". Yet the entire premise is to allow content editors to build content. Silly, at best.
The code editor worked fine until it was upgraded to highlight tags. If it is not MEANT to edit code directly, then why BREAK IT by adding features SPECIFIC to direct editing of code? Again, silly.
If the script editor and xslt editor were not meant to directly edit code, then why are they context sensative to a flaw? Why not just a plain old editor so that users can "touch up" files built in "proper" editors. Again a contradiction in logic.
We both know that the three examples above are actually not contradictions in logic, they are simply excuses for bugs that nobody has taken the time to prioritize and fix.
The most "comfortable" projects to work with are those that have clearly defined goals with clearly defined milestones meant to reach those goals and a well designed user experience designed to compliment both the timeline and the goals. The "Umbraco" experience feels poorly organized and ever widening, not well organized and focused.
So again, this is nothing personal toward any member of the project. I just happen to think it is time for some very deep reflection. A "feature freeze" and project "reset" if you will. This was to have happened when U5 was dumped, but many of us feel nothing has changed. At many level the project appears to be right back in the same rut it was stuck in before.
Hi William
No offense taken.
I think it's only fair that people get the stuff of their chest and there is no reason to be religous and having flame wars. That's not going to benefint anyone.
In the above post you have some very valid points. Stuff that used to work is broken and that's really annoying and creates a lot of frustration since it should just work. These things do also frustrate me very much on daily basis since it's really hard to explain to editors..."Yeah well, this USED to work...but now it does not...".
That's a weird and frustrating situation to be in - What arguments have been used for one or the other I can't remember. But bugs unfortunately do happen and my impression during the last year has been that many bugs have gotten fixed very quickly and I'm sure that if these mentioned bugs are in the issue tracker the core team will get to them at some point and get them fixed. But if there are people out there who knows how to do it by any means feel free to contribute and make the life easier on all of us. If I had the right skillset (and the time) I would love to contribute way much more to the core getting rid of the silly bugs. Currently I don't have the skills but I'm considering to have a look and see if I can fix some of them.
I have no idea how much has changed under the helmet but I can imagine many things have been rewritten and unfortunately not all scenarioes have been tested. Unfortunately the core team does no longer build actual wesbites so therefore they don't catch the same bugs as those who do. Maybe some efforts should be put into doing some real beta-testing instead of just relying on unit testing before a release so minor bugs (which usually causes the most frustrations) is getting caught and fixed before a stable release. I'm sure the core team would love to get some input on that.
It's not my impression that the project is at the state that V5 where in - but I might be biased but I have not heard or experienced this myself. I did when V5 was in the works. But I could be wrong.
Umbraco should be easy, flexible and fun to work with...That is what we should aim for.
I just hope that anyone who loves to build wesbites on Umbraco will do whatever they can to contribute to the project to make it he most fun it can be.
Cheers,
Jan
...Oh btw regarding the issues of editing files from the backoffice.
I've worked with other CMS'ses than Umbraco, which where commercial and their code editors worked like crap and at a certification course we got told not to use the inline editor ever since it messed up some user controls if you did. It did so no matter the browser. I know it does not fix this issue but it's just to say that it's not just an Umbraco thing and if one has the option of using a proper external editor no matter the CMS that should be encouraged at all times imho.
/Jan
is working on a reply...