WordPress auto-install and upgrade

We have a further question.
Looking at “permissions’ we were led to consider “file Ownership” and this led us to the UID and GID in our DirectAdmin screen for the Contents Directory. See here.

Notice in this image that Plugins is one of the Folders with a GID of Apache. For information, the Contents Folder also has GID=Apache.
This may mean nothing when applied to music or graphics, but might it be critical in the context of “Permissions” related to “Plugins”.
Whenyou has ownership throughout, as a general rule, but we are not really so advanced as to know if it’s safe to switch ownership of GID from apache to whenyou in that particular case.

It has occured to us, this might be precisely the “permission” we don’t have when it comes to Auto-Update? Or is it “here be dragons” territory?

How say you?
Nebody?

Whenyou has ownership throughout, as a general rule, but we are not really so advanced as to know if it’s safe to switch ownership of GID from apache to whenyou in that particular case.

You might want to change those to whenyou

It has occured to us, this might be precisely the “permission” we don’t have when it comes to Auto-Update? Or is it “here be dragons” territory?

That is entirely possible. If that doesn’t help, try changing the permissions of /wp-content/plugins/ to 777

I clicked on ‘Reset Owner’ on that plugin row and it changed the GID apache to whenyou. It looks at the Dashboard that we now have permissions for Auto!
It’s difficult to be sure because the ver. installed is 2.9.2 with a ver. 3.0 version.php file in wp-includes.
For information, even setting ‘permissions’ to 777 had no impact in the past.
I’ll go read more in DirectAdmin about ‘Owners’ – it was 2 am when we decided to make that last swap.
One of us will return and report.

Incorrect ownerships are usually caused either when the blog files are installed by your hosting provider’s automatic installer (Fantastico, Simple Scripts, etc.) or they are incorrectly overwritten by your FTP client.

I’d be interested to hear what happens after you upgrade to 3.0.

Surprisingly – NO
With WP 3.0 fully installed (instead of just the wp-includes/version.php file) I still get the “you have insufficient permissions etc.”
As the plugins folder had handed off permission to the web server:
“Handlers tell Apache (the web server software) what to do with certain types of files.” –
I had hoped that by handing them back to the Owner (admin) I would finally crack this problem.
It didn’t work. While I was doing this I also switched the permissions from public, through contents, plugins AND each plugin folder to 777 and that also had no effect.
I have now restored the system to the condition before these latest changes. Back to my Host I guess.

I incline to your hint above – fault at installation by Host – but then I have reinstalled WP countless times in the last 2 1/2 years. It’s all new and only the matter of ‘subcutaneous’ permissions, such as those apache handlers, about which I know nothing, remain.
Recently I, more than once, Deleted the entire admin and includes folders, starting again from scratch. Contents is a different matter as only the plugins folder really is at issue and it seems, only in the contents folder were these GID=apache settings in place.

ggrrr
So. Currently running 2.9.2, very satisfactory, works in every respect AND alerts me to WHICH plugin has an update available and WP database Registry thinks it’s 3.0

I also remain convinced there are very many other silent sufferers out there with the identical problem. I know of at least one a week ago.

Empty Tables in phpMyAdmin

wpau_active_plugins_info
wpau_upgrade_log

wpau doesn’t work, the Tables are Empty and I get “the message”

Any help out there?

Those are not part of the core WordPress database, they’re installed by the deprecated third party WordPress Automatic Upgrade Plugin.

Could this entire problem be because you’re confusing the core automatic upgrade functionality with the long-depricated third party plugin that was only guaranteed to be compatible up to WP 2.7.1?

Good question!
I didn’t understand it but infer from your comment that I can safely delete those tables?
There are two others, associated with “yet-another- bla bla plugin that I tried but uninstalled. I have been thinking there is no reason for those to be ‘cached’ there either.

I am just clutching at straws because I get no solid suggestions as to what might be causing Auto-Update to not work – due to the ‘permissions’ lockstep.
I genuinely am pleased at that Comment macmanx! I had a blindspot there and should have instantly remembered there is no such thing now.
I’ll go do a backup of the Domain etc – and delete the waup and yarpp Tables. That will not impact on the “permissions’ thingy but it will take trash out of the Tables in phpMyAdmin

Still waiting for suggestions relating to “permissions”.

OK That happened. The Database is now down to 11 Tables.
Blog wrx, DirectAdmin wrx, WP Dashboard wrx.

