WordPress on Debian 8

what http server software are you using? (for example Apache, vs. Nginx vs. ________?)

What method was used to install the web server software? like doing an “apt-get install” or rather manually downloading and installing it?

apt-get install apache2

@matteo4536

The problems are caused by installing WordPress using “apt-get”. When WordPress is installed manually in the Apache web root – /var/www/ – you won’t have those issues.

Thanks for your reply. I usually prefer to install through apt-get to mantain the system coherent: isn’t it possibile to make the “apt-get” installation work simply acting on configuration?

Another question, but maybe this is not possibile also in the manual install: is it possibile for a super admin to give install plugins and themes priviledge to sites admins, in a multisite configuration? They are frustrated to ask every time… ??

Matteo

Installing WordPress using apt results in symlinks and non-standard configuration files that almost always prevent updating WordPress through the dashboard, and the WordPress versions found in Debian repos are rarely up to date. Serving your web applications from the web root solves those issues.

I got this reply from a Debian developer:

“Are you sure that you have put the required
Alias /wp-content /var/lib/wordpress/wp-content in your apache
configuration?

If yes, then please report those bugs to the plugin authors… they should fix them to support their usage through a symlink.”

PS: I already had the “Alias”.

Debian developers develop for Debian. The proper WordPress package doesn’t care what OS it’s on, as long as it’s in a properly configured server environment that meets the minimum requirements for running WordPress.

It really isn’t a WordPress issue. It’s a .deb configuration issue. The .deb package is customized for automatic installation in a Debian OS (not to be confused with a properly configured web server environment). That results in symlinks, non-standard configuration files, and versions of WordPress that are usually behind the latest and most secure version. But I’m just repeating myself..

You can do as you like, but my opinion is that your results with WordPress on your own local server will be much, much, more gratifying if you were to concentrate on serving WordPress from your web root.

Some info that might help you either way..

“how to” wordpress on debian

You might also search out discussions using “Ubuntu” as a keyword. Lots of good relative information there as well.

Good luck to you!

Using the vanilla tarball seems easy (at least at first), but in my experience/opinion the Debian packages are preferred for production environments, particularly where security and stability are paramount.

A couple of tricks with Debian (or the DotDeb repos).
* Make sure your FTP autoupdate user has permissions set properly using extended access lists. This way you avoid granting access to the webserver or other users to write in your sensitive wp-content directory. A lot of HOWTOS just chmod the entire path as writable by the www-data user. (I base my own setup off of https://shiftedbits.org/2012/01/29/enable-wordpress-automatic-updates-on-a-debian-server/)
* Do the same for your developers in terms of ACLs via SFTP/SSH.
* The aliased /var/lib/wordpress/wp-content provides additional security and is easily maintained by using “dpkg-reconfigure wordpress” which will symlink themes and plugins installed as necessary.

So, you can have a single web root /site where all the core code and user content sits completely accessible to the webserver and rely entirely on wordpress/plugin developers to put security over functionality
OR
You can run a packaged version that separates permissions related to resource modification and separates readable and writable resources to help indemnify against the never ending discover – expose – fix lifecycle of vulnerabilities across the platform. No to mention it actual runs against OS built libraries so no worrying about versions of any supporting PHP components.