Fabrica Dev Kit is a toolkit for WordPress development. You…
- Clone a GitHub Repo
- Configure your WordPress project (settings, plugins, etc) through a `.yml` file
- Run a Ruby setup script which
- Downloads dev dependencies (like Gulp) through npm or yarn
- Builds a Docker container and volumes to run everything inside of
- Everything, including the big WordPress dependencies like PHP and MySQL, and running inside Docker. The web server is Nginx and PHP-FPM
It goes a step further and sets up some WordPress theme development dev dependencies like:
- Twig templating
- Specifically Timber, which brings Twig to a WordPress context and allows for MVC like structuring of your theme
- Advanced Custom Fields and a customization of that to allow version controlling of that setup
It goes another step in sets up build processes for theme development, like:
- Preprocessing of HTML through PostHTML, so you can use a special BEM syntax
- PostCSS with add-ons like LostGrid
- Autoprefixer
- Image optimization
- Linting, minifying, and source mapping assets
- Incorporates BrowserSync for helping make testing in browsers faster and easer
It assumes some other theme dependencies like:
- Normalize.css
- jQuery
- If you need more front end dependencies, you can use npm and Webpack to include them
- If you need more back end dependencies, you can use Composer for those
And then for moving from development to production, you’ve got:
- WordMove (“Capistrano for WordPress”)
High five to Andrew, Thomas and João who build and released this and emailed me about it. It’s an ambitious project and it’s cool that it’s free and open source.
There are some mixed emotions here though. Gosh that is a THICK STACK of tooling in use there. It making assumptions across the entire stack of how you work. I’m feel like an old man yelling at a cloud here, but I’m going to suggest you work with these tools individually first before going all-in on a stack like this. This is a lot of abstraction to swallow in one pill.
This particular take at entire-stack-abstraction hits all the right notes for me. I’ve worked with almost all those tools and have a decent understanding of what they do and why they are useful, so combining them all into an easy-to-setup thing is appealing, but I could just as easily see being turned off by something like this that assumed some depenedencies that I didn’t like or didn’t have a taste for.
I can’t this up and running on Ubuntu 16.10
I keep getting:
[Fabrica] Waiting for 'timpress_wp' container...
More than 360 seconds elapsed while waiting for WordPress container to start.
‘timpress’ being my slug
Anyone have this problem?
We’re looking into this and will respond via the Github issue you created as soon as we have more information!
We’ve now resolved this issue, the latest version of FDK works on Ubuntu no problem.
Hello Chris,
Andrew, Thomas and João from Fabrica here! Thanks so much for the write-up, we really hope other developers will be able to put the Kit to good use.
Regarding your reservation about the thick stack, it’s certainly true that we include a selection of technologies by default: the Kit started life as an internal tool on our own custom WP projects, and these are the tools we’ve found to be most powerful and flexible. However, perhaps we should have been clearer in our email to you (and our documentation) that almost all of them are optional and/or can easily be swapped out for alternatives.
For example, if you don’t want to use Timber/Twig, you just write normal PHP templates. If you don’t want to use the PostHTML-BEM syntax, you just write normal HTML. If you want SASS instead of PostCSS, you just
npm install
it and alter a couple of lines in the Gulpfile.In other words, no tool in the stack – with the exception of Docker, really – is absolutely indispensable or immutable. And version control of a FDK project folder includes its
package.json
and Gulpfile, which means that any swapped tools or alterations to the build process are kept along with the source files.So it’s not quite right to say that we’ve made sweeping assumptions about how other developers will want to work: we’ve just included a default set of tools for a quick and complete setup. We’ll make some changes to the documentation and add a page to our website to make the flexibility clearer.
That said, we’ll be happy to discuss any adaptations that could facilitate the use of alternative tools. Developers can contact us via Github issues or at [email protected]