Posted by nod_ on August 24, 2012 at 7:03pm
68 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | major |
| Assigned: | mcjim |
| Status: | active |
| Issue tags: | Assetic, JavaScript |
Issue Summary
This is aimed to solve #352951: Make JS & CSS Preprocessing Pluggable
As well as making it trivial for contrib to implement something like this #1310698: Add a CSS preprocessor to core
Assetic is a symfony component written by Kris Wallsmith, one of the main symfony contributors.
This is used by several other big PHP projects and has a neat Twig integration.
It will also make life easier for the other initiatives by providing a sane way to interact with assets. The current process is pretty bad and complicated.
Comments
#1
From the documentation:
That's pretty darned nice!
#2
So what would be the general approach to implementing this?
#3
1) get the lib in core with composer and all
2) make drupal_add_js use Assetic to add stuff and get rid of all the processing that exists currently (aggregation is broken at this point).
3) make Assetic take care of the actual processing/aggregation.
I think. Tried and failed 1).
#4
Did 1) fail for technical or social reasons? I mean, do you just need support to get this in place or technical input as well?
#5
oh just because I have no idea how to use composer to add the Assetic lib to core. No politics or anything actually. I just fail at composer :p
#6
In order to start building up a patch, we don't need to wait for core to include assetic. Just modify the composer.json and update.
In order to test this for core we could have a large patch, a patch with just the changes, and (if so desired) a patch with just the tests.
#7
Hey all,
Kris has asked me to chime in here on his behalf as his wife passed away yesterday. If you want to support him during these times, I think he would appreciate it: http://indiegogo.com/franyaberkman.
Unfortunately, I have never used Drupal, so I am totally unfamiliar with how your Asset management works at the moment. So, I will just give you a quick introduction how Assetic works, and I can answer any questions that you might have along the way.
As you mentioned, Assetic has a very good integration with Twig. Currently, we rely on static analysis to parse your templates and extract all assets that are defined in them. Then, we apply the different filters that you have configured (can be different per asset), and dump them in a location you have specified, or for the development environment we also offer the option to route asset requests through a controller action which compiles the assets on-the-fly.
Also, it is possible to compile the same asset for different languages (if you have an i18n page), or to compile optimized assets for each browser. Assetic would then choose the correct asset to include at runtime, and for example only send the German version of your asset to German users.
I hope that is good for a start, if you have any questions, keep them coming.
#8
Thanks for reaching out to us, I'm deeply sorry about the situation. I hope he has the support he needs to have and my thoughts goes to him and his kids.
I'm uncomfortable going from this to lowly technical questions but here goes:
I've looked at the API and it seems there is always a need to dump the files somewhere, is that correct? I'm not sure we can really support the "put the php script as the script src and dump from there" workflow but we can try it out. The "dump the file and serve it" is totally fine, that's what we're already doing.
The l18n thing does looks nice, we have our own way of handling it so we might need to look into that and see how we can approach the problem best.
Thanks a lot for reaching out to us, at this point we're mostly running into drupal-related issues more than Assetic ones but once we're up to speed we'll be definitely need you input on how we do things.
Thanks, and take care.
#9
I've been given time to work on this issue by my employer (yay!): I'll see how far I can get.
#10
mcjim: yay indeed!!!
#11
Slowly (very!) getting my head around Assetic.
Here's some example code I've got working which gathers together CSS files located in one place and servers them as one file from another.
I'm still very far from a useful patch, but learning lots :-)
$factory = new AssetFactory(DRUPAL_ROOT . '/sites/default/files/css');
$system_all = $factory->createAsset(
array(
// This isn't actually a useful example, as you'd never do this.
DRUPAL_ROOT . '/core/modules/system/*.css'
),
array(
// Filters go here.
),
array(
'output' => 'system-all.css?*',
)
);
$am = new AssetManager();
$am->set('system_all', $system_all);
$writer = new AssetWriter(DRUPAL_ROOT . '/sites/default/files/css');
$writer->writeManagerAssets($am);
var_dump($system_all->getTargetPath());
#12
Woo-hoo! :-)
#13
I'm pretty sure Assetic doesn't have anything in it to help with 'bundling'. In #352951: Make JS & CSS Preprocessing Pluggable we discussed making the actual processing of the files, vs. the bundling separately pluggable, and I think that still stands. So the question is how to cleanly separate those two things out into separate subsystems (one of which might be raw assetic or we might need to extend it). If any aggregation logic needs to change to allow Assetic to handle concatenating the file, please take into account #1014086: Consider using imagecache style generation of css and javascript aggregates which has a lot of discussion on how to improve what we currently do as well as various pitfalls.
Also I'm not sure why this is a new issue rather than #352951: Make JS & CSS Preprocessing Pluggable, can we mark it duplicate and do the work there? Or at least make it clear why there's two issues?
#14
@catch Over on comment #46 in #352951-46: Make JS & CSS Preprocessing Pluggable, I think there's a fairly good reason to do "grouping" as a separate plugin from "packaging". So this issue is simply to explore using Assetic to do the packaging, I think.
Maybe mcjim can jump in with what he's learned from the past week working on Assetic.
#15
+1 to title change for clarity.
@catch You're entirely right, Assetic has no logic itself to handle bundling together of assets, it needs to be told what to do.
What Assetic is fantastic at is packaging those bundles into discreet files which can be served from anywhere in the web root, and that's what I've been exploring.
Attached is an experimental patch (which depends on Assetic being in core: see patch at http://drupal.org/node/1784774#comment-6481486. You'll need to apply this first). It simply shows Assetic being used: an actual implementation would need much more work.
Existing Drupal core functions are used to group together CSS files which are then filtered and packaged by Assetic so they can be served from sites/default/files/css. Currently, one filter is being applied, which rewrites image URLs to the new paths, but there is commented-out code in there which can be used to apply the YUI compressor filter too (just as an example, it could be anything).
#17
Just to let the bot have at it.
#18
@17, won't happen, the patch is marked as do-not-test, and it depends on assetic being in core. So it would fail regardless.
#19
@mcjim: since you're now the guy who has hands on experience with assetic, what is needed to move this forward? Do you have an idea what/where is needed to create a working patch? So other followers are able to chip-in :).
(assumed the #15 patch was a non-functional, proof of concept patch)
#20
step 0 is this #1784774: Add Assetic component to core then we can talk about patches.
issues should be tacked in this order:
#21
@Kiphaas7 Give the patch in #15 a whirl, see what you think. it only works for CSS at the moment, so If you have time to experiment with making it work with JS, that would be great. It could be really useful to show the benefit of using Assetic.
I'm working on http://drupal.org/node/352951 at the moment, as bringing in Assetic will be a lot easier once we've made the whole asset system pluggable. I'm reworking the patch in http://drupal.org/node/352951#comment-6537684 but it's still worth looking at, in case you have any suggestions to improve the abstract class I've introduced. Ping me at any time in IRC to discuss :-)
#22
Since #1784774: Add Assetic component to core has been fixed , we can now focus on #1762204: Introduce new asset declaration architecture to facilitate removal of global drupal_add_js/css() [Moved to sandbox]
#23
#24
Sandbox at http://drupal.org/sandbox/mcjim/1813618
#26
Did you make any further progress on this? Is there any way we can help?
#27
i think this, and a number of other issues, are a sorta on hold in favor of the more exhaustive approach we're attempting in #1871596: Create a PartialResponse class to encapsulate html-level data [Moving to sandbox].
#28
I have written a module to add the base Assetic functionality in D7. Maybe I can help getting the same functionality in core D8 :)