Mittineague

Thanks for posting.

I’ve encountered a series of distracting life events for ages now.

I was about ready with the translations and Wham! life got in the way and kept at it.

Things are – knock wood – finally settling down and I will hopefully be releasing the next version soon.

And I will implement this change. Can’t let myself knowingly use deprecated code!

The Clean Options plugin does not touch other databases/tables, only the WordPress “options” table.

@aeroman

Those options are new with version 2.8 and did not exist in 2.7.1

So if you are now running 2.7.1 again they won’t be needed and should be safe to delete, although there might be problems if you didn’t roll back your database too.

I made a few changes with Clean Options 1.2.0 including making those new options non-selectable for deletion

– Internationalization
– updated the $known_ ok array (for WordPress 2.8)
– changed admin CSS hook
– plugin page Settings link
– option count in admin menu
– minor tweaks

so you may need to use CO ver. 1.1.9 if you want to use the plugin to remove them.

Sorry for the delayed response. For more timely responses, please post any problems in the support forum (as indicated in the plugin) where I will be instantly notified rather than need to check here.

@vesket, Just to be sure we’re on the same page here, you are referring to the plugin by Alex Rabe, version 1.3.3 correct?
The Clean Options plugin does not have a “fix automatically”, what exactly are you referring to?

It may be that there is an incompatability issue. I will look into it.

However, note that this plugin does not list only orphaned options, but rather options that appear to be orphaned. That is, the plugin will find true orphaned options, but may also find options that, as looked for by the regex used in the plugin, will appear to be orphaned when in fact they are not.

The Clean Options plugin is written so that as best as is possible, WordPress Core options can not be accidently deleted. However, it is impossible to take into account all possible options from all possible plugins and themes. Thus the need for blogmasters, that hopefully have knowledge of their blog’s particular plugin history, to investigate options in the list of possible orphans before removing them.

The plugin has several ways to help users in identifying true vs. false orphans. All measures should be taken before any option is removed. Only when when it is certain that an option is truly an orphan should it then be removed.

Hi gestroud,

I recommend you do NOT delete those options. I myself just upgraded and have the same ones showing. I’m guessing that those are new core options in version 2.8 that do not “fit” the regex I’m using in the plugin when it combs through the core files. I am in the process of making the plugin compatible with version 2.8 and will have the next release out ASAP.

The statistics are indeed a bit “bonky”. The “All Time” number of downloads for one of my plugins is going down?!

I guessing that “all time” should be more like “total for X number of weeks”. But it does make me wonder what algorithm is being used to find “total” as it surely isn’t purely additive.
$total = $old_value + $new_value;
$old_value = $total;

That code doesn’t look like the wp-includes/user.php file I have in version 2.7 but compare the syntax of
$this->query_from_where .= " INNER JOIN $wpdb->usermeta ON $wpdb->users.ID = $wpdb->usermeta.user_id WHERE $wpdb->usermeta.meta_key = '{$wpdb->prefix}capabilities' AND $wpdb->usermeta.meta_value LIKE '%$this->role%'";
to
$users = $wpdb->get_results( "SELECT user_id, user_login, display_name, user_email, meta_value FROM $wpdb->users, $wpdb->usermeta WHERE " . $wpdb->users . ".ID = " . $wpdb->usermeta . ".user_id AND meta_key = '" . $wpdb->prefix . "capabilities' ORDER BY {$wpdb->usermeta}.user_id" );

No need to write a plugin to do it, I already have –
Clean Options Plugin

I have heard of the “no name” problem before. The plugin uses the option_name value of the row instead of the id value. This is used to display next to the select box, and in subsequent handling. When I first wrote the plugin I assumed (I know, I know) that all options would have a name. I don’t know how they would work without one. When I first heard of this problem, I thought it must only be a rare event (silly me), so I put in an error message to alert the plugin user so that the row could be deleted in another way (i.e. phpMyAdmin) if they wanted to, but still allow other rows to be deleted.

When I get some time, Ill try to see if I can change the plugin to use the id values instead, and replace the error message with a warning, as it may be difficult for a user to determine what plugin/theme the row is associated with without a name belonging to it.

As for the file failing to open, the plugin uses a recursive directory search to find PHP files and search them for “get_option” and “get_setting”. the option_name values are put into an array, so that only orphaned options are listed. ATM, I don’t see why this failed for you, although the “..//” looks suspect. At worst, what could happen is that some options that the unopened file uses may get displayed as orphans when in fact they aren’t.

As long as you are careful to not delete anything that you’re uncertain of, you should be OK.

As for the 10130 rows, I just put up the Release Candidate with a “Delete ALL ‘rss’ Options”. Not the best solution to the “many rows” problem perhaps, but I figured it will do until I can come up with something better.

Meanwhile, I’ll try to figure out what happened and how to rectify the problem.

Thanks for posting.

My “Clean Options” plugin allows for the deletion of both orphaned options and excess “RSS” options. https://www.mittineague.com/dev/co.php
Enjoy and happy blogging ??

My “Clean Options” plugin allows for the deletion of both orphaned options and excess “RSS” options. https://www.mittineague.com/dev/co.php
Enjoy and happy blogging ??

My “Clean Options” plugin allows for the deletion of both orphaned options and excess “RSS” options. https://www.mittineague.com/dev/co.php
Enjoy and happy blogging ??

Failure to get filesize is often due to either the wrong path/filename or insufficient permission settings. The script has to be able to get to the file and needs to be able to read it, and most likely execute it as well.
You could temporarily give the file 777 (0777, rwxrwxrwx) to see if the plugin then works, and if so, then tighten up the permissions as much as possible without breaking it.

When you went directly to the plugin file, did you get any error messages? If not, make sure the plugin hasn’t turned off error messages with error_reporting(0);
If it has, temporarily comment out that line and try going to it again.

The plugin most likely has a php error in it. If you request the file directly. eg https://www.yourblog.com/ .. /wp-content/plugins/ [plugin file name].php you will see the errors if there are any. If not you will get something like “undefined function [WP core function]”