Main Content

Magnolia Community Forums: Get help with Magnolia: Resources app rename template


  • armasescuroxana
    armasescuroxana
    Full name: Armasescu Roxana
    Posts: 2
    Last post: Nov 15, 2016 12:39:11 PM
    Registered on: Nov 10, 2016
    Resources app rename template
    #1 by armasescuroxana on Nov 15, 2016 12:39:11 PM

    The resources app does not have a rename teamplate feature.



    Is there a way to do it?

  • rgange
    rgange
    Full name: Richard Gange
    Posts: 44
    Last post: Dec 13, 2016 8:35:33 AM
    Re: Resources app rename template
    #2 by rgange on Nov 21, 2016 9:19:49 AM

    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

  • rihard_m
    rihard_m
    Full name: Rihard Monovic
    Posts: 1
    Last post: Nov 28, 2016 5:23:34 PM
    Re: Resources app rename template
    #3 by rihard_m on Nov 28, 2016 5:23:34 PM

    Klassifizierung - INTERN: Die Inhalte und Informationen dieser Nachricht sind ausschließlich für die kommunizierenden Unternehmen bestimmt.

    hi roxana

    you can install the (optional) processed ressources app:

    https://documentation.magnolia-cms.com/display/DOCS/Resources+module#Resourcesmodule-Optional:ProcessedResourcesapp

    best begards,

    rihard

    -----Ursprüngliche Nachricht-----
    Von: user-list-owner@magnolia-cms.com [mailto:user-list-owner@magnolia-cms.com] Im Auftrag von Armasescu Roxana (via Magnolia Forums)
    Gesendet: Dienstag, 15. November 2016 12:39
    An: Magnolia User List <user-list@magnolia-cms.com>
    Betreff: [magnolia-user] Resources app rename template

    The resources app does not have a rename teamplate feature.



    Is there a way to do it?

  • runger
    runger
    Full name: Richard Unger
    Posts: 571
    Last post: Feb 1, 2017 9:54:59 AM
    Re: Resources app rename template
    #4 by runger on Dec 5, 2016 10:06:37 AM

    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) <forum@magnolia-cms.com<mailto:forum@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

  • vicky-midson
    vicky-midson
    Full name: Vicky Midson
    Posts: 3
    Last post: Dec 12, 2016 6:10:48 PM
    Registered on: Dec 12, 2016
    Re: Resources app rename template
    #5 by vicky-midson on Dec 12, 2016 6:10:48 PM

    That's great!

  • rgange
    rgange
    Full name: Richard Gange
    Posts: 44
    Last post: Dec 13, 2016 8:35:33 AM
    Re: Resources app rename template
    #6 by rgange on Dec 13, 2016 8:35:33 AM

    Hi Richard-

    Thanks for your comments. As a trainer, I try and guide customers down a path of greatest success. That's why I made the "best practice" comment. As a support person, I think the most frustrating thing to deal with it repo corruption. So, you know, but anyway I agree with a lot of what you said there. We consider this as valuable input.

    Regards from Basel

    richg

  • had
    had
    Full name: Jan Haderka
    Posts: 1,406
    Last post: May 12, 2017 8:31:00 AM
    Re: Resources app rename template
    #7 by had on Dec 13, 2016 9:49:39 AM

    Hi Richard,

    first thanks for the detailed feedback. And also few comments of my own to it

    Anything except JCR has significant disadvantages when it comes to a real world production setup.


    Not true. I agree that there is setup and work practice for which JCR works best and that's the one we used to recommend before introducing LD. While designing LD we have discovered other working patterns that we believe are more agile and even more beneficial than JCR, addressing number of other pain points that we were trying to solve for years. It might not be that everyone suffered from such issues or that they were not major enough, however we do not want to stop innovating the framework just because some users were already satisfied with it as it was.

    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.


    Again, not true. What you describe applies for classpath resources, but not to those that are on the FS and brought in via Light Modules. I don't know where this misconception is coming from and it would be interesting for me if you would be willing to elaborate on what made you think this is true for Light Modules. In light modules, and I have few projects using those, you can change your definitions or template scripts or other resources such as css or js and have them picked up by server, in production, without restart. It's actually even better. It's picked up by all author and all public instances at once with single step.
    My setup and workflow is as follows:
    - resources directory of Magnolia is configured outside of the webapp
    - all light modules are in git
    - I work on the branch, and only after testing the code locally, merge any and all my code changes to master
    - git repo is cloned in the resources directory of Magnolia on each server
    - servers are configured to observe git and pull in all changes from remote master when they occur with polling interval set to 5 seconds

    No need for activation, no need for remote access to the system and yet I'm able to modify all files in my favorite tools and have full version control and audit log of who did what. How much better can it get? This is more than I was ever getting from JCR and as long as I have access to git repo, I can do update from any place and any device (yeah, done this from the phone too, which is much more comfortable for working with github than with the internal code editor in Magnolia). Where in this scenario am I missing anything that activation over JCR was offering to me?

    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.


    Indeed this is legitimate question. No dispute here. And the answer is: it can be. But you need to use processed resources app. If you want to use JCR resources exclusively this is the app to use. If you want to work with Light Modules, Magnolia instance is a terminal node for distribution of the files/code in those modules. Hence no renaming functionality. It is not meant to be. If you want to rename the resource, rename it in your local clone of the light module, commit it to the repository and get the change distributed to all of your servers.

    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.


    I respectfully disagree. You were not part of internal process and have no clue whether and what we analyzed and not. Please do not jump to conclusions. We did analyze the benefits and costs of introduction of light development and decided that benefits outweigh the costs. Success of the feature confirms this analysis. Yes, there are those who were satisfied with the way how working with resources and publishing of them via JCR worked previously but that is not reason to stop the development and evolution of the product. We tried to make it as little disruptive as possible for you to continue using old ways should that be your preferred way of working with Magnolia. However do not claim that we didn't know what we are doing just because you didn't grow to like new working pattern.

    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

    Not true.
    You can activate JCR resources via processed resources app same as before.
    Should you edit FS or Classpath based resource over JCR, you can activate such change as well.
    Previously you could NOT see and amend CP based resource w/o knowing exactly what path it lies on and recreating that manually. Now we made this much more transparent. How is that not an improvement?

    - no processed resources

    Again, you can install and use processed resources app should you require so. We don't do this ootb and do not recommend it as best working pattern. Why? Because there are plenty of tools that can do pre-processing of resources much more efficiently than Magnolia itself. And more of it. You can do all minification, sass/less translation, combining js scripts, creating image sprites and much more. Why would we limit you to do just few of those within Magnolia when you can do it all outside and bring it to productive servers at runtime all the same?
    There are few corner cases where you want to inject something from within Magnolia, but that's something that 90% of users don't need, hence we still support it via processed resources app, but do not install by default and do not encourage anyone to go down that path as we see it limiting flexibility of development in long term.

    - resources can no longer have models or templates to render them

    Sure they can, via processed resources or via custom apps or custom pages/components/renderers. Yet again, while preprocessing is common and can be done more efficiently outside of Magnolia and brought to production by means described above, templating/processing at runtime is much less often necessary. Similarly for working with models, we recommend working with templating functions and in templates directly these days since it requires less distinct sets of experience for the users. Yet still should you want to work with models you can and there are certainly the cases when it's necessary.

    - 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.


    In your opinion. Indeed. The results we are seeing overall and research we have been making suggest otherwise. For majority of our users the light modules and possibility of accessing resources on FS directly without CMS interrupting in between is a major advantage. And as I said, even with that we still support old ways of development for existing projects created before introduction of LD or for those for whom old ways were "perfect" and do not need or wish for anything more. But just because you don't want to use it, doesn't mean it is bad or failure in general.

    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


    Again, it is well thought. In new process CMS receives templates and definitions defined outside of it. They are manipulated in any and all ways outside, hence no need for doing anything inside of CMS except for patching for which we decided to use JCR. Similarly all processing of templates such as sass translation can happen much more easily and fluently outside with light modules and for example gulp or grunt tools. Using and connecting code repository for the code allows you to distribute the code to all necessary locations via pull mechanism making it much more flexible and resilient to failure.

    We understand that this pattern takes a bit of thinking before understanding and adopting. however we are strongly convinced that it is worth the effort. Results we are seeing and responses we are getting are all confirming this approach. Yet we also understand that it is not for everyone. That's one of the real strengths of Magnolia - you can extend it to your liking. If you like to have all templates and configurations in JCR, you can and you can use processed resources app to manipulate and execute them. Similarly there are other parts of community that like to define all their templates and definitions via spring. Those too can do it by simply installing blossom module. There is no discrimination, we have just chosen default which we believe is most progressive and provides most benefits to biggest part of the community that's all.

    Cheers,
    Jan

You don't have the permission to post on this thread

Sign in

To login on this forum, you can use your Magnolia Forge, Support or Partner account, or, below, your Google, Yahoo! or OpenID account. If you have trouble logging in, or any other sort of issue, please let us know in the Meta forum, on the user-list, or simply by email at forum-admin at magnolia-cms dot com.

* Required

... or sign in with:

  • icon http://{your-openid-url}
  • icon
  • icon https://me.yahoo.com/