CSS file is not aggregated
szy - August 25, 2008 - 19:33
| Project: | Sphinx search |
| Version: | 5.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Hello again,
Drupal's built CSS aggregation doesn't work with Sphinx search stylesheet.
Is it Sphinx search's feature, or Drupal's one? :]
Szy.

#1
ahem... it is a Sphinx search module "feature".
Well, in fact it has been inadvertently inherited from Drupal search module, which sets up its own CSS file for not being preprocessed by Drupal's CSS aggregator. I copy/pasted a few code snippets from search module to start coding the search form.
I believe the reason that search module does not allow CSS aggregation is because it is not a page with a lot of visits, and having to create a different CSS pack just for this little CSS file might not worth... ok, just guessing...
However, with Sphinx this might probably expose a different scenerio, since Sphinx is a lot faster and will become more powerful than Drupal search, aside that it will implement tagadelic features, etc. and all CSS stuff will be shared on the same little file, so... I think it's best to remove this restriction for now. Let's use CSS aggregation and time will tell...
Change will be applied in next CVS commit. Thanks for the report. Honestly, I didn't thought about it until now.
Edited: as per common.inc comments around drupal_add_css(), yes, it's set in search module because its pages are probably used rarely. So... I think I will add a module option, so one can choose what best fits particular environment.
#2
Well, I finally added tagadelic support, and now we need to load CSS for all pages. It is enabled to work with Drupal CSS aggregator, so I would say this feature request is done. Feel free to re-open if is there anything else that I may have missed.
#3
And now there will be a new need for having our CSS stuff rendered for all pages... I'll be commiting faceted search support pretty soon... it was easier to implemented than I initially thought. :-)
Closing issue...