SASS/SCSS are discouraging and phasing out support for @import rule in favour of the @use rule.

This makes styling more readable, safer and reduces compile time.

For more detail see '⚠Heads Up!' notice in the documentation here.

Read @use rule docs here.

Changes:

• Updates Node dependencies.
• Makes use of Dart Sass through gulp-sass
• Converts all @import statements into @use or @forward as recommended in the Sass documentation.
• Changes to how styles are organised, introducing an abstracts/ directory and a _components.scss and _blocks.scss to include component styles while keeping component folder structure.
• Component styles no longer compile via concatenation which removes the requirement for a temp.scss to be created. Now they get forwarded from _components.scss.
• Component and block style files are automatically managed on a watch task. As new style files are added, _components.scss and _blocks.scss will be automatically updated.
• Removed unused Node packages.
• Migrated all Gulp tasks to version 4 syntax.
• Gulp tasks are now in a directory to allow task splitting.

No longer required to manage font paths

In previous version of Hozokit there was a dedicated set-font-path mixin to set the correct path for local hosted fonts both on the theme side and the admin side:

/* A prior version of mixins.scss */

// Sets paths for compiling for blocks or front end.
$font-paths: (
    base: 'assets/fonts/',
    admin: '../fonts/'
);

/* Sets font declarations and the paths in which they are declared.
 * This helps setting paths for rendering fonts both on blocks and
 * the front end of the site.
*/
@mixin set-font-path($path: map-get($font-paths, 'base')) {
  @if map-has-key($font-paths, $path) {
    $offside-path: map-get($font-paths, $path) + 'offside/' !global;
    $karla-path: map-get($font-paths, $path) + 'karla/' !global;
  }
}

This meant that changing or adding new fonts required the mixin to be updated. This was slightly simplified:

/* Current version of _fonts.scss */
$font-path: "assets/fonts/" !default;

// Define the paths for your fonts here, one per variable:
$offside-path: $font-path + "offside/";
$karla-path: $font-path + "karla/";

// @font-face rules here...

The font path is now a variable with a default value, meaning it can be changed to a different path for the admin panel:

@use "abstracts" as a with (
  $font-path: "../fonts/"
);

This simplifies the code behind setting up hosted fonts and what needs to be removed as well in cases where Adobe or Google Fonts are used via a URL instead.

Changes in how styles are structured

Sass version was changed to use Dart Sass which required all @import statements to be deprecated and replaced with either @use or @forward, depending on the use case. The @import functionality is being deprecated in future versions of Sass.

In previous version styles and partials would be all directly stored in styles/ and components and block each could have their own style.scss which would then get merged during bundling to create a final style.scss:

.
├── admin.scss
├── base.scss
├── fonts.scss
├── general.scss
├── media_queries.scss
├── mixins.scss
└── palette.scss

In the current version, variables, mixins, fonts and other utilities are now stored in abstracts/. A _components.scss and _blocks.scss was introduced too (more on this below) and the required comment that defines theme metadata has been moved to its own partial to make sure it prints at the top of the stylesheet:

.
├── abstracts
│   ├── _fonts.scss
│   ├── _index.scss
│   ├── _media_queries.scss
│   ├── _mixins.scss
│   ├── _palette.scss
│   └── _variables.scss
├── _blocks.scss
├── _components.scss
├── admin.scss
├── base.scss
├── general.scss
└── theme_meta.scss

This organises files slightly differently but allow for flexibility when access abstracts:

// All abstracts listed in /abstracts/_index.scss:
@use "abstracts" as a;

// Accessing mixins only:
@use "abstracts/mixins" as m;

Component and block list partials

As a result of implementing the @use and @forward syntax, components now are forwarded to a _components.scss and blocks to _blocks.scss, respectively. This allows for the compile task to be simplified and not rely on the concatenation of all components to a _temp.scss:

// Components (this file is self managed by a Gulp task)
@forward "../templates/components/example/style";
@forward "../templates/components/footer/style";
@forward "../templates/components/header/style";

