We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22303 MODX Staff
    • 10,725 Posts

    That sounds like it is working just like it should-- you cannot use subdirectories in your path and relative URLs at the same time.
    I tried changing everything to absolute paths (relative to the server root) and had no better luck.
    Actually, this is why I added the <base href= tag to the templates, so the relative pathing would work from any subdirectory. I probably just missed an important detail somewhere.

    This I don't get because it works for me: /assets/sites/style.css always works, even with aliased paths like /work/projects/thissite/changes.html

    Or am I misunderstanding something?
    No, I just couldn't get it to work, but like I said above, I may have missed something. I'll try it again with my next site.
      • 34162
      • 1 Posts
      I just couldn't get it to work, but like I said above, I may have missed something. I'll try it again with my next site.

      Yeah, it definitely sounds like something may just be out of sync, because especially with a base tag in there, relative paths should work.

      I guess if you wanted to automate your switching idea, you could have it automatically apply the <base ...> to the head which, under ideal circumstances, would only affect the relative paths, but I don't know that I'd personally be happy with a system doing something to one of my templates that I could not control. In other words, you'd need an option to deactivate this auto-"correct" behaviour and use the aliasing as they work now:

         ALIASING
         You can have the system generate human readable URLs for you.
         For more information [click here].
      
         Do you want to use hierarchical aliases?  YES / No
            + Auto correct relative paths when using aliases?  Yes / NO
      

      Does that make sense?
        • 22303 MODX Staff
        • 10,725 Posts

           ALIASING
           You can have the system generate human readable URLs for you.
           For more information [click here].
        
           Do you want to use hierarchical aliases?  YES / No
              + Auto correct relative paths when using aliases?  Yes / NO
        

        Does that make sense?

        Absolutely; was thinking it would just be a snippet I put in the header (only to make it dynamic, i.e. portable), along with my GetKeywords and GetDescription snippets. Though adding an automatic option for that might be a nice end-user feature.
          • 25663 MODX Staff
          • 12,272 Posts
          I vote for an automatic option switch/checkbox. I've beat my head against the wall with alias paths with both absolute and relative path problems. Definitely something to test immediately upon Raymond's initial commit.

          Could we have the admin tool automatically write the .htaccess files? There's a fix for flickering images on hovering elements in PC IE that could go in there as well:

          ExpiresActive On
          ExpiresByType image/gif A2592000
          ExpiresByType image/jpeg A2592000
          ExpiresByType image/png A2592000
          
          # This stops the horrible screen flicker in IE
          BrowserMatch "MSIE" brokenvary=1
          BrowserMatch "Mozilla/4.[0-9]{2}" brokenvary=1
          BrowserMatch "Opera" !brokenvary
          SetEnvIf brokenvary 1 force-no-vary


          We could also then have it update the rewrite rules if you move it from a staging directory to live site as well.

          Thoughts?
            Ryan Thrash, MODX Co-Founder
            Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
            • 34162
            • 1 Posts

            Could we have the admin tool automatically write the .htaccess files? There's a fix for flickering images on hovering elements in PC IE that could go in there as well:

            We could, as long as we are sure that no one has any rules already in there. Not sure we could do it reliably when someone is already using .htaccess rules, since ordering can be important. For instance, my htaccess is about 70 or 80 lines long.

            Along these lines, though, I would like to see the system handle some of these things itself, at least through config options that then runs pre-defined snippets. For instance, why must we tell new users that they need to include tags such as GetKeywords and GetDescription in their templates?

            Seems like we could simplify a lot of things for beginners if we had some predefined tags for templates:

            {{Header}}
            {{Menu}}
            {{Leftside}}
            {{Rightside}}
            {{Content}}
            {{Footer}}

            The {{Header}} one could include the [[GetKeywords]], [[GetDescription]], [[DoBaserefFix]], etc.

            The {{Leftside}}/{{Rightside}} could be placeholders for the concept that you and I discussed the other day, Ryan.

            Use of these would be completely optional but would supported "out of the box", so to speak, so you could have a fully functional site with a template that just looked like:

            <html>
            <head>{{Header}}</head>
            <body>
            {{Menu}}{{Content}}
            </body>
            </html>

            I have several more thoughts on this-- for instance, we really need a stock CSS template that ships along with a big selection of CSS stylesheets that can be downloaded and installed without ever needing to see the template (ala Wordpress). Using something like the above + the placeholders, a newbie could customize their site by just checking some boxes in the site config.

            Basically, I would really like to include a means to harness the power and completely hide it from the end user. Someone who knows what they are doing can do anything they like but the clueless can do everything they can imagine, too, only the system will grow with them.

            Does that make any sense? If you are interested in discussing this further, let me know-- I've spent the last three years working with over 5,000 church customers (generally computer clueless volunteers), so I definitely have some experience and thoughts on how to simplify things. smiley

            On the otherhand, maybe we only want to target developers and leave it up to someone else to make a version/mod/addon that knocks things down a couple of notches on the scary tech chart?

            (Also: sorry for bringing this so far off topic.)
              • 25663 MODX Staff
              • 12,272 Posts
              In the dev forum, we're allowed to ramble and go off topic! wink

              I really like your idea though about making it idiot-proof for clueless folks via checkboxes. The church volunteer set is a perfect test case for this, too. laugh

              I think we SHOULD in fact do it! However, I think we should spend all our time marketing to developers/programmers at this point. I'd rather not be supporting a million "what's PHP/how do I install X/will this run on Y?" questions right now... hmmm... maybe time to crank up on the young, energetic moderator recruiting! :lol:
                Ryan Thrash, MODX Co-Founder
                Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                • 34162
                • 1 Posts
                Oh, definitely agreed on the not wanting those type questions, at least right now! :shock:

                I think once I get my hands on a copy of the CVS, I'll have some ideas on how we can do this easily.

                Which brings me back to something else: just like the abstracting of the permissions, I'd like to also abstract the config screens.

                Anyone have a knee jerk on this? I have some reasons why, if that would help. smiley
                  • 25663 MODX Staff
                  • 12,272 Posts
                  I'm in favor of abstracting pretty much everything. In an ideal world, what makes MODx tick would be nothing more than a parser and a plugin/module manager. Sessions, Data access, users, etc. would all be a plugin or a module.
                    Ryan Thrash, MODX Co-Founder
                    Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
                    • 22303 MODX Staff
                    • 10,725 Posts
                    I'm in favor of abstracting pretty much everything. In an ideal world, what makes MODx tick would be nothing more than a parser and a plugin/module manager. Sessions, Data access, users, etc. would all be a plugin or a module.

                    Absolutely guys. What makes MODx so great is that it lets you mix and match best of breed web resources. This allows me, as a service provider, to easily put together new sites or existing sites with what would typically be disparate technologies. And once we accomplish that, the next step is to ask, wouldn't it be great to have MODx included on major LAMP hosting services, as an add-on site builder, or Fantastico script?

                    I am white boarding some ideas on achieving complete object abstraction for the core, which can also be used to create an integrated object designer for end-users (with a tree view/detail view that fits in perfectly with our existing manager). This would allow a user to go to the manager and define custom persistent objects using a form; for instance defining a User Profile object that aggregated whatever other objects they wanted, including user-defined objects that could generate php class files and instantly generate the proper data containers if they don't already exist, based solely on the class definition. Then using whatever template syntax we decide to use to access the objects, or using standard PHP object syntax directly, we have an easy-to-use, flexible, and powerful PHP application development and integration platform. The core persistent objects become just another set of classes supporting our already great content management features.

                    The persistence layer is then a set of extended core classes for whatever database implementation you want to support. We can provide MySQL for round one, and then look at using an existing database abstraction layer (EZsql, etc.) to exemplify alternate persitence options.

                    Before I ramble on more, I'll pause for comments and questions...