khawkins98
commented
4 years ago I could see us eventually getting to No. 3 (PHP templates) but it's probably not going to happen soonish given all the other things to be done.
If we go with No. 4 for now (the only realistic option?) there are few reassurance thoughts:
- Most of the elements/blocks shouldn't have too many more class changes (we should probably start making some v1.0.0 releases)
- When a site does update components between major releases, perhaps we could add a command line or WP admin script to "rebuild" each post?
dbushell
Parts of a theme that exist as PHP templates – e.g. the
vf-masthead– can adapt to customisation changes because the PHP is rendered on every page load.There is a problem with Gutenberg blocks that are rendered with Nunjucks templates.
Say we add a
vf-factoidblock to a page within the Gutenberg editor. Thefactoid.njktemplate is rendered as the page/post is edited. HTML is saved to the post content. When that post is visited the pre-rendered HTML is outputted.If the theme is later customised and
vf-factoidblocks require different markup (e.g. a new modifier class), we cannot update those within post content. Only when each post is edited again will they be rendered with the new template.This is because Nunjucks is a JavaScript library and it runs client-side in the browser.
Possible solutions
❌ Find a way to run Nunjucks server-side. This is not practical without a PHP library (which doesn't exist). Running Node on the server is a big ask. Also keeping track of which post content contains out-dated templates is not trivial. Then updating all posts after each customisation change would be an expensive operation.
🤮 Update posts client-side. This would require a lot of AJAX in the WordPress admin. We cannot guarantee the process will complete, and all the same problems as above.
🤔 Do not use Nunjucks and do not save rendered HTML to the post content (only the block attributes). Instead use PHP templates to render server-side on each page load. This would require a PHP version of the component
.njktemplates – invf-coreorvf-wp– either way adding to the maintenance.🤷 Ignore the issue. Assume customisation will be done once when the theme is set up and therefore changes are unlikely. Posts will require a manual edit/save to update.
Thoughts
1 and 2 are non-starters. 3 would be easy to implement (in the theme at least). I'm leaning towards 4 for now until we know just how often the issue might occur.
There may also be some blocks where the style variant is chosen independent of any global theme customisation. We need to account for this use case too.