WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 10 years ago

#5191 closed enhancement (duplicate)

Style tag cloud by color

Reported by: webrocker Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords:
Focuses: Cc:

Description

After looking into #5131, #5171, and #5172 I'd like to see the (additional) ability to style the tag cloud between two colors - like it is possible with the UTW Plugin (http://www.neato.co.nz/wp-content/plugins/UltimateTagWarrior/ultimate-tag-warrior-help-themes.html#tagcloud).
With the above tickets we have the ability to apply individual classes per tag and ignore the font-size thing, which in theory should be enough for a color-weighted tag-cloud. But with every additional tag one would have to re-define the css-stylesheet - not very Wordpressy.

It would be nice to have additional parameters in the wp_tag_cloud() function for the start- and end-color, and have the function "render" the in-between colors... like wp_tag_cloud('...&startC=#990022&endC=#1166CC');

I guess since the font-size is already calculated in relation to the amount and order of the tag shown, it shouldn't be too hard to tweak the function to do the same for hex-color-codes?

The difficulty is to calculate the right in-between color-codes... I have tried to understand what is done in the appr. function (ultimate-tag-warrior-core.php) in UTW, but frankly, failed to understand it (and the comment at the beginning isn't encouraging either):

/* This is pretty filthy.  Doing math in hex is much too weird.  It's more likely to work,  this way! */
	function GetColorForWeight($weight) {
		global $maxtagcolour, $mintagcolour;
		if ($weight) {
			$weight = $weight/100;

			$minr = hexdec(substr($mintagcolour, 1, 2));
			$ming = hexdec(substr($mintagcolour, 3, 2));
			$minb = hexdec(substr($mintagcolour, 5, 2));

			$maxr = hexdec(substr($maxtagcolour, 1, 2));
			$maxg = hexdec(substr($maxtagcolour, 3, 2));
			$maxb = hexdec(substr($maxtagcolour, 5, 2));

			$r = dechex(intval((($maxr - $minr) * $weight) + $minr));
			$g = dechex(intval((($maxg - $ming) * $weight) + $ming));
			$b = dechex(intval((($maxb - $minb) * $weight) + $minb));

			if (strlen($r) == 1) $r = "0" . $r;
			if (strlen($g) == 1) $g = "0" . $g;
			if (strlen($b) == 1) $b = "0" . $b;

			return "#$r$g$b";
		}
	}


What do you think?

Change History (9)

#1 @jaredbangs
12 years ago

If I understand #5172 correctly (specifically the "tag-cloud-size-X" class part), coloring the list can be handled by theme authors, which is probably where this type of style issue belongs.

Westi noted that he was going to implement such classes for styling, so I think this ticket could probably be closed, since this type of thing seems like it should be plugin/theme territory rather than core.

#2 follow-up: @webrocker
12 years ago

thanks for the answer.

the problem with assigning classes per tag (where "x" is the tag ID) is, that you need to expand the (theme)stylesheet with every new ID whenever a new tag is added.
plus, if the class is "bound" to the tag, it will not be possible to style a weighted cloud, say by alphabet or amount of posts associated to the tag.

#3 @webrocker
12 years ago

in addition: yes, the coloring part belongs in the hands of the theme(authors), but in my opinion it should be provided by the wp_tag_cloud() function as possible parameters - analog to how a theme author would style the blogroll, for example.

#4 in reply to: ↑ 2 @webrocker
12 years ago

Replying to webrocker:

the problem with assigning classes per tag (where "x" is the tag ID) is

oops, in #5172 the "X" is the order-number of the tag in the list, not the tag-ID.
This still will require additional styles if the list is expanded, though. :-)

#5 follow-up: @Otto42
12 years ago

No, look closer at the patch in #5172. It adds an additional class of "tag-cloud-size-X", where X is the number of the size. This would allow you to style based on weight and not just on tag ID.

So, basically, #5172 does exactly what you want. You can style the weights as colors if you choose.

#6 in reply to: ↑ 5 @webrocker
12 years ago

Replying to Otto42:

So, basically, #5172 does exactly what you want. You can style the weights as colors if you choose.

hm... not quite, since the "X" in "tag-cloud-size-x" is an absolute number which depends on the amount of the tags shown, you need to know the numbers calculated aforehand for your stylesheet - so you have to expand your stylesheet everytime you choose to change the number of tags shown in your tag-cloud.

$tag_size = round($smallest + ( ( $count - $min_count ) * $font_step ),0); 

The "$count" is dependend on the call to the function in the template, where one will set how many tags will be shown - at least this is how I understand it :-)
I still find it more comfortable (and more "wordpress-like") if the color-range could be set via the call to the function in the theme.

But - if the color is calculated via the function, it would require an inline style, which is kind of ugly, too.
:-)

#7 @atppp
12 years ago

I tend to agree with Otto42. Whenever you change parameters in tag cloud (i.e. $smallest, $largest), you are basically changing the theme, then it's theme's responsibility to change style sheet. I think a nice tag class in the core is all we need, but the tag cloud presentation is up to the themes..

e.g., when theme asks for $smallest=8, $largest=32, the theme should provide styles for all integer numbers b/w 8 and 32, assuming #5172 rounds size up to integer number.

#8 @AaronCampbell
12 years ago

I agree with Otto42 and atppp. Set the defaults, and if a theme specifies non-default settings, it should be able to deal with them. I tend to think though that we should do away with sizes, and do 1-x. 1 should be the most weighted, and x the least. Default to 1-10 or even 1-20. If we do this, the default tag cloud widget should have these options available to be configured.

#9 @Denis-de-Bernardy
10 years ago

  • Milestone 2.9 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

see #5172. there are just too many of these.

Note: See TracTickets for help on using tickets.