Posted by firebus on September 19, 2011 at 9:21pm
2 followers
Jump to:
| Project: | AddThis |
| Version: | 6.x-3.0-beta2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Howdy!
There's a checkbox named "Use default style provided by AddThis" on the settings form.
There's no documentation for this field, but my assumption is that if you uncheck this box, addthis should not load widgetXX.css, however that doesn't seem to be the case.
I confirmed that the drupal module is setting use_use_css option to false in addthis_config, but widgetXX.css is still getting loaded.
Is this a bug? If not, can someone explain what the "Use default style" checkbox is supposed to do?
Thanks!
Comments
#1
looking at the order of operations, i suspect this is because addthis_widget.js is loaded before the addthis_config variable is set.
it would be nice if addthis checked addthis_config when addthis.init() is called, but after experimenting with the order, that doesn't seem to be the case.
if i manually add addthis_config.ui_use_css before the external script is called addthis respects it.
in my experience, when you need to set a javascript variable using Drupal.settings, and you need to have an external script respect that variable, you have to add the external script to the page using javascript as well.
using this technique would also allow addthis.module to avoid calling drupal_set_html_head() (so we're really replacing one kludge with another :)
another solution would be to get rid of the async parameter, but instead add a defer parameter to the script tag - this way the external file is only loaded after the page is finished loading and Drupal.settings have been evaluated. IIRC older browsers don't support defer though.
#2
Hi,
Could you elaborate in detail what you did? I'm stuck with same issue and need to have my own css for addthis block.
Thanks.
#3
I gave up on suppressing the addthis css, and wrote css rules to override theirs.
I thing the easiest way to work around this bug would be to write the required javascript directly to the page (instead of using Drupal.settings). You could do this in your theme (by adding a script tag to page.tpl.php, or by creating a small custom javascript file to include).