Next: “you have insufficient permissions to update plugins”

or words to that effect

aka ggrrr

I know we tried this once before, but at this point it wouldn’t hurt to do it again.

Access your database via phpMyAdmin (most hosting providers offer this in their control panel), go to the wp_users table and find the row for your user_login . Note the ID of this row. Now, go to the wp_usermeta table and find the wp_capabilities row for your user_id . Set the value of this row to a:1:{s:13:"administrator";b:1;}

OK I checked that again. I may have found something.
The data I was checking as you suggested was fine:
user_ID meta_key meta_value
1 nickname admin
1 rich_editing true
1 wp_capabilities a:1:{s:13:”administrator”;b:1;}

The remaining Users have additional data: Names & Descriptions.
BUT
I noticed that User IDs 2, 3 & 4 have ww_user_level 10
This is not even mentioned in connection with UID 1 admin

As a rule, Guran, User 2 is the Webmanager (assistant ghost) and frankly, User 1 admin hardly ever gets used.

We have made a number of changes throughout the entire installation during the last week.

Please inform me if the line: wp_user_level 10 has significance.
Any one of us can login as admin but we usually log in under our User names because of traceability to our Posts. We are fairly sure admin has been used more than once as a user during Update operations (since Jan 2008) and the problem with Plugin Permissions has persisted (we think) but will be happy to perform experiments if you think that would be useful.

For instance, we can reinstall WP 3.0, which works quite well anyway aside from an inability to know WHICH plugin needs updating when the Dashboard shouts out that we have one.

It’s easy to revert one of the Plugins to an earlier version and test the functions within WP 3.0 then to see if we have a fix.

All that takes a while though. To FTP 3.0 to the Domain takes about 45 minutes so we need something in the order of two hours to run it up, test it and revert to 2.9.2 to regain full functionality. As you know, we leave WP 3.0 version.php in wp-includes just so that won’t keep prodding us about an upgrade to WP. It has no impact upon the problem at hand however.

So. wp_user_level 10 ???
User admin does not even mention wp_user_level. It’s only the three other users, who each have administrator rights in WP Dashboard (supported by wp_capability: a:1:{s:13:”administrator”;b:1;}, in phpMyAdmin, who have this user level factor added to their status in the phpMyAdmin Table.

Yes, the admin user should have wp_user_level set to 10

Please feel free to try that. I hope it works.

See this for more info:

https://codex.www.ads-software.com/Roles_and_Capabilities#User_Levels

That was interesting. Thanks.
In the event, I found there were another 30 lines overpage and the admin wp_user_level turns out to be 10 after all.

Then I noticed that wp_usersettings, in wp_usermeta, is not the same for each user:

1 | wp_usersettings | m0=c&m1=c&m2=c&m3=c&m4=c&m5=c&m6=c&m7=c&m8=c&m9=

2 | wp_usersettings | editor=tinymce&m0=o&m1=c&m2=c&m3=c&m4=c&m5=c&m6=c&…

3 | wp_usersettings | editor=tinymce&hidetb=1

4 | wp_usersettings | editor=tinymce&hidetb=1

I honestly do think this is the area where our problem lies but I accept, as UID 1 admin is the fixed wp_user 1, there would likely be some differences in the settings for that user so as to prevent meddling. The user name, for instance, cannot be changed and I seem to recall it cannot be deleted.

As the actual codes in each meta_va;ue box mean nothing to me, what are the Forum’s views of whether changes could or should be made?

I clicked on Upgrade (we are still in WP 2.9.2) and the message about plugin update permissions remains unchanged. Obviously, none of the other changes I may have made [backlog] have had any impact on the ‘problem’.

I generally don’t mess with the wp_usersettings values. They seem to be there for a reason. However, it’s easy to test whether or not this is the cause.

Just use your existing administrator account to create a new administrator account. The new administrator account will be created with the default correct settings. If the new administrator account works, then you know that the problem is with the old administrator account. If it doesn’t, then we know that it has nothing to do with the account settings.

Quote – “Was never able to Auto-Update in WordPress. Was used to doing so in Joomla and felt peeved it didn’t work here.”

Are you saying that autoupdate has never worked for you on this host?

Quote – “We have made a number of changes throughout the entire installation during the last week.”

Have you tried a fresh install 2.x.x on the same host to see if the autoupdate works?