here my proposal:
—-
wpsocialite.php – line 124
—-
$return .= ‘<ul id=”wpsocialite” class=”‘.$size.'” class=”social-buttons cf”>’;
—-
wpsocialite.css
—-
#wpsocialite.large { … }
#wpsocialite.large > li { … }
ecc….
You’re absolutely right. I think it would be best to keep the classnames more within the namespace:
.wpsocialite_large
.wpsocialite_small
I’ll get those changes put in and pushed up. I’ll reply to this thread when they go live on the WP Repo. If you have the plugin installed, it will ask to you upgrade.
Appreciate your notes and hope you like the plugin!
I wanted to post the exact same thing but you were quicker by a day:)
I totally agree with you guys. Hope to see the updated plugin soon:)
Best reagrds
Oh and BTW. I’ve noticed that on line 124 in wpsocialite.php “class” declaration is doubled.
Chris/miziomon,
After many headaches this weekend I’ve finally got the plugin re-synced to the development version.
You should now see proper CSS coming through in version 1.4.1.
Let me know if this works and if you need anything else.
So, after a few hours of playing with it these are my questions, suggestions and a bug notice:
Bug:
1. I don’t know why but scroll lazy loading didn’t work for me. I found that in wpsocialite.js you check whether “body” has “wpsocialise-scroll” class. In my case it didn’t no matter what I checked in admin panel.
Suggestions:
1. I don’t know why you ask people in admin to write classes associated with posts if by default there’s “social-buttons” class both in what you suggest and a class of <ul> with buttons. Instead I would simply write in wpsocialise.js this > var articles = $('.social-buttons'). This would save unnecessary script in head.
2. In your response to miziomon’s question in this thread you suggested using ‘wpsocialite_’ namespace before ‘large’ and ‘small’ classes, which you didn’t implement in the final update. These very general classes can be a big problem since they are often used in many themes and can conflict with other styles. Could you please change it so it sais ‘class=”wpsocialite_large”‘ or ‘…small’ by default?
BTW. Thank you for the ability to turn off all the scripts. Now I reduced their initial number to “0”:)))
Chris,
Agree on all points. Will have updates in the next release.
As always, appreciate your feedback.
Chris,
1. Unsure why you are having a scrolling bug. In the latest release I’ve double checked and the scrolling element is working fine. Can you link me to the page you are working on so I can test?
2. I agree with you that having the classes set by the user is unnecessary at this point. In the beginning it made sense, but not at this point. I’ve removed the option in the latest release and removed the javascript set in the header. This will come in 1.4.2.
3. The namespace is set to wrap in .wpsocialite .large (or small) so there shouldn’t be any conflicts. Are you still seeing an issue?
1. Unfortunately I can’t do that. I made quite a few modifications in your plugin to minimize the number of http requests and now most of the scripts are a part of my default ones. That’s why I can’t install a new version of wpsocialite because it will conflict with the rest.
2. That’s great news:)
3. I checked the code of the latest release. We don’t seem to understand each other. The problem is in the sheer existence of class “small/large” (line 136). It doesn’t matter if you style it in CSS with “.wpsocialite” before. It’ll still “borrow” styles from theme’s CSS if it has “small/large” classes.
Imagine you’ve got a theme. In your CSS you have a class “small” with e.g. padding, margin, color, underline and… blink:))) Now, the fact that you also use it in your plugin means that your “ul” with buttons will also take the values from the theme’s stylesheet (if they aren’t overwritten [“blink” surely isn’t]). Check these 2 files with the changes showing what I mean >>> https://dl.dropbox.com/u/16604210/wpsocialite.7z (line 136 in .php)
