PHPStorm, MAMP and Xdebug – How to keep (some of) your hair

I’m mostly logging this here for my own benefit, but if the Google gods brought your here, sweet!

Just came across another fun quirk with running Xdebug, MAMP and PHPStorm together. 😅😅😅😅

I’ve talked about this combination causing me issues in the past, but this is a whole new situation that killed a couple hours for me.

So, it appears that for PHPStorm to pick up Xdebug correctly, the xdebug.remote_host variable needs to be set correctly. It normally is, if you copy-pasta some of the tutorials on the internet.

Unfortunately, for some reason, this Monday morning, setting this value to localhost no longer worked. Why? Welp, localhost is pointing to an invalid folder location, according to MAMP. Apparently this was enough for PHPStorm to freak out and just not run Xdebug. Period.

Fun!

So how’d I figure out this was the reason for Xdebug throwing up?

The PHPStorm docs of course! Wayyyyy at the bottom of this page it’s plainly stated:

Remote host is configured as ‘localhost’ despite server host is probably not local

The URL to validation script contains something different from localhost, but the xdebug.remote_host value is not set and so is using the default value of localhost, or is set to localhost or 127.0.0.1.

#themoyouknow

JavaScript build tooling and the CLI

Something that’s come up recently in the front-end world is the topic of a learning curve and JavaScript tooling such and Webpack and Babel. While I agree that new tooling can sometimes be a pain to learn, since when did being a web developer/programmer/rockstar not require learning new things? I mean, learning the CLI is one thing, but it’s not suuuuper difficult and is definitely a skill that will serve you well in your career. On top of that, front-end build tooling has been around for a while, first with Grunt and then Gulp. Does Webpack make things that much more difficult?

The argument I’m making is partially around React and how Webpack (or similar) is required. To me, this doesn’t seem like a problem, as many languages require compilation during a build step. I see the build step and associated tooling a good thing, as it allows for more streamlined and complex programming concepts to be brought into front-end development.

If you’re worried about learning something like the Webpack build process, Create React App has got all the setup jank covered. In Vue, there’s vue-cli which similarly gets you set up. In both cases all it takes to get up and running is npm install then npm start. That’s not too bad!

I guess what I’m saying, if all this ‘new’ stuff bothers you as a developer, it might be time to 1.) upgrade your skills, or 2.) do something else. Things aren’t slowing down any time soon in the front-end landscape, better get on the wagon or jump off!

MAMP, Xdebug, PHPStorm and symlink madness

Ask any PHP developer and they’ll tell you Xdebug is the best thing since sliced bread. While true, it’s also one of the biggest pain in the asses to setup. I’ve probably set it up, in various incarnations, close to 10 times.

There’s always something that get’s me caught up and messed up. This time I decided to document how I was able to get it working this time, so hopefully I don’t have suffer through this again.

I followed Michael Novotny’s post on this, and it almost works. There’s just one missing piece, for me, and that was how to handle symlinks in your plugins.

This overview assumes a few things. You’re on a recent version of OSX, you have MAMP Pro 3 installed, and you’re using PHPStorm.

Step 0: Use the same version of PHP for your CLI and your webserver.

Time and again I’ve seen people have issues with their CLI PHP version and Web server PHP version not matching up. This can cause all sorts of weirdness, especially with Xdebug, so make sure you’re using your MAMP version of PHP on your CLI.

This can be as simple as adding the MAMP PHP version to your $PATH.

In your ~/.bash_profile file you can add something like this.

echo $PATH | grep -q -s "/Applications/MAMP/bin/php/php5.6.10/bin"
if [ $? -eq 1 ] ; then
export MAMP_PATH=/Applications/MAMP/bin/php/php5.6.10/bin
export PATH="$MAMP_PATH:$PATH"
fi

Step 1:Make sure Xdebug is installed.

This one’s a gimme, but still a point worth making to cover all the bases. Make sure you’ve got Xdebug running and remote_enable=1 is set in your php.ini. There’s plenty of resources on the inter-web’s for this.

You can check if Xdebug is available, by running php --version in your CLI. You can further check what kind of Xdebug settings your have enabled by running php -i | grep xdebug

Step 2: Setting up PHPStorm

Make sure PHPStorm is using the same PHP Interpreter you’re using for everything else. You can set this in Preferences > Languages & Frameworks > PHP and selecting the MAMP PHP version you’re using.

Interpreters_and_Preferences_and_wpmdb-replace_php_-_wp_-____Sites_wp_

After that, essentially follow Michael’s guide for setting up PHPStorm with the debug configurations, once PHP is all set up.

