Practicing 7/1

tree

IMG_2542

I really liked the light in the bottle, and the golden color of the beer of course

IMG_2416

A little blurry, but I liked the Rembrandt-ish light

Enable status for php-fpm

Accessing the PHP-FPM Status screen is easy enough. First, enable pm.status in your php pool:

Then add the following block to your Nginx vhost conf:

Restart php-fpm and nginx and then browse to http://<SERVERIP>/status. You will be presented with some useful information on the current status of your PHP-FPM pool.

By default /status will just show a short status, like an overview of all of the processes. To see output on each process append ?full to the url, http://<SERVERIP>/status?full. You can also pass ?json to get JSON output, if you wanted to feed the data into some other log or stats processing tool (thinking like, greylog or logstash?).

Here is a breakdown of the stats presented to you:

pool – the name of the pool.
process manager – static, dynamic or ondemand.
start time – the date and time FPM has started.
start since – number of seconds since FPM has started.
accepted conn – the number of request accepted by the pool.
listen queue – the number of request in the queue of pending connections (see backlog in listen(2)).
max listen queue – the maximum number of requests in the queue of pending connections since FPM has started.
listen queue len – the size of the socket queue of pending connections.
idle processes – the number of idle processes.
active processes – the number of active processes.
total processes – the number of idle + active processes.
max active processes – the maximum number of active processes since FPM has started.
max children reached – number of times the process limit has been reached.

Use this information to tune your pool configuration.

My Pantheon + Jenkins Process

pantheon-workflow-jenk

Here is a rough outline of my Pantheon + Jenkins process. I like my code in BitBucket. I also like Pantheon (check them out). The Pantheon workflow is all about being the source of truth for your code. This is fine, and actually I dig it because it promotes good practices. However, I, and my company, have many projects in BitBucket already, and am using Jenkins more and more for some Continuous Integration functions. We want to keep using BitBucket as our source of truth and our existing workflows, but also want to use Pantheon.

Already, this is problematic and managing it on a developer by developer process is going to be prone to error. You have to push branches to two remotes and deal with, probably, some ugly merging and potentially other issues.

What I want to do is to push to BitBucket and use a commit hook to trigger Jenkins to deploy our code to Pantheon automatically. I use Pantheon Multidev (at work) and this process assumes that the Mutlidev env already exists. It will not create it for you (yet).

The BitBucket commit hook

How this is going to work is we are going to setup a POST hook with BitBucket. We will set the POST url to be a PHP script (our receiver script) in our Jenkins server (or just setup a small ec2 instance to host it if you don’t want to install PHP on your Jenkins server). The POST payload will include the list of modified branches. I have called my receiver script jenk.php because, heh. I have setup some environment variables with my Jenkins username and access token so that I can make API requests to the Jenkins server.

The POST hook url looks something like: http://jenkins.server/jenk.php?project=<project-name>&token=BUILD-PROJECT

Replace <project-name> with the name of your project, and replace BUILD-PROJECT with your build token.

jenk.php

This is the receiver script. It gets data from your commit, and submits a build request to Jenkins. Easy peasy.

The Jenkins + Pantheon Deploy Configuration

I have configured a parameterized build with Jenkins. The single defined parameter is “BRANCH_TO_BUILD“.

Under Source Code Management I have added the two git remotes, one for BitBucket called “origin” and one for Pantheon, called of course, “pantheon”. In the “branches to build” section I added in  remotes/origin/$BRANCH_TO_BUILD .

Under Build Triggers I used “BUILD-PROJECT”.

Under Build I added an “execute shell” task to checkout our branch from origin so that we can push to the pantheon remote –  git checkout remotes/origin/$BRANCH_TO_BUILD

Finally, I added a “Git Publisher” post build task configured to push the “$BRANCH_TO_BUILD” to the “pantheon” remote.

To summarize, the process is make code changes, commit, push to BitBucket remote, hook is fired, and a POST is sent to our receiver script, which sends a POST to Jenkins with the $BRANCH_TO_BUILD parameter, and if the build passes, the branch is pushed to Pantheon. If everything worked you will see Pantheon converging your app in the dashboard! If it fails, well, check your console output from the build.

And that’s it. We can continue using our regular, non Pantheon, workflow, with Pantheon. The process and workflow stays consistent!

A WordPress ajax handler for custom themes

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 to me that a relatively complex theme ends up with a lot of add_action calls for custom ajax handlers, and this could be simplified/reduced. 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?

The goal would be that all ajax requests are run through our custom ajax handler and routed to the appropriate controller & method for execution. 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.

With some sane configuration I think that this could be a good way to build a flexible 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 though. 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 would need to be scrutinized and tested for security issues. We don’t want someone to be able to craft a request to execute code we don’t explicitly want executed.

Here is an example structure in a hypothetical Theme class.

 

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