Hi Rich, I object to the statement that storing templates or other resources in JCR is in some way not best practice.
JCR was the principle storage location for resources prior to the resource module changes, and is still an excellent choice. Classpath is obviously a bad choice, but filesystem is a good alternative for some users I imagine. While the new way of working is good for development, it sucks for production. Anything except JCR has significant disadvantages when it comes to a real world production setup. Since FS or classpath resources can't be activated, deploying templates stored in those locations is a major pain, requiring physical copying to each public node, and a server restart (unless you have your production server in development mode, then in theory it could hot-load FS resources. Classpath always needs a restart). So in community edition you would have actual downtime to deploy templates (only one public node), while in enterprise edition you could theoretically do a complex rolling deploy over several public nodes to prevent downtime, but you'd lose the transactional activation that guarantees consistency, and be serving different versions of the page during the deploy. It's also very hard to coordinate the deployment of content and resources when the resources aren't in JCR. Armasescu's question is perfectly legitimate. Why can't JCR resources be renamed? It's obvously a necessary feature for those of us using JCR. Magnolia has caused a slew of problems in terms of usability, bugs and security issues by releasing the new resources concept without properly analyzing the impact beforehand. The new system is broken by (lack of) design. It was all "yay, light development, let's go", and the new resources concept is therefore missing essential functions like the renaming in JCR that Armasescu has noticed, but also the following: - no activation of non-JCR resources - no processed resources - resources can no longer have models or templates to render them - major security problem where your entire classpath gets exposed to the internet (apparently fixed in 5.5) - major bug with stale JCR Node references (now fixed, I think) JCR and the fact that magnolia *can* deploy resources via activation are major strengths of your CMS. FS and particularity yaml are cool for developers, but in the end running the sites is as important as developing them, in my opinion. JCR is more than just a solution to "patch" resources. There is no reason at all the new resources concept can't work well with JCR, it just needs a bit more thought and work to complete the new resources app. I would suggest thinking about the following: - add back the ability to properly work with JCR resources: move, rename, etc... - add back the processed resources. See my scss-resources-module for an idea of how this could work - add the ability to activate FS resources. This would give the best of both worlds: GS development and activation for production @Armasescu: to solve your problem in the meantime, the old processed resources module can still be installed, as Rihard suggested. Also, it should not be hard to configure the resources app to add extra actions like rename to it. You could also take a look at my resources-scss module (shameless self-promotion :-)) - this adds back processed resources in a nice way, and also fixes the classpath security issue. There is a wiki page for it. Regards from Lancaster, Richard Unger (iPhone) On 21 Nov 2016, at 08:22, Richard Gange (via Magnolia Forums) <fo...@magnolia-cms.com<mailto:fo...@magnolia-cms.com>> wrote: Hi Armasescu- The goal of the Resources app is to provide a way to view the resources in the system. These resources can exist in a JAR, file system, or the resources workspace. To provide a way to rename would mean that the resources would have to exist in the resources workspace only. We could not provide a way to rename a resource that existed in a JAR for example. It's not good practice to have templates that only exist in the resources workspace. Templates that exist in that workspace are meant to hotfix a resource that exist in one of the other two places, so they must have to same name. So in the end, no there is no way to rename a resource in this app. The reason being is that the resources are loaded from different places and it's wouldn't be possible to rename all of them from this app. HTH Rich -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=664d58e1-ec19-4cbe-b918-19bc44116774 ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <user-list-unsubscr...@magnolia-cms.com<mailto:user-list-unsubscr...@magnolia-cms.com>> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <user-list-unsubscr...@magnolia-cms.com> ----------------------------------------------------------------
