WordPress .gitignore

Updated May 2016. I wrote the original version of this in 2014 and have since change how I work, thus the update. Unfortunately there is no *right* answer.

Wondering how git fits into your WordPress dev workflow? Here’s a great little file to help you get started – WordPress gitignore. Don’t know what a gitignore file is for? Read up on the gitignore file on the git manual.

The contents of your .gitignore file will vary depending on your style of versioning your work. Some devs keep their entire WordPress sites under version control… including WordPress core and plugins/themes from the .org repo. Others only store custom plugins and themes while ignoring any code that’s not custom. I currently manage code/workflow in all these ways as it varies by project and requirements.

Basic WordPress .gitignore

However in any case, you should ALWAYS ignore the wp-config.php file and the file uploads. You shouldn’t store wp-config.php in git because it is generally unique to the environment it is in (dev, test prod) and it potentially exposes your database username and password. The file uploads (wp-content/uploads) directory should be ignore because it should be handle like content in a database. You don’t wan to store file uploads in version control for the same reason you don’t want to keep your database rows in version control. File uploads should be treated the same way and synchronized with a tool for different environments.

wp-config.php
wp-content/uploads

Other WordPress .gitignore Considerations

There are many other types of files you don’t want to clutter up your nice clean repo. There are many type of files found in the wp-content folder that you want to ignore. In most cases it’s easier to tell git what to look for (ie themes and plugins) than it is to list all the things to explicitly ignore. For instance, one will often find backups and cache stored in wp-content. These things can easily be generated and are often environment specific. These are others to often ignore…

wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/cache/
wp-content/upgrade/
wp-content/wp-cache-config.php

 

Slack Slash Command With WordPress REST API Backend

I’ve spent the last several weeks building Slack bots and other custom integrations. One of the simplest types of Slack integration to build is the Slash Command – which can be a way for a user to interact with a bot or to provide functionality to a team or channel. Slack provides built in commands (like /topic and /remind) or you can develop custom commands either through a Slack app or just a one off implementation.

Setting up a slash command is pretty easy, because all you need to provide is a RESTful endpoint that returns data to post to a channel.

Slack Slash Command
Hey Kramer bot slash command integration

Slack will do a POST or GET to your endpoint with either JSON or query string parameters giving you information about the command that was given.

Slash Command POST Data
Slash Command POST Data

And your endpoint can simply return a string to send back to the user who initiated the slash command. Or you can send back a formatted message which is essentially a JSON package with the message to send back and some options along with it.

Kramer Slack Bot

This is where WordPress and its REST API come in. This is also where WordPress starts to become a platform. I’m not designing a theme or even building a website with WordPress. I’m creating a RESTful API with a nice simple way for users to enter data. In less than 5 minutes you can have a fully functional API outputting JSON via RESTful URLs backed by an easy to use and extend CMS.

Out of the box you have access to all data in your WP backend with a simple URL schema…. ie ‘/posts’ get a paged list of posts, ‘/posts/{id}’ to get a specific post. Here is an example from the Seinfeld API I am developing for the Kramer bot. Notice the URL structure: https://heykramer.com/wp-json/wp/v2/posts

WordPress REST API JSON Output
WordPress REST API JSON Output

Great! But not so fast … Slack is expecting something specific back. Well thankfully the REST API is easily extendible. Below is an example plugin I created to show how easy it is to extend the WP REST API to provide Slack what it needs back. (here it is on Github

To extend WP REST API, I register a custom endpoint and define a callback function to execute when that URL is requested. In this instance we are expecting a GET request with query string parameters from Slack. It expects one of two commands: gif or image. Based on the command, it will query different categories of content on WP backend and return one random result to be posted in the Slack channel where the slash command was initiated.

Kramer Bot Responds To Slash Command

Next up – building out a full Slack bot on NodeJS with a WordPress backend…

WordPress Single Page Template For Categories

If you are familiar with building WordPress themes you’ve likely caught onto the naming convention used for page templates. These conventions are things like ‘page-{slug}.php’, ‘single-{slug}.php’, and ‘category-{slug}.php’.

The conventions are very handy and I wanted something similar for posts in a category. This method is much cleaner than having conditional logic all over your ‘single.php’ file to do have different design elements or functionality for posts in different categories.

A simple one-liner to drop into your theme’s functions file does the trick…

Now, you can create ‘single-news.php’ for a post in the News category and ‘single-blog.php’ for a post in the Blog category and have completely different designs and layouts.

Using WordPressSharp To Publish A Post

This is a brief intro to using WordPressSharp to publish a post with C# via the WordPress XML-RPC API.

A few notes… the ‘PostType’ property of the Post class can be set to either “post” or “page” depending on which WordPress type you want to publish. And the ‘Status’ property can be set to either “publish” or “draft” depending on whether you want to publish your new post/page right away or not. In the future I’d like to make these enums or something extendable. But WordPress has them as strings so you can define new ones (ie Custom Post Types) on your own.

Keep in mind this class is merely a simple example. In most cases you might want this in a service layer where you can inject the WordPressSiteConfig class as you need it.