I use the WordPress to Dropbox backup plugin on many of my WordPress installs and, up until I changed the setup to use PHP7, things were working great.

Thanks to the post from smowton over on the wordpress.org support channel, it is now working again.

The backup plugin was throwing errors in the logs about curl and an unexpected “overwrite” parameter. E.g.
Warning: curl_setopt_array(): Disabling safe uploads is no longer supported in /srv/users/mjburton/apps/mjburton/public/wp-content/plugins/wordpress-backup-to-dropbox/Dropbox/Dropbox/OAuth/Consumer/Curl.php on line 92

The fix is as follows:

All paths are relative to $YOUR_SITE_DIRECTORY/wp-content/plugins/wordpress-backup-to-dropbox.

In file Dropbox/Dropbox/OAuth/Consumer/Curl.php:
comment out the line:
$options[CURLOPT_SAFE_UPLOAD] = false;
(this option is no longer valid in PHP 7)

In file Dropbox/Dropbox/OAuth/Consumer/ConsumerAbstract.php: replace the test if (isset($value[0]) && $value[0] === '@') with if ($value instanceof CURLFile)

In file Dropbox/Dropbox/API.php: replace 'file' => '@' . str_replace('\\', '/', $file) . ';filename=' . $filename with 'file' => new CURLFile(str_replace('\\', '/', $file), "application/octet-stream", $filename)

This replaces the long-deprecated, now-disabled support for uploading files with “@/file/to/upload” with the replacement “CURLFile” class. Also a note to the author (and optional patch for the reader): check the return value for curl_setopt_array, as this was failing unnoticed, leading to confusing behaviour downstream.

I wanted to check that suPHP was working correctly and executing scripts under a specific user id.

This little PHP script did the trick.

php echo ‘whoim = ‘.exec(‘/usr/bin/whoami’);

That echo’d (outputted) the result of running a file /user/bin/whoami

I had a frustrating error for a while when using suPHP. It kept giving error 500 when enabling mod_suphp for .php files:

Directory /var/www is not owned by user

Of course, the directory was not owned by the user. The user belonged to a sub-directory only, the reason behind using suPHP.

It turned out to solve this the directory /var/www had to be owned by user root. That fixed the error.

I was configuring an apache2 setup to work with suPHP and ran into various Internal Server Error 500s due to folders and files having too generous permissions on them. suPHP doesn’t like that.

These two commands, when run from the directory where the web files reside, will recursively reset the permissions as required.

Find files and set to permissions 644

sudo find . -type f -exec chmod 644 {} \;

Find folders and set to permissions 755

sudo find . -type d -exec chmod 755 {} \;

The following was kindly provided by my friend, James.  You can find his setup at www.donut-tech.com

I wanted to echo (read: output) some system commands to webpages over time.  James has done this as part of a wider project and provided the useful code for TOP.  The TOP command displays the processes running and the CPU and Memory commitments, amongst other things.

This code is for a .php page and will execute and return the outputs of /usr/bin/top

 

<html>
<head><title>Pi</title></head>
<body><h1>Pi</h1><br>
<pre><?
system(“/usr/bin/top -b -n 1”);
?></pre>
</body>
</html>