cvquesty

I think I’m just going to go much more static and try and find a different platform I’m not constantly screwing with.

I’m always on the road and always trying to get documentation to my customers and I can’t be futzing with WordPress from some random hotel in some random city at 2 in the morning when I have to be on a customer site first thing in the morning.

It’s been a great run, but I need to do something else.

Yeah… you have to completely remove them from disk before reinstalling them. They live at:

$DOCUMENT_ROOT/wp_content/plugins/<plugin_name>

I followed the suggestions above (sort of). I had to completely reinstall one-by-one each and every plugin I use because the WordPress product would not read the directory. It’s the reason I turned off auto-updating, and it continues to be a problem.

After installing all my plugins again, I did a long listing of the subdirectories and produced a hash of the new plugins against the old plugins and it is identical. This is a WordPress problem.

My hunch is that during the upgrade procedure, the installer either does not read that directory or somehow skips the process to catalogue existing plugins and populate the plugins page (regardless of everyone’s attempts to help here, I still believe this to be the case). Once the upgrade process completes, it just never looks again.

As I said above, the directories, subdirectories, and all associated hidden files are owned by the web server user and are sporting a UMASK of 022 (0644 for files and 0755 for directories) and WordPress refuses to read the directory. However, installing a new plugin into the very same directory gets read while all pre-existing plugins get ignored.

There is no solution other than to do all your work again.

@samuel Wood

I’m going to refrain from getting grumpy and reiterate what I said in an earlier post that appears to have gone unread.

I have checked all permissions for the plugins directory and associated subdirectories and the permissions are UMASK 022 (for those of you unfamiliar with Linux permissions, that means 0755 on directories and 0644 on files) and owned by apache:apache (the proper web server user for my platform). When I install a plugin I don’t currently have installed via the plugins page, it installs properly and without incident into that directory with precisely the same permissions the existing, unable-to-be-read directories and files have. The interface can now see the new plugin, but not the old one.

If I try to reinstall an old plugin, the interface says it cannot, as the directory already exists and refuses to continue (so, it can see the directory when trying to install something new, but will not read it when trying to upgrade from a previous version). By removing the old plugin (running a mv <directoryname> to <directoryname-BAK> and reinstalling it, the plugin installs without issue. By taking a recursive file/permission list and diff-ing the <directoryname> and <directoryname-BAK>, I get NO DIFFERENCES between the two directory trees including filenames, permissions, and ownerships.

Extended File Attributes are not being used. ACLs are not being used. SELinux is not being used.

For whatever reason, WordPress refuses to recurse that subdirectory that was working minutes before the upgrade. I have restored the previous installation and installed even more plugins, run the upgrade, and all plugins disappear.

Sorry, guys… had a busy weekend thus far.

All directories are 0755 and all files are 0644 (UMASK 022).

When you install a new plugin via the plugin installer, it does precisely the same thing by making all directories 0755 and all files 0644.

Again, everything is in place, I do an upgrade and it loses a whole subsystem while maintaining all appropriate permissions. I’m at the point where I’m going to say this is a bug.

Good questions…all of them.

Pippin: No plugins installed at all. I look in the directory and there are 9 there. I roll back to my previous backup, and they all appear.

Samuel: I used the installer inside the admin control panel. The installation completed without error. As I told Pippin, the plugins page shows no plugins as being installed, although they are most certainly on disk in the wp-content/plugins directory.

I don’t use a hosting provider. I host my own servers. RHCSA/RHCE/Puppet Certified. “We don’t need no stinking providers”. 🙂