Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#32541 closed defect (bug) (fixed)

Call to a member function do_items on a non-object ($wp_styles)

Reported by: frozzare's profile Frozzare Owned by:
Milestone: 4.3 Priority: normal
Severity: normal Version: 4.3
Component: Script Loader Keywords:
Focuses: Cc:


On line 64 in wp-includes/functions.wp-styles.php it try to call do_items on a non-object.

Attachments (2)

32541.patch (651 bytes) - added by Frozzare 9 years ago.
Fixed call to do_items on a non-object
32541.1.patch (432 bytes) - added by Frozzare 9 years ago.
Fixed so a new instance of WP_Styles will be created if missing

Download all attachments as: .zip

Change History (12)

9 years ago

Fixed call to do_items on a non-object

#1 @johnbillion
9 years ago

  • Component changed from General to Script Loader
  • Keywords reporter-feedback added

Thanks for the report Frozzare.

Can you give us steps to reproduce the issue please? If $wp_styles isn't an instance of WP_Styles in a particular situation then it could be masking another problem.

#2 @Frozzare
9 years ago

I just used the wp_editor function like this (inside a metabox):

wp_editor( 'value', 'textarea_id', [ 'textarea_name' => 'textarea_name', 'media_buttons' => true ] );

and then the errors appears

Last edited 9 years ago by Frozzare (previous) (diff)

#3 @ocean90
9 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 4.3

#4 @SergeyBiryukov
9 years ago

#32557 was marked as a duplicate.

#5 @SergeyBiryukov
9 years ago

#32573 was marked as a duplicate.

#6 @DrProtocols
9 years ago

With reference to the patch attached to this ticket - it does not properly fix the issue because it simply adds the condition to return the empty array if the global $wp_styles is not set to an instantiation of WP_Styles - this introduces yet another assumption that it is OK under _any_ circumstance for $wp_styles to not be set. This is _not_ OK because there is no requirement that the caller of wp_print_styles() should have already ensured that the global $wp_styles is validly set.

Whilst I am happy for the ticket I raised to be closed as a duplicate based on it reporting the same fatal error we should be clear that the ticket I raised reported what was in fact a change to code logic and behaviour with no justification and without taking into account the context of the statement that was changed. It should not be required for a caller of wp_print_styles() to have to determine whether or not the global $wp_styles is properly set or not - but with the change in wp_print_styles() that has been made it then becomes a requirement for every caller of wp_print_styles() to have to explicitly call wp_styles() before calling wp_print_styles(). I really do not believe that this was the intention of the change that was made to wp_print_styles() - if it is really necessary to have the final statement of wp_print_styles() be

        return $wp_styles->do_items( $handles );

then the call to wp_styles() to ensure that $wp_styles is set must be included in the earlier conditional statement to maintain the current functional usage of wp_print_styles(). Otherwise the change to that final statement should be reverted so that it calls wp_styles().


#7 @jeremyfelt
9 years ago

I'm seeing this error on a new install of trunk in wp-admin/install.php. The global $wp_scripts is not an instance of WP_Scripts, but a handle of user-profile is passed so the empty array doesn't return.

The attached patch would hide the error, but the expected scripts would not load. We could setup a new object if a handle is passed, similar to what wp_scripts() does.

9 years ago

Fixed so a new instance of WP_Styles will be created if missing

#8 @Frozzare
9 years ago

I attached a new patch that will create a new instance of WP_Styles if it's not a instance of WP_Styles.

#9 @DrProtocols
9 years ago

The root cause of this issue is the change made on this ticket:

which according to the description is a ticket for "improving static analysis". Whilst the change that was made may well have accomplished that it also broke the functionality of the plugin.

I believe there was no intention on the part of the author of that ticket/change to break the function but it happened because no attention was paid to the logic of the function and how the change impacted that.

It would seem that the change should be reversed in order to "unbreak" the function and then if it is necessary to modify the function in some way related to the change that was made then this should be done with due attention to the logic of the function so it is not broken.

I don't think it is the correct approach to try and "fix up" the current state of the function but better to restore the correct functionality and then review how to change the function without breaking it.

So this change should be reverted:


#10 @wonderboymusic
9 years ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.