Here’s the process I followed to get ImageMagick installed on a CentOS 5 DV Server over at Media Temple. I needed ImageMagick to convert PDFs to JPG files.

1. yum install ImageMagick*
2. pecl install imagick

   Here’s where I encountered the first hiccup:

   shtool at ‘/var/tmp/imagick/build/shtool’ does not exist or is not executable. Make sure that the file exists and is executable and then rerun this script.
   ERROR: `phpize’ failed

   Luckily I found someone with a similar issue. The fix was to create a different temp folder for pear to use. Steps as follows:

   mkdir rw /tmp2

   pear config-set temp_dir /tmp2

   pecl install imagick

   Build process completed successfully Installing ‘/usr/lib64/php/modules/imagick.so’ Installing ‘/usr/include/php/ext/imagick/php_imagick_shared.h’ Installing ‘/usr/include/php/ext/imagick/php_imagick.h’ Installing ‘/usr/include/php/ext/imagick/php_imagick_defs.h’ install ok: channel://pecl.php.net/imagick-3.1.2 configuration option “php_ini” is not set to php.ini location You should add “extension=imagick.so” to php.ini

3. Add “extension=imagick.so” to php.ini.
4. Verify install was successful and ImageMagick is loaded into PHP.

   service httpd graceful

   php -m | grep imagick (should output imagick)

   php -r "print(class_exists('imagick'));" (should output 1)

   rm -rf /tmp2

5. After confirming that ImageMagick was installed and loaded into PHP, I still had the following error in my application:

   Fatal error: Class ‘imagick’ not found

   Found that the PHP file loaded was different than the default php.ini:

   Loaded Configuration File /var/www/vhosts/system/domain.name/etc/php.ini

   To resolve, I created imagick.ini in /etc/php.d with the following content:

   ; Enable imagick extension module extension=imagick.so

   I then removed the extension from inside the default php.ini file (step 3) to clean things up.

6. One last restart! service httpd graceful
7. Check for ImageMagick again via phpinfo() at the domain your application is running on =)

This is a pretty rough outline so if you have any questions, please let me know in a comment below. Thanks!

This post is an explanation of the Zero-configuration Web Application Debugging with Xdebug and PhpStorm wiki entry over at JetBrains.

While the instructions are pretty straight forward, I wanted to share where being a beginner had me scratching my head wondering why things weren’t working. Enjoy!

1. Install Xdebug
I stumbled upon a wizard to help me get Xdebug installed on my system (OS X Yosemite using local MAMP). You can find the wizard here, which will give you step-by-step instructions specifically for your current environment.

1. a. Configuring Xdebug
Here is what I added to my php.ini file (values left as <explanations>):

zend_extension=”<this was already added as part of Install Xdebug step>” xdebug.remote_enable=1 xdebug.remote_port=”<the port for XDebug to listen to>” (the default port is 9000) xdebug.profiler_enable=1 xdebug.profiler_output_dir=”<AMP home\tmp>”

More about how to configure Xdebug can be found here.

After updating the php.ini file, I restarted Apache (sudo apachectl restart).

2. Prepare PhpStorm
Probably the most straightforward step!

3. Set a breakpoint in the source code
Find an area in your code that you want to debug and click the gutter before the line of code to set break point.

4. Activate debugger on server
I’m currently using the bookmarklets to activate/deactivate the debugger.

Note: To bookmark, I found it easiest to click and drag the link to my Bookmark Bar in Chrome.

5. Start a debug session in browser
Nothing will seem to happen when clicking on the bookmark, but not to worry, proceed to the next step!

6. Reload the current page
Here’s where the code should stop executing (your page should “pause” it’s loading) and PhpStorm will now be at the forefront with its debug window open.

7. Set initial path mappings
I skipped this step. Your mileage may vary here.

8. Debug!
Step into functions, check what variables are set as, etc.

There you have it! Let me know via a comment if you ran into any other issues or have any tips to improve upon the install / debugging process with PhpStorm.

Special thanks to @chaplinkyle for his recommendation to use PhpStorm.

Get to vhost root:
alias www='cd /var/www/vhosts/'

From domain.name, get to WordPress theme directory:
alias t='cd httpdocs/wp-content/themes/'

Restart Apache gracefully:
alias apachegrace='/etc/init.d/httpd restart graceful'

Directory listing with timestamp, ownership, permissions, etc:
alias ls="ls -l"

There are times that you want to hide mobile specific features on desktop to avoid user confusion. Today I ran into such a case where a tel href on a phone number was being used that resulted in someone getting a 404. To hide this from desktop, I used jQuery to reference the display value to only load if the value was set to block.

var $isMobile = $(‘.toy-gallery td’).css(‘display’);

if ( $isMobile == ‘block’ ) {
    $(‘.phone-number’).wrapInner(‘<a href=”tel:5555555555″></a>’);
}

There’s a lot you can do to make your WordPress install more secure–some easier than others! Here are a few of the easy ones. These can be applied to a new or existing WordPress install.

wp-config.php

Salt passwords:
https://api.wordpress.org/secret-key/1.1/salt/

Salting the passwords on an existing site will force everyone to log in again.

Disable file editing from within WP Admin:
define('DISALLOW_FILE_EDIT', true);

And if the site is taking advantage of SSL:
define('FORCE_SSL_ADMIN', true);

File system

Make sure permissions are set correctly:
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;

Caution: the above two commands could break WordPress plugins that require unsafe (IMHO) permissions to be set. See how to setup WordPress with FastCGI (coming soon).

Was working on updating a WordPress installation from 3.4.1 to 4.0 while also pulling it out of a multisite install. I have been using Git to keep track of changes along the way (thankfully!). I ran into an upgrade issue and used the following commands to get me back to where I needed to be:

git reset --hard hash

git clean -qfdx

Sources: Revert To A Previous Git Commit, Git Reset Hard Leaves Untracked Files Behind

Add the following to your .htaccess file to block posts to wp-comment-posts.php and wp-login.php that have do not have an http referrer or user agent. This will also redirect the user back to their IP address.

<IfModule mod_rewrite.c> 
    RewriteEngine On 
    RewriteCond %{REQUEST_METHOD} POST 
    RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php* 
    RewriteCond %{HTTP_REFERER} !.*domain.name.* [OR] 
    RewriteCond %{HTTP_USER_AGENT} ^$ RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L] 
</ifModule>

Replace domain.name with your domain name (sans www subdomain).

Source: Deny Access to No Referrer Requests

Reading log files that are from another time zone can add an additional (and unnecessary) layer to your troubleshooting headache. Most of the servers that I touch are on the Eastern seaboard and thus, depending on the earth’s tilt, the offset can vary (thanks UTC!). To resolve this on CentOS, check out the following two commands:

Make a backup of the current time zone (by moving it):
sudo mv /etc/localtime /etc/localtime.bak

Create a link between desired time zone and /etc/localtime:
sudo ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

Now run date to verify the changes took.

That’s it!

Source: Change Timezone In Centos