Can this work for CSS/JS from Add-On's?
Permalink Browser Info Environment
I understand that the other poster raised a good point that the optimization should be incorporated into the core engine, and I agree.
But for now, based on what's available now, can we consolidate CSS and Javascript used by add-on modules to save connections and page loading time?
Thanks!
Ryuji
But for now, based on what's available now, can we consolidate CSS and Javascript used by add-on modules to save connections and page loading time?
Thanks!
Ryuji
| Type: | Discussion |
|---|---|
| Status: | New |
Can you provide some example code snippets to use this on addon's? How can I specify /updates/100510/concrete part of the path in an abstract way?
Thanks,
Ryuji
Thanks,
Ryuji
All scripts would access the Optimizer in the same fashion, the major item to note is 'Compile*' is called once and only after all files have been queued.
An example of the general usage can be found at 'http://xclydes.com/samples/c5-utility-pack/'.
I am not sure how you would specify a part of the url as a file to be processed, the optimizer was designed to load file whatever source and process its contents.
I suggest you look into finding out the location of the file(s) at that url and loading those instead of trying to use the url.
Apart from opening up yourself to an infinite loading loop, but the url may return more than just a simple script or css file.
It could be I am not understanding your question, please let me know.
-x
An example of the general usage can be found at 'http://xclydes.com/samples/c5-utility-pack/'.
I am not sure how you would specify a part of the url as a file to be processed, the optimizer was designed to load file whatever source and process its contents.
I suggest you look into finding out the location of the file(s) at that url and loading those instead of trying to use the url.
Apart from opening up yourself to an infinite loading loop, but the url may return more than just a simple script or css file.
It could be I am not understanding your question, please let me know.
-x
I looked at your page but all examples are about themes and not about add-ons. Add-on files may be located athttp://whatever.com/updates/100510/concrete/css/ccm.base.css... orhttp://whatever.com/packages/superfish/blocks/superfish/js/superfis... depending on the package and how the site is installed (mutisite or not).
So, what can I use other than $this->getThemePath() to refer to those places?
Also, where can I put in the code to combine files across packages and themes?
Thanks,
Ryuji
So, what can I use other than $this->getThemePath() to refer to those places?
Also, where can I put in the code to combine files across packages and themes?
Thanks,
Ryuji
Hi Xclydes, great idea for an add-on- long overdue. But I echo some of the other comments in saying some better documentation is needed. Can you explain where exactly (file names) you implement your code as demoed on your site? Thanks!
Firstly, let me say thank you.
I have not been ignoring the requests for more documentation, unfortunately I just haven't found the time to create a full example.
The same method which is used to add items from within a theme are the same methods used everywhere else. The only difference is the '$block->getBlockPath()' ('$this->getBlockPath()' from within the block) is used instead of '$this->getThemePath()' for block related assets.
I will try to make some time to setup a full and complete example. I just cannot say exactly when just yet.
I have not been ignoring the requests for more documentation, unfortunately I just haven't found the time to create a full example.
The same method which is used to add items from within a theme are the same methods used everywhere else. The only difference is the '$block->getBlockPath()' ('$this->getBlockPath()' from within the block) is used instead of '$this->getThemePath()' for block related assets.
I will try to make some time to setup a full and complete example. I just cannot say exactly when just yet.
If you want to implement this in your theme, you can add it to your 'header.php' file in the location where you would traditionally put your .css loads.
For example, in the Whitespace theme, there are two .css files, 'typography.css' and 'main.css'. Here's the original code for loading them in 'header.php':
And here's the xclydes utility method for adding them. The original files will be ignored, the new combined file will be loaded, apparently to reduce the number of HTTP requests and load the page faster.
Still trying to figure it out for a number of .css and .js files called from add-on packages & blocks, though... that's where the real bloat seems to be happening in c5.
Sherm Stevens
http://www.invision-studios.com
For example, in the Whitespace theme, there are two .css files, 'typography.css' and 'main.css'. Here's the original code for loading them in 'header.php':
And here's the xclydes utility method for adding them. The original files will be ignored, the new combined file will be loaded, apparently to reduce the number of HTTP requests and load the page faster.
<?php try{ Loader::model('asset_optimizer','xclydes_utilities'); AssetOptimizer::addCSS($this->getThemePath().'/main.css'); AssetOptimizer::addCSS($this->getThemePath().'/typography.css'); echo '<link type="text/css" href="'.AssetOptimizer::compileCSS().'" media="all" rel="stylesheet" />'; } catch(Exception $error){ Log::addEntry($error->getTraceAsString()); } ?>
Still trying to figure it out for a number of .css and .js files called from add-on packages & blocks, though... that's where the real bloat seems to be happening in c5.
Sherm Stevens
http://www.invision-studios.com
Yes, it should be able to. It was originally designed for use with any and all modules.
The core is able to access use the asset optimizer, it all comes down to whether or not the script is able to address the AssetOptimizer and the AssetOptimizer is able to find the media using the class specified.
Once both conditions are met, then the files will be packaged once the appropriate packager is called.
Currently the only drawback is an inherent problem related to javascript. If script A has a dependency on script B, then script A needs to be submitted to the optimizer before script B is submitted. If this is not done, javascript errors will be most likely be generated on the client-side.
I have been looking at ways of handling this problem, but I am always open to suggestions on improving the package.
-xclydes