What am I doing wrong?

[szepeviktor]

npm ci
npm run build

then all files in build/ get deleted.

@seothemes Please help me.

[seothemes]

src directory is not present in this repo. It exists in wp-content above both plugins and themes so that I only need one node_modules and webpack setup to build all blocks and themes.

Let me push an update with the latest changes - I've removed all of the blocks and added the theme framework.

[szepeviktor]

Oh nooooooooooo!
So one is not able to develop in this repo nor CI is able to generate a build 😢

I thought repositories are self-sufficient.

[szepeviktor]

As far as I understand we have

• a "Lightweight block toolkit"
• the theme
• and blocks

How could we reorganize these?

[szepeviktor]

https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/
This says blocks should be distributed as a plugin.

[seothemes]

Not yet, but we should be able to move everything into this plugin and treat it as the source. I think blocks would have to be split locally though.

Yes, that's correct, here's the structure (open to better ideas):

Plugin (also theme framework)

This is the main Blockify plugin. It contains all of the theme functionality originally in the Blockify theme. It can also be installed in themes as a Composer package. This includes block extensions and additional functionality required by themes.

Themes

Themes require the framework as a Composer package (which is just the plugin). Please see Startify theme.

I'm considering delisting the original Blockify theme and then submitting startify instead. Maybe that's not necessary.

I plan to release a ton of themes once this is all in place, hence the need for a framework.

Blocks

All blocks have been separated into different plugins. I need to submit them to wordpress.org before removing them from the main plugin.

The build process for blocks uses the same webpack setup as the framework. The build directories are moved to the separate block plugins.

[seothemes]

Hope that makes sense. The blocks were removed here 7247ed1. They all have separate repositories now.

Ideally there would be no need for a framework, and the plugin would just be installed. However because of WordPress.org theme previews, the functionality is still needed in the theme itself to display correctly.

I've been going around in circles for months trying to find the best structure and to avoid duplicated code across products 😩

[szepeviktor]

I would call the plugin: Blockify Framework - containing only PHP code. No blocks, no UI.

One totally empty theme called Blockify to facilitate FSE. "the editor"

One block per plugin. But only source code, no built code. CI workflows should build actual WordPress plugins and uploads to WP Plugin Repository. Separation of development and production.

Of course there could be bundles for easy installation.

What do you think?

[seothemes]

Would much prefer to do it that way, but the .org theme previews won’t work then 😕

Themes submitted to WP need to include the shared CSS and PHP includes, otherwise the preview is messed up. editor.js also needs to be included in the theme because some of the blocks will be broken in the editor when a user opens it (image icons for example).

Let’s forget about the plugin, that can be a future thing. I’ll create a separate repo for the framework to make things less confusing. That reduces it to a single purpose. It can include the src and be built with the CI workflow.

Themes can then pull the composer package into vendor on build. Hopefully that is possible?

For the blocks, I will add the src to the repos, and remove build. It should be fine locally, I think they can all still share the same node_modules.

[szepeviktor]

I'd like to repeat it. The above idea is for GitHub only.
Then a CI workflow could mix and match any way you want!

I think it is quiet important to think of Gitub repos as a place of development and .org theme repo as a totally different thing.

source code + build process = plugin
source code != plugin

[szepeviktor]

So we have 3 environments.

1. GitHub repos with source code only
2. Development environment on your local machine
3. Production environment on WP.org (which will get copied - called plugin installation - to the user's WP installation)
4. CI environment

... they turn out to be 4

[seothemes]

Ah gotcha, sorry I am new to the CI stuff. Have been doing everything locally up until now. The GH repos weren’t really being used. They were just for issue tracking and I had planned to set up automatic deployment to .org from them.

Not sure I understand how it would work locally - at the moment I'm mirroring the plugin in the theme with composer https://github.com/blockifywp/startify/blob/main/composer.json#L28

That would need to be removed from composer.json in order to have it work with a CI workflow right?

[seothemes]

The reasoning behind my current setup is that I can work in a single src directory locally which is split up with webpack into the correct locations. Since all themes and blocks share a majority of the code it didn't make sense to have separate build process for each. But, if there are better ways I'm definitely open to learning!

Here's what it looks like at the moment (I'm not set on this at all):

.
└── wp-content/
    ├── node_modules/
    ├── plugins/
    │   ├── blockify
    │   ├── blockify-accordion
    │   ├── blockify-icon
    │   ├── blockify-tabs
    │   └── ...
    ├── src/
    │   ├── blocks
    │   ├── components
    │   ├── extensions
    │   ├── formats
    │   ├── options
    │   └── ...
    ├── tests/
    │   ├── php
    │   └── js
    ├── themes/
    │   ├── startify
    │   ├── bizify
    │   └── ...
    └── webpack.config.js

And here's how it should probably look:

.
└── wp-content/
    ├── node_modules/
    ├── plugins/
    │   ├── blockify/
    │   │   ├── includes/
    │   │   │   ├── utility.php
    │   │   │   └── ...
    │   │   ├── src/
    │   │   │   ├── components/
    │   │   │   ├── extensions/
    │   │   │   ├── scss/
    │   │   │   └── ...
    │   │   ├── tests/
    │   │   │   ├── php/
    │   │   │   └── js/
    │   │   └── webpack.config.js
    │   ├── blockify-accordion/
    │   │   ├── src/
    │   │   ├── tests/
    │   │   └── webpack.config.js
    │   ├── blockify-icon/
    │   │   ├── src/
    │   │   ├── tests/
    │   │   └── webpack.config.js
    │   └── ...
    └── themes/
        └── startify/
            ├── vendor/ # Ignored by git.
            │   └── blockify/
            │       └── plugin/
            ├── functions.php
            └── style.css

[szepeviktor]

I can work in a single src directory locally

If you install WordPress with Composer you could also store all your repos in a single directory, e.g. /home/$USER/projects/blockifywp/$REPO-NAME
And in the development WordPress installation's composer.json: "type": "path" ...

[seothemes]

Ok, looks like I have some work to do. It will take me some time to set up but looking forward to having this in place. Thank you for this advice, much better way of doing things.

Originally I wanted to further separate packages, e.g blockify/utility, blockify/dark-mode etc. I believe this will be easier to achieve now.

With this approach, would the framework still need to be mirrored into each themes vendor directory locally for theme file paths to work correctly?

[seothemes]

After putting some more thought into this, and chatting to the theme review team, I think it would be best to leave both the plugin and framework idea for now. Seems way too difficult to setup and maintain as one person.

It will be a whole lot easier to use child themes to separate designs, instead of multiple parent themes sharing a framework. That way it's just the single Blockify parent theme (with source code) + multiple empty child themes (no code).

This aligns more closely with your recommendation of having a single theme, and allows for the CI workflows that you have put into place. Much cleaner and simpler 🙌

[szepeviktor]

the theme review team,

That team is pro-WordPress thus pro-PHP4 🦕

It is very easy to keep different source codes in different repositories and merge them into anything you want.