Category Archives: Linux Servers and Software

General Linux server and software information.

Install Imagick for WordPress on CPanel WHM Server

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.

/opt/cpanel/ea-php70/root/usr/bin/pecl install imagick

Reviewing my own setup, I had already used the following script.

/scripts/installimagemagick”
before proceeding with the “imagick” PECL installation

Running the Site Health check again showed the same issue. So I restarted Apache and the PHP-FPM services and tested again. Issue resolved.

Magento Wget Download

If you use Linux servers, are working with Magento, and want to download the latest version or patches then the Magento site is not as friendly as you might want.

The download process is java driven and does not provide a link for the download, just a browser based download to your local computer.

I work mobile a lot and I do not want to download 22Mbyte files to my notebook over 3G and then have to upload from my notebook to the server. It is just a waste of time and bandwidth.

So I went searching for the path that we need to use and for the latest tar.gz file for magento this is what works.

http://www.magentocommerce.com/downloads/assets/1.9.1.0/magento-1.9.1.0.tar.gz

From what I can see, and assuming that they do not change the process, http://www.magentocommerce.com/downloads/assets/ followed by the version number as a directory, and then the file name should provide a full download path.

In this case this combo downloaded the latest release for me to my Linux server.

[text]
# wget http://www.magentocommerce.com/downloads/assets/1.9.1.1/magento-1.9.1.1.tar.gz
[/text]

A word of warning!

When extracting the tar.gz file, Magento do not provide a unique version path for the contents. All versions use the root path of ‘magento’ so assuming you always download to the same path you may have magento-1.9.1.0.tar.gz right alongside magento-1.9.1.1.tar.gz and extracting the newer version will extract it into the magento directory over the top of existing magento directory. The result of this is that your new version is potentially saddled with artifacts from the earlier version. Delete the magento directory and start again.

A 4 step process could be:

1. Clean up from previous downloads

[text]
#rmdir magento // or // #rm -Rf magento
[/text]

2. wget the new version

[text]
# wget http://www.magentocommerce.com/downloads/assets/1.9.1.1/magento-1.9.1.1.tar.gz
[/text]

3. Prepare a directory ready for the extract of the new version

[text]
#mkdir magento-1.9.1.1
[/text]

4. and finally extract the file contents from the tar.gz file, into the stated directory, and strip the first directory from the path that is stored within the archive, i.e. /magento/

[text]
#tar zxvf magento-1.9.1.1.tar.gz -C magento-1.9.1.1 –strip-components=1
[/text]

Next, carry on as usual with your backup existing, copy the new files, etc, etc.

(Solved!) NextGEN Gallery works only with a role….

WordPress, MultiSite, NextGEN Gallery and this annoying message “Sorry, NextGEN Gallery works only with a role called administrator.”

Dashboard Error Nextgen Gallery WordPress Multisite
NextGEN Gallery error Administrator role

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.

Wordpress Multisite Users Panel with no users
There were no users for the sub-site

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.

Empty WordPress Roles
The role dropdown is not populated.

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;
}

$role->add_cap(‘NextGEN Gallery overview’);
$role->add_cap(‘NextGEN Use TinyMCE’);
$role->add_cap(‘NextGEN Upload images’);
$role->add_cap(‘NextGEN Manage gallery’);
$role->add_cap(‘NextGEN Manage tags’);
$role->add_cap(‘NextGEN Manage others gallery’);
$role->add_cap(‘NextGEN Edit album’);
$role->add_cap(‘NextGEN Change style’);
$role->add_cap(‘NextGEN Change options’);
[/code]

Debian Install SSL Certificates for Apache OpenSSL

Something else that I do not do often and have never documented is the install of an SSL certificate on Debian servers for use with Apache / OpenSSL. For this post I am assuming that an existing SSL certificate has been purchased. I use a lot of wildcard certificates for multiple servers rather than a certificate per site / server.

Go to this directory

[text]# cd /etc/ssl/private/[/text]

By default there is a self-signed certificate key ssl-cert-snakeoil.key in the directory

This directory is restricted to root user and ssl-cert group.

Using an existing certificate, key, and intermediate certificate, create a file for each in the same directory.

Change the relevant ownership

[text]# chown root:ssl-cert *[/text]

and change the access

[text]#chmod 640 *[/text]

This should provide something like:

[text]

/etc/ssl/private# ls -la
drwx–x— 2 root ssl-cert 4096 Apr 14 12:12 .
drwxr-xr-x 4 root root     4096 Mar 28 08:41 ..
-rw-r—– 1 root ssl-cert 1589 Apr 14 12:11 mydomain-intermediate.crt
-rw-r—– 1 root ssl-cert 1704 Mar 20 23:25 ssl-cert-snakeoil.key
-rw-r—– 1 root ssl-cert 2049 Apr 14 12:10 mydomain-cert.crt
-rw-r—– 1 root ssl-cert 1678 Apr 14 12:13 mydomain-key.key

[/text]

Ok, now off to the Apache config

[text]# cd /etc/apache2/sites-available/[/text]

and edit the site file that is relevant so that the Virtual Host *:443 section includes the correct paths to the above certificate files

[text]
# Example SSL configuration
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
SSLCertificateChainFile "/etc/ssl/private/mydomain-intermediate.crt"
SSLCertificateFile "/etc/ssl/private/mydomain-cert.crt"
SSLCertificateKeyFile "/etc/ssl/private/mydomain-key.key"

[/text]

If there is no Virtual Host *:443 section then there should be an existing VirtualHost *:80 for the website and this can be copied / duplicated in the same file, just change the port in the copy from 80 to 443 and insert the above Example SSL lines at the bottom of the new section above the closing tag.

If Apache is a fresh install it may not have SSL enabled

[text]#a2enmod ssl [/text]

Test Apache syntax

[text]#apachectl -t [/text]

Restart Apache
[text]#apachectl graceful [/text]
or
[text]#service apache2 restart [/text]
depending on what you need for existing sites on the server.