Development

1. Approach
2. Coding Conventions & Style
   1. Tools
3. WordPress Build Structure
   1. Logging
   2. Updating
4. Theme Structure
   1. Build
   2. Build Mode
   3. Packages
   4. Error Reporting
   5. Debugging
5. Security
6. Serving

---

Approach

I’ve learned much more from maintaining websites than from building them. I’ve repaired, rebuilt, and redesigned sites and I have websites that were published almost 20 years ago still running. The primary takeaway I’ve gained from these experiences is the need to place emphasis on the extensibility, usability, and sustainability.

Aside from design and functionality changes, supporting websites involve core upgrades, hosting upgrades, database maintenance, and the occasional rewriting a function that has been deprecated. Design and functionality changes are made easier by a site built not to limit the ability to fundamentally alter the design patterns or functional elements. If the website is intuitive enough to use, users won’t need support. I try to keep the usability simple by matching the editor design to the site design and minifying the administration elements. Keeping the codebase trim by relying almost entirely on the core features of WordPress and automating the database maintenance make it more sustainable.

Coding Conventions & Style

I use and .editorconfig file to set the styles. Most text editors will abide by it. I like for my code to be compact and readable. I use small indent sizes, very little white space and I don’t do inline comments. I do notate sections with comment headers so that I can quickly find a section I’m looking for. Otherwise, I keep all of my lint and hint files exactly the same as the WordPress Develop coding standards.

Tools

I use PhpStorm, Atom, Sublime, & Textmate as text editors. I use the theme Sunburst for syntac highlighting everywhere including my terminal. I use TablesPlus for SQL and Postman for the API. I use Homebrew to manage my local stack and I try to keep it identical to my two main servers. OhMyZsh is my default shell and I prefer Vim over Emacs.

WordPress Build Structure

I don’t use Docker for running the standard WordPress develop stack because I like to match the same host configurations I have on my servers and I don’t like the overhead. Although I should try to give back more, I rarely offer any patches or pull requests on core. I only test backward compatibility for themes using phpcompatiblity-wp and the Jenkins and Scrutinizer CI inspectors. I use the same set of tests as core, but I rarely run them. I use run Xbebug and I rely on Composer to install a Whoops and Monolog for cleaner reporting. I also use phpdotenv so that I can keep all my passwords in a .env file. I keep a public repo of my build @ https://code.davidawindham.com/david/wp.

Logging

I always run WP_DEBUG set to log and display. I keep an error.log file for build errors and a php_error.log for PHP errors. I run two terminal windows to tail the log and watch the Gulp processes.

Updating

I use git for version control on everything. Because the configuration has WordPress in it’s own directory, I can keep that sync’d with the master. I do the same for plugins and themes. I’ve also set up a suite of testing, development, and regularly used plugins that I copy/paste from the .gitmodules.remote and .gitmodules.extra files. ( I need to update those since I no longer use many of them )

Theme Structure

I think I just kind of grew into the structure I use. I can’t stand to dig into another theme like… Genesis that has gone to great lengths to build out a custom structure with chained dependencies. I’d rather have a lot of lines on one file than 10 files with 10 lines. The convention I use is pretty standard.

Build

I use Gulp.js for my preprocessor. I like WebPack and I use it on occasion, but I spent so long with Grunt that Gulp fits somewhere in between. Plus I’ve put all kinds of alias’ for git and Gulp in my terminal and I’ve yet to do so for Webpack. I have a less is better approach to the build. I really just want to be able to update my dependencies with NPM or Yarn and then copy those to the _src/ directory to chop and dice at will. I depend on just a couple core gulp processors like uglify, purgecss, and concat.

Build Mode

Somewhere along the line, I got tired of manually flipping my enqueue scripts between the contatinated versions, that I just added a toggle on the front and back end so I could switch between the two. see – /mode/

Error Reporting

I built a little alert box that displays error on the front end of the site, becuase I don’t always have my eyes on the inspector console.

Debugging

There are a bunch of good tools out there for debugging. My gotos are the WP-Debug-Bar and Query- Monitor

Security

I handle a lot of security issues server side. I’m a stickler against bad agents, bots, and other nuisance nonsense on the web. I continually block IP addresses from public repos of known bad agents. I also watch the logs and manually block others and I block all spam referrals. The abnormal site structure here helps to obfuscate from some automated attacks. There are also some simple steps I add into WordPress specific sites because the automated attacks are so prevalent.

1. Use a custom prefix for the database tables
2. Block the wp-login.php and xmlrpc.php files using .ini (nginx) and .htaccess (Apache)
3. Place the wp-config.php file outside of the web accessible directory.
4. Use strong passwords and usernames.

I’ve created a dedicated page about how to implement some extra security @ /security.

Serving

I like to run a pretty standard LAMP setup using Nginx as a proxy for static assets. I keep my localhost matching. I like to use Redis to cache if high scalability is needed. I tune the PHP-fpm based on the server and I like to have rollover database servers.

I trim down some of the files in both the WordPress build and the theme before placing them on the server.

Here’s a list for the WordPress Build… You literally only need the /app, /wp, index.php, & wp-config.php files on the server. You can remove these.

• /tests/* ( for testing )
• .travis.yml
• .jshintrc
• .jshintignore
• *.log ( access, php_error, error )
• /bin
• gruntfile.js
• package.json
• /SRDB ( *should be removed after database rewrites )

You can remove these from the theme.

• /_src ( used to move file from packages )
• .git & .gitignore ( optional for runing your remote sites under version control ) .
• /css/*.scss ( the sass files )
• gulpfile.js
• inc/dwp-dev.php
• readme.md