Overriding CSS files in themes
Hello all. Many modules have their own mymodule.css or mymodule.js Most of these are added via: theme_add_style(drupal_get_path('module', 'mymodule')).'/mymodule.css'); This is often called in hook_menu() so as to get in as early as possible. Themes almost always need to override those css files. The way it is done is to go to the mymodule directory and edit mymodule.css. The problem here is when one upgrades, they have to be very careful not to overwrite the changes. What is worse, if one is upgrading from cvs directly, then there could be conflicts resulting in invalid data in the file. So, in order to make this easier for all, it is best if this is written as: theme('add_style', drupal_get_path('module', 'mymodule')).'/mymodule.css'); This way, the theme can say: function mytheme_add_style($path) { $file = basename($path); theme_add_style(base_path() . path_to_theme() . '/' . $file); } This way, the css file for each module has a copy in the theme directory that can be customized, and and the rest of the stuff does not get touched. Some modules do this already, most do not. Here is the status in 4.7 today: $ grep "theme.*(.*add_style" */* | awk -F: '{print $1}' | sort -u | wc -l 19 $ grep "theme_add_style" */* | awk -F: '{print $1}' | sort -u | wc -l 77 So, module owners should be encouraged to use: theme('add_style', ...) instead of theme_add_style( ...) Is it enough that I post here, or is there some other mechanism (short of opening 77 issues for 77 modules ...)
Actually while what you say about calling theme('add_style', drupal_get_path('module', 'mymodule').'/mymodule.css'); instead of theme_add_style(drupal_get_path('module', 'mymodule')).'/mymodule.css'); makes sense, it has the un-intended side effect of initializing the theme subsystem and making it hard/impossible to override the theme being used. This is in part due to the css/js being included in the menu hook which is also often used as a place to overrride themes. I would argue the answer is not to use a theme function (i.e. theme_add_style) since the direct call means it can not be override any how. It seems that a more general solution should be provided that takes the files to add (mymodule.css) and a prefereed path ( drupal_get_path('module', 'mymodule')) which is used if the file (mymodule.css) does not exist in the "current" themes directory. Steve Ringwood
2006/10/31, Khalid B <kb@2bits.com>:
Hello all.
Many modules have their own mymodule.css or mymodule.js
Most of these are added via:
theme_add_style(drupal_get_path('module', 'mymodule')).'/mymodule.css');
This is often called in hook_menu() so as to get in as early as possible.
Themes almost always need to override those css files. The way it is done is to go to the mymodule directory and edit mymodule.css.
The problem here is when one upgrades, they have to be very careful not to overwrite the changes. What is worse, if one is upgrading from cvs directly, then there could be conflicts resulting in invalid data in the file.
I think this is not an issue. If you want to override module's css rules, just do it in your theme's style.css. This is added lastly, so you are able to override its css rules using the same css selector or one with a high priority. You can also use the !important flag if you are having problems with cascading order.
So, in order to make this easier for all, it is best if this is written as: theme('add_style', drupal_get_path('module', 'mymodule')).'/mymodule.css');
This way, the theme can say:
function mytheme_add_style($path) { $file = basename($path); theme_add_style(base_path() . path_to_theme() . '/' . $file); }
This way, the css file for each module has a copy in the theme directory that can be customized, and and the rest of the stuff does not get touched.
Some modules do this already, most do not.
Here is the status in 4.7 today:
$ grep "theme.*(.*add_style" */* | awk -F: '{print $1}' | sort -u | wc -l 19
$ grep "theme_add_style" */* | awk -F: '{print $1}' | sort -u | wc -l 77
So, module owners should be encouraged to use:
theme('add_style', ...)
instead of
theme_add_style( ...)
Is it enough that I post here, or is there some other mechanism (short of opening 77 issues for 77 modules ...)
The theme_add_style() function have been replaced with drupal_add_css() in Drupal 5. Henrique
theme_add_style(drupal_get_path('module', 'mymodule')).'/ mymodule.css');
This is often called in hook_menu() so as to get in as early as possible.
Themes almost always need to override those css files. The way it is done is to go to the mymodule directory and edit mymodule.css.
The problem here is when one upgrades, they have to be very careful not to overwrite the changes. What is worse, if one is upgrading from cvs directly, then there could be conflicts resulting in invalid data in the file.
As far as I know, theme_add_style() is not and never has been a themable function. In 4.7, it is only once invoked in its themable form, which is obviously as a mistake. And, ironically that's inside theme_maintenance_page(), which is unthemable by definition. The proper function to use in 4.7 is theme('stylesheet_import'). In spite of this, I don't see why you'd need to edit module .css files. Due to the CSS cascade, you can just provide more specific CSS rules in your theme to override them. Depending on the order the theme's stylesheet is added in, you either need to use the same specificity, or one level more, for example prefixing the CSS selector with "html". http://www.w3.org/TR/CSS1#the-cascade In 5.0, this problem has been solved, as the theme_add_style()/theme ('stylesheet_import') functions have been replaced by drupal_add_css (), and themes get a nice structured array of all stylesheets back in $css, which they can hack up as much as they want. You can then do drupal_get_css($css) to render this structured array into the right set of HTML headers. Steven Wittens
Steven Wittens wrote:
As far as I know, theme_add_style() is not and never has been a themable function. In 4.7, it is only once invoked in its themable form, which is obviously as a mistake. And, ironically that's inside theme_maintenance_page(), which is unthemable by definition. The proper function to use in 4.7 is theme('stylesheet_import').
Well, the problem was that 'theme_' prefixes were used in non-themeable function names. This should not have been the practice at the first place, but it is now a known problem, and is getting fixed (in all cases??) in Drupal 5.0. Gabor
Thank for all who took the time to reply. What I ended up doing is roll all the css in the style.css of the theme, but I had to zero out the .css files in two modules (event and nice_menus if that matters). If I left them then some stuff would not show up, and I did not have time to troubleshoot why.
participants (5)
-
Gabor Hojtsy -
Henrique Recidive -
Khalid B -
Steve Ringwood -
Steven Wittens