commando

I’m also finding it no longer works with PHP 5.6. Yes it’s an older version, but some plugins and themes still don’t support newer versions of PHP.

I guess I’ll roll back to an earlier version of Ninja Forms.

I solved this by moving the plugin to another folder using the Linux command line, effectively disabling the plugin

sudo mv /var/www/wp-content/plugins/bwp-recaptcha /tmp

The steps to replicate are probably very long. The website uses the “My Listing” theme, with plugins including Contact Form 7, Elementor, My Listings Addon, WooCommerce, WP Job Manager, and a couple of CloudFlare plugins. I don’t think there’s anything you can reasonably do to diagnose this one.

If anyone has a similar problem try turning W3 total cache off temporarily.

Yes, you’re right, there were ?? It’s definitely CSP related, but I’m not sure what the solution is.

Before with the CSP I had I got these errors

WordPress 4.9 CSP Problems

I change the CSP as below, and I don’t get the errors in the console any more, but it doesn’t work either.

The problem seems to be loading / executing “data:” type elements in the page. Anyone know how to fix this?

For now I’ll just turn CSP off, since it’s non-essential. When I have time I’ll learn more about CSP but if anyone has a quick fix that preserves some of the security I’d appreciate it.

add_header Content-Security-Policy “default-src ‘self’ data: blob: filesystem: https://www.google-analytics.com ajax.googleapis.com https://www.google.com google.com gstatic.com https://www.gstatic.com connect.facebook.net facebook.com secure.gravatar.com;”;

Would you mind posting a link to your github project?

Found it – https://github.com/tillkruss/Nginx-FastCGI-Cache

Yeah I did. I was telling you in case you wanted to fix it ??

You can’t – the entire website including admin area white screens.

I’m getting it today. As soon as I switch themes to Photocrati it white screens and the only way recover is to run the SQL below against the database.

I have a WordPress multisite install which otherwise works fine. I can do some limited experimentation, but it’s a production site so I can’t do too much that could break it.

Note that I use HHVM, the Facebook written PHP VM, rather than standard PHP. I run on Amazon Linux, obviously on one of their VPS systems.

[Tue Jan 26 17:31:30 2016] [hphp] [2979:7f1b01229700:1979:000001] [] \nFatal error: Call to undefined function request_filesystem_credentials() in /var/www/wordpress/wp-content/plugins/nginx-cache/nginx-cache.php on line 250

UPDATE wp_options SET option_value = ‘twentysixteen’ WHERE option_name = ‘template’;
UPDATE wp_options SET option_value = ‘twentysixteen’ WHERE option_name = ‘stylesheet’;
UPDATE wp_options SET option_value = ‘Twenty Sixteen’ WHERE option_name = ‘current_theme’;

The best thing to do would be to contact the makers of ProPhoto to get a copy of the theme. ProPhoto is a pretty odd theme, doesn’t seem to follow WordPress standards, so you’d have to look into it. https://www.prophoto.com/

Yeah I know it’d be easier, and that’s by backup plan, but I’d like to go for technical elegance. If I have to do something manual each time WPMU is updated that would count out elegance.

I’ve spent a few weeks (on and off, but a lot on) moving four blogs to a new AWS server with nginx, WPMU, and I’ve written a huge comprehensive guide which I’ll release when it’s ready. So I don’t mind spending a bit of time to work this out for the guide.

Yes, that’s right. Site4 is https://www.headphonereviews.org, it runs a custom written PHP on the domain root and the blog in the /blog subdirectory.

Yes I guess I could move it to a subdomain, but that has SEO implications – it’s treated as a separate website by Google.

A symlink is an interesting idea, but wonder if WPMU would respond… maybe. Is it possible to put the WordPress index.php or sunrise.php into a different directory and have it somehow work, even if it requires changes?

I also wonder if I can do anything fancy with Nginx or similar.

The reason I’ve gone to WPMU is to reduce the maintenance hassles – patching, upgrades, backups, etc. This is my simplest blog install though, so if one has to be separate this is the easiest one.

I just had another shot. Unsure why but now it works fine. If I notice anything else I’ll post ??

Yes, it did, thanks!

One thing I find quite regularly is 500 errors communicating with dropbox, far more often than I’d expect. Could you implement a silent retry mechanism before putting errors in log and emailing people with those errors?

Sorry, I posted the wrong log earlier. I manage about ten blogs and I’m actively working on three of them today, I got mixed up.

Here’s the information about the right blog below. Now I have the 3.2.0-RC1 version should it automatically go over 2GB files? I just can’t find any option to let it go over 2GB that I saw mentioned somewhere.

[INFO] BackWPup 3.2.0-rc1; A project of Inpsyde GmbH
[INFO] WordPress 4.3.1 on (removed)
[INFO] BackWPup job: Weekly WordPress Database Backup; DBDUMP+WPEXP
[INFO] Runs with user:
[INFO] Cron: 0 3 * * 0; Next: Sun, 20 Sep 2015 @ 03:00
[INFO] BackWPup job started manually
[INFO] PHP ver.: 5.5.29 (64bit); litespeed; Linux
[INFO] curl ver.: 7.38.0; OpenSSL/1.0.1e

Thanks Daniel.

[INFO] BackWPup version 3.1.4; A project of Inpsyde GmbH
[INFO] WordPress version 4.3
[INFO] BackWPup job: WordPress Media Backups 2015 and later; FILE
[INFO] BackWPup cron: 0 3 1 * *; Next: Thu, 1 Oct 2015 @ 03:00
[INFO] BackWPup job started manually
[INFO] PHP ver.: 5.5.29 (64bit); litespeed; Linux

So you can’t have files above 2GB with a 64bit PHP version? That seems backwards, 64 bit should have >2GB support natively.

It’s generally impossible to change the PHP version on shared hosting. Interested to hear more about this limitation and how it could be worked around.