Opened 10 years ago
Closed 10 years ago
#32541 closed defect (bug) (fixed)
Call to a member function do_items on a non-object ($wp_styles)
Reported by: | Frozzare | Owned by: | |
---|---|---|---|
Milestone: | 4.3 | Priority: | normal |
Severity: | normal | Version: | 4.3 |
Component: | Script Loader | Keywords: | |
Focuses: | Cc: |
Description
On line 64 in wp-includes/functions.wp-styles.php it try to call do_items on a non-object.
Attachments (2)
Change History (12)
#1
@
10 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
@
10 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
#3
@
10 years ago
- Keywords reporter-feedback removed
- Milestone changed from Awaiting Review to 4.3
See ticket:32444:86.
#6
@
10 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().
Thankyou.
#7
@
10 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.
#8
@
10 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
@
10 years ago
The root cause of this issue is the change made on this ticket:
https://core.trac.wordpress.org/ticket/32444#comment:43
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:
https://core.trac.wordpress.org/changeset/32597
Thanks.
Fixed call to do_items on a non-object