We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 17301
    • 932 Posts
    I'm certain it'll be something along those lines (maybe with http:// without www. etc). Hopefully someone else can offer more insight shortly.
      ■ email: [email protected] | ■ website: https://alienbuild.uk

      The greatest compliment you can give back to us, is to spend a few seconds leaving a rating at our trustpilot: https://uk.trustpilot.com/review/alienbuild.uk about the service we provided. We always drop mention of services offered by businesses we've worked with in the past to those of interest.
      • 51020
      • 670 Posts
      Quote from: lkfranklin at Feb 27, 2017, 10:45 AM
      I'm certain it'll be something along those lines (maybe with http:// without www. etc). Hopefully someone else can offer more insight shortly.
      ]
      thanks - I'll have a play around with it.
        • 3749
        • 24,544 Posts
        There are several things at play and it's difficult to sort them all out. I don't use multiple contexts if I can possibly avoid it (this is why -- are you sure you need another context? wink ). If the dev context is just for development, it's easier to create a local version of the site on your computer with XAMPP or something similar, and do development work there, imo. Otherwise, when things don't work in the dev Context, you won't know whether it's a problem with the Context itself, or with what you're trying to do.

        I'm guessing at some of this, so maybe someone more familiar with multi-context sites can chime in.

        First, you need to create Context settings for the dev context -- things like base_url, site_url, and base_path. That may keep TinyMCE happy -- I'm not sure where TinyMCE gets its base path and base URL settings from.

        Second, make sure your base href tag has the exclamation point, so it won't be using cached versions of the site_url:

        <base href="[[!++site_url"]] />


        Third, I think you'll need to create new Media Sources for the dev context (this will only effect TVs). Then, edit the Media Sources tab of each TV to add the new dev Media Source so it will use the right source in each context. If the TVs will be shared between contexts, I think you may have to use full absolute paths and URLs in the Media Source's properties.

        Finally, if users will be logging in and need to access both contexts, you need to add the &contexts property to the Login snippet tag and list both contexts there:

        [[!Login? &contexts=`web,dev`]]






          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
          • 51020
          • 670 Posts
          Quote from: BobRay at Feb 27, 2017, 02:17 PM
          There are several things at play and it's difficult to sort them all out. I don't use multiple contexts if I can possibly avoid it (this is why -- are you sure you need another context? wink ). If the dev context is just for development, it's easier to create a local version of the site on your computer with XAMPP or something similar, and do development work there, imo. Otherwise, when things don't work in the dev Context, you won't know whether it's a problem with the Context itself, or with what you're trying to do.

          I'm guessing at some of this, so maybe someone more familiar with multi-context sites can chime in.

          First, you need to create Context settings for the dev context -- things like base_url, site_url, and base_path. That may keep TinyMCE happy -- I'm not sure where TinyMCE gets its base path and base URL settings from.

          Second, make sure your base href tag has the exclamation point, so it won't be using cached versions of the site_url:

          <base href="[[!++site_url" ]]="">


          Third, I think you'll need to create new Media Sources for the dev context (this will only effect TVs). Then, edit the Media Sources tab of each TV to add the new dev Media Source so it will use the right source in each context. If the TVs will be shared between contexts, I think you may have to use full absolute paths and URLs in the Media Source's properties.

          Finally, if users will be logging in and need to access both contexts, you need to add the &contexts property to the Login snippet tag and list both contexts there:

          [[!Login? &contexts=`web,dev`]]







          That's a very good point well made - a local version would be simpler and safer - the problem is i have several iterations of several resources all at various stages of approval. So I can't just put everything live in one hit by updating the database.
          This was really a workaround as I wasn't sure I could get stagecoach to work.

            • 3749
            • 24,544 Posts
            I'm not sure how I'd handle that. One way would be to do the local resources as Static Resources. You could have extra files for the revisions and just cut-and-paste them into the live site when they go live.

            If you wanted to get really fancy, you could use Git and have separate branches for the different revision statuses.

            A more complete system would be to use Static Resources for the live site as well. Then you could use FTP to update the live site from your local copy. A good editor, like PhpStorm, would let you perform the updates inside the editor's IDE.
              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
              • 51020
              • 670 Posts
              Thanks for your thoughts on this.
              I need to read up about Ststic resources. To me it sounds like the way I used to build sites before I used mode - so sounds like a backward step - but I'm sure there must be more to it than that.

              Currently my workaround is to duplicate the resource and hide it from menus so that the client can review it - but then I have to copy and paste and the changes across to the live resource once approved which leaves a lot of room for error.
              I wish there was a way I could just swap the id of the new version to that of the old version - but I can imagine this is not possible!