Make WordPress Core

Opened 8 years ago

Closed 3 years ago

Last modified 3 years ago

#38723 closed defect (bug) (invalid)

Widget correct number is not displayed into the global $wp_registered_widgets array

Reported by: alexvorn2's profile alexvorn2 Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7
Component: Widgets Keywords:
Focuses: docs Cc:

Description

When displaying the array on the page (widget.php)...

<?php
echo '<pre>';
print_r( $wp_registered_widgets );
echo '</pre>';

I get the widget number value incorrect, it is the maximum number of widgets of the current widget type.

How to replicate my problem?

  1. Fresh install
  2. Drag 2, 3 or more widgets to a sidebar
  3. paste the this code in the functions.php file of the theme..
<?php
function show_registered_widgets() {
        global $wp_registered_widgets;
        
        echo '<pre>';
        print_r( $wp_registered_widgets );
        echo '</pre>';
        
} add_action( 'widgets_admin_page', 'show_registered_widgets' );
  1. Go to widgets.php page and you will see a big array with all widgets

Find the widgets you added to the siderbar, and if you look close in the that object of the widget array, you can find that the number is incorrect.

Take a look to this screenshot of what you will see...
http://alexvorn.com/wp-content/uploads/2016/11/why3.png

Change History (10)

#1 follow-up: @westonruter
8 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

This is expected. Multi-widget numbers start numbering at 2. This could have been done for back-compat reasons.

#2 in reply to: ↑ 1 @alexvorn2
8 years ago

Replying to westonruter:

This is expected. Multi-widget numbers start numbering at 2. This could have been done for back-compat reasons.

It is not the problem that the widget number starts at 2, the problem is that the number value is expected be 2 not 3... (in this array: http://alexvorn.com/wp-content/uploads/2016/11/why3.png)

If you take look into the image I added you can see that the callback widget array, we have the number value - incorrect and the widget id value too.

I can upload an image with a greater value... ex 6
http://alexvorn.com/wp-content/uploads/2016/11/oyo.png

I will reopen this because I think I was not understood about exact problem.

#3 @alexvorn2
8 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#4 follow-up: @westonruter
8 years ago

  • Keywords close reporter-feedback added

@alexvorn2 ok, in that case the issue is that all of the widgets of a given type re-use the underlying WP_Widget instance as their callback class. So if you have 10 pages widgets, you'll have widgets with numbers 2 through 11, and each will have a callback that references the same WP_Widget_Pages class. The id property of the class gets set by WP_Widget::_set() before the widget is in \WP_Widget::display_callback(). So the id will be correct when the widget is processed. It doesn't clean up after itself to empty out clear out the id by doing something like $this->_set( -1 ).

Is this behavior actually causing a problem for any functionality or is it just that the property doesn't have the value you expect? If the latter, then just call the _set( $number ) method before to ensure it has the proper number context.

#5 in reply to: ↑ 4 @alexvorn2
8 years ago

Replying to westonruter:

Is this behavior actually causing a problem for any functionality or is it just that the property doesn't have the value you expect? If the latter, then just call the _set( $number ) method before to ensure it has the proper number context.

The problem is that this can create confusion for everybody, as it did for me.
A lot of developers can face the same situation of not knowing why this happens.

#6 @netweb
8 years ago

  • Milestone set to Awaiting Review

Moving reopened tickets without a milestone back to Awaiting Review for review

#7 @desrosj
6 years ago

  • Keywords reporter-feedback removed

#8 @hellofromTonya
3 years ago

  • Focuses docs added; template removed
  • Keywords reporter-feedback added

Hello @alexvorn2,

It's been a lot of years since this ticket had movement. As @westonruter notes, it is by design and not a defect/bug.

That said, I'm wondering about your comment:

The problem is that this can create confusion for everybody, as it did for me.
A lot of developers can face the same situation of not knowing why this happens.

Are you thinking about additional information in the documentation? If yes, what kind of information could have potentially helped you avoid confusion?

For example, here's the docs page for the WP_Widget::_set() method.

Close the ticket?
I realize it's been a long long long time since the reporter opened this ticket. As there's no bug to fix and it's marked as a close candidate, I'd suggest keeping it open for no longer than 3 months to give folks time to consider if additional docs are needed. Then if after 3 months there's no additional feedback, then the ticket can be re-closed.

#9 @alexvorn2
3 years ago

  • Keywords close reporter-feedback removed
  • Resolution set to invalid
  • Status changed from reopened to closed

widgets are being replaced with blocks anyway so, yeah, let's close this.

#10 @desrosj
3 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.