Make WordPress Core

Opened 9 years ago

Closed 8 months ago

Last modified 8 months ago

#33330 closed defect (bug) (fixed)

Undefined property: stdClass::$slug

Reported by: mattfiocca's profile mattfiocca Owned by:
Milestone: 6.1 Priority: normal
Severity: minor Version: 4.0
Component: Plugins Keywords: 2nd-opinion has-screenshots php80 needs-unit-tests
Focuses: Cc:

Description

When logged in and going to the Add Plugins page: /wp-admin/plugin-install.php, i get two identical php notices:

[10-Aug-2015 20:44:59 UTC] PHP Notice: Undefined property: stdClass::$slug in /wp-admin/includes/class-wp-plugin-install-list-table.php on line 38

I can reproduce with all plugins enabled and disabled, so I'm posting here as a potential issue with 4.2.4?

Attachments (2)

33330.diff (810 bytes) - added by kraftbj 9 years ago.
33330.2.diff (1.0 KB) - added by kraftbj 9 years ago.
Expose better debug data.

Download all attachments as: .zip

Change History (44)

#1 @MattyRob
9 years ago

I'm unable to reproduce this issue running 2 live sites on version 4.2.4 and also running a localhost test site with the WP_DEBUG constant defined as true.

I think this might be a database issues caused by a call to get_site_transient( 'update_plugins' ); returning something unexpected on your site. Can you check what that returns?

#2 @mattfiocca
9 years ago

Ah, when i do a var_dump() of $plugin_info->no_update of line 35, my value is this:

["no_update"]=>string(30) "Already on the latest version."

The code assumes no_update property to be an array of objects though. In my case, no_update renders as a string. I am seeing the same result when disabling all plugins as well.

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

#3 @MattyRob
9 years ago

That's correct, on my sites I'm getting an array of plugins and that string isn't present anywhere.

I can't find that string in the WordPress source code either.

#4 @mattfiocca
9 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Found it.

In my database, in wp_options table, _site_transient_update_plugins option, I found this in the serialized value:

{s:9:"no_update";s:30:"Already on the latest version.";}}}

Not sure how that got set, but this is local to me. Cleaning up the DB resolved it for me.

#5 @SergeyBiryukov
9 years ago

  • Milestone Awaiting Review deleted

#6 follow-up: @dd32
9 years ago

FYI; This is most likely caused by a broken 3rd-party plugin updater (Usually Paid-for plugins).

#7 @beascott
9 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

I am having this same issue. Can you tell me what cleaning up the DB means? I ran optimize and repair and it did not change. Is there a specific setting that needs to change. Not an expert but know enough to get into trouble.Any help is appreciated.

#8 @MattyRob
9 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

@beascott

You probably would be best finding that '_site_transient_update_plugins' value in your wp_options table and deleting it

#9 in reply to: ↑ 6 @kraftbj
9 years ago

  • Keywords has-patch added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version 4.2.4 deleted

Replying to dd32:

FYI; This is most likely caused by a broken 3rd-party plugin updater (Usually Paid-for plugins).

An example is the WooThemes Updater plugin. Example output from the site_transient update_plugins showing an expected and unexpected result:

["yourls-wordpress-to-twitter/plugin.php"]=>
    object(stdClass)#838 (6) {
      ["id"]=>
      string(4) "8029"
      ["slug"]=>
      string(27) "yourls-wordpress-to-twitter"
      ["plugin"]=>
      string(38) "yourls-wordpress-to-twitter/plugin.php"
      ["new_version"]=>
      string(5) "1.6.1"
      ["url"]=>
      string(58) "https://wordpress.org/plugins/yourls-wordpress-to-twitter/"
      ["package"]=>
      string(76) "https://downloads.wordpress.org/plugin/yourls-wordpress-to-twitter.1.6.1.zip"
    }
    ["woothemes-updater/woothemes-updater.php"]=>
    object(stdClass)#839 (1) {
      ["no_update"]=>
      string(30) "Already on the latest version."
    }

We can compensate for it by ensuring the $plugin->slug is set to save all of those bits and bytes recorded in logs everywhere. Patch incoming.

I reported it to the folks on the Woo side as well.

@kraftbj
9 years ago

#10 follow-up: @dd32
9 years ago

If a 3rd party plugin updater is inserting bad data, I'd rather that problem be surfaced than us patch over their bad manipulation of the array.

The notice isn't a site breaking side effect.

