WP-Starter. WordPress theme starter template.
1. Download WP-Starter
2. Change the name of the theme (the folder itself, global variable $GLOBALS[‘theme_name’] inside the functions.php file and modify theme information inside style.css). Upload the theme to the themes folder of the WordPress project and activate it.
3. Install npm packages through the editor’s terminal, previously change the current directory in terminal to dev, in which the package.json file is located:
cd dev npm install
4. Provide url to the local server in the dev/settings.js file
exports.urlToPreview = 'wpstarter.local/' // url to the local project
5. For development:
6. For release:
In this article I want to share my experience in organizing file structure and describe the front-end development process creating a new theme for CMS WordPress.
The main question the I will try to answer is “How not to turn another WordPress project into a heavily maintained, slow💩”.
WordPress is a great, feature-packed tool that provides great opportunities for creating high quality websites, you just need to learn how to do it.
To easily maintain the code of any project in any programming language, it should be written using modules in order to separate functionality. This is what we are going to discuss right now.
Let’s take a look at the key concepts behind the WP-Starter template.
The root directory of the WP-Starter template looks like following:
The functions.php file contains only global variables and code for including all PHP files from subdirectories of the includes folder. This means that each created file in the specified subdirectories will be included automatically.
The main mistake of beginners (and not only) is the constant scaling of the functions.php file, and as a result, sooner or later it turns into a headache.
Speaking about the server side files, this directory is about to scale quickly. In my case, it usually contains following subdirectories:
WP-Starter uses the following rule – each hook is written in a separate file, as well as a function, class, shortcode, ajax request and so on.
Let’s take a closer look at the existing files in the hooks subdirectory, since it initially contains a lot of starter template code.
This file contains the hook of the All-in-One WP Migration plugin, which excludes dev directory from the migration file of the project. This directory is needed exclusively during the development process and should be excluded from the release.
In this hook I exclude the default CSS and some standard WordPress markup. Let me remind you that the code with comments can be viewed on GitHub by clicking the Source code button.
This is where custom theme scripts and styles are included and some default WordPress scripts and styles are disabled.
hook-wp-head.php | hook-get-header.php
These hooks in my case are initially responsible for customizing the appearance of the admin panel. The panel becomes smaller and translucent if not interacted with. Also, the admin panel stops breaking the markup if there is a sticky header or other elements that it affects.
Based on these examples, you can easily guess what the names and content structure of the files of the remaining subdirectories inside the includes folder will look like.
The file names are formed in this way not only to display the main functionality of the code inside it, but also to easily navigate between them inside the editor.
All files related to automating the development process are placed in a separate dev directory. And again, you can look at the template code in detail at the link on GitHub. But it’s even better to download it right away and test it yourself.
The file structure organization rule remains the same – we need to divide all the functionality into separate modules for easy writing, editing and maintaining the project. Styles and scripts also need to be divided into modules. In my case it looks like this:
Speaking about styles, for example, I always have a text.scss file in the common directory where I work with the fonts of the project and the appearance of text. The elements folder contains such elements as button, popup, form. The components folder contains more complex components, such as responsive header menu, slider, hero section.
You get the idea. A similar approach is used dealing with JS.
In addition to a good file structure and modularity, WP-Starter is also focused on an equally important point when creating a site – optimizing its loading speed.
To do this, the starter template contains all the necessary packages and the gulpfile.js handler file with the necessary tasks.
These tools achieve the following goals.
- Working with styles using the SASS preprocessor.
- Source Maps mechanism for styles.
- Synchronization with browser editing *.scss, *.js, *.php files.
- Writing, converting and building JS with the Webpack tool.
- Images compression (additional option, not performed when building a release).
- Minification, concatenation, adding prefixes for cross-browser compatibility and removing unused style classes.
- JS minification.
Still, one of the most important points for optimizing the loading speed of any site is images optimization. And it’s not just about compression alone. That is why the issue of working with images when creating a theme for CMS WordPress will soon be described in a separate article.
The WordPress community is incredibly large, primarily because of the ability to create websites without programming skills. But these are a low quality websites most of all.
The WP-Starter template is designed for developers with programming skills in order to elevate or perhaps even standardize the approach writing a WordPress project.
That’s all. Share your experience of writing WordPress projects and tips for improving WP-Starter template in the comments.
One response to WP-Starter. WordPress theme starter template.
Helpers.scss. Library for comfortable CSS workflow.
Helpers.scss library adheres to the basic principles of the well-known TailwindCSS library. But on the author's opinion...