So maybe you’re thinking, “why is she sharing something she hasn’t even started?” That’s a great question. I thought it’d be pretty neat to document the entire journey of building this thing. To many of us in the WordPress community, this whole REST API thing is still a foreign concept. Breaking our traditional PHP theme paradigm is going to take time. It’s going to take research. And it may not be pretty. I already have questions about implementation of things in the back of my mind, and I’m hoping to answer these questions as I go, and share them with the community. Of course, if you’re reading one of these posts, and you have questions, speak up and ask in the post comments, or @me on Twitter. Let’s help each other. With that, let’s get this thing started. Read on below for a detailed project plan.
Implementation of the REST API gives WordPress users and developers several advantages. WordPress can continue to operate as a familiar and robust backend for data storage and delivery, while making the data itself more accessible to other platforms. Decoupling data delivery from the content management system (CMS) makes WordPress more accessible to a broader audience. For example, building a frontend to consume WordPress data no longer requires knowledge of the WordPress theming system. It frees developers up to consume their data in whatever way is necessary from use in websites, to apps, and other third party services. Instead of WordPress being the solution for a website, it can be a building block in the foundation of a user’s larger application.
Requirements & Objectives
Any starter theme built for WordPress needs to give developers a leg up in the development process, but should not include so many features that it becomes burdensome to work with. To that end, it is incredibly important that Aurora remain relatively un-opinionated, yet provide the basic features one might expect of a functional WordPress theme (i.e. if you install and activate the theme, it shouldn’t look like a dumpster fire). Ideally, any opinionated elements (e.g. styling) could easily be blasted away, giving the next developer a clean slate.
Aurora will be a clean, modern theme with the following features:
- ES Next + React
- Icon (SVG) management
- Linting according the WordPress Coding Standards using PHPCS, ESLint, and Stylelint
- Documentation support
- Support default post types (post, page, nav-menu, * comments)
- Easy to understand
- Complies with Section 508 and WCAG 2.0AA accessibility standards.
- Meets WordPress internationalization and localization guidelines.
- Use techniques including Atomic Design to keep the theme files organized and easy to understand.
Project Scope / Deliverables
At this time, Aurora will only consist of the starter theme. Future implementations may include:
- Extensibility via the command line–easily spin up reusable components via a command line integration (e.g. Yeoman), which will be hosted indepently from the theme (likely via a branch of Aurora Project).
- Gutenberg components. Support for default Gutenberg components will exist, but new components are not in scope for the initial phase of the project.
- A plugin for interacting with Custom Post Types / Custom Endpoints.
Aurora will be a clean, elegant starter theme with simple styling, and basic components, to help developers get started on their WordPress REST API theme projects.
Use Aurora Project (the non-theme boilerplate) as the base setup for the theme
- Tweak Aurora Project Webpack setup to work with WordPress (keeping in mind that hot module replacement doesn’t work in WordPress).
- Browser Sync
- Use Underscores for some of the base theme files _ header.php (pulls in styles and head scripts) _ footer.php (pulls in scripts) _ index.php (a fall back if our JS fails) _ 404.php? * functions.php
Theme components (React components)
- Navigation (this might be a challenge given that there is no clear way of interacting with menus via the default endpoints)
- Archive (home, categories, tags, etc.)
- Single post / page
- Sidebar (I’m really curious about supporting widgets via the REST API)
- Search results (maybe this is the same as the archives?)
- Social icons (menu)
How should the theme interact with the Customizer?
- Custom logo
- Site title
- Site tagline
- Site icon (favicon)
- Sidebar (no sidebar, sidebar right, sidebar left)
- Widget area(s) for the footer (see Alcatraz)
- Footer copyright text
- Testing (Mocha? Jest? other?)
- Performance metrics
- Sass documentation
- Component documentation (KSS? Storybook?)