| Project: | Accessible Content |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
Accessible content provides Quail with a list of the css files which would be included (from accessible_content_get_css_files). This list can be incorrect.
Themes can remove a css file which has been added by a module, by adding an entry for the css file in the theme's info file (and not having the css file in the theme).
This would normally remove OG's css (assuming sites/all/themes/foo/og.css doesn't exist).
stylesheets[all][] = og.cssAt the moment, if this theme feature is used, accessible content will include http://example.com/sites/all/themes/foo/og.css in the list of css files to pass to Quail. Quail then requests this file with curl (getting 404'd), which adds significant performance overhead.
The attached patch mimics the approach used in the core theme engine, which checks that the css file exists before adding it to the $vars['styles'].
| Attachment | Size |
|---|---|
| accessible_content.performance.patch | 1.09 KB |
Comments
#1
Meh. That was the old patch. Try this one instead :-)
#2
Applied the patch and tested and it all looks good. In the future, it would probably be better if QUAIL actually accepted strings of CSS content rather than having to go out on HTTP, as firewall rules would prevent this from working and it would be faster as well. In the meantime this is committed, and after a few more changes this will be rolled into a future release.
#3
What do you mean by "patch (to be ported)" if you say that it has been committed to the module's code?
Typically on drupal.org that status means the patch has been committed to one branch and is ready for porting to another one.