Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proper server-side APIs for block modification #6494

Open
braders opened this issue Apr 30, 2018 · 10 comments
Open

Proper server-side APIs for block modification #6494

braders opened this issue Apr 30, 2018 · 10 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Enhancement A suggestion for improvement.

Comments

@braders
Copy link

braders commented Apr 30, 2018

I can see various PHP functions for parsing blocks out of the post_content (gutenberg_parse_blocks, do_blocks), but it appears not to be possible to modify these blocks server-side and insert an updated serialised content back into the database. There feels like a significant need for this, in order to support more complex use-cases.

Use Cases

  1. As a WordPress developer, I am often asked to migrate content out of legacy databases into WordPress. Usually, I migrate to ACF flexible-content and it is not unusual to be inserting several rows/ blocks of content. As block-based editors become more wide-spread it is likely that migrating between different block-based systems will become more common.

  2. In Block migration on larger sites?  #5615 the question of how to update the markup for a block across all posts was raised. If a server-side API was available it would be able to loop through all posts and modify all instances of a single block. This could be a one-time migration script either run on plugin activation or via WP-CLI (depending on the context of the plugin and site).

  3. There is occasionally a need to allow post_content to be edited from the front-end by non-administrative users - For example, on certain types of membership sites. This is also supported by some form plugins. There is likely to be a desire to insert this content in a block-based fashion.

Ideal solution

I would love to see a proper object-based representation of the blocks, which would properly represent the inner-content, attributes and comments, with methods for updating and inserting blocks. It would be amazing if this object could be passed directly back to wp_update_post as the post_content arg, and serialised from there.

@jasonbahl
Copy link

Related to #2751

@danielbachhuber danielbachhuber added [Feature] Blocks Overall functionality of blocks [Feature] Extensibility The ability to extend blocks or the editing experience labels May 11, 2018
@gziolo gziolo added this to the Future milestone May 14, 2018
@schlessera
Copy link
Member

schlessera commented May 15, 2018

I really like the idea of having a real object model of the blocks and making wp_update_post() understand this model, and would love to work on making that happen.

Blocks should be represented by the "Composite" pattern, to represent a tree that allows for easy traversal and modification, but can still be treated as a whole. So a call to the root object's render_html() would just recursively iterate over all its children's render_html() methods.

I'll work on creating a first PR to show how such an object model could work.

@schlessera
Copy link
Member

schlessera commented May 15, 2018

I finished a first implementation that basically does the following:

$factory    = new WP_Block_Factory();
$post       = get_post( $post_id );
$block_tree = $factory->create_from_html( $post->post_content );

// $output will be equal to $post->post_content.
$output     = $block_tree->render_html();

The object tree is built up of composite objects and leaf objects.

image 2018-05-15 at 11 50 52 am

However, it seems that the data model that Gutenberg uses does not construct a tree out of composite objects and leaf objects (which is a standard pattern for such a use case), but rather adds an innerBlocks array to every single block (which is empty most of the times), turning every single block into both a leaf block and a composite block.

Is that the finalized data model design, or is this still up for discussion?

I can easily change the code to adapt to this data model instead, but I'd like to get confirmation first, as it seems this might have been a temporary work-around only.

@rchipka
Copy link

rchipka commented May 15, 2018

I implemented a concept for PHP block template partials, which are limited to updating or replacing the block string content.

Having access to the block model from within a template partial would be extremely powerful for server-side block rendering.

@braders
Copy link
Author

braders commented May 17, 2018

@schlessera That looks like a good start, and fairly close to what I had in mind. I'm less familiar with the composite/ leaf concept, so I'm not sure how well this works with the Gutenberg data structure.

I can imagine a few more helper functions for inserting blocks might be useful (e.g. insert_at_position, replace_with) but your suggested approach seems to leave a solid base which can later be extended.

@braders
Copy link
Author

braders commented Jun 25, 2018

@schlessera you mentioned you had an initial implementation working? In the absence of any feedback from the Gutenberg team I wonder if a pull-request would provide something to review in order to get this discussion moving again?

@mtias mtias mentioned this issue Aug 1, 2018
16 tasks
@pento pento modified the milestones: Future, WordPress 5.0 Aug 26, 2018
@danielbachhuber
Copy link
Member

Related #11523

@pablinos
Copy link
Member

@schlessera I'd love to learn more about your implementation here. As I understand it, the serialisation of most blocks is handled on the JS side. We're considering how to manipulate post_content containing blocks as it's being imported. At this point, things like IDs of images can change which need to be updated.

How is your render_html method implemented? Does it assume that all blocks have a server-side render function?

@paaljoachim
Copy link
Contributor

Can we get a status update?
I see there are various closed PRs and issues. Can we go ahead and also close this issue?

@braders
Copy link
Author

braders commented Jan 22, 2021

I don't believe development ever got underway on this, although I would still love to see it happen. If there is an equivalent issue/ PR somewhere it would be great to post a link - I may have just missed it.

@gziolo gziolo mentioned this issue Feb 13, 2023
68 tasks
@gziolo gziolo added the [Feature] Block API API that allows to express the block paradigm. label Feb 13, 2023
@jordesign jordesign added the [Type] Enhancement A suggestion for improvement. label Aug 1, 2023
@talldan talldan removed this from the WordPress 5.x milestone Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks [Feature] Extensibility The ability to extend blocks or the editing experience [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests