Open Source, PHP and Visual Studio Code

Lately, VS Code has been getting a lot of hype in the dev community. It’s been around since for a few years and TBH is a really sweet editor. Lots of great extensions and community support. It’s also quite fast (for an Electron app 😬) and the peeps and Microsoft seem to be keeping it up to date and iterating quickly.

However, anything you really need to work with PHP is missing by default. I believe this is by design to encourage a vibrant extensions community. Luckily, like most languages, there’s a vibrant open source PHP extension community. There’s a few great extensions for PHP: PHP IntelliSense, PHP Debug (both by the same developer) as well as PHP Intelliphense (#wat?). There’s even a really great intro by Jeffrey Way on Laracasts outlining everything you need to do to get VS Code set up for PHP dev.

Some of the PHP packages work fine and have over a million installs (!!!). Sometimes, however, they don’t work. Like, at all. Just today, the PHP Debug extension completely broke. Luckily the developer was paying attention and rolled out a fix within hours. Pretty awesome support for an open-source product!

However, if you paid for the editor, say something like PHPStorm, you could go and raise an issue on their support channel. You could complain about the product not working, rightly so, as you’ve paid for the right! As a ‘customer’ you have a certain amount of clout with a vendor like Jetbrains. This is NOT the case with open source, and I feel that we developers forget this.

This is where I take issue. I’m all for open source software. I’ve built my career on it. The issue is that the developer for this plugin had to fix the issue himself. There’s an expectation there that he HAS to fix the issue, and do it RIGHT NOW. And if it’s not done immediately people freak out, complain on Twitter, write a blog post about, have a cow 🐮, man.

Open source is just that, open. If you find an issue with a plugin, editor, extension or WHATEVER, see if you can fix it! That’s the whole point. Let’s not throw our hands up and complain, let’s get our hands dirty and fix the damn thing.

That’s what open source is all about. Let’s remember that.

/rant

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

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 and Drupal Deployment – the Dev, Stage, Production conundrum

One of the issues us as developers face daily is the concept of deployment. Especially with a CMS. Here’s an overview of some of the tools and approaches out there.

Deployment (or environment syncing of dev > stage > production)  of a CMS/Website has the following components:

  1. Deploying code
  2. Deploying a database
  3. Running post deploy scripts.

Typically deployment is one way, from development to stage to production, although all the below can be performed in the opposite direction.

The following are some of the common methods of deployment:

Via (S)FTP or file syntonization – Old school

The old school method of deployment is by using scripts or manual process is to mirror dev, stage and production environments. Steps in this process involve manually exporting a database script and deploying that database to the staging or production environment. For files, they are copied directly to the staging/ production environment. Major drawbacks of this method are deployment tracking is lost and there is no easy rollback.

git deployment

A newer and currently popular method for deploying website/CMS files is by using git. With a git deployment strategy, a git remote target is setup (either staging or production) and a git push is run whenever these environments need to be updated. This however only updates CMS files, and not a database. Post deploy hooks can be called on the target server to mimic database changes and run other commands via shell commands (run unit tests or clear caches). The added benefit of this approach is that deployments are tracked in git and can be rolled back easily.

Script based approach

Similar to a git deployment, a script based approach can be used for deployment to staging and production sites. This approach relies more heavily on POSIX shell commands (like rysnc, grep and diff). This requires more up front work for deployment, but is much more customizable and ultimately  powerful. A combination of a script based approach and git deployment are common in the WordPress and Drupal worlds for deployment.

Continuous integration

A more robust build system can also be implemented. In a CI type environment, a combination of unit tests, code review, VCS and deployment can all be rolled into one. More robust and powerful than a script based approach, a CI deployment plan is almost bulletproof as most (Travis CI, Jenkins) mandate testing of code before passing a build. This approach requires the setup of a dedicated CI server that has hooks into the VCS (git, svn etc.) and still requires the integration of shell scripts to fully take advantage of.

Tools

More than scripts but less that full-fledged CI systems are some tools that can be used to deploy and sync WordPress and Drupal sites.

Capistrano

Capistrano is a Ruby based tool that became popular with the Ruby on Rails crowd as a way to deploy code. Similar to a git deployment process, Capistrano allows for command line deploys and post deploy hooks but allows for a robust roll-back feature. Capistrano is configured via config files and has a requirement that both host and target are running Ruby.

https://github.com/capistrano/capistrano

Drush

Drush is the Drupal-shell that allows for running command line scripts specifically on a Drupal codebase. Many things like installing modules, setting up sites and themes, basic database versioning to basic deployment via rsync, can be accomplished by Drush.

http://drush.ws/

wp-cli

Another tool similar to Drush is wp-cli. A super powerful command line tool for managing WordPress, wp-cli does for WordPress what Drush does for Drupal. Custom commands can also be written to hook into custom code, themes and plugins. Cool.

http://wp-cli.org/