All things WordPress on Linux. I don’t do WP on Windows as there is no point. If you have a licenced Windows server install Hyoer-V and run up a virtual linux system for apps like WordPress. Its a much more robust process than trying to make Windows do things it was never designed to do.
Lots of issues cropping up on one of my CPanel servers, most of which are pointing to issues with MySQL.
While trying to test I have copied a database for a WordPress website from the live site to a dev site, or at least I attempted to do so.
MySQL 8.0 Incorrect format parameter error message in phpMyAdmin
Which led me down a rabbit-hole of database optimisation tools, plugins, and SQL configuration.
Having run some WordPress plugins to remove rubbish, I exported again to find that all that effort only removed 2MB of data and was essentially a waste of time. Obviously the system is full of cruft, but identifying the cruft takes more effort than WP Database Cleaner plugins can do. I’ll come back to this later.
In any case, the export .sql file was too big, so I cut it into slices, finding that even with grabbing a stack of lines, there was a bulky section of data in one area and I had to mess around with the file slice sizes to get the largest file down to under the 128M and even then it was still 129M on disk, but probably under the 128MiB vs 128MB.
After looking at the wrong end of the puzzle for an hour, what I eventually found was that I should have checked the diskspace consumed by the tables and / or the number of rows in the tables. In this case only one table was accounting for 130MB of the total 190MB of the database. It was a log record and defaulted to 30 day retention which was consuming a large chunk of space. Reset to have 14 days retention, truncated the table removing some of the older records and tried again.
This time, with 40MB reduced file size, exporting the Structure first and then data in two chunks, that large log table in one, and everything else in the other. Importing 3 files to the new database went smoothly.
Lesson learnt, before exporting SQL, review what is being exported, and make an assessment of expected output file sizes. It should save a lot of effort.
A quick how-to Install Imagick for WordPress on CPanel WHM Server.
Running Site Health check within and updated wordpress site shows:
One or more recommended modules are missing
PHP modules perform most of the tasks on the server that make your site run. Any changes to these must be made by your server administrator. The WordPress Hosting Team maintains a list of those modules, both recommended and required, in the team handbook (opens in a new tab).
Warning The optional module, imagick, is not installed, or has been disabled.
Following many of the search links to resolve this leads to using the Module Installer PECL via the WHM console, but for me I got this error:
WARNING: channel “pecl.php.net” has updated its protocols, use “pecl channel-update pecl.php.net” to update Warning: popen() has been disabled for security reasons in OS/Guess.php on line 241 Warning: fgets() expects parameter 1 to be resource, null given in OS/Guess.php on line 242 Warning: pclose() expects parameter 1 to be resource, null given in OS/Guess.php on line 251 downloading imagick-3.4.4.tgz … Starting to download imagick-3.4.4.tgz (253,434 bytes) ……………………………………………..done: 253,434 bytes 19 source files, building running: phpize Warning: popen() has been disabled for security reasons in PEAR/Builder.php on line 465 ERROR: failed to run `phpize’
Continuing my search ended up at the CPanel forums and a resolution for installing imagick from cPanelMichael and a command line option – noting that I modified my command line to use ea-php73 which is the target version of php for this WordPress site.
WordPress, MultiSite, NextGEN Gallery and this annoying message “Sorry, NextGEN Gallery works only with a role called administrator.”
I noted a lot of older posts on the WordPress support site that lead nowhere to find a resolution, or, as someone else posted, they went poof! into a bug report hidden from the public.
Have I really solved this issue ? Yes, for the specific site that I am working on. Will this be the same issue for you? Maybe not, but here are the details.
So to be clear I am using the latest WordPress version and the latest NextGEN Gallery version in a multi-site configuration with about 6 sites within it. The nature of the issue is that the stated error message persists in the dashboard / admin view for a sub-site. It was not all sub-sites and when I did a proper review it was in fact only in one sub-site that the error displayed.
So I checked the php script just to confirm that the error message was telling the truth or at least was not a case of poor translation and it wasn’t. The actual script is at the bottom of this post but it is not relevant beyond confirming that it is a ‘role’ issue.
Next I questioned, if I am the administrator for the main site and most of the sub-sites, why is there no administrator role?
Sure enough a check of the Users page for all the sites revealed that I was correctly in that role for all but the site that was giving the error.
This is where it got tricky, the sub-site was the #2 sub-site and the oldest sub-site, aside from the main site and when I tried to add an existing user or a new user to the subsite it completed but still did not show a user.
The Role drop-down was not populating and therefore the concept of administrator was not available to be set for the user.
I experimented for a while with different settings, comparing sub-sites and trying to fathom why this was happening. The end result was no reason for it, other than I think this original blog #2 may have pre-dated a major upgrade in WordPress Multisite and perhaps there was some artifact or setting missing as a result.
In any case, I did a backup of the database, created a new subsite, ran an export of the #2 subsite, ran an import of the same data into the new subsite, and bingo! There is now a new user with a role of Administrator and the NextGen error is no longer appearing.
The final clean up was to rename the old #2 site and archive it. Then rename the new site to the same as the old one, tweak the settings for theme, menu, widgets, and url, and the transition was done. All up this should take you less than 15 minutes to do.
Does it resolve the actual issue, no, but I think the error is not actually a NextGEN issue, but an issue with the WordPress site. If you have read this far, you probably have a similar problem, I hope this works for you.
NextGen nggallery_install Function
Now dont panic, the following code is just for my records, there is no need to change it. This is the piece of the PHP function that generates the error and I include it here just to confirm that the error is generated when there is not an available administrator role for the site.
[code]
// Set the capabilities for the administrator
$role = get_role(‘administrator’);
// We need this role, no other chance
if ( empty($role) ) {
update_option( "ngg_init_check", __(‘Sorry, NextGEN Gallery works only with a role called administrator’,"nggallery") );
return;
}
The NextGen Gallery is one of the plugins that I use on lots of WordPress sites.
I’d never struck this before and the information from all the blogs and forum posts I looked at did not or could not resolve how to fix this issue.
The situation arises when you rename an image file directly in the file manager, or in my case the linux command line. The filename is actually stored in the database in the wp_ngg_pictures table and for manual correction you would expect that updating the filename column would be sufficient.
Then selecting the image and the recreate thumbnail option is expected to do just that, but it doesn’t. You may see an “error occurred” message in the thumbnail creation screen but it is not a helpful message.
The issue is in fact that the thumbnail details are stored in another column called metadata in the same table and this column is referenced for the thumbnail update and not the filename, i.e. NGG is still the original thumbnail filename and recreating that file not the new file.
There are two steps required, change the filename in that column and delete the metadata field value back to null or empty. Then you can re-create your thumbnails and they will work with the new filename.