WordPress: Maintaining Active Nav Status with Custom Post Types

Scenario: You have a custom post type archive page, and you want to be able to add some custom content to the archive without hardcoding it in the template. This is easy enough – you can create a page with the same name and slug, and set your templates to pull in the data from the page on the archive listing page by performing a query based on the post type slug.

However, it introduces a problem with the active state on the WordPress nav. You can create a custom nav item to point to the slug of the archive for your post type, but WP will see the nav item as referencing a page, even though you specified the item as custom.

In order to fix this behavior, you will need to filter the wp_get_nav_menu_items function to tell WP that the nav item is custom if it references a post type, which will force WP to match based on the URL and restore the active state to the nav:

Automating Grunt Builds in PhpStorm

I’ve started using PhpStorm for doing PHP development. So far, it’s been great. I find that I need to have significantly fewer programs and windows open, and that it automates a lot of the tasks I was doing manually.

Today, I puzzled out how to have PhpStorm invoke Grunt instead of running grunt watch in a terminal window:

  1. Navigate to Project Settings > File Watchers.
  2. Click + > Custom.
  3. Name: Grunt.
  4. Show console: Always.
  5. Deselect Immediate File Synchronization.
  6. File type: Any.
  7. Scope: Click button.
    1. Click + and add a new scope – name it Grunt Watch, click OK.
    2. Expand this window.
    3. With your scope selected, browse in the file tree and select directories that Grunt would be watching and click Include Recursively.
    4. Select files that Grunt is outputting (such as minified CSS and JS files) that you included in the previous step and click Exclude (this prevents the resulting output file from endlessly re-triggering Grunt execution).
    5. Click OK.
  8. Program: (browse to grunt executable path).
  9. Working Directory: (browse to the directory that contains the Grunt file).
  10. Click OK to create the File Watcher.
  11. Click OK to exit the Preferences dialog.

A Vagrant Script to Automatically Enable Apache Sites

At work, we are starting to use Vagrant to manage our virtual machines, and are largely having great success with it. Through mapping a virtual directory back to a source folder on our Mac, we are able to use the same git repositories across multiple virtual servers and operating system environments, and thus Vagrant automates most of the VM build and configuration process for us.

One area that isn’t automated, that we decided should be, is mapping the Apache configuration files stored in our git repositories to Apache automatically. I wrote this small script and placed it in our Puppet / PuPHPet files/exec-always directory, which crawls our git folders looking for local configuration files and mapping them into an Apache conf file at initial vagrant up and then at every reboot:

We have PuPHPet set up to map /Volumes/Sites to /var/www, so that /var/www contains all of our repos. Apache config is found in /var/www/reponame/apache/local.conf – if your configuration differs the above would need to be modified. However, it automates the process of setting up Apache config, which just helps us develop faster. Combine this tactic with the use of dnsmasq to automatically resolve all addresses ending with a custom TLD directly to the virtual machine, it also eliminates the need to modify the hosts file for each new site.

EDIT: Depending on how fast the mapping to /var/www happens, it is possible that Apache will attempt to load configuration from /var/www before it is actually mounted, causing Apache to error out and fail to start. I changed the Apache reload directive for a restart directive to ensure that Apache starts after loading the config, which is already being delayed by 30 seconds to give the filesystem time to fully mount.