Little enhance proposition

You got it wrong!

This is inline and not in a CSS file, because this is a option in plugin design settings.
This is content/style dynamic.

Before there was no option for this and nobody ever configured in the theme CSS file and which caused more work in support forums and emails in my inbox.

So there this option for anyone can change the color.

Oh OK, i’ve just read the PHP code, and rechecked the plugin panel, you are right.
So maybe it could be interesting to have a checkbox option to enable personal colors or to consider 333333 as a default color and so to not show it in the generated code ?

What do you think ? I know it’s a bigger change than I thought firstly ??

Feel free to contribute to the plugin code https://github.com/claudiosmweb/social-count-plus

Honestly I see no need to generate more conditional code just to remove some inlines styles.

Thanks Claudio for the proposition,

I’m not a git-aware person, but I’ve tested this code in my dev environment and seems to work : juste replace line 956 and 957 but those :

if ( isset( $design['text_color'] ) ) {
	$html .= sprintf( '<span class="count">%s</span>', apply_filters( 'social_count_plus_number_format', $count ) );
	$html .= sprintf( '<span class="label">%s</span>', $color, $title );
	}
else {
	$html .= sprintf( '<span class="count" style="color: %s !important;">%s</span>', $color, apply_filters( 'social_count_plus_number_format', $count ) );
	$html .= sprintf( '<span class="label" style="color: %s !important;">%s</span>', $color, $title );
	}

Thanks you for your great reactivity !

I’ll not implement it.
More conditional it is not necessary at what cost?
Besides that when you install the plugin already saved the text_color.
And then it will not work what you did.

I test before with isset() to ensure compatibility with older versions that did not have this option.

As I said before had no style, was the defining in the theme, but it was a problem with people sending me emails.

I still do not understand your problem with inline styles.

Hello Claudio,

yes, you’re right, I’ve pasted my first try of code modification instead of the final version, then it would be :

if ( $color == '#333333' ) {
	$html .= sprintf( '<span class="count">%s</span>', apply_filters( 'social_count_plus_number_format', $count ) );
	$html .= sprintf( '<span class="label">%s</span>', $color, $title );
	}
else {
	$html .= sprintf( '<span class="count" style="color: %s !important;">%s</span>', $color, apply_filters( 'social_count_plus_number_format', $count ) );
	$html .= sprintf( '<span class="label" style="color: %s !important;">%s</span>', $color, $title );
	}

The goal is to have a neat code when possible (it’s to say when standard, when user doesn’t change the default color). Surely it will work with inside styles, but I think it’s always better when styles are in css classes than repeated inline.

I suppose that most of users don’t have more than 6 (I’ve personally 3) counters, so i suppose the “if” would not be something that eat processor time.

What do you think ? As I said initially, it’s not a big deal, just a little enhancement proposition ??

You’re still doing it wrong xD
The best would be:

$style = ( $color != '#333333' ) ? ' style="color: %s !important;"' : '';

$html .= sprintf( '<span class="count"%s>%s</span>', $style, apply_filters( 'social_count_plus_number_format', $count ) );
$html .= sprintf( '<span class="label"%s>%s</span>', $style, $title );

But still did not understand what you mean by “clean code”.
Never seen anything in my entire life saying that it was forbidden to have inline CSS xD

But I will not implement it xD
Because if the theme of the user is forcing the text color for anything … The color #333 will not work and the widget can be white, green or any color just not the #333.
In other words, if I implement it the way you want I will receive emails with the word “BUG” in the subject, because that really creates a bug.

I do not want to receive emails with the “BUG” word in the subject!

Ok Claudio,

I can understand it could be a pain for you in the support if you do that. As a developer I can imagine the bug requests you could receive, so OK, I understand your argument and validate it. ??

Thanks for the time taken to respond me and long life to your plugin !