The back-end and front-end teams at Modern Tribe set out to create a WordPress starter development kit in order to speed up development and help keep uniformity among projects. So, how did we build it? Why didn’t we use “________” framework instead? What does the code look like? Is our universe real? What is true happiness? This session will attempt to answer at least 60% of these questions.

1. BUILDING A
WORDPRESS STARTER
DEVELOPMENT KIT
BACK TO SQUARE ONE:

2. @KYLE_UNZICKER
Designer + Developer

3. OVERVIEW
• Building what now?
• How did you build it?
• Why didn’t you use ____ instead?
• What does the code look like?
• Is our universe real?
• What is true happiness?

4. WSDK? WTF?
• It’s not just a starter theme
• It’s not just a development framework.
• It’s a collection of tools that allows for the
creation of WordPress sites and applications
• It presents a unified workflow for teams
across multiple projects

5. LET’S DO SOME
WINDOW SHOPPING!
• Starter Themes
• _s, Bones, Roots
• Front-end Frameworks
• Bootstrap, Foundation
• WP Frameworks/Libraries
• Carrington Core, Timber, Bedrock

6. WHY NOT USE ______?
• We did…sort of.
• We need solutions that are tailored to our
unique set of challenges.
• We need something that we can maintain
ourselves.
• We’re not reinventing the wheel, we’re just
making one designed for the roads we drive on.

7. OUR OBJECTIVES
1. Get a headstart on each new project
2. Implement a collaborative process in building
and maintaining commonly used code.
3. Create a consistent development approach
across projects and teams.
4. Create a consistent file structure that makes it
easy onboard new team members

8. HOW WE BUILT IT
• We identified our niche
• We build large WordPress projects that must scale
gracefully.
• We build sites that can be accessed quickly and easily
from any* device
• We build sites that empower business owners to have a
say in how their content is published on a daily basis.
• We create admin experiences that make training simple.

9. HOW WE BUILT IT
• Teamwork!
• When you start a project, where do you
start?
• What tools do you commonly use?
• How do you prefer to keep your files
organized?

10. HOW WE BUILT IT
• We started with a starter theme
• Created an outline of the file structure, on paper
• We gradually added build tools
• Outlined a SASS structure
• What mixins should we include?
• What variables should we have defined?
• Outlined a JS structure
• How do we want to organize site wide functions and application
states vs. functionality specific modules (sliders, filters, etc..)
• What third-party js libs should we include?

11. HOW WE BUILT IT
• We added plugins
• What plugins do we use on every project?
• What functionality do we wind up building
multiple times?

12. SO, LET’S GET BACK TO

13. WHAT’S INSIDE?
• WordPress!
• Mark Jaquith’s WordPress Skeleton
• With WP as a git submodule, upgrading/
downgrading is a breeze.
• Allows us to have a local-config.php file

15. WHAT’S INSIDE?
• Debugging Plugins
• Debug Bar
• Debug Bar Console, Debug Bar Cron,
Debug Bar Action Hooks, Debug Bar
Extender

16. WHAT’S INSIDE?
• Optimization Plugins
• Tribe Object Cache
• Tribe Quick Profiler

17. WHAT’S INSIDE?
• Security Plugins
• Tribe Security
• Limit Login Attempts
• Tribe Glomar

18. WHAT’S INSIDE?
• Admin Plugins
• Tribe Branding
• Tribe Admin UI
• Tribe Admin Dashboard

19. WHAT’S INSIDE?
• Publishing Plugins
• Tribe Roles
• Tribe Panel Builder

20. WHAT’S INSIDE?
• Development Tools
• Node Packaged Modules
• Grunt Tasks
• Bower packages

21. [1] Build Tools

22. [1] Build Tools

23. WHAT’S INSIDE?
• Starter Theme
• Based off of _s
• Barebones templates
• SASS Architecture
• Grid, typography, forms, admin styles
• JS Architecture

24. T
[1] Theme Structure

25. [1] Theme Structure

26. [1] SASS Structure

27. [1] SASS Structure

28. [1] JS Structure

29. [1] JS Structure

30. [1] JS Structure

31. [1] JS Structure

32. WHAT’S NEXT?
• Identifying code we seem to build
from scratch every time and create
reusable packages
• Galleries
• Mobile navigation systems

33. WHAT’S NEXT?
• Standardizing back-end workflows
and approaches
• Difficulties:
• Developer preference on organization/
encapsulation can vary
• Certain approaches are only appropriate
for certain projects

34. WHAT’S NEXT?
• Maintenance
• Monthly Reviews
• Review what we’re currently using - are we
using everything we’ve included?
• Propose additions and discuss
• WCTO Additions
• Accessibility tools
• Responsive Image Approach

35. WHAT’S NEXT?
• Diving Deepr Into Defining Best
Practices
• code style guides
• Keep the documentation momentum going
through the duration of the project

36. WHAT’S NEXT?
• How can we extend this philosophy to
the rest of the agency?
• Standardizing a design process
• Deliverable file names
• Version control
• Improving our recruitment process
• Fine tuning our human resources approach
to on boarding new members

37. FINAL THOUGHTS
• “Don’t get intoxicated by a process or
fall in love with tools.” - Andrew Clarke
• This mindset will help both create a
standardized workflow for teams and
individuals, but also force you to reevaluate
your process.
• We didn’t add build tools to be fancy or
cutting edge - we had to prove that they work
for us and provide consistency and efficiency.

38. FINAL THOUGHTS
• Learn from others
• Hundreds of thousands of people can’t be
wrong (right?)
• Beat your own path
• No one knows your process and workflow
needs better than you.
• Listen to your teammates

39. FINAL THOUGHTS
• Resources
• A 1000-Hour Head Start: Introducing the _S
Theme
http://tiny.cc/1000hours
• A Modern Designer’s Canvas
http://tiny.cc/aclarke
• 10up - Best Engineering Practices
http://tiny.cc/10up
• Grunt For People Who Think Things Like Grunt
are Weird and Hard
http://tiny.cc/coyier

40. FINAL THOUGHTS
• Is our universe real?
• Probably. But maybe not. Read up on the
Holographic Principle
• What is true happiness?
• “Instead of searching for possessions and
achievements to make you happy, reflect on
who you are and find authentic joy within.”
- oprah.com

41. THANKS!
@kyle_unzicker