Workflow for building a block-based WordCamp site

[ryelle]

In the past, the WordCamp US web team has used a GitHub process plus local environments to track and review changes before deploying out to the site (via remote-css). That allows multiple people to work on the site, roll back any changes that break things, and the site is not changed until the updates are complete.

While we can still use remote-css with block themes, the real power comes from the Site Editor— but there's no good way to sync the changes in the site editor with a local or staging environment. We can export the updated theme from production, but there's no automated way to push local changes back up. So if a new template is created, or global styles are customized, that needs to be done again, manually.

I don't have a proposal here, but I would like to kick off a discussion on how we could make this process a little easier, and see if others are running into issues too.

[miminari]

Thanks for the great Issue.

I think we should improve on the lack of dev sites on the WordCamp site regardless of using block themes in the first place. It's a bit scary to be able to push the current output files to production directly because it would include the content as well as the styles.

But, at the first, what about the idea of allowing each site the right to edit only theme.json? I feel that if it's only theme.json, it's no different than allowing changes related to style, so it wouldn't be that difficult, but I'm not sure if I'm being too optimistic.

[ryelle]

But, at the first, what about the idea of allowing each site the right to edit only theme.json?

If you're using a block theme, you should be able to make a lot of those changes in the Site Editor. What would you like yo do with theme.json that you can't do right now?

[miminari]

@ryelle Thank you for your reply. At first, there are a few features that can only be changed in theme.json because the GUI(Site Editor) is not yet ready, right?

Even if Site Editor is already in perfect condition, I think what we are discussing here is about the workflow, so what I am saying is that pushing all updates obtained from Site Editor changes involves content, so I would like to add a function to override only theme.json, which can be separated into styles. I think that if it is only added, it will dramatically increase the expressive power of wordcamp.org.

[miminari]

@ryelle Hi! I was wondering I will try this issue at WordCamp Asia 2024 Contributor Day (March 7). Do you have any concerns about this? I'm thinking of adding a plugin that allows custom theme.json to be read.

[ryelle]

I'm thinking of adding a plugin that allows custom theme.json to be read.

I think that would be helpful :)

I recommend focusing on making something simple, a proof of concept, so you can get feedback on the idea. Tag me on the PR if you get something built!

[renintw]

On the WCAsia contributor day, @miminari brought up this ticket and we worked together to clarify the requirements and came up with a feasible POC idea.

The main requirement is to have the ability to export the theme.json from a WordCamp site, modify it, and then push it back to the site. This would allow changes to the default settings or options in the block editor's sidebar tools.

The aim is to ensure that each WordCamp site maintains a consistent and coherent style as required by the specific design of the event, enabling precise control over the website's appearance.

The POC idea:

1. Exporting theme.json from the site.
2. Editing it locally.
3. Pushing it to GitHub.
4. Synchronizing it back to the site using a plugin.

We discussed the possibility of executing this logic through RemoteCSS, but @miminari suggested creating a dedicated plugin for this purpose, to keep it more focused and simple.

What do you think, @ryelle?

Additionally, @miminari mentioned that we could potentially just change the theme.json in a way similar to using 'Additional CSS', which would eliminate the need for exporting and syncing steps. The drawback of this approach would be the inability to track update logs unless they are recorded manually, though.