JointsWP: a Foundation 6 starter theme for WordPress that stopped moving

A blank theme whose real content is the build pipeline

JointsWP is described as a blank WordPress theme built with Foundation 6, giving you all the power and flexibility you need to build complex, mobile friendly websites without having to start from scratch.

The word blank is doing a lot of work there, and it is worth being precise about what it means. This is not a bare WordPress theme with a header and a footer. The repository root contains the full set of templates a theme needs: index.php, single.php, page.php, archive.php, search.php, searchform.php, comments.php, 404.php, header.php, footer.php, sidebar.php, template-full-width.php, a functions.php, a parts directory and a functions directory. What is not there is content. There are no demo posts, no designed pages, no images of a finished site.

What the theme does supply is Foundation itself, wired into a build system, and that is the part that was genuinely tedious to assemble by hand. Foundation is a Sass framework, so using it means a Sass compiler, a way to concatenate and minify the output, autoprefixing, image optimisation, and a development loop with live reload. JointsWP is that toolchain, preconfigured, plus a set of PHP templates that already know how to output the Foundation classes.

The Foundation version in use is 6.5.3, and the package manifest names the project jointswp-sass with the description a WordPress starter theme using Foundation 6. The author is Jeremy Englert, the primary language is PHP, and the homepage is jointswp.com.

The intended audience is a WordPress developer who wants a working grid, responsive breakpoints and a component library on the first day, rather than a designer looking for a finished look.

The README says the project is no longer maintained

The first line of the README is a bold statement: this project is no longer actively maintained.

That line should shape every other thing you read, and it is reinforced by the release history. The listed releases are JointsWP 5.0, 4.0 and 3.0, and all three are dated on the same day, 2017-02-07, with times a couple of minutes apart. That is a bulk tagging of the major versions rather than a sequence of shipped releases, and there is nothing newer in the list.

The repository metadata and the description disagree in a small but telling way. The description leads with ARCHIVED in capitals, while the repository's own archived flag is not set. The last push to the repository was on 2026-06-23, so the tree is not a decade old, but the README's statement about maintenance is the one to trust about the project's intent.

What this means in practice is that the code will not get new features, new Foundation versions, or fixes for a build chain that is drifting further from current tooling every year. What you keep is the design decisions, the file structure and the working pipeline.

The licence situation is also worth checking before you ship anything. The repository licence is recorded as unknown with a custom licence that GitHub cannot classify, while the package manifest declares the licence as GPL-2.0 AND MIT. For a WordPress theme, whose template files end up in a public directory and whose output is a public website, the GPL side of that pair is the one that matters, and the LICENSE file in the repository root is the document to read rather than the badge.

There is also a yarn.lock and a package-lock.json in the root, which is a small sign of the era the project was built in.

npm install does the whole setup, because postinstall builds

The installation section is three commands, and the theme takes care of the rest.

$ cd my-wordpress-folder/wp-content/themes/
$ git clone https://github.com/JeremyEnglert/JointsWP.git
$ cd JointsWP
$ npm install

The theme states that at this point JointsWP should be installed and fully running on your local machine. It also says that if you prefer to install the theme manually that will work as well, with the caveat that you must run npm install after moving the files into the themes directory.

The reason a plain npm install produces a working theme is in the package manifest. There is a postinstall script set to npm run build, and build is gulp. So the install compiles the Sass, concatenates the JavaScript, optimises the images and writes the output into the theme, and if the install fails, the theme does not work.

That is a deliberate choice with a consequence. It means a fresh clone is immediately usable, and it also means the install is the slowest and most fragile step, because it is where the toolchain either works or does not. On a current Node version, an old Gulp 4 from a GitHub tag, Babel 6 and gulp-sass 3 are exactly the combination where you should expect trouble.

The Node requirement is stated in the theme's own requirements section: JointsWP requires Node.js v6.9.x or newer. The README is quick to add that this does not mean you need to understand Node, or even Gulp, it is just the steps needed to make sure the development tools are installed. That reassurance was reasonable when the theme was current, and it is the point at which a reader on a modern Node has to stop and check for themselves.

The daily loop is gulp watch, with Browsersync if you edit one variable

The working section covers two commands, and the difference between them is one file.

$ npm run watch

