All the tutorials on optimizing website assets with grunt and grunt-usemin are based on the src -> dist deploy strategy. basically processing the items in your src folder and compiles them into the dist folder.
But PHP doesn't work this way. It isn't compiled and "distributed". The source and target page are the same. Which makes it a destructive process.
How do you work around this? Any tips on using Grunt in PHP project in general?
Thx.
We do something similar. We created an index.src.html with the non-minized sources, and create an index.html from this file using usemin, and we have a "proxy" php file which opens the index.html if it exists (which means we are in the production environment and the assets are built), otherwise the index.src.html if the assets haven't been built or we are in a development environment. The main idea is to separate the important parts for usemin to a different file.
The usermin plugin is for preparing static assets (concatenate, minimise,...). Static means the server gives the same content for everybody. This constraint doesn't apply to PHP...
If you would like to use this tools to optimize your php generated pages assets, you should create input files which can be parse-able by usermin. For example you can collect the javascript/css file references into a template or a different php/html, and you include/use this file where you need, and after the build you use the usermin parsed version of it.
The ideal approach would take advantage of the dynamic nature of PHP to make the "distribution" URL replacement. The process would be:
Your build tool creates some kind of manifest or machine readable file with changes applied. Some tools, as gulp-rev will do this for you.
Read the manifest from PHP and replace the resource URLs with the final ones.
Related
I'm creating an app in Phalcon which contains a theme manager. A theme is nothing more that a collection of .scss and .volt files. Naturally, these .scss are built before being used.
I'm been testing Phalcon's assets manager. Apart from some difficulties creating custom filters, etc, I started wondering: why would someone build their files all the time? This would make each request much slower. Does Phalcon cache these assets?
Furthermore, when developing themes or doing a lot of frontend work it is useful to watch the source sass files for changes. Is this possible in Phalcon?
According to manual using ->setTargetPath() on assets collection makes it possible to save all selected files into one location. If you have some scripts you always include to your page, you can marge them to one file, and meantime minify thanks to filters filters. Code snipped would be somewhat like that:
$controller->assets->collection('jsGlobal')
->addJs('libs/jquery.js', true)
->addJs('libs/jquery-ui.js', true)
->setTargetPath('js/global.js')
->setTargetUri('js/global.js')
->join(true)
->addFilter(new \Phalcon\Assets\Filters\Jsmin());
You may want to check if script it already built under that js/global.js location to prevent from building it over and over again on production. This way, when making your deploy script you can just implement deletion of certain files on your production server.
Projects I'm working on uses less. We installed \lessc library to manage to keep in repository only .less files.
And again, in development mode we're not even checking if file was changed - we assume is was and are recompiling it just always. For production purposes, PHP is written to check if certain scripts does exist and is compiling .less only if they dont.
I have been looking into incorporating an asset management/pipelining tool (probably Assetic) into my PHP project.
Since assets can be grouped into collections or wildcard-based paths using such tools, if I wanted to set up a watch process that re-compiled/minified only those source files that had changed, how would I do that given that assets have to be looked up by name (see example below)?
(I noticed that for Symfony there's a watch task for Assetic but I'm not sure that it re-compiles only the changed file(s) and also I would have to make it work outside of Symfony since my app uses the CodeIgniter framework.)
In Assetic, you can create a wildcard-based asset, e.g.:
new GlobAsset('/path/to/compass-sources/*')
You can tell it to send the assets through a filter (Compass in this example) and then output the result (CSS) to a folder like public/css.
Let's say I set up the watch process using node.js's fs.watch so that I can theoretically tell Assetic to re-compile a particular asset whenever one of its source files changes.
Since my node.js script would only know the name of the actual file that changed (e.g. compass-sources/layout.scss), how could I look up which AssetCollection or GlobAsset that particular file belonged to (say an asset called global-styles) in order to recompile it?
I'm open to alternatives here. I looked at grunt and may very well use grunt-contrib-watch to handle the file watching, but I like the idea of using Assetic because the project is in PHP and I think that will be easier on future PHP developers working on the system who may not be familiar with node.js. It seems grunt take a different approach where assets don't necessarily go in named bundles. Mostly I want to understand the conceptual approach of named asset bundles (like in Assetic) as it relates to my goal of recompiling assets whenever the source files change.
I can't find much information about Yii's AssetManager for the management of JS and CSS files. My question here is what is the point of using the AssetManager? I'm not sure what value it adds to my development process, in fact, it seems like it complicates my code... every time I change my scripts or css code, I have to go in and delete my assets folder to make sure I have the latest versions.
Seems it is much simpler to just put all Javascript files under /webroot/js/ and just use the tags to load the files instead of going through the trouble of AssetManager. Plus, Yii's registerCoreScript function always places script tags inside the header tag, instead of placing them at the bottom of the code, near the closing body tag, as recommended by YSlow.
I think there must be a gap in my understanding of Yii's AssetManager. Anybody have any ideas why using the AssetManager is better than hard-coding the script tags inside the PHP code? I'm a bit confused...
Thanks!
I'm sure someone can answer this better than myself, but basically it's so that your source JS and CSS files can remain in your Protected folder.
This is a little more secure for one thing, but the main benefit to me is that you can compress and minify and otherwise process your assets with the asset publishing system, and it makes it easier to host your JS and CSS on a CDN since it's separate from your codebase.
Also, here's an official response from qiang (the guy who wrote Yii) about this.
The main benefit of Yii's asset manager is that it allows you to structure your components in a self-contained manner.
A tale of a widget
Consider a component that is a UI widget. Let's assume the distribution includes a couple of assets along with the component implementation, for example these files:
SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png
Consider how you would incorporate this widget into your application if the asset manager did not exist. Typical steps might include:
Copy SuperWidget.php somewhere inside the protected/ directory
Copy superwidget.js to your js/ directory
Copy superwidget.css to your css/ directory
Copy image_for_css.png to your images/ directory or perhaps also inside css/ to help reduce the relative path dependencies
Then at runtime SuperWidget would emit appropriate tags to include the CSS and JavaScript; to do this, it would need to know where exactly you have placed these assets. In other words: some choices regarding the installation can be made arbitrarily, but then they are set in stone unless you go and edit the source.
Is the widget reusable?
If this widget were highly customized and meant to be an inseparable part of your application then this approach would work fine and there wouldn't be much need to have an asset manager. But what if it's a broadly useful component that you want to distribute?
Problems start arising.
First of all the deployment scheme we have examined requires users of the widget to copy different files into different directories, complicating the installation procedure and increasing the chance of error.
But the greater issue is that your deployment scheme could conflict with that of any other component developed independently of yours. What if someone else decided to have a superwidget.js file too?
If the installation instructions for these two components conflict then obviously one of them cannot be installed as intended, and then you resort to changing some details and hacking the source code of the component to accommodate these changes. If you later upgrade to a newer version of that component you will be forced to carefully account for your customizations, making a "copy/overwrite" upgrade impossible.
All of this is really not pretty, and while it can be unlikely to happen in practice it certainly doesn't feel right.
Asset manager, make it so
Here's where the asset manager comes in. Let's assume you decide to structure your component like this:
superwidget/
SuperWidget.php
assets/
css/
superwidget.css
js/
superwidget.js
images/
image_for_css.png
You can directly copy this somewhere inside your protected/ directory no matter what other components you have installed; the worst thing that could happen here is that you'd have to rename superwidget/ to something else if there was a conflict.
Using the asset manager, SuperWidget.php publishes the whole superwidget/assets/ directory, with the copy ending up at e.g. assets/1337c0de/ where assets/ is your application's base asset path and 1337c0de/ is a random hash created by Yii and guaranteed to not conflict with any other published asset.
This means that the assets for SuperWidget cannot possibly conflict with those of any other component, making SuperWidget truly reusable. And since the directory structure inside 1337c0de/ will be the same as in your distribution, CSS can refer to images using the relative path ../images/ without needing to refer to the value of the random hash (which is only know after publishing).
What the asset manager is not
It's not a way to increase security. Your component source would be somewhere inside protected/ anyway (so no improvement there), and the assets need to be web-accessible no matter where they end up being copied (no security for them no matter what).
It's not a catch-all solution for processing your assets (e.g. minifying CSS). While it is possible to install a custom asset manager that does this, don't forget that assets included with reusable components will a small minority among all of your "base application" assets; if you want minification across the board, you 'll have to also process everything else and the asset manager will not help you there.
TL;DR
The asset manager allows you make components that are easily distributable and can be included in applications without the fear of creating conflicts with other components.
Another perk that I like about the asset manager, is that it allows you to update your asset files without having to tell your users to clear their cache.
http://www.yiiframework.com/wiki/311/assetmanager-clearing-browser-s-cache-on-site-update/
What is a benefit of having "build/" folder where all the sources will be placed and "built"?
Maybe it's a silly question, but I'm trying to understand Continuous Integration with PHP. Any example of build.xml for phing uses such build/ folder, but what's a sense in that for PHP where a checked out project doesn't require a compilation, only a basic configuration. Copying it all into build/ will just complicate the things, because you'll have doubled files and +1 folder to the web root path (if you'd like to have web UI to run selenium tests on)
Particularly I need phing for two cases:
1) let new user setup his first installation (or update old), right on a working copy
2) run unit/func-tests, phpcc, phpcs, phpdoc etc (all that usually on CI server)
Should I have "build/" for the second task? What is the best practice for PHP?
There are several good reasons to have a build directory (i.e., deployment to multiple environments, performing some text replacement, minimizing and combining CSS and JS, optimizing images, handling of config files etc.)
However, these may not apply in your use cases. There is no rule saying you need this directory. Depending on your thinking on testing in production, a build directory may be a good reason to keep this directory.
I run multiple websites all running off of a single installation of CodeIgniter on my server (separate application directories and a single system directory). This has been working fabulously and I don't see any reason to change it at this point.
I find myself writing library classes to extend/override CI all of the time and many times if I find a bug or improve effeciency I have to go back to several websites to make the same adjustments at risk of a typo that breaks one of the websites. Because of this it requires that I change each file and then test that site for bugs.
I have been pondering a solution of using a single libraries directory in a central location and symlinking all of my websites to that central directory. Then when I make a file change it will immediately propagate to all of the downstream websites. It will still require that I test each one for errors, but I won't have to make the changes multiple times. Anything that is specific to a single website will either be a non-shared file (still in the linked directory just not used elsewhere) or can be put in a local helper.
Also, I keep separate 'system' directories by CI version so I can migrate my websites independently if necessary--this central libraries file would be attached to a specific version to reduce possible breaks.
Does anyone see potential issues or pitfalls from taking this approach? Has anyone accomplished this in another direction that I should consider?
Thanks in advance!
I think this actually makes sense :] Go for it. Even on official CodeIgniter page, they mention it's possible.
Also, I don't see one reason why there should be any problem.
Edit: they touch the problem of multiple sites here: http://codeigniter.com/user_guide/general/managing_apps.html
also:
http://codeigniter.com/wiki/Multiple_Applications/
http://www.exclusivetutorials.com/setting-multiple-websites-in-codeigniter-installation/
How to Handle Multiple Projects in CodeIgniter?
http://codeigniter.com/forums/viewthread/56436/
I have a single system directory and separate application directories for my CI apps. In order to share libraries and some view templates between my apps, I have created a "Common" directory, in the same folder as the CI system and with the same structure as a regular app folder and used symlinks, but you can modify the Loader class so that it looks in the Common folder too. My setup looks something like this:
/var/CodeIgniter/
/var/Common/
/var/Common/config/
/var/Common/controllers/
...
/var/Common/libraries/
...
/var/www/someapp/
/var/www/someotherapp/
...
I'm not sure how you handle publishing your sites (assuming you actually do any of that), but I'd look into version control. For example, in SVN you can make external to another svn directory (or file) and then just update the current svn directory which grabs the external file. This approach gains one benefit from the others, which is when you modify the common library, the others aren't immediately affected. This prevents unwanted breaks before you have time to go test all the sites using the common library. You can then just update each site's folder whenever you are ready to test the changes. This is "more work", but it prevents code duplication AND unwanted breaks.
I wrote a MY_Loader to do exactly that.
http://ellislab.com/forums/viewthread/136321/