Roy Lindauer

A WordPress ajax handler for custom themes

Something I have been noodling on is a better way to handle ajax requests in my custom themes. Seems that a relatively complex theme ends up with a lot of add_action calls for custom ajax handlers. Every time a new endpoint is required we have to add two new add_action calls to our theme. Maybe a better approach is to write a single ajax endpoint that will route requests to the proper classes/methods?

Basically, we pass in the Class and Method we want to execute into the ajax url. With some sane configuration I think that this could be a good way to build an ajax interface into your theme. To protect against malicious calls classes are namespaced (\Ecs\Modules\), and the methods are prefixed (ajax*). This should stop most attempts to execute arbitrary theme code. There are issues. There would be a fatal error if the class does not exist which could expose information about the environment. We have to make sure that the $_REQUEST params are well sanitized.

This method allows us to encapsulate functionality into separate classes/modules instead of cluttering functions.php with ajax functions. Potentially this makes the code more reusable.

 

Reno Linux Users Group (RLUG) responsive website redesign

I recently launched a new website for the Reno Linux Users Group (RLUG). It’s a custom theme on top of WordPress.

It’s a custom responsive website that integrates with the Meetup.com API to sync the monthly RLUG meetings to the site. The custom theme is based around my sort-of-framework for WordPress theme development. The front-end is built using Grunt, Sass, and jQuery. I am using composer and a custom framework for the backend.

rlug-website-mobile

rlug-website-design

My VagrantFile

This is the Vagrantfile I am using for my development box at home and work. It is determines how much ram is available and how I want to allocate, how many CPUs are available, and configures the VM for me. I use NFS for shared folders. Finally, starting to use “hostupdater” to keep my host machines hosts file current.

I would love to make that more dynamic, based on the Apache vhosts I have configured in the VM. Something to work towards I suppose.

The base box was provisioned using Packer and Chef.

 

Ohai Plugin for OpenVZ VMs to get public IP Address

Media Temple uses the OpenVZ virtualization system and I have quite a few Media Temple servers under Chef management. The one thing that has made management difficult is that by default during a Chef run ohai returns 127.0.0.1 as the default IP address which means I cannot run knife to execute commands from my workstation.

For example, when I run  knife node show mydv.server.com  I get the following:

Kinda sucks. If try to execute on all of my MT servers, say something like  knife ssh 'tags:mt' 'sudo chef-client'  I will get a ton of failed connection errors because it is trying to connect to 127.0.0.1.

The solution is to get ohai to return the correct IP. OpenVZ has virtual interfaces and the actual public IP is assigned to them, while the main interface, eth0, is given the ip 127.0.0.1. This ohai plugin will retrieve the correct IP.

Put this in your ohai plugins directory for chef: /etc/chef/plugins/openvz.rb and when chef runs, it will get the correct IP address.

Now when I run knife show mydb.server.com

 

Corgi Meetup at Fuji Park

IMG_2148

IMG_2038

IMG_2109

IMG_2069

IMG_2130

IMG_2176

IMG_2112

See more photos at https://www.flickr.com/photos/ecsyle32/sets/72157651648832885/