I'm a full time Drupal developer and would like to contribute back modules I develop for client sites.
I have developed a Drupal 7 module called Node CSS based on the work I did for www.nowmusic.com to allow custom backgrounds to be managed through the CMS:
http://www.nowmusic.com/bundles/now-thats-what-i-call-no-1s
http://www.nowmusic.com/bundles/now-thats-what-i-call-80s

I have created a sandbox project at: http://drupal.org/sandbox/xalen/1079842

It essentially allows values from fields in a node to be used in a CSS template.

There are other CSS modules but these are simply for including manually written CSS from a single field: http://drupal.org/project/css, http://drupal.org/project/css_injector. My module uses a CSS template instead and injects data from fields into the template therefore allowing end users to easily change node background colours and images etc.

Another module I plan to create is a file icon manager. There is http://drupal.org/project/icon which I would take over since it doesn't appear to be actively maintained.

CommentFileSizeAuthor
#2 node_css-n1116706.patch14.9 KBdamienmckenna

Comments

damienmckenna’s picture

Nice module idea, I'll take a look at this tomorrow.

damienmckenna’s picture

Status: Active » Needs work
StatusFileSize
new14.9 KB

Reviewing the code there are minor code formatting tweaks that could be made, e.g.:

  • Unnecessary $Id$ comments, e.g. nodecss.install.
  • Unnecessary empty lines after long comments, e.g. in nodecss_uninstall()
  • Unnecessary empty lines before closing parentheses, e.g. in nodecss_uninstall()
  • Missing blank line at the end of the file, e.g. nodecss.install.
  • Some lines not intended enough, e.g. a few lines in nodecss_schema().
  • Some todo comments for functionality that appears to already be implemented, e.g. nodecss_uninstall().
  • Some translated strings have unnecessary whitespace.
  • Not all comments are wrapped correctly at 80 characters.
  • Comment sentences should have a period at the end.
  • Words should be spelled with American English, e.g. 'color' vs 'colour'.
  • A few other minor things.
  • The CSS output from css.tpl.php doesn't follow the coding standards.

A few other suggestions:

  • You might want to add some validation code to the settings page to ensure that the requested files are present, to avoid needless 404 errors.
  • It would be useful to add a README.txt file to provide some (limited) instructions on what the module can do and how to use it.

Take a look at the attached patch, it cleans up most of the coding standards issues.

oliverpolden’s picture

Thanks Damien. I went through the patch manually rather than applying it so I could see where I went wrong. I had used the coder module, did you use the grammar parser for some of that?
Fixed code formatting etc. and committed.
Validation and README.txt todo

oliverpolden’s picture

Status: Needs work » Needs review

I've added a README.txt file, fixed a couple of bugs and added validation to check the template files exist.

damienmckenna’s picture

Status: Needs review » Needs work

Good stuff, getting very close. A few items:

  • The README.txt file doesn't need the CVS-style comment at the top, instead should list the project name and should give an explanation of what the module is for along with the configuration instructions.
  • Remove the unnecessary blank line at the top of nodecss_theme().
  • Rather than using several variables to control the template path in nodecss_theme(), you should just define it relative to your module's path and then let users use normal normal template engine's functionality to change it as needed.
  • A small thing - you could change nodecss_node_save_css() to have one main if() check around nodecss_node_enabled($node) and nest the rest of the logic inside that.
  • In nodecss_node_css() you might want to do a check to see if $css_vars is empty before going through the effort of theming it, i.e. if it is empty just return an empty string or NULL.
  • Given you're writing the module for D7, you might consider giving it a more general name and then for a future "v2" write it to work with all entities rather than just nodes. Making this change now would be easier than later, so you don't potentially end up with a project "nodecss" when what you really want is e.g. "entitycss".
  • Another small thing - you don't need to list files in nodecss.info if they don't have classes that you wish to lazy-load, though it doesn't really hurt anything.
  • From a performance perspective,
damienmckenna’s picture

Component: new project application » module

I think this is very good with the improvements, takes a different approach than the current CSS module and only has small issues remaining (besides a v2-worthy expansion of functionality). I'd like to see a response from @xalan regarding plans for the module's future vs naming convention (see my comment #5 above) but otherwise this is good & worth approving.

oliverpolden’s picture

Hi Damien,

Yes I had considered calling it Entity CSS. The main reason I called it Node CSS was because it runs off hook_node_insert and hook_node_update, plus I'm not familiar with entities (yet). Naming it Entity CSS could be misleading as it wouldn't work with other types of entities in its current state.

I guess it's best to name it Entity CSS now and I can always put notes in the module text explaining it doesn't work with entities yet, would probably get patches from others for that! It would be great to have this working with users and taxonomies etc. It would be really powerful, haha I'm really quite excited!

I'll change the module name and get it updated shortly.

P.s. It's xalen ;-)

damienmckenna’s picture

Any further progress on this?

klausi’s picture

Status: Needs work » Closed (won't fix)

No activity in several months. Reopen and set the status to "needs review" if you are still pursuing this application.