This weekend I'll be presenting on "Isomorphic WordPress Applications using NodeifyWP". I'll also be discussing the NodeifyWP Environment – a Dockerized environment pre-setup for running NodeifyWP applications.
Category Archives: Node.js
Fluxible at DevIgnition 2016
Today I am presenting at DevIgnition 2016.
Fluxible is a framework by Yahoo that follows the Flux architecture by Facebook. The framework enables you to build powerful isomorphic JavaScript applications that are extremely maintainable, extensible, and scalable using React.js components. The Flux architecture employs a “unidirectional dataflow” and has three major parts: “dispatcher”, “stores”, and “views”. Yahoo’s Fluxible library contains some very powerful tools for setting up your application.
My presentation will run through the basics of React.js, Flux, and Fluxible. It will then run through the key pieces of my Fluxible Starter library which is a barebones Fluxible implementation using Gulp as a task runner.
Here are the slides:
Modifying the DOM using jQuery within React Components in Isomorphic Applications
React works awesome within isomorphic JavaScript applications. There are a number of frameworks and design patterns available for accomplishing this. My personal favorite is Fluxible.
In an isomorphic application, your JavaScript renders views both server side and client side. Essentially the same view code is being executed client side and server side. At first it was hard for me to wrap my head around that concept. React components can be used to implement those views.
jQuery, especially it’s UI libraries, is a useful client side tool. Since jQuery itself relies on a client side DOM, we can’t use it server side. Therefore we need to execute jQuery code in our React components but only during client side renderings.
Here is an example ES6 React component using JSX. Let’s pretend we are using this as a view in an isomorphic JavaScript application where it is being rendered both server side and client side:
import React from 'react';
class MyComponent extends React.Component {
render() {
<div>
This is my React component. <a title="Checkout my tooltip text.">Tooltips</a> are pretty helpful.
</div>
}
}
Let’s use the jQuery tooltip plugin to power our tooltip. First make sure you include jQuery and the tooltip plugin in your page output. It usually makes sense to add external scripts to your base React component.
Let’s setup our tooltip code:
import React from 'react';
class MyComponent extends React.Component {
componentDidMount() {
jQuery(React.findDOMNode(this.refs.tooltip)).tooltip();
}
render() {
<div>
This is my React component. <a ref="tooltip" title="Checkout my tooltip text.">Tooltips</a> are pretty helpful.
</div>
}
}
First, we added a ref tag to our tooltip. This let’s us reference our component node later. We then added a componentDidMount method. componentDidMount executes after initial rendering on client side only. Refer to the React lifecycle for more details on this. React.findDOMNode selects our tooltip node based on ref. We then wrap the node in jQuery and call the jQuery tooltip method. Since componentDidMount executes client side only this works perfectly and doesn’t cause any issues with our server side rendering.
Dockunit: Containerized Unit Testing Across Any Platform and Programming Language
Problem:
I want my application to work on all the environments I claim to support but I have no way of easily testing updates in each environment.
Bad Solution:
Continuously push to your remote to force Travis CI to test changes in multiple environments.
Good Solution:
Containerized unit testing with Dockunit.
Dockunit is a simple node command that lets you run your test framework of choice across a number of predefined containers. Each container can have it’s own test command and Docker image. It was born out of the need to ensure my PHP applications (WordPress specifically) were compatible with a spectrum of environments. Travis CI dropping support for PHP 5.2 was the final straw so I created this command for myself and decided to make it public.
Install/Usage Instructions for Dockunit
1. Ensure dependencies are met. See requirements on Github.
2. Install Dockunit
npm install -g dockunit
3. Setup project(s) with predefined containers.
To do this create a file called Dockunit.json in the root of any project you want to run Dockunit on. Github contains specific guidelines for how to write Dockunit.json files. Here is an example file for testing a WordPress plugin in PHP 5.2 FPM in WordPress 4.1, PHP 5.5 FPM in WordPress 4.0, and PHP 5.5 for Apache in WordPress 3.9:
{
"containers": [
{
"prettyName": "PHP 5.2 FPM WordPress 4.1",
"image": "tlovett1/php-5.2-phpunit-3.5",
"beforeScripts": [
"service mysql start",
"bash bin/install-wp-tests.sh wordpress_test root '' localhost 4.1"
],
"testCommand": "phpunit"
},
{
"prettyName": "PHP 5.5 FPM WordPress 4.0",
"image": "tlovett1/php-fpm-phpunit-wp",
"beforeScripts": [
"service mysql start",
"bash bin/install-wp-tests.sh wordpress_test2 root '' localhost 4.0"
],
"testCommand": "phpunit"
},
{
"prettyName": "PHP 5.5 for Apache WordPress 3.9",
"image": "tlovett1/php-apache-phpunit-wp",
"beforeScripts": [
"service mysql start",
"bash bin/install-wp-tests.sh wordpress_test3 root '' localhost 3.9"
],
"testCommand": "phpunit"
}
]
}
3. Run Dockunit command.
dockunit
Note: This assumes you have changed directories to your project root. You may need to sudo.
Detailed command usage instructions can be found on Github. Contributions and bug reports are encouraged :).
Run WordPress Cron on Real Unix Cron with Node.js
WordPress cron is a confusing beast. Most people don’t understand it or intentionally use it. It is not the same technology as Unix cron. Scheduled post functionality actually depends on WordPress cron. By default on every page load, WordPress checks to see if any cron events are due to fire. If an event is due, it sends a request to wp-cron.php asynchronously to execute the event(s).
So what?
This system works great for small websites running simple theme and plugin setups. Often when building WordPress applications for enterprise, enough resource intensive events get setup on cron that HTTP requests timeout before completion. We can circumvent this problem by executing WordPress cron using actual cron.
wp-cron-node is a simple node command that runs WordPress cron events via PHP CLI and Unix cron. It will execute WordPress cron events that are due for execution. The command requires WP-CLI.
Let’s run our scheduled events using actual Unix cron and Node:
- Make sure npm and WP-CLI are installed.
- Run the following command:
npm install -g wp-cron-node
- Disable WordPress cron. This will prevent HTTP requests from triggering cron events. Put this code in
wp-config.php:define( 'DISABLE_WP_CRON', true );
- Finally, setup your crontab file to your liking. Edit your crontab with the following command:
crontab -e
Here is an example crontab entry that will check for scheduled events every 10 minutes.
*/10 * * * * wp-cron-node /path/to/wp
Note: Running this every 10 minutes means cron events could fire up to 10 minutes late. Ten is a conservative number for performance reasons. Change this to whatever makes you comfortable.
Modifying core WordPress files is a quick way to introduce security vulnerabilities, break your site, and break future updates. From the perspective of a developer, nothing is worse than searching through a theme and plugins for a problem only to discover a previous developer modified a core WordPress file an introduced a bug.
I wrote a simple Node module that lets you easily check WordPress installations for modified or removed core files. Install the detect-wp-core-modifications npm package with the following shell command:
npm install -g detect-wp-core-modifications
You can run the command without any arguments from within the root of a WordPress installation with the following shell
command:
detect-wp-core-modifications
You can also specify a relative or absolute path to a WordPress installation:
detect-wp-core-modifications ../wordpress
Taylor Lovett 