Valera Vilks

Blog

  • Today I released Celestial version 1.0.0.

    https://github.com/valeravilks/celestial/releases/tag/1.0.0

    It finally works the way I wanted, and I’ve pretty much nailed down the architecture. I can release version 1.0.0 and then fix some of the remaining bugs.

    As a result, I came to the conclusion that I need to make it as thin as possible using official WordPress packages. Fewer dependencies, less support, more transparency. Essentially, it’s a customized @wordpress/scripts and @wordpress/env with a specific structure that I found to be the most effective. Plus, there’s composer, linters for styles and JavaScript, and a code sniffer.

    I previously considered collecting my best practices and examples in this repo, but I decided against it. I think the advantage is transparency and the lack of unnecessary clutter. You can now create your own blocks or write a theme using the exact methodology you want.

  • Before the release of Celestal 1.0

    Yesterday, I realized I’m at the point where I’m ready to release Celestal 1.0 (WordPress Starterkit). It looks clean, there’s virtually no unnecessary code, and all the official WordPress development tools are carefully used. These are:

    • @wordpress/env
    • @wordpress/scripts

    A minor tweak with the npm-run-all package to enable watch mode for several commands.

    Now I see that development of a block, theme, and PHP code can all happen in a single repo, additional linters have been added, and build paths have been configured. Further updates are also planned, but they shouldn’t break the project or the current build.

    Next, development, bug fixes, and documentation.

  • Celestial Release 0.8.0

    https://github.com/valeravilks/celestial/releases/tag/0.8.0

    I managed to work on it this weekend, but I’m only releasing it now.

    I’ve reconsidered my stance on linters for the project. I’ve decided to add linters for PHP, JS, and styles. I’m using the default PHP linter, Code Sniffer, for WordPress with rules other than folder names, as I want the folder structure to be simpler for composer.

    I also rebuilt the core plugin. It now includes blocks and editor scripts as well. I thought this would make it easier to understand and also reduce the size of package.json in the scripts.

    There were also some changes in terms of architecture. Previously, I wanted to compile best practices within Celestial. But I changed my mind. I think it needs to be more refined. Fewer layers and files = easier to understand. Celestial is a project launcher on official WordPress tools. But the content and how you want to use it are up to you. You choose your own naming methodology and use of design tokens.

    I wanted it to be upgradable. For example, if there’s version 1.0, you could upgrade to 2.0 without any problems. I think this is important for long-term support.

  • Celestial Release 0.7.0

    I managed to find some time and push my StarterKit for WordPress forward. I released version 0.7.0. https://github.com/valeravilks/celestial/releases/tag/0.7.0

    It actually seems counterintuitive. In the age of AI generation and new tools that generate thousands of lines of code per minute, I build something on WordPress, study the documentation, and release it. And this isn’t just a learning project.

    In Celestial, I improved the project structure, dividing everything into four areas:

    • FSE theme
    • Core plugin
    • Editor plugin
    • Blocks plugin

    Each part covers everything needed for a WordPress site and does so as closely as possible to the official documentation. This separation also helps make the project more modular. For example, you can simply copy block files from another project, and it will work, since the blocks plugin is the official @wordpress/create-block plugin. There’s no need to explain anything about the FSE theme, since everything is structured according to the WordPress documentation. There’s almost nothing custom, and I see that as an advantage.

    Also, when I was writing the documentation, I knew the AI ​​could follow it. My recent experience with OpenCode shows that it doesn’t do a bad job of following the principles in the documentation, as long as they’re clearly described and the architecture is unambiguous.

    The next goal here is to improve the documentation, especially for the AI ​​and developers, so they understand and are clear on how and what to do in this repository. So that the entire architecture is clear without me having to bother.

  • Basic repository protection in BitBucket

    One of the basic but critical tasks in any project is protecting the repository. Depending on the project, this can become quite complex, especially when CI/CD pipelines are involved.

    Here I want to show a simple and effective approach that can significantly reduce risks and help prevent accidental or dangerous changes.

    The core idea is straightforward: protect the main (or master) branch. Any changes to this branch should only be possible via pull requests.

    (more…)

  • I came up with the post format for myself.

    It’s difficult to start writing. I’ve seen many blogs that started great. Lots of posts, structure, thoughtful content. But it quickly ended. The author couldn’t keep it up for long. I’m probably on my 6th or 7th attempt myself. I have the desire, and even the opportunity, but I stop doing it.

    I’ve thought about this a lot. Why is that? Why can’t I, a WordPress website developer, whose platform is designed for blogging, maintain my own blog? I have ideas and experience in web development. A blog seems like a great extension of my work, a way to preserve information. It’s also an opportunity to share personal thoughts or approaches with colleagues and the world. Theoretically, it’s also a way to showcase my expertise to potential clients. All advantages. But why don’t I do it?

    After much reflection, I understood. I have a kind of perfectionism. I think too much about each article or post. I consider it perfect and unchangeable. I don’t allow myself to make mistakes. I don’t allow myself to do something simple and obvious to me. It seems like everything has already been written and there’s no point in doing it. I don’t want to look like someone who tries for the eighth time, thinks everything will work out, and then gives up. It looks like weakness.

    Having made this conclusion, I realized that I need a different strategy here. It’s about writing simpler, faster, not being afraid of mistakes, and simply generating content from my current life. Learned something in Azure? Show it. Found an approach that seems great in theme.json? Write a post about it. It can be short, or unstructured. Or even wrong, and then you’ll change your mind and won’t think that way anymore. But that’s the only way it’s possible. Let companies with managers and resources handle polishing articles. I don’t have time to write something for a long time. It seems any reasonable busy person understands this.

    So I started with this explanation, probably to myself first and foremost. I hope I continue.

  • Using Strings Instead of Variables in WordPress Functions

    The official WordPress documentation recommends registering CPTs this way

    register_post_type( 'book', $args );

    This works fine. But sometimes we want to register it via a variable. For example, to do it in a class. Here is an example

    
class Book_Post_Type {
	private string $type = 'book';

	public function __construct() {
		add_action( 'init', [ $this, 'register' ] );
	}

	public function register(): void {
		register_post_type( $this->type /* , $args */ );
	}
}

    This all works as well. Thinking about extending this class, it looks good. We can use $this->type here and not duplicate this variable.

    From an OOP perspective, this is not bad, and looks like a best practice, but it seems to me that from a WordPress perspective, this is not so.

    Why is that? When we do not use the string directly, it will be much more difficult to find everything related to this CPT and where it is used. From a long-term observation point of view, it looks like doing a search on the project, you can find all functions related to this CPT.