We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 6180
    • 31 Posts
    I’m looking for clarity.

    I have a site set up with a vanilla install of Revo 2.0.0-rc-2 rev6923. I have configured a couple of contexts and folders for running subdomains, and my server is configured to point requests for the subdomains to the specific folders.

    Using stock elements from the repository, do I need to have the assets content in each folder, or is the central Assets folder accessible?

    My inquiry comes as I have found templating to not work in the subdomains - all CSS and external resources are not available.
      • 18373 ☆ A M B ☆
      • 3,141 Posts
      I’ve not been messing around with contexts myself just yet, however as long as your contexts are web accessible you should be able to reference to the CSS and other files. Just gotta get the link pointing to the right location.

      Perhaps using a <base href="[[++site_url]]"></base> in your template will fix your problem. If not, you’ll have to see how relative urls are behaving in the different contexts and define your links in that way.
        Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

        Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
        • 22303 MODX Staff
        • 10,725 Posts
        I generally set-up a subdomain specific for our "assets" that are used and shared on each subdomain and use a custom system setting to prefix the common CSS, JS, images, etc. For example, we would set a system setting called shared_assets_url and prefix our assets used in our templates using [[++shared_assets_url]]relative/path/to/asset.ext.

        Another option would be to set assets_url explicitly in the subdomain context settings to always look at the virtual host where the actual assets are being installed by the package manager, i.e. the MODX_ASSETS_URL from the config file. I also believe some packages may actually allow you to configure an assets_url for the entire component via system settings and/or element properties/property sets.
          • 6180
          • 31 Posts
          Jason,

          Thank you for answering my question. The two options are very helpful.

          Regarding setting the "assets_url" to the directory used by the package manager, I understand that any unmodified element that uses file system objects would therefore be looking to the single directory. I realize this may cause complications for elements that attempt to write back to the Assets directory without first allowing for user definable locations. That situation can be mitigated.

          On another note, can elements be assigned to specific contexts? In this sense I’m thinking of subdomain specific templates where keeping available options distinguished is of sufficient concern, particularly in the case of sub-site administrators.
            • 6180
            • 31 Posts
            I think that, instead of beating around the bush, I should just state clearly what I’m trying to accomplish.

            Global Assets vs Local Assets.

            I have been experimenting with the assets_url context setting to point that to the default system assets location that is used by the package management system. Unfortunately I haven’t yet figured out what that value is supposed to look like. e.g. site.net (physically at /home/site/)with assets at http://site.net/assets (/home/site/assets/). For my.site.net (physically at /home/site/my/), what should the assets_url, or assets_path setting be?

            I would like to understand the subdomain processes so I can determine if I can perform the task of setting up subdomains without having to modify every single element to point to a custom setting.
              • 22303 MODX Staff
              • 10,725 Posts
              Quote from: CwnAnnwn at Jul 04, 2010, 02:28 AM

              I have been experimenting with the assets_url context setting to point that to the default system assets location that is used by the package management system. Unfortunately I haven’t yet figured out what that value is supposed to look like. e.g. site.net (physically at /home/site/)with assets at http://site.net/assets (/home/site/assets/). For my.site.net (physically at /home/site/my/), what should the assets_url, or assets_path setting be?

              I would like to understand the subdomain processes so I can determine if I can perform the task of setting up subdomains without having to modify every single element to point to a custom setting.
              You are pioneering a bit here, but obviously, the Extras you choose to use have to be Context-aware to be useful in these situations.

              Look at the default values for MODX_ASSETS_PATH and MODX_ASSETS_URL (these are your global defines that are set in the configuration). PATH refers to the absolute physical path on the filesystem where the directory exists, and URL refers to the URL that would access it (not including the scheme/domain, e.g. /assets/). But you have to remember that this URL is also relative to your current virtual host. This may not be what you want, and in our case, we chose to create our own system setting to manage web-accessible assets in a specific subdomain. With most Add-Ons, installing them in the main domain will simply provide a few web accessible default CSS and JS files that are meant only for demonstrating how to customize the markup and styling yourself using the typical Chunk (or file-based) tpl properties that most Add-Ons utilize. More complex Add-Ons will of course be the challenge.

              We’ll have to establish a set of best practices for building multi-context capable OR single-context targeted Add-Ons for MODx as we move forward. These are new and unique challenges for new and unique features in Revolution, so these are certainly not well established yet.
                • 10596
                • 18 Posts
                I apologize if my explanation is out of your target, here we go:

                add the following "redirect" to your .htaaccess of your subdomain

                Redirect permanent /old_directory/ http://www.new-domain.com/new_directory/

                mine: Redirect permanent /assets/ http://www.my-site.com/assets/

                this following tree is mine:

                +assets
                - images (share images for main domain & subdomain)
                - js
                - style
                +connectors
                +core
                +manager
                +web
                +my_sub_domain
                - .htacess --> add redirect here
                - config.core.php
                - index.php

                if you "view source" your file, the image tag in http://sub.my-site.com still says: <img src="assets/images/ads/728X90.gif" alt=""/>
                and pointing to http://www.my-site.com/assets/images/ads/728X90.gif in your subdomain, BUT .htaccess does the magic.

                PS: the sub domain creation’s based on this: http://rtfm.modx.com/display/revolution20/Creating+a+Subdomain+from+a+Folder+using+Virtual+Hosts
                  • 16430
                  • 217 Posts
                  If I put this code in subdomain .htacess it does nothing.
                  If I put it in maindomain .htaccess it end up in loop.
                    • 16430
                    • 217 Posts
                    I worked it out this way:

                    Put this code at the begining of htacces file
                    RewriteEngine On
                    RewriteBase /
                    RewriteRule ^assets/?(.*) http://www.domain.com/assets/$1 [R=301,L]
                      • 3112
                      • 11 Posts
                      I know this thread is old, however I think "ln -s path_to_your_assets_folder assets" would work in your virtual host folder if your web server allows followsymlinks.