Watch does three things. It watches the assets/styles/scss directory, and when a change is made the SCSS files are compiled, concatenated with the Foundation files and saved to the styles directory, with sourcemaps created. It watches the assets/scripts/js directory, and when a change is made the JS files are compiled, concatenated with the Foundation JS files and saved to the scripts directory, again with sourcemaps. And it watches the assets/images directory, optimising the image files and saving over the originals.

The Browsersync variant watches the same files but adds live reloading and style injection. The one thing you have to do first is update the URL variable in the gulpfile.js to your local install URL.

$ npm run browsersync

That is a small piece of configuration and it is the only manual step in the whole loop, which is a good sign about how the rest is arranged.

The compile commands are split the same way, so you can rebuild one asset type without touching the others.

$ npm run build

The build script compiles and minifies all scripts and styles, npm run styles compiles all SCSS files in the assets/styles/scss directory, npm run scripts compiles all JS files in the assets/scripts/js directory, and npm run images optimizes all image files in the assets/images directory.

The package manifest also defines update-foundation as npm install foundation-sites, which is how the Foundation dependency would be refreshed, though the version pinned in the manifest is 6.5.3 and the README says that is what is currently in use.

The file structure section tells you the theme is scaffolding, not design

The file structure section is the most useful part of the README for anyone deciding whether to use this theme, and its first entry sets the tone.

style.css: this file is never actually loaded, however, this is where you set your theme name and is required by WordPress. That single line tells you how little the theme does on its own. The file exists to satisfy a WordPress requirement, and everything you actually write goes somewhere else.

The custom styles are split across four SCSS files. assets/styles/scss/style.scss is where you import all of your styles, and if you create an additional SCSS file you must import it there. assets/styles/scss/_main.scss is where your custom styles go. assets/styles/scss/_settings.scss is where you adjust the Foundation style settings. And assets/styles/scss/login.scss holds your custom login styles, which generate their own stylesheet.

The leading character in those file names is what tells Sass the file is a partial and should not be emitted on its own, and the split follows a standard practice: settings feed the framework, main holds your own rules, and style.scss is the entry point that pulls in both. A developer who has used Sass before will recognise this immediately, and a developer who has not will still find the two files they need to edit by following the file names.

The custom scripts go in assets/scripts/js, and each .js file is compiled and concatenated when the build process runs. The images go in assets/images and are optimised during the build.

What you are really getting is a directory layout with the build already wired, and a decision about where each kind of file goes. That is worth having, and it is also the whole of what the theme contributes.

The templates are the part you can read to learn the conventions

The remaining value in the repository is the PHP, and it is there to be read.

The template set covers the standard WordPress template hierarchy: index.php, single.php, page.php, archive.php, search.php, 404.php, plus header.php, footer.php, sidebar.php, comments.php and searchform.php. There is a template-full-width.php, which is a page template that lets a page opt out of the sidebar layout, and a parts directory for the pieces that get included in more than one template, and a functions directory for theme support functions.

For a developer building a WordPress theme with Foundation, these files are a worked example of how Foundation's grid classes and components are applied to WordPress output. That is the kind of knowledge that is genuinely hard to look up and easy to copy, and it does not rot in the way a dependency version does.

The same is true of the gulpfile.js. It is where the concatenation order, the Foundation import list, the image optimisation settings and the Browsersync configuration live, and it is the file you would port if you were building the pipeline yourself. Reading it tells you exactly what this theme's asset pipeline does, in a way that survives the toolchain going stale.

The pattern to follow, then, is port rather than adopt. Take the template structure, take the file layout convention, take the Sass organisation, and rebuild the build with current tooling. That gets you everything the theme has to teach, without the Gulp 4 from a GitHub tag and the Babel 6 dependency.

Editorial conclusion

JointsWP suits a developer who has an existing WordPress project, wants Foundation's grid and components, and does not want to assemble the SCSS and Gulp pipeline from scratch, since that is exactly what the theme provides and it still runs. It does not suit a new project in 2026, because the pipeline depends on Gulp 4 from a GitHub tag, Babel 6, gulp-sass 3 and a Node 6.9 baseline, and the theme is explicit that it is no longer actively maintained. Before you start, read the first line of the README and treat the theme as a reference implementation to port rather than a foundation to build on, and check the file structure section, because the theme tells you that style.css is never actually loaded and exists only to satisfy WordPress, which tells you how little the theme does by itself.

Frequently asked questions

Official sources

1. Issues
2. JeremyEnglert/JointsWP on GitHub
3. Project website
4. README
5. Releases