We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    Quote from: OpenGeek at Dec 26, 2007, 02:08 PM

    I have to disagree with any attempt to try and impose structure of any kind on MODx add-ons or external file dependencies, but let me explain a bit...

    I can definitely see the reason for this, but I think it will make things much harder for new MODx users. I seem to be the only one who thinks so, but IMHO, suggesting guidelines for locating MODx objects doesn’t actually keep anyone from doing anything they want; it just makes it easier to find things when you want them.

    I never meant to suggest that MODx would *look* for things in particular places, that would be an unreasonable restraint, just that there are standard elements that everyone uses (images, .css files, .js files, etc.), and having suggested locations for them makes them easier to find. I’ve spent hours spelunking in MODx looking for a particular object that "could be anywhere" and the confusion is easily preventable.

    First, let me say that everything in assets should be, and will be site specific in the future. This isolation is absolutely necessary to build a shared layer of elements accessible to multiple sites via the core (i.e. a library).

    Do you mean the reverse, also (that every site-specific element should be under the assets folder)?

    Bob
      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
      • 25969
      • 118 Posts
      I’m happy working out of the /assets/templates folder. For each project I make a template based on the name, with all template based and CSS referenced images being in an "img" dir inside that, for example -
      /assets/templates/sal/all.css
      /assets/templates/sal/ie6.css
      /assets/templates/sal/img/a.png

      Other images the content-manager might want to have a handle on outside of the template structure is kept in the /assets/images directory, such as banner images, etc.
        • 22303 MODX Staff
        • 10,725 Posts
        Quote from: BobRay at Dec 26, 2007, 04:19 PM

        I can definitely see the reason for this, but I think it will make things much harder for new MODx users. I seem to be the only one who thinks so, but IMHO, suggesting guidelines for locating MODx objects doesn’t actually keep anyone from doing anything they want; it just makes it easier to find things when you want them.

        I never meant to suggest that MODx would *look* for things in particular places, that would be an unreasonable restraint, just that there are standard elements that everyone uses (images, .css files, .js files, etc.), and having suggested locations for them makes them easier to find. I’ve spent hours spelunking in MODx looking for a particular object that "could be anywhere" and the confusion is easily preventable.
        As we continue the evolution to a content management framework from our current state as content management system, I think it will become clearer that I am simply suggesting that anything to do with MODx add-ons and/or external dependencies will not be part of the MODx core. And depending on what the add-on you are developing needs to do, the scenarios and configurations it must support, and numerous other factors that will likely affect your implementation, those decisions should rest entirely with the developer. I’m not talking MODx "users" in the sense of end-users deploying a MODx site, just in terms of add-on and/or core extension development. This means the responsibility for acclimating end-users will rest entirely with the add-on packages, and it will be critical that add-ons are well documented in regards to any standards such as the location of CSS files. Add-ons include themes.

        Quote from: BobRay at Dec 26, 2007, 04:19 PM

        Do you mean the reverse, also (that every site-specific element should be under the assets folder)?
        No; IMHO, that decision should rest entirely with the developer of the add-on. Consider an add-on that provides a theme switcher capability or an add-on that provides a port of a legacy theme with all sorts of odd path dependencies you might not want to spend hours resolving.

        As for end-user targeted add-ons/sample sites to use as starting points, creating and documenting such standards in relation to such a sample site would be extremely useful, and I do not discourage that at all.