Export/Features capability for CSS Injector

Agreed++

For now, one can still backup their rules in bulk by means of copying their /sites/default/files/css_injector/ directory.

Related (somehow) issues:

#335571: Abillity to link to or upload existing .css file instead of making a new
#335574: Custom paths and filenames for rules' css files
#886184: Store CSS info in database (and export it to files directory) (this one was filed by Randy that since today is a co-maintainer, so we might see some action here)

Exportables would rock this. Any arguments against me taking this on and doing a patch for Drupal 7? I have a DrupaCamp presentation on Exportables in a couple of weeks and I would combine the work here into a case-study.

I guess it's fine, since features are (supposed to be) added to 7.x first and then back-ported to previous versions.

I am deassigning myself from this. Working on my presentation, I know better what is required which includes some changes to the css_injector_rules table and potentially some changes to the UI workflow. It's just a bit deep for me to jump into a patch for this until I am more familiar with how exportables work.

sub

Subscribe

sub

sub

Subscribing

Subscribe.

I made http://drupal.org/project/css_injector_export a while ago. That doesn't use ctools exportables, but it does allow css injector rules to be dumped wholesale to a single file.

Added ctools exportables to the module. Some big rewrites, changing database structure etc, which breaks earlier versions. Upgrade path needed to be added if this should be put in 1.x - but I think it should be better in 2.x.

Fixed php-rule-stuff.

Yes, need to update the tests also... Getting back to that.

I have tested the module and patch and it seems that on simplytest.me the module breaks after it is applied. Once applied you can't find the module in the configuration menu at all.

I would love to see this patch applied to the module, has their been any further progress?

I need to do some additional work, hopefully this week, if not somebody else will do it before :-)

Thanks MiSc, how is the progress of this patch going? I would be more than willing to test any patch that you should release if needed.

It might also be worth mentioning in here that I ported js_injector over to ctools exportables a year ago (on the 7.x-2.x branch). Feel free to check the code out. Ctools exportables has native support for importing and exporting objects to code.

From reading the patches attached here, I can see my code is helping already (pro tip: do a search for "JavaScript" and fix up those comments ;).

Also don't forget to check out the new 8.x-1.x branch which was created just yesterday which switches over to CMI configuration entities so all rules are exported as YAML configuration files. Here is a link to the write up on the Drupal 8 port in case you want to read more about it.

I thought for a while that these two modules could be combined to some sort of super injector module, as essentially that do 99% the same task, just switch out a few labels here and there. Food for thought.

Feel free to ping me if you need any help with ctools exportables and or the Drupal 8 port. Heck I might be able to help you if you need it.

I thought for a while that these two modules could be combined to some sort of super injector module, ...

You do know about Custom CSS and JavaScript files (and #1141722: Port Custom CSS and JavaScript files module to drupal 7). Right?

PS: There's also Scriptastic (currently a sandbox) and this issue in its queue: #1335052: Take note of CSS Injector & JS injector

Well good to see that others have tried to combine these two modules.

I really think in order to get traction, a new Drupal 8 module needs to be released, with an upgrade path from both css_injector and js_injector to it. Perhaps the new module would be called code_injector or something. I would be happy to collaborate as the maintainer of js_injector if the css_injector maintainers would be keen as well. Drupal 8 upgrade instructions could be placed on both module description pages to inform them that the upgrade path is a new module.

Is this something that people want - a generalised script/css/something else injector? It would take only around half a day I think to absorb css_injector's functionality into the 8.x-1.x port I wrote for js_injector, and maybe a day for upgrade path testing.

Keen to hear thoughts on this proposal.

Is this something that people want - a generalised script/css/something else injector?

As far as CSS Injector goes, there's #669106-11: Merge custom css and js module with css injector where you can see that it has the blessing of the most current maintainer of the project.

Now, there's

- the 443 sites currently using Custom CSS and JavaScript files
- the 9 people following #669106: Merge custom css and js module with css injector
- the 3 people following #1335052: Take note of CSS Injector & JS injector
- a couple of people following #274930: What about JS Injector?
- me ;)

So you can safely assume that there's at least about 500 people interested and I'm sure that there are more that simply don't know it yet. Meaning that most people would not follow issues or be bothered much - they'd simply use what works for them. If these modules were to be merged and there was a notice pointing people to the new consolidated module, I'm sure that the user base would slowly move to the new module ;)

Some great discussion on this issue the last few days.

I think that an integrated module is the way to go. As klonos pointed out there is clearly a need for this kind of functionality for front-end developers.

At this stage though should MiSC be working on the patch for the existing module to get feature integration working or should the focus of development be on some new direction for CSS Injector and JS Injector?

I would suggest getting patch #15 in a state to where it can be committed, you will need to think about a few things (e.g. upgrade path as your install base is much larger). And then what I am suggesting is a new Drupal 8 combined module which simple takes the name 'injector' (this is free at the moment). Using Symfony's plugin architecture we could make the 'things to inject' plugable. Or we can simply do JS + CSS and do that easily (my 8.x-1.x branch already does JS).

In any case, is there any people willing to help me do the new Drupal 8 module? I can create a sandbox and we can get cracking over the next few months.

Thoughts? Comments?

I won't be able to help much with testing until I actually start using/learning D8 in a more regular basis :/

...well, perhaps some testing through simplytest.me sandboxes I guess.

Oh yes, the drupal 7 patch i posted is more or less copy paste from JS injector - and I agree, the two modules should be one, and I am interested in helping outwith the durpal 8 port.

My 5 cents
This feature looks like not needed if we convert css_injector rules to revisionable entities #2046855: Add feature to keep revisions for a rule

postponed due to #2160675: [META] Testing Coverage and refactoring of css_injector

I've restarted the 2.x work on CSS Injectors based on the improvement already made to JS Injector. Still working on the update hook to from 1.x -> 2.x, but CSS for each "rule" is now stored in the database, is exportable/importable, and plays well with Features.

@kreynen that is awesome news!

I'm happily using 2.x for featuring (with fix from #2415482: Error when creating rule after 2.x update: Field 'rule_themes' doesn't have a default value).
Found a showstopper in #2428949: Reverted rules don't show

You can try my sandbox module for import CSS Injector rules:

https://www.drupal.org/sandbox/stillfinder/2597592
https://github.com/stillfinder/css_injector_import

@stillfinder please update those project pages to indicate that the css_injector_import only works with 1.x. The 2.x branch moved the CSS to CTools plugins largely so they could be captured by Features.

Thank you! Description of the CSS Injector import has been updated.

I'll update the setting page with your module link, stillfinder, so people can check it out :)

So this is a 1.x issue, for 2.x this is solved as ctools plugins are exportable.