#11 in reply to: ↑ 10 @kraftbj
9 years ago

Fair point. What would you think about providing better debug data, like triggering a custom error with the plugin file name? (See next patch, which would provide https://cloudup.com/cD3wyIT2WyK :) )

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

@kraftbj
9 years ago

Expose better debug data.

#12 @DrewAPicture
8 years ago

#31995 was marked as a duplicate.

#13 @allegroclub
8 years ago

I just read debug log on my WordPress 4.3.1, and found the same error logged. In my environment, I know the theme use https://github.com/TGMPA/TGM-Plugin-Activation v2.5.2 for updating related plugins. Don't know if this plugin help contribute the error.

[06-Oct-2015 18:40:57 UTC] PHP Notice:  Undefined property: stdClass::$slug in /home/xxx/public_html/wp-admin/includes/class-wp-plugin-install-list-table.php on line 44

#14 @SergeyBiryukov
8 years ago

  • Milestone set to Awaiting Review

#15 @mDaedalus
8 years ago

I had the same issue, on an older site. I forgot, I had created a function to remove core updates and then commented out the add_filter() function. Once I removed the function from the functions.php file in a child theme, everything worked fine.

So, I would guess it could be a plugin, template or a child theme, that is causing your annoyance.

If possible do a grep search on the files and look for keywords like "update".

Here are some examples of core update blocking functions. http://www.wpoptimus.com/626/7-ways-disable-update-wordpress-notifications/


#16 follow-up: @hr-automation
8 years ago

  • Keywords needs-patch added; has-patch removed
  • Version set to 4.5.3

Error still exists:

 Notice: woothemes-updater/woothemes-updater.php did not return a plugin slug in /var/www/vhosts/hello.com/wp-admin/includes/class-wp-plugin-install-list-table.php on line 53

Any idea why the woothemes updater brings this error?

All Plugins and Theme on latest versions.

Thanks and best regards.

#17 in reply to: ↑ 16 ; follow-up: @SergeyBiryukov
8 years ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Awaiting Review to Future Release
  • Version 4.5.3 deleted

Replying to hr-automation:

Any idea why the woothemes updater brings this error?

Because it's not inserting correct data in _site_transient_update_plugins option, see comment:9.

There are two patches here, we just need to decide which one is the way to go. I agree with dd32 in comment:10, we should not hide a developer error, but perhaps should provide better debug data, so I'm leaning to 33330.2.diff.

#18 in reply to: ↑ 17 ; follow-up: @hr-automation
8 years ago

  • Keywords needs-patch added; has-patch removed
  • Version set to 4.5.3

Replying to SergeyBiryukov:

Replying to hr-automation:

Any idea why the woothemes updater brings this error?

Because it's not inserting correct data in _site_transient_update_plugins option, see comment:9.

There are two patches here, we just need to decide which one is the way to go. I agree with dd32 in comment:10, we should not hide a developer error, but perhaps should provide better debug data, so I'm leaning to 33330.2.diff.

Then it would be helpful to contact the woothemes support. Correct?

Last edited 8 years ago by hr-automation (previous) (diff)

#19 in reply to: ↑ 18 @SergeyBiryukov
8 years ago

  • Keywords has-patch added; needs-patch removed
  • Version changed from 4.5.3 to 4.0

Replying to hr-automation:

Then it would be helpful to contact the woothemes support. Correct?

Correct :)

The Version field indicates the earliest affected version, not the latest one. It appears to be 4.0 here, as the code in question was introduced in [29227].

#20 @jrf
8 years ago

I am wondering whether it wouldn't be better to replace the trigger_error() call in the patch with a _doing_it_wrong() call.
I realize that _doing_it_wrong() is more specifically intended for function calls, all the same, this issue very much feels like a _doing_it_wrong situation and notice.

#21 @cristiano.zanca
8 years ago

  • Keywords reporter-feedback added
  • Version 4.0 deleted

Hi all,

Notice: Undefined property: stdClass::$slug in /var/www/wordpress.local/www/wp-admin/includes/class-wp-plugin-install-list-table.php on line 52

this msg appears in my local installation WP development version (4.7-alpha-38298) debian PHP 5.6.24-0 MySQL 5.5.5 Nginx with all plugins disabled.

To solve the problem I've run this command

wp transient delete-all

and the message disappear

the code involved is

