hallcp

When it times out after scanning 1 or 2 plugins and you have 70 or 80 I don’t think it’s practical to increase the timeout. You’d have to make it astronomically large.

Was there a command-line version of this thing?

And where would I find this download? My WP installation says 1.65 is current, your links all point to something called the odude network.

This problem also affected me, on sites which had had no changes to plugins or themes in years. Without a better error message I don’t see how I can hunt this down. What changed in 4.8 to start spitting out this error?
I’ve looked at my theme files, none of which have changed, and see no issues with any @import statements.

This problem has also cropped up for me. I have WP 4.7.3. A link like this:

https://sww.sas.com/blogs/wp/worklife/category/college

shows only a single page of 10 posts, but there are many, many more. The user says this has only recently been the case. It used to have paging buttons like the front page of the blog does.

Same error here. Apparently the developers don’t care whether this thing works or not.

FIXED! This turned out to be a missing directory. We have PHP configured to store session data in a particular directory… and somebody deleted it.

So sorry to have falsely accused poor Custom_Sidebars. It was completely innocent. It just happened to be the first snippet of code to try and begin a session.

You’d think I’d have gotten errors from all over the place, but maybe WordPress turns off the warnings at some point.

In any case, Custom_Sidebars was not the culprit here.

Thanks so much for posting Predrag. It makes me feel very good about CS support.

Charles.

Thanks Predrag. I am attaching a screen shot of the page and the View Source.

The readme.txt of our plugin says:

Tested up to: 4.7
Stable tag: 2.1.1.9

We have used this successfully in the past, so it’s possible there are existing sidebars in the database. Could that be an issue? Where would I look to delete them?

Sorry I can’t be more help. I’m stumped.

Hah! Well here’s a fix. I don’t know why but the code is trying to write out a file called “nirvanas.txt” to the blog’s upload directory. But it then proceeds to load it into the database. Why not just upload the originally uploaded file from it’s temporary location and skip writing out that intermediate file?

So just comment out all the lines in admin-functions.php nirvana_import_file() function having to do with credentials: 138-140, 142, 144-146, 149, 150, 153-157. And change line 162 from this:

$data = $wp_filesystem->get_contents($filename);

to this:

$data = file_get_contents($_FILES[‘import’][‘tmp_name’]);

and it works!

OK, I’ve spent two more days on this and I know a lot more now. As written, this functionality will never work with a site using the FTP transport method. Here’s what happens for a direct (non-FTP) scenario:

1. You browse to your local file, and click import.
2. The browser uploads the file and checks the user’s file-write-credentials with request_filesystem_credentials(…).
3. If the user has credentials, the settings are updated.

But with FTP, the request_filesystem_credentials() triggers an intermediate page that requests FTP credentials. Then you have to check credentials a second time, the function returns true, and you save the file.

So the two problems with this script are:

A) It only checks credentials once.
B) The intermediate page requesting FTP credentials flushes out the newly uploaded settings file from it’s temporary home.

It would take a total rewrite of this code’s logic to make this work properly.

I’ve done a little more checking and I believe the issue is that it is a multi-site installation on a Unix server, and the FTP access is the problem. Does anyone know what files Nirvana is trying to access? If I knew, I could check permissions.

Thanks.

Charles.

Whoops, my bad. I tried this on another 4.3.1 site and it worked as anticipated. I must have a plugin conflict. If I find out anything interesting I will report back.

Charles.

Your example is quite beyond me!

Are you suggesting that we disable the current port 443 and instead have whatever is happening at port 80 also listen to 443? Simply disabling Port 443 would just cause a failure when WP attempts an SSL connection, wouldn’t it?

This is a corporate intranet, and we really have no need for SSL within the company, so this solution seems to make sense to me, but is that what you are proposing?

Thanks!

Charles.

I doubt we can alter our server config because a lot of other stuff runs on it, but this sounds like a really clever solution.

Can you tell me what change I would need to make in WordPress to make it use 80 instead of 443? Or do I just add ‘sslverify’=>false to the call in wp-admin/network/upgrade.php?

Although I still say this is a bug in WordPress. And I’m curious as to why it is surfacing now, since our SSL has been broken for ages. This particular upgrade.php file does not appear to have changed in recent updates.

Thanks!

Is there some way to escalate this issue? It’s still present in 4.2.4.

Charles.

Thanks James, but I am not clear on this. The upgrade to the WP source code was successful, it was the step where you “upgrade the network” that failed. This is where it marches through each site on the multi-site install. I always presumed it was making updates to the database entries during this step.

Those instructions for manual upgrading, besides looking really painful, don’t seem to address the step that’s giving me problems.

Charles.