Alternative for updating wp_podpress_stats?

Well, the update corrects in the wp_podpress_stats table basically certain characters in old entries.

The SQL command is

UPDATE wp_podpress_stats SET media = REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(media, ' ', '%20'), '!', '%21'), '(', '%28'), ')', '%29'), ';', '%3B'), '@', '%40'), '&', '%26'), '=', '%3D'), '$', '%24'), ',', '%2C'), '[', '%5B'), ']', '%5D') WHERE id IN(SELECT b.id FROM (SELECT a.id FROM wp_podpress_stats as a LIMIT 0,10) as b);

You may adjust the LIMIT values. (But you can do this by change the increment in the update dialogue. The default value is 10 only to avoid problems with the execution time limit for scripts. But I noticed during the tests that you can choose higher increments and the increment level may rise also in a non-linear relation.)

If you are sure that you have no entries made with podPress 8.8.10 – 8.8.10.12 then you may skip that part of the update and remove the entry with the option_name _podPress_upgrade from the wp_options table.

Fantastic. I verified there were no entries from 8.8.10 to 8.8.10.12 and removed the _podPress_upgrade entry from wp_options. Problem solved.

Thank you for the quick response!!!

I had the same issue however when I removed the _podPress_upgrade entry from wp_options the entire podcast site crashed and was unable to connect to the database. I was force to to do a restore but I lost all my theme upgrades and customize settings. Now I’m still seeing the same message.

Notice: The podPress upgrade is not complete. Please, go to the General Settings page of podPress to finish this process manually.

Any other advice?

@voice903fm:

when I removed the _podPress_upgrade entry from wp_options the entire podcast site crashed

I’m sorry that such a thing happened. But it is highly unlikely that this happened because of erasing this particular row from the database. This database entry affects only podPress other plugins, themes or WP itself does not use nor rely on this entry. Only podPress checks whether this entry exists. If it exists then it shows the message that the upgrade is not complete and loads the necessary scripts on the general setting page of podPress. If this entry does not exists then podPress will simply go on.
Removing this entry will only affect this part of the upgrade nothing more. But editing the database directly has it’s risks and it seems possible that you have accidentally removed more than just this entry from the wp_options table. This database table contains all the important information which are necessary to run the blog and if one removes more than just that one podPress entry, a crash will probably happen.
That is why recommend to all which are not that experienced like chadclubb to take the time and do the update.

In general I recommend to make a db backup before upgrading a plugin or WP (read on https://codex.www.ads-software.com/WordPress_Backups#Database_Backup_Instructions).

My initial reaction was to roll back, which I did. That left me with some blog editing issues, so I removed Prodpress and reinstalled it. I didn’t realize this would remove all 316 of my podcasts. I have a backup of the database from a week ago. Can the attachments be restored?

As noted on my entry “Too many entries to upgrade”, I upgraded Podpress again which restored the 300+ attachments. Then I removed the value associated with the Podpress_Upgrade entry in wp-options and the upgrade nag went away. Since I really don’t care about stats, this solution is fine with me. Thanks for your help!

I annotate the related code and remove the information. I don’t know whether this will effect the plugin.

// if this option exists then show a certain message in the admin area only
//$upgrade_status = get_option(‘_podPress_upgrade’);
//if ( FALSE !== $upgrade_status ) {
//add_action(‘admin_notices’, ‘podpress_showadminmessages_onupgrade’);
//~ } else {
//~ remove_action(‘admin_notices’, ‘podpress_showadminmessages_onupgrade’);
//}

@northcamel: You may disable those lines of code without doing harm. But if the option _podPress_upgrade already exists it does make more sense to remove only the entry from the database.