<?php
                $plugin_info = get_site_transient( 'update_plugins' );
                if ( isset( $plugin_info->no_update ) ) {
                        foreach ( $plugin_info->no_update as $plugin ) {
                                $slugs[] = $plugin->slug;
                        }
                }

#22 @SergeyBiryukov
8 years ago

  • Keywords reporter-feedback removed
  • Version set to 4.0

#23 follow-up: @mikegraf
7 years ago

Hello Everyone,

I'm glad I found this thread.

I've been searching for a while to determine what is going on with that error message.

I have done what @cristiano.zanca suggested by deleting all transients from options in the database but still the issue continues.

Is there anything else we can do/check to see what is going on?

One thing I did when moving my site from my local host, to the live server was export and import the database. My local environment was running on a newer version of MySQL and the web server where it was moved to is running an older version.

I believe the live server can only support UTF8 where my local server supported UTF8mb4. I think this is where the issues stems from but I could be wrong.

Can anyone help point me in the right direction?
Thanks!

#24 in reply to: ↑ 23 ; follow-up: @toktor
7 years ago

try disabling Woocommerce Helper plugin, then cleaning deleting transients. Does the error dissapear?

Once you enable WC Helper again, does it reappear?
Does it reappear when visiting WC Helper update page and Dashboard -> Updates?

For me, as WC Helper is just regenerating this each time is to disable wp_debug_display in wp-config as it does not seem to break anything.

EDIT: Disabling wp_debug_display should be taken as band-aid, support ticket to woocommerce.com is the correct way to go.

Replying to mikegraf:

Hello Everyone,

I'm glad I found this thread.

I've been searching for a while to determine what is going on with that error message.

I have done what @cristiano.zanca suggested by deleting all transients from options in the database but still the issue continues.

Is there anything else we can do/check to see what is going on?

One thing I did when moving my site from my local host, to the live server was export and import the database. My local environment was running on a newer version of MySQL and the web server where it was moved to is running an older version.

I believe the live server can only support UTF8 where my local server supported UTF8mb4. I think this is where the issues stems from but I could be wrong.

Can anyone help point me in the right direction?
Thanks!

Last edited 7 years ago by toktor (previous) (diff)

#25 in reply to: ↑ 24 @mikegraf
7 years ago

Hi Toktor,
Thanks for the reply.

So here is my diagnosis.

If I delete the woothemes helper plugin and delete all transients then the message disappears.

I tried the steps you suggested, but the message still appears.

I will submit a support ticket to woothemes and attach this thread as I believe the error message is now definitely coming from the woothemes helper plugin.

'> try disabling Woocommerce Helper plugin, then cleaning deleting transients. Does the error disappear?'
The message disappears only if I deactivate and delete the plugin. Then delete all the transients.

> Once you enable WC Helper again, does it reappear? Yes it reappears.
> Does it reappear when visiting WC Helper update page and Dashboard -> Updates?
It does not appear on the WC Helper update page and it does not appear on the Dashboard -> Updates page.

Also I know I can hide the wp_debug_display but as others have said, I rather have the developers of the plugin fix this issue instead of us just ignoring( hiding ) it.

Thanks for your response.
If anyone else knows of some kind of fix, please let us know!

Appreciate it!
Mike

Replying to toktor:

try disabling Woocommerce Helper plugin, then cleaning deleting transients. Does the error dissapear?

Once you enable WC Helper again, does it reappear?
Does it reappear when visiting WC Helper update page and Dashboard -> Updates?

For me, as WC Helper is just regenerating this each time is to disable wp_debug_display in wp-config as it does not seem to break anything.

Replying to mikegraf:

Hello Everyone,

I'm glad I found this thread.

I've been searching for a while to determine what is going on with that error message.

I have done what @cristiano.zanca suggested by deleting all transients from options in the database but still the issue continues.

Is there anything else we can do/check to see what is going on?

One thing I did when moving my site from my local host, to the live server was export and import the database. My local environment was running on a newer version of MySQL and the web server where it was moved to is running an older version.

I believe the live server can only support UTF8 where my local server supported UTF8mb4. I think this is where the issues stems from but I could be wrong.

Can anyone help point me in the right direction?
Thanks!

Last edited 7 years ago by mikegraf (previous) (diff)

#26 @DoNotIgnoreUs
7 years ago

Amazing, I just upgraded to 4.7.1 and I can assure everyone that this issue still exists... Is this a Woocommerce issue and if so, why isn't there a patch?

#27 @nicmare
7 years ago

have the same annoying bug with 4.7.1. and WC.

