Upgrade script stuck

So far I can only acknowledge problems in combination with WP 2.7.x. In this combination (WP 2.7.x + podPress 8.8.10.17) the upgrade dialog on the general settings page of podPress does not appear.
I’m working on an upgrade which will solve this problem. But I doubt that it will solve problems which occur in combination with newer WP versions.
The problem for me is that I have trouble to reproduce the problem which you reported with newer WP version. Because I can only try to guess what the problem might be, it is hard to find and fix the problem.
But every detail you can give me is helpful and would make it easier for me to guess.

What other details can I give you? I’m willing to help.

Also, it would be great if you could tell me what does the dialog box do, so maybe we can do it manually and get rid of it.

Rafael, thank you for the screenshot! In your case the problem is probably connected to a time limit. On most servers a script is only allowed to run for a certain time. In your case the limit seems to be 2 seconds or at least that is what the upgrade script could retrieve.
2 seconds is very low limit. If it this value is really that low then it is possible that the database action needs more time than it is allowed to run. The result is that the script and upgrade process get stuck.
I did not expect that the time limit could be that low and thought that the lowest limit would be at least 10 seconds.

I will revise the script and will try to find a better solution to handle low time limits.

But it would be great if you could find out whether the max_execution_time limit is really 2 seconds.
I recommend using one of the monitoring plugins for that purpose. My favourite is WP System Health. This plugin will tell you also which server software is running on the server.

Also, it would be great if you could tell me what does the dialog box do, so maybe we can do it manually and get rid of it.

The dialog box is a precaution in regard to the execution time limit for php scripts. If you open the general settings page it starts to update a low amount of rows in the database and measures the time while doing that.
This time is the basis for the maximum increment. When this works correctly the database requests are quick enough to avoid the time limit.

In most cases the upgrade of all database entries at once would take longer than the limit allows. One solution is to upgrade only a limited amount of entries at once.
The dialogue lets you choose an increment (amount of rows per upgrade action) and clicking on the button in the right bottom corner of the dialogue window would start a new upgrade action until all entries are corrected. Almost every click on that button starts a database command like I have posted in the other thread.

At the moment the only two ways to make this dialogue go away are
– to erase the _podPress_upgrade entry in the wp_options table
– or to clear the podPress statistics tables.

But I’m sure that the next podPress upgrade will contain a solution for this situation. Until than you may use the current podPress version the dialogue has no effect on the rest of the plugin.

I installed that plugin, what information do you need from it?

I think I’ll wait for the plugin’s next version to solve this, if you say everything else works just fine. Thanks.

Same issue here… Some information for you.

In this case the max. execution time for the blog software is: 2 seconds.

The time needed to correct 10 rows in the data base: 0.00461411476135 seconds

Select an increment: <= 9 (The increment should be smaller than this value)

Number of rows in the data base table wp_podpress_statcounts: 803

Number of rows which need be processed: 634
the increment starts at 10 and every time you run it it counts down by 1. Then if you let it try and run with any of the values it just hangs. Have tried in firefox, chrome, and IE and running wordpress 3.5.1

It would be interesting for me to know the max_execution_time value which the other plugin retrieves.

I cloudn’t find that value from the information the plugin retrieves. Are you sure it shows that?

So no idea how to fix it, without dropping my stats?
If so, I will switch to Podlove Podcast Publisher (https://podlove.org/).

I’m working on a solution and there will be an upgrade. But I will need 1-2 weeks for it. Meanwhile podPress will work and continue to collect statistics despite the incomplete upgrade.

@raphael: Go to the WP System Health page in your blog. Open the PHP panel and display the Core information. One of these value should be max_exectuion_time.

Okay, I’ll be patient.

Here you go:

max_execution_time 0 30

@jbc3k: It would be interesting and helpful for me to know what the max_execution_time values are on the server of your blog. Could you try to find out, how high (or low) these values are? and whether they are different from each other like in Rafaels case?

mine is:
max_execution_time 0 7200