Closed (outdated)
Project:
AddThis
Version:
6.x-2.9
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jan 2010 at 17:07 UTC
Updated:
2 Mar 2016 at 07:27 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
bacon commentedYes. I just noticed the same behavior in IE 8.0.6001.
There are multiple instances (6-8) of the following line at the top of the web page source before the
<title>.<link rel="stylesheet" type="text/css" href="http://s7.addthis.com/static/r07/widget02.css" />The following code in addthis.module may be the culprit.
I know I shouldn't have, but I went ahead and commented out the above code, downloaded the widget02.css file, put it in the addthis folder and edited the addthis.module to do a drupal_add_css on the widget02.css.
Comment #2
Firetracker commentedHi,
I can confirm that this is happening too in IE6. Only happens on a page that loads in a GMAP. I've rolled back to 6.x-2.7 to fix the issue.
Cheers
Zap
Comment #3
rapsli commentedme too. This server side browser distinction doesn't make any sense either! Let's assume we are using a cache Boost or probably even the standard Drupal cache. The complete rendered HTML is being stored, well depending on what browser builds the cache we have the css loaded or not. Using conditional CSS would be a better solution for this!
Comment #4
vesapalmu commentedI agree that this should be changed to conditional CSS. Any patches that are tested to work with IE are welcome.
Comment #5
dgale commentedJust to let everyone know, this problem isn't specifically caused by AddThis. The real problem is that IE has a harcoded limit of 31 stylesheets. If you are close to this limit and using 6.x-2.8 of AddThis, those extra 6-8 references just might push you over the edge.
There is still obviously the problem of AddThis adding those extra duplicated references. But if your site has a lot of modules, you might hit the limit anyway.
To get around the problem, you can try turning on Optimize CSS files at /admin/settings/performance. If you are unlucky, this will cause your webserver to choke. Read here http://drupal.org/node/444228 for a detailed discussion of *that* problem (and thankfully a few patches to try.)
While researching this problem, I also came across this module http://drupal.org/project/unlimited_css which seems like it also might address the IE problem. I haven't tried it myself, but there you go.
Sort of back to the original question . . . is there a reason the stylesheet widget02.css for this module points to an external site as opposed to being part of the module itself?
Comment #6
vesapalmu commentedThe reason for pointing CSS to external site is two fold: 1) Originally addthis.com forced you to use their version of JS+CSS. 2) Addthis.com uses CDN which is faster than most Drupal servers and also way more likely to be cached on visitors browser. That said we will add an option to cache locally everything from Addthis.com in 3.0 version.
I will lower the priority of this issue since it really only has critical effects in a very specific setup. The bug itself needs to be fixed anyway.
Comment #7
ChrisRut commentedStill having issues with this in 6.x-2.9 even with Optimize CSS enabled (admin/settings/performance)
Also tried Unlimited CSS module, no go with Optimize CSS on or off
Tested in IE6,7,8
Solution in #1 solved it, Thanks bacon.
Comment #8
AlexisWilke commentedThere is another side effect to that add: I use AddThis on a secure connection and adding a link to an unsecure server generates warnings in IE. That's a problem since such errors tend to make people think that they should not proceed (and when that happens in your cart, you lose sales!)
So, may we at least change that link to an HTTPS version? It shouldn't cause any problem when not secure. We could also test whether we should use HTTP or HTTPS... (use $_SERVER['HTTPS'] for the condition).
Also, I think that the original problem may come from people who have more than one AddThis on a page. Then the function may get called more than once and thus the link added multiple times. The following includes a potential fix for that problem. Let us know if that fix your duplicates. I do not see any duplicates on my end, but I do have just one AddThis button.
The following would be checking whether we have a secure server or not:
Thank you.
Alexis
P.S. I changed the secure entry since it looks like you may need/want to use https://secure.addthis.com/ ... It worked with s7 too though.
Comment #9
AlexisWilke commentedI posted a patch for that HTTPS problem and other HTTPS problems in #736816: PHP notice Undefined index: HTTPS
Thank you.
Alexis Wilke
Comment #10
mstrelan commented#8 is the way to go. If you wanted to use conditional comments you could use drupal_set_html_head()... for example
Comment #11
mstrelan commentedComment #12
haopei commentedHello, I am not familiar with PHP. What do I do with this?
Comment #13
fabianderijkHi,
I've created a patch for this issue. It's against the 6.x.2.10 version of this module, but it solves it all (in my case).
Comment #14
xtfer commented#10 isn't a fix for review, its a suggestion for a fix.
#13 appears to be a fix for #654180: php notices with some overlap on this issue.
This issue still needs a fix.
Comment #15
AlexisWilke commentedYeah... Interestingly enough I posted a patch in #736816: PHP notice Undefined index: HTTPS in comment #5 and then Dave simply marked the post as a duplicate. Bye bye patch... 8-P
Thank you.
Alexis Wilke
Comment #16
eduserrat commentedThanks "AlexisWilke", it worked for us.
We put your code in "addthis.module":
The only thing we saw: "https://s7.addthis.com/static/r07/widget02.css" was old, and we replaced it for "http://s7.addthis.com/static/r07/widget66.css" (the new one).
Thanks !
Comment #17
gisleThis fix is for an outdated version of the module and for an outdated version of MSIE.
Feel free to repoen if you still think this need to be fixed for the 7.x-4.x branch and modern browsers.