We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39932
    • 483 Posts
    Yes and No. Yes, but it creates a lot of manual work for you.

    1) As other people have mentioned, you may do a URL rewrite. However URL rewrite in .htaccess won't affect where URLs generated on your site will go to. It only affects the displayed URL of an already requested URL. So, the URL in the browser address bar may indicate that it is not it "home", but the links will all say "home".

    2a) You could manually remove the "home/" from all addresses on all of your pages... (not recommended). You could alternatively, use "relative" for your URL scheme. This is in System Settings. This will mean that every page link will be broken, however.

    2b) You could write a plugin that uses aliasing and "sendForward" so that your URLs without "home" retrieve the desired document. This is not extremely hard. You would basically get the "$_SERVER['REQUEST_URI'] and add a "/home/" to the beginning. Then you would have to compare resrouces to find a match. The problem here is that every page would take longer to find increasing load times. Additionally, search results can be affected negatively (if these are important to you).

    Ultimately, I wouldn't recommend this as this defeats the purpose of using a CMS to begin with. What you should ask yourself is whether the resources should really be under Home to begin with. URL Structure. Mind you, I wanted and did exactly what you wanted to do, and it broke my site in a lot of ways, so I had to think about whether it was really worth the effort.

    Here is the logic I used to trick myself out of the desire. Logically, the home page is the one of the few pages of any website that doesn't really "deserve" being a parent. Often, home pages are a conglomeration of every area on your site. It directs readers to more specific areas based on what they need and your site provides. They typically have no specific function except to act as a router for information.
      Website: Extended Dialog Development Blog: on Extended Dialog
      Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
      Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

      Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
      • 40735
      • 119 Posts
      @frogabog I've structured it this way for organizational purposes. I have a couple other top-level containers that have things like site utilities and such in them. I'm not too familiar with Contexts in MODx so maybe could accomplish my goals with them. I'll look into that more.

      @sottwell I thought that might be the case. I guess I'll either live with the full path or come up with a different organizational system.

      Thanks!
      • I usually keep my site utility pages in a container named "Tools" or something similar that is either unpublished or set to not show in the menu.
          Studying MODX in the desert - http://sottwell.com
          Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
          Join the Slack Community - http://modx.org