Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
function add_path in Core Asset
  • /**
         * Adds the given path to the front of the asset paths array.  It adds paths
         * in a way so that asset paths are used First in Last Out.
         *
         * @param   string  the path to add
         * @return  void
         */
        public static function add_path($path)
        {
            array_unshift(static::$_asset_paths, str_replace('../', '', $path));
        }
    

    has str_replace special meaning here ? because i want use assets from main domain in subdomain (that we did not duplicate assets) it would be possible if: 1 set asset config to 'url' => ''
    2
    Asset::add_path('../../assets/');
    
    3
    no str_replace in add_path function
  • Because the paths are used to construct the filename of the asset, and the filename is part of the rendered output (for example as a src attribute to a script tag), all assets should be inside the docroot. Going up beyond that is pretty pointless. You can't add a asset like "http://website/../../assets/bla.js", it won't work. Not to mention it's a security risk if it does...
  • Harro Verton wrote on Sunday 30th of October 2011:
    Because the paths are used to construct the filename of the asset, and the filename is part of the rendered output (for example as a src attribute to a script tag), all assets should be inside the docroot. Going up beyond that is pretty pointless. You can't add a asset like "http://website/../../assets/bla.js", it won't work. Not to mention it's a security risk if it does...
    but i wasnt use path "http://website/../../assets/bla.js"; but relative path "../../assets/bla.js" i dont see problem
  • My point is that "../../assets/bla.js" means DOCROOT."../../assets/bla.js", which means you're constructing something that is not inside your docroot, but two directories up. Which is never going to work for an asset, since assets HAVE to be inside the docroot to be loadable by the browser. It might work if one of your asset paths is two or more directories below your docroot (in which case ../../assets is still within the docroot) but that's an odd reverse way of working. I agree that this might be confusing, it should be better if asset::find_file() would check if the final result (the file found) is inside the docroot, and should throw an exception if not.
  • Harro Verton wrote on Sunday 30th of October 2011:
    My point is that "../../assets/bla.js" means DOCROOT."../../assets/bla.js", which means you're constructing something that is not inside your docroot, but two directories up. Which is never going to work for an asset, since assets HAVE to be inside the docroot to be loadable by the browser. It might work if one of your asset paths is two or more directories below your docroot (in which case ../../assets is still within the docroot) but that's an odd reverse way of working. I agree that this might be confusing, it should be better if asset::find_file() would check if the final result (the file found) is inside the docroot, and should throw an exception if not.
    sry but you have bad point i think because i have public_html
    -- assets
    ---- _sub
    subdomain1
    subdomain2 i want on subdomain1 have assets from main domain = IAM ALWAYS IN PUBLIC DIRECTORY - but yes its not in DOCROOT
  • I still don't get what you are trying to do. The root for any asset load is the DOCROOT, I assume in your setup that is the 'public_html' folder. Which from a browsers point of view, is "/" (hence the name docroot). From there, going up doesn't make sense, since anything up from the DOCROOT is not accesable by the browser. I don't know why you think the 'subdomain' folder is the root of asset loading, so you feel the need to use '../' to navigate up the tree. Maybe you should explain your setup first, so I don't have to work with assumptions.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion