WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 12 months ago

#38723 reopened defect (bug)

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

Reported by: alexvorn2 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.7
Component: Widgets Keywords: close reporter-feedback
Focuses: template 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 (6)

#1 follow-up: @westonruter
13 months 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
13 months 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
13 months ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#4 follow-up: @westonruter
13 months 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
13 months 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
12 months ago

  • Milestone set to Awaiting Review

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

Note: See TracTickets for help on using tickets.