I expect this file to (in most cases) be free from manual edits. As component style.scss are added, renamed and removed the componentForwarding task manages the file automatically. Same for any block specific styles as well.

Hi, cool project!

I'd like to contribute, but the project needs a license file first.

Do you have a license in mind for this project? https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository#choosing-the-right-license

Thanks!

Updates Node version from v13.0.1 tolts/fermium(version14.15.1`). This allows theme developers to use the current LTS version of Node in their projects.

• Updates Node to v14.15.1
• Updates .nvmrc to match current supported version.
• Updates README where the version number is mentioned to keep it consistent and reduce opportunity for error.
• Adds requirements list in order to make it clearer what software is needed to run the project.

• Notes that Hozokit uses a specific version of NodeJS
• Gives example of how to set the Node version using nvm
• Additional instructions for Windows users with a WSL2 setup.

A new release for Hozokit which brings a few changes:

• Introduces Docker container configuration to allow containerized theme development.
• Switches Sass to Dart Sass.
• Introduces the _components.scss and a Gulp tasks which manages it automatically with the aim of improving DX.

• Adds support to spin up a development environment do develop a Hozokit theme with Docker

This brings advantages such as:

• No need to configure or install WordPress, MySQL or Node, this is now all automated.
• npm install and npm run watch are ran automatically.

For anyone using Docker you can try it by changing directory into the theme folder and running docker compose up. If environment variables are changed run docker compose restart. To shutdown the containers run docker compose down.

At the moment the WordPress site can be accessed via localhost:8080 or localhost:2077 if hot reloading is setup.

Bumps y18n from 3.2.1 to 3.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This change adds a GPLv2 license just like Wordpress (addresses #13).

Wordpress feels strongly that plugins and themes are derivative work and thus inherit the GPL license and Hozokit does fall under the category of a theme.

Hope Hozokit helps more and more developers creating themes for Wordpress. 🤍

Resources:

• https://wordpress.org/about/license/
• https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
• https://choosealicense.com/licenses/gpl-2.0/

Adds a further steps section to the README for users following the installation path using the generator. The same steps are displayed in the generator at the end of the install.

Bumps ini from 1.3.5 to 1.3.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Setup: Using Hozokit Generator.

On npm run start the following error occurs at styles.

Error: File not found with singular glob
**AT**
/styles/base.scss

(if this was purposeful, use `allowEmpty` option)

Gulp is looking for this file but doesn't exist from generator.

Note: this is on main and not v2.0.0

When a new component is added or renamed whilst running Hozokit in a Docker container it creates the following issue:

Warning: file_get_contents(/var/www/html/wp-content/themes/hozokit/templates/components/button/index.twig): failed to open stream: No such file or directory in /var/www/html/wp-content/themes/hozokit/vendor/twig/twig/src/Loader/FilesystemLoader.php on line 145 

How to replicate:

1. Run an instance of Hozokit in a Docker container.
2. Render the home page.
3. Add a new component with an index.twig file and some markup. e.g templates/components/button/index.twig
4. Include the component in the templates/index.twig so that it tries to render in the homepage.
5. You should get a failed to open stream warning and the button component won't render.

Need to work this one out eventually but for now docker compose down && docker compose up -d solves it (document compose restart does not do the trick in this case).

templates/components/button/index.twig:

{% block button %}
  <button>Press me!</button>
{% endblock %}

templates/components/button/style.scss:

// Empty but it does exist

templates/index.twig:

{% extends "base.twig" %}

{% block content %}
  <h2>This is index.twig</h2>
  <p>This content block is rendered inside base.twig, which allows the header and footer to be included as well.</p>

  {% include "button/index.twig" %}

  <h3>Posts:</h3>
  <ol>
    {% for post in posts %}
    <li><a href="{{post.link}}">{{post.title}}</a></li>
    {% endfor %}
  </ol>
{% endblock %}