#5770 closed enhancement (invalid)
Add extra options for default tag-cloud widget
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | minor | Version: | 2.5 |
Component: | Widgets | Keywords: | has-patch needs-testing |
Focuses: | Cc: |
Description
The default tag cloud widget only allows changing the title that appears above the tag cloud in the sidebar.
This patch allows use of more configurable options in wp_tag_cloud(), ie smallest, largest, unit, number, format, orderby, order.
Attachments (7)
Change History (42)
#4
@
17 years ago
Its been several months. Is there any way that this patch could be merged with the trunk, or updated if necessary?
#5
@
17 years ago
As the beta of 2.6 is imminent, is there any chance of this getting included? Or at least, if it's not going in, of someone coming along and telling me my code sucks?
#6
follow-up:
↓ 7
@
17 years ago
Or at least, if it's not going in, of someone coming along and telling me my code sucks?
Cant say why its not gone in, However, On your code:
- $optionss should probably be merged with $args somehow
- Theres no need to translate defaults(
__()
and_e()
are translatable strings) - For defaults, Look into wp_parse_args() and the way $defaults are used elsewhere.
Finally: I was going to update your patch so it took into consideration those, But the patch needs to be refreshed(recreated) on a later branch, As it is, The patcher is getting confused as to which changes need to be made..
#7
in reply to:
↑ 6
@
17 years ago
- Theres no need to translate defaults(
__()
and_e()
are translatable strings)
I did that to be consistent with what was already there.
I'll have an updated patch available shortly based on revision 8180.
#8
@
17 years ago
- Theres no need to translate defaults( () and _e() are translatable strings)
I did that to be consistent with what was already there.
Ah, Well, I meant theres no need to translate non-string defaults, Ie. "tags" or "Default Header" would be translated, But anything that is constant between languages (such as size, measurements, etc) dont need to be.
#14
@
16 years ago
- Resolution set to fixed
- Status changed from new to closed
patch needs a refresh, too.
#15
@
16 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
woops, seems like keyboard shortcuts led me to close this...
#17
follow-up:
↓ 18
@
16 years ago
- Milestone 2.9 deleted
- Resolution set to invalid
- Status changed from reopened to closed
The current setup makes things simple: The user doesn't need to ask himself questions. If there is a need to override any or all of this, a plugin can easily be written. Or a filter can be added in the theme's functions.php file, on widget_tag_cloud_args.
#18
in reply to:
↑ 17
@
16 years ago
Replying to Denis-de-Bernardy:
a plugin can easily be written
Not true.
Seriously, I can't find anything in the codex that even hints at how I might add options to an existing widget.
Or a filter can be added in the theme's functions.php file, on widget_tag_cloud_args.
And, if a function is added to the theme it's not going to affect the widget page of the admin area is it? Wouldn't it mean that a user would have to edit the functions.php file any time that he wanted to change any of the options?
#19
@
16 years ago
like this:
add_filter(widget_tag_cloud_args, your_function)
then, there are two hooks that let you add to the form:
// filters the widget admin form before displaying, return false to stop displaying it $instance = apply_filters('widget_form_callback', $instance, $this); $return = null; if ( false !== $instance ) { $return = $this->form($instance); if ( 'noform' !== $return ) do_action_ref_array( 'in_widget_form', array(&$this) ); // add extra fields in the widget form } return $return;
and finally, there is a two hook that let you fetch the options that were sent:
$instance = apply_filters('widget_update_callback', $instance, $new_instance, $this); if ( false !== $instance ) $all_instances[$number] = $instance;
#20
@
16 years ago
Thanks for the prompt reply and hints.
It becomes clear to me that it is too complex for my comprehension so I shall give up.
#21
@
16 years ago
- Milestone set to 2.8
- Priority changed from normal to low
- Resolution invalid deleted
- Severity changed from normal to minor
- Status changed from closed to reopened
let's re-open it, then. an option or two could probably be useful in a future release (or now, if someone refreshes dion's patch)
#22
@
16 years ago
- Milestone changed from 2.8 to Future Release
Setting to future pending patch. Tag clouds are so passé now anyway. :-)
#23
@
16 years ago
- Keywords has-patch needs-testing added; needs-patch removed
Updated the patch, it works for me but probably needs further testing.
Tag clouds may be passé but they still get used, and it should be easier to use the options that are available for it, IMO.
#25
@
16 years ago
You could probably get by without minimum size and unit, but I think the others are useful.
#27
@
16 years ago
- Keywords needs-patch added; has-patch needs-testing removed
- Milestone changed from 2.9 to Future Release
broken patch
#29
@
16 years ago
- Milestone changed from Future Release to 2.9
Can I suggest only adding two options, taxonomy and number? The other options seem to give the impression we're really coding:
- Order by name should automatically imply ASC; order by number should automatically imply DESC.
- It seems like it would be better to change the default args for the tag cloud for the size if 22pt is too large
On a separate note, when number is set, does it take the first N tags, or those with the highest term count. If the former, we may want to change the behavior to the latter.
#30
@
16 years ago
Well, maybe order might be good too, but the ASC/DESC definitely doesn't belong in there imo.
#31
@
16 years ago
I'm having trouble working out just how number works; It appears to be the first N tags but irrelevant of whatever other options that may be set. IMO the other options should be applied first then the number last but this doesn't seem to be the case. It may be possible to fix by editing the wp-generate_tag_cloud function in category_template.php, moving
if ( $number > 0 ) $tags = array_slice($tags, 0, $number);
from lines 640/641 down below
$font_step = $font_spread / $spread;
on line 654, but I haven't tested yet.
With regard to the ordering, as the default is "ASC" (no matter what other options are set) you could change the Order dropdown to a checkbox for reverse order.
#32
@
16 years ago
No, moving that block of text doesn't work. It appears that setting Number selects the first N tags based on the order in which they were created, which IMO opinion is just plain wrong, but I haven't tracked down the block of code that performs this action to confirm.
#34
@
11 years ago
- Milestone Future Release deleted
- Resolution set to invalid
- Status changed from reopened to closed
In the five years since this ticket was opened, wp_tag_cloud()
has received a number of optional arguments, so this ticket is no longer valid.
See wp-includes/category-template.php for its arguments.
#35
@
11 years ago
There always were a number of optional arguments. My point was that when you use the widget, as opposed to a php template tag, you only had the chance to change the title and not use any of the other arguments.
Clearly as my original point still stands after six years I was the only person it mattered to.
Same file, proper spelling this time