Closed tellyworth closed 2 years ago
Some possibilities for the first part, syncing content during early development, not exhaustive:
I was thinking about something like this for hacky translation support, but it would also help keep the content synced… What if we had a set of PHP files that contain the block content + i18n functions, like this:
<!-- wp:group {"style":{"spacing":{"padding":{"top":"6rem","right":"4rem","bottom":"6rem","left":"4rem"}}},"backgroundColor":"blue-5","textColor":"white","layout":{"inherit":true}} -->
<div
class="wp-block-group has-white-color has-blue-5-background-color has-text-color has-background"
style="padding-top: 6rem; padding-right: 4rem; padding-bottom: 6rem; padding-left: 4rem"
>
<!-- wp:heading {"textAlign":"center","level":1} -->
<h1 class="has-text-align-center"><?php _e( 'Meet WordPress', 'wporg' ); ?></h1>
<!-- /wp:heading -->
<!-- wp:paragraph {"align":"center","fontSize":"extra-large"} -->
<p class="has-text-align-center has-extra-large-font-size">
<?php _e( 'WordPress is open source software you can use to create a beautiful website, blog, or app.', 'wporg' ); ?>
</p>
<!-- /wp:paragraph -->
</div>
<!-- /wp:group -->
Could we use something like the filter approach used in pattern translations to swap the post content for our PHP content?
It's pretty much what's done in the theme now, but as block content instead of plain HTML.
But IMO a big win with a block theme is being able to edit in WP, so maybe we could look at it the other way — sync down from a staging site? You can get block content via the API with the edit context. We'd need a single site that's the "source of truth" though.
We could use php files or similar for initial work if that'll accelerate things. But yeah it'd need to be temporary since we want things editable in WP before launch. Maybe starting with it in post content is the right approach. For some things using patterns could help, since they can be registered from text.
I have a PR mostly done for Learn that might fill in a gap here: https://github.com/WordPress/Learn/pull/249
It adds a new export
context on the staging site and then uses the REST API to fetch block content for local testing. It needs a little work but is basically functional, so let me wrap that up and I'll move it to the parent theme repo.
We also need to define exactly what we mean by "staging site" here. We could create a test site at w.org/main-test
or similar and use that for testing and as the Source Of Truth for content. That does mean we'll need to copy that content across to the live w.org
site before launch, but we had the same process for the news blog and it worked ok.
Alternatively, if we trust the theme switch code enough we could consider using the w.org
front page site as our "staging" site, and make sure only special accounts can see the block theme. That eliminates the need to copy content from staging at launch. It would mean though that we'd need some way to separate content for the new design from existing classic theme content though, and it's probably unnecessarily risky. Maybe it's worth considering at a late stage, just prior to launch.
I've set up a staging site at https://wordpress.org/main-test/, added the theme to svn and set up a sync script.
That Learn PR is just about ready to use here, will add a copy to this repo next as a plugin.
I made a PR here to add the server-side part to mu-plugins. That'll make it available in any sites that need it.
https://github.com/WordPress/wporg-mu-plugins/pull/227
Will add a second PR for the import script in the new theme.
@tellyworth Anything else need to be done here, or can we close this issue?
Let's close this one, we can open a new issue if related stuff comes up.
A key assumption for this project is that some of the design will be implemented in WordPress content, rather than in code (like Kelly's front-page-in-the-editor experiment).
We'll need a way to sync and share this kind of content in several ways:
This issue is for discussing sync methods and workflow.