#28 @meekohi
7 years ago

Can confirm same issue here as well, with Wordpress and WooCommerce just upgraded from whatever was current in Nov 2016 to today's most recent versions.

#29 @clivewalker
7 years ago

I've tried the solutions listed above. But still getting the error. Before I get into editing the database directly. Please can you confirm exactly what I need to delete in the _site_transient_update_plugins values in wp_options table. Thank you.

#30 @lesliebigos
7 years ago

  • Keywords 2nd-opinion has-screenshots added; has-patch removed

I too have this issue. Tried using the Plugins Garbage Collector and it did not work. Tried deleting and installing the WooCommerce helper plugin and that did not work.

Here's what my Add Plugins screen looks like.

https://storage.googleapis.com/leslie_storage/stdClass.jpg

#31 @jleung1994
7 years ago

I also have the issue. I have WooCommerce helper plugin.
I noticed the error came up after I installed one of my custom plugins. But the error still exist after I removed my custom plugin.

#32 @meatloaf1024
7 years ago

Also having the issue and I as well have WooCommerce helper plugin installed.

#33 follow-up: @carasmo
7 years ago

Same error. WooCommerce Helper. Deactivated it and then it wouldn't go away. Then I upgraded WooCommerce to 3.0.7 and it's gone now.

#34 in reply to: ↑ 33 ; follow-up: @jleung1994
7 years ago

Replying to carasmo:

Same error. WooCommerce Helper. Deactivated it and then it wouldn't go away. Then I upgraded WooCommerce to 3.0.7 and it's gone now.

Didn't fix the issue for me. The message is there when WP_DEBUG is true.

#35 in reply to: ↑ 34 @carasmo
7 years ago

Replying to jleung1994:

Replying to carasmo:

Same error. WooCommerce Helper. Deactivated it and then it wouldn't go away. Then I upgraded WooCommerce to 3.0.7 and it's gone now.

Didn't fix the issue for me. The message is there when WP_DEBUG is true.

I have debug on too.

#37 @KoolPal
3 years ago

Any progress on this?

#38 @jrf
3 years ago

  • Keywords php8 needs-unit-tests added
  • Severity changed from normal to minor

Just making a note here that as of PHP 8.0, the notice Undefined property: stdClass::$slug will now be a warning due to the Reclassified engine warnings. This may mean that more people will be exposed to the issue.

As for the solution:
This should preferably be solved in whichever plugin is causing the issue.

As for the patch:
In my opinion, as I stated above, if a patch should be accepted at all, the trigger_error() should be changed to a _doing_it_wrong() and I think the break will probably need to change to a continue (needs testing/further review).

Adding unit tests for this particular issue, safeguarding the functioning of the code before and after, would increase the chances of a patch getting accepted.

#39 follow-up: @sc0ttkclark
15 months ago

This appears to have been solved in May 2021 as part of [50921].

The new code does an isset() check, but it does not throw a _doing_it_wrong notice.

I'm unsure if effort should be made to throw a _doing_it_wrong at this point, it would have already been fixed by any active plugin that had a problem.

I suggest marking this ticket as fixed via [50921] (leaving this to @jrf to confirm)

#40 @hellofromTonya
12 months ago

  • Keywords php80 added; php8 removed

#41 in reply to: ↑ 39 @hellofromTonya
8 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to sc0ttkclark:

This appears to have been solved in May 2021 as part of [50921].

The new code does an isset() check, but it does not throw a _doing_it_wrong notice.

I'm unsure if effort should be made to throw a _doing_it_wrong at this point, it would have already been fixed by any active plugin that had a problem.

I suggest marking this ticket as fixed via [50921] (leaving this to @jrf to confirm)

Good catch @sc0ttkclark! Yes, I agree this ticket can be closed as fixed via [50921].

However, the fix hides why the code is being skipped. As @jrf noted, the original notice/warning was informational to alert developers of a problem in their code.

As for the solution:
This should preferably be solved in whichever plugin is causing the issue.

As for the patch:
In my opinion, as I stated above, if a patch should be accepted at all, the trigger_error() should be changed to a _doing_it_wrong() and I think the break will probably need to change to a continue (needs testing/further review).

As a follow-up to [50921], I'll open a new ticket for adding a _doing_it_wrong() and tests. On my TODO list.

#42 @hellofromTonya
8 months ago

  • Milestone changed from Future Release to 6.1
Note: See TracTickets for help on using tickets.