An Unexpected Error Occurre – SOLVED

Solved: WordPress – “An unexpected error occurred.” when installing plugins, themes, and more.

Problem

Attempting to add things to WordPress like plugins or themes causes the following error:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

Solution

Check your SELinux audit logs for signs of denials. Your web server software (probably Apache / https) or a module being used by the software is most likely having outbound connection attempts denied.

You’ll probably want to read through Red Hat Enterprise Linux’s documentation on SELinux. However, in the absence of that enormous task, at least read through “Allowing Access: audit2allow” and understand the basics of allowing blocked actions in SELinux. Please do not disable SELinux. That’s a bad habit. SELinux is your friend and wants to protect you.

And you’re likely solution will involved installing the Python utilities to manage SELinux:

Then you’ll want to run audit2allow -w -a to determine what is being blocked in the recent past. It may take some sleuthing to correlate the blocked behavior that WordPress is attempting to perform from other blocked behavior on the Linux host. I recommend  tailing your audit log, and then immediately attempting to perform whatever action is being blocked in WordPress.

You should immediately see what’s being blocked, and then have a better idea of how to interpret audit2allow -w -a.

Lastly, create the exception based on what audit2allow -w -a has shown you by using audit2allow -a -M your_module_name and then semodule -i your_module_name.pp. In my case, my final solution was:

The Long Story

What better way to kick off a fresh blog than with a WordPress problem to work through. On a fresh install Of WordPress 4.9.8, I was unable to perform actions like adding a theme or plugin via the GUI. The error was:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

Welp, that’s unfortunate. I tailed Apache’s logs when I unsuccessfully tried adding a theme or plugin and didn’t see anything useful. Next I turned on WordPress’s debugging by adding the following to my wp-config.php file:

With that added, I got a slightly more verbose error to look at:

An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums.

(WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /path/to/my/webroot/wp-includes/update.php on line 529

Hmm… a secure connection couldn’t be established, you say? Sounds vaguely TLSy to me. Let’s take a look at line 529 in update.php to see if we can get a bit more context.

Well would you look at that. Looks like there’s something up with SSL/TLS after all. A quick check of phpinfo() told me that openssl was a loaded module, and enabled. Curl had SSL support. Everything looked okay, but one thing caught my eye:

openssl.cafile: no value
openssl.capath: no value

That seems odd to me. However after some research, I understood it and realized that in my case, it wasn’t an issue.

Another lead I followed up on was IPv4/IPv6 issues with the host that WordPress was installed on. After some quick tests, I realized that IPv6 was working on my host, and didn’t seem likely as a culprit.

And then it hit me. What are the two most common things that stop network applications from running on a Linux host? A firewall and SELinux. I quickly disabled the firewall and tested. Nope, still didn’t work. I quickly put SELinux into permissive mode and WordPress was able to install themes and plugins.

A quick perusal of /var/log/audit/audit.log showed telltale lines like this:

I made sure that policycoreutils-python-utils was installed on my RedHat-based server and then used audit2allow to allow php-fpm the needed access. First I observed the logged SELinux denials with audit2allow -w -a:

And next I used audit2allow to allow access. In my specific case, I inspected the rules that would be created by running:

I then created a SELinux module from that subset of audit failures with:

And finally I loaded the module:

After that, WordPress was able to perform operations that required it to make connections to remote hosts, such as installing plugins and themes from the GUI.