Step 3: Symlinks

If you’re using plugins in your local PHP install that are symlinked (and many plugin developers do this), make sure you map those folders for Xdebug and PHPStorm! This is where I got caught many times. I even needed to map the base of my WP install, since I had checked the ‘Use path mappings’ setting.

Servers_and_Run_Debug_Configurations

For me, that’s all it took to get things running. Without the explicit path mappings for the symlinks, Xdebug half worked – which was super confusing…

I should note that if you’re running multiple sites on your MAMP install, and 2 of these sites are talking to each other in any way (via AJAX or the WP Rest API etc.), make sure ONLY ONE is running Xdebug. Not sure what the reason is, but the workaround is easy enough. Just use another version of PHP within MAMP, one that doesn’t use Xdebug.

Hope this helps someone else.

WordPress Jetpack contact forms – AJAX

EDIT, May 9, 2016

I noticed that the form wouldn’t submit when not logged in, so I’ve updated the gist to include a check to see if a user is logged in. 


Jetpack is awesome for a lot of things. Unfortunately, one of the things that it isn’t so great for is submitting it’s contact form via AJAX. I’ve looked into this before and decided I might as well hack something together that ‘kind of works’ ™.

Here’s the full working code, I’ll go into a bit below:

Basically, all you do is fake-send the form via ajax, parse the returned page’s HTML and look for an H3 tag with the submission message.

Easy-peasy…

WordPress security – Tools and third-party services

(This is part 1 of a series on WordPress security)

Online security is has been gaining alot of attention in the media recently, and with good reason. With much of our lives now taking place online, security is something that effects all of us.

The recent ‘Sony Hack’ and the iCloud photo hack were just 2 of the many security issues in 2014.

WordPress specifically was effected with the SoakSoak malware effecting over 100,000 sites.

With security on the top of everyone’s mind, I thought it was a good idea to list some resources for securing, hardening and locking down your WordPress installation. This guide aims to expand on some of the concepts in the “Hardening WordPress” post on WordPress.org (http://codex.wordpress.org/Hardening_WordPress) – read this first.

After all, WordPress security is worth the investment if you’ve spent the time (and money) curating and writing a blog.

Keeping things up to date

This is an obvious one, but as the Hardening WordPress guide states, “you should always keep up to date with the latest version of WordPress”. I would go even further, and say that you should always keep up to date with the latest versions of plugins and themes. The WordPress auto-updater is coming along but only works with minor point releases and doesn’t update plugins OR themes. Keep those themes and plugins up to date!

Third-party services

The next simple thing you can do to keep your WordPress site secure is sign up for some security and monitoring services. Not all of these services are free, but if you or your client’s website is a source of revenue, the small fees are well worth the investment.

I’m a big fan of Sucuri and their Malware removal tool (referral link) and it offers a great peace of mind knowing that they’re monitoring my sites and are available for quick malware cleanup’s if needed. They send out notification emails each week letting you know of the status of your site(s). Awesome.

They also have a Web Application Firewall (WAF) that’s similar to CloudFlare. I haven’t used it but it seems cool.

Secondly, VaultPress is an excellent service for backups and security monitoring. I recommend the ‘Security Bundle’ for all the clients I work with, and for $29/month, quick backup restores and monitoring are taken care of. Heck, even the $5/month plan is a great deal for their service that backs up your site code, files and database to the cloud.

CloudFlare is a free DNS and CDN service to protect your site from spammers and provide some base level of speed increase. It’s an additional layer in front of your site that will intercept some illegitimate traffic and bots.

You can configure how much or how little CloudFlare caches, and what level of DDOS and security protection you get. There are other options for restricting spam users and IP’s from the CloudFlare control panel.

It’s worked pretty well for me, the only drawback is that is requires pointing your DNS at CloudFlare’s servers. This could be a deal breaker if you don’t control you’re DNS (or don’t know who to ask). There’s also the whole privacy issue with funnelling your traffic through CloudFlare’s infrastructure.

Website monitoring services, like New Relic, AppDynamics or even Pingdom, are also worth mentioning.  Though not specifically related to security, they are great for knowing when your site goes down and what caused it (like a spike in spam traffic).

There are a whole host of other security related services and tools out there, which ones do you use?

Next post – Security plugins!

Now with 50% more self-hosting…

Just switched this blog over to a self hosted Digital Ocean VM. I was able to migrate all of my content away from WordPress.com, which was nice. Testing out some Cloudflare DNS and Nginx action.

 

This site is going to be a playground for new tech and fun code. Stay tuned!