Set up block theme

[psrpinto]

• Please review only the final result instead of individual commits as there was a lot of trial and error.
• I would recommend checking out the branch and taking a look at the themes/wporg-translate-events-2024 directory, which contains the new theme.
• The new theme is where the bulk of the changes are, other changes were just to "fake" that theme as the active theme for the current request.

---

This PR introduces a new block theme to be used for translation events, and potentially in the future for the whole of translate.wordpress.org (wporg-translate). For the moment, the theme is contained in this repository, but we can extract it into its own repository later, once/if we decide to use the theme for the rest of wporg-translate.

Before proceeding, please read the new theme's README, which contains valuable information that is useful to review this PR.

Summary of changes

• Document how themes work at translate.wordpress.org
• Remove the templates/new-design directory
• Create a a new block theme under themes/wporg-translate-events-2024
• Add a mechanism to enable the new theme only for specific pages (call $this->use_theme() on the Route of the page)
• Implement the block theme as described in this section of the theme's README

How to review and test

1. Pull translate-w-org-env and run the provision script again (it will take a while, probably). This is to get the changes introduced by:
   • https://github.com/WordPress/translate-w-org-env/pull/7
   • https://github.com/WordPress/translate-w-org-env/pull/8,
2. Make sure the Gutenberg plugin is installed/activated, and if not install/activate it
3. Checkout this branch
4. Set the TRANSLATION_EVENTS_NEW_DESIGN env variable to true
5. Navigate to the "My Events" page
   • You should see the same as the screenshot below
6. Navigate to other pages and make sure they look and function as they did

Screen capture

This is how a page looks when using the theme.

TODO

• [x] https://github.com/WordPress/translate-w-org-env/pull/7
• [x] Fix issue with styles when new design not in use
• [x] Remove add_css() function
• [x] Remove styles from active theme
• [x] Remove wporg-gp-customizations styles and scripts
• [x] Include styles from parent theme
• [x] Remove global-styles-inline-css in favour of the parent theme styles
• [x] Undeprecate header and footer?
• [x] Create a theme
• [x] Load the custom theme
• [x] Implement the basic theme
• [x] Figure out why styles are broken when the theme is not the active theme (it works correctly when it is the active theme)
• [x] Figure out the correct way to use templates/parts/etc
• [x] Remove breadcrumbs block as it's only there as an example block and is not used
• [x] Turn php parts into patterns
• [x] Implement breadcrumbs
• [x] Align navigation to the right
• [x] Fix issue with parent theme style giving a 404
• [x] https://github.com/WordPress/translate-w-org-env/pull/8

[psrpinto]

After quite some effort and digging into WordPress internals of how themes are loaded, I've made some progress here but there are still some things to fix. See the Screen capture section in the PR description.

[akirk]

Fantastic! Looks like we're getting close!

[akirk]

Furthermore we can then replace the filter with just a block attribute: https://github.com/WordPress/wporg-gp-translation-events/commit/8ea412dd23fe7dac67cd7caedf40708e3c70a164

[psrpinto]

Great points @akirk! I'm working on incorporating your suggestions into this PR.

[psrpinto]

@akirk I've incorporated all suggestions you made:

• Make header its own block, which takes the page title as attribute.
• Make footer its own block.
• Minimize the number of do_blocks() calls.
• Remove the page "wrapper" block and make the route call the page-specific block instead.

I also took the liberty of adding a render_header( string $title ) convenience function so that individual pages don't need to do the wp_json_encode() and phpcs ignore dance.

[psrpinto]

I am unsure about your hesitation to just use do_blocks() over the whole PHP output, why is that?

This is something that I should've have explained earlier, apologies. The reason there can't be a single do_blocks() call over the entire page (header, page content, footer) is described as follows.

The header block calls wp_head(), which results in the styles that have been registered being output as <link> tags. Similarly, the footer block calls wp_footer() which will output the <script> tags.

This means that when do_blocks() is called on the header, all styles must have already been registered. Similar for footer and scripts.

So before calling do_blocks() on the header and footer, we must first call do_blocks() on the page content, so that styles and scripts required by the page content are registered.

A similar thing is done on the header block itself, because for example the local-navigation-bar block has its own styles. So we must call do_blocks() on it before the header calls wp_head().

---

There was actually an issue in the code you reviewed, because this behaviour wasn't happening: we were not correctly registering styles and scripts because we were not calling do_blocks() on the page content before the header/footer.

I've now pushed a commit that fixes this.

[psrpinto]

Just to add to what my comment above, the global-header-footer block uses a similar strategy: https://github.com/WordPress/wporg-mu-plugins/blob/trunk/mu-plugins/blocks/global-header-footer/blocks.php#L387-L421