search

markstory / asset_compress

An asset compression plugin for CakePHP. Provides file concatenation and a flexible filter system for preprocessing and minification.
MIT License
370 stars 125 forks source link

Dynamic build files and Debug issues #135

Open gabrielslau opened 12 years ago

gabrielslau commented 12 years ago

Hello Mark, I'm having some problems with the latest version of the plugin. He is not working with debug = 1 and the "dynamic build files" are not being generated correctly.

In my Local server (development)

with DEBUG = 0:

Loads static content correctly however, the dynamic build file is different from that was generated via console with the command cake asset_compress.asset_compress build --force.

[css]

[js]

with DEBUG = 1:

[css]

[js]

with DEBUG = 0:

[css]

[js]

with DEBUG = 1:

[css]

[js]

From what I saw, the values ​​(true or false) of (cacheConfig) and (alwaysEnableController) had no effect in building the url, but if I use debug = 1, the plugin does not work anymore.

markstory commented 12 years ago

I'll take a look, I honestly never use dynamic build files, and generally think they're a bad idea. I'm half tempted to remove them as I think they're just a bad idea. But since they're still in the code they should work :)

gabrielslau commented 12 years ago

I also don't like how they work now because, in my tests, all "dynamic files" of all views and elements were compressed into a single file. The compressed javascript file was over than 1Mb.

In my opinion, the Dynamic build files should be generated on each final page that is displayed, and generate a cache for this file if there is none.

markstory commented 12 years ago

I just don't use them :smile:

markstory commented 12 years ago

One problem with 'each final page' is solving what a final page looks like. Without visiting each page, its a non-trivial problem to resolve the various parts of a view and figure out what assets should be in a dynamic build. If you figure it out, I'd be happy to include the changes. I've found in practice that defining assets in the ini file is simpler faster, and easier to debug.

gabrielslau commented 12 years ago

In my case, in the .ini file I set only those files that are required for all parts of the site, and in each view, if necessary to load some extra asset, I include them dynamically.

In the previous version of the plugin, the dynamic files was detected by the controller and compressed into a single file that was displayed with a huge url with all their names.

The controller already does the check which files are loaded by the final view page. It only remains to ascertain whether there is already a cached version of this file and return the url:

If not, creates and compress the file and returns only the cached url.

markstory commented 11 years ago

Dynamic build files should still work, but you cannot generate static assets with them. I really don't like the idea of allowing the development features from writing to the filesystem. It requires making more directories writable by the webserver. It also exposes servers to DOS attacks. An evil person can continually request new asset files to be generated. When minifiers and preprocessors are involved its not hard to exhaust server resources.

gabrielslau commented 11 years ago

Hello Mark, I was running some more tests to find the problem and discovered that the reason the plugin is not working is the hash names generated by the plugin helper.

If I set the $target parameter to the methods addCss() or addScript(), the files are generated and the helper points to them correctly. But if I do not pass the $target parameter, the helper points to a different file that is generated by the compiler.

This happens regardless of the debug level.

I hope this information is useful to solve the problem.