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.css
At 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'].
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | accessible_content.performance.patch | 1.09 KB | manarth |
Comments
Comment #1
manarth commentedMeh. That was the old patch. Try this one instead :-)
Comment #2
Anonymous (not verified) commentedApplied 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.
Comment #3
EvanDonovan commentedWhat 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.
Comment #4
vensiresI suspect it was to be set as "Reviewed & tested by the community" but the user misclicked. I set it as Needs Review for now and anyone is free to check the patch and either review it or create a MR based on it with any possible corrections.
Comment #5
vensires