Node CSS uses node fields to populate a CSS template file. CSS for all nodes can either be aggregated into a single file or generated per node. In both modes, the CSS files are added using drupal_add_css() so it complies with full Drupal aggregation and compression. If aggregation is turned on in Node CSS it is recommended to make the CSS node specific via a body node class because the same CSS file is loaded for multiple nodes. Many themes output a node specific class by default.
Full aggregation is recommended for performance (the same CSS file can be used across the entire site). Individual files is recommended for small sites and/or where you don't have access to a body node class.
body.page-node-<?php print $css_vars['nid']; ?>
Example applications
Set an image uploaded into a node as a background image e.g. a body wallpaper or a flourish
By default, fields according to the naming scheme field_css_ in enabled content types will automatically be passed to the template and hidden from the node display. Both the naming scheme and visibility can be changed.
The Computed Field module only updates its computed values on saves or on load (if no computed value is computed yet). This is not optimal when using computed values in lists etc., or if you should wish to change the logic in the computed field.
The solution
If you wish to avoid re-saving all the entities/nodes using the computing field, you can use this tool to re-compute all the values again.
The computed field tools module offers a way to re-compute the computed fields of existing entities/nodes. It does so through the Batch API.
When the batch is running it does not save the entire entity/node, but it only saves the computed field. This make it a fast way of updating the content.
Features
Fast processing of all computed fields.
Select specific computed_field to process.
Select content types to process for selected computed field.
It processes ALL entities/nodes. Also the ones with no value computed yet.
Since we don't do an entity_save() we don't clear the cache on every(!) node processing and no search index updates are triggered, so there is a huge performance advantage here on high traffic sites over the VBO way.
The taxonomy display module allows administrative configurable term display pages. This allows administrators to override the default presentation of taxonomy term pages per vocabulary through the taxonomy term page's manage display form.
Hook into taxonomy term pages
Taxonomy display exposes three plugin types for modules to overwrite portions of taxonomy term pages by providing their own plugins. These plugins are selectable on a per vocabulary basis, allowing the site administrator to decide which plugins they want to display for each vocabulary. To learn how to provide your own plugins see the developer resources page.
Taxonomy based Access Control List module provides taxonomy-based access to the nodes. tacl module provides only a common API but this package also contains a "frontend" - tacl_user that allows for managing per-user, taxonomy based permissions.
The target audience are site builders (tacl_user) and developers (tacl).
Features
Control access to view, update and delete a node based on taxonomy term
Handles per-role settings (only in tacl API module)
Handles per-user settings
Handles multiple terms and vocabularies for the same node
Taxonomy Access Control and TACL should be merged at some point into API and dependent module. TACL provides an API, while TAC is full module on its own. TACL provides more features than TAC, that is:
Likno JavaScript/CSS Menus is the ultimate module to create menus for your drupal site. It collaborates with the likno AllWebMenus software to produce the menu you want.