You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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 😩
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.
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.
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.
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):
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" ...
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?
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 🙌
Activity
seothemes commentedon Sep 18, 2022
srcdirectory is not present in this repo. It exists in wp-content above both plugins and themes so that I only need onenode_modulesand 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 commentedon Sep 18, 2022
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 commentedon Sep 18, 2022
As far as I understand we have
How could we reorganize these?
szepeviktor commentedon Sep 18, 2022
https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/
This says blocks should be distributed as a plugin.
seothemes commentedon Sep 18, 2022
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
builddirectories are moved to the separate block plugins.seothemes commentedon Sep 18, 2022
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 commentedon Sep 18, 2022
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 commentedon Sep 18, 2022
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.jsalso 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 commentedon Sep 18, 2022
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 = pluginsource code != pluginszepeviktor commentedon Sep 18, 2022
So we have 3 environments.
... they turn out to be 4
seothemes commentedon Sep 18, 2022
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 commentedon Sep 18, 2022
The reasoning behind my current setup is that I can work in a single
srcdirectory 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.jsAnd here's how it should probably look:
szepeviktor commentedon Sep 18, 2022
If you install WordPress with Composer you could also store all your repos in a single directory, e.g.
/home/$USER/projects/blockifywp/$REPO-NAMEAnd in the development WordPress installation's
composer.json:"type": "path" ...seothemes commentedon Sep 19, 2022
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 commentedon Sep 19, 2022
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 commentedon Sep 19, 2022
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.