Create Props Block for Make Blogs and Deverloper Blog

[bph]

Most Make Blogs and the Developer blog have a review policy. Many times the author also credits reviewers and other creators in a "Props" section at the end of the blog post.

It would be fabulous of Custom Block, called "Props Block" could be created that would add the props to the respective contributors Activity list on their wp.org profile.

Here are a few examples from posts.

[bph]

Props from GB release post

[bph]

Props from Developer Blog (What's new for developers roundup)

[bph]

Props from a 6.2 Dev Notes post

[dd32]

If someone wants to give creating a patch a try (It seems like a pretty simple block!) you can make a PR against ​https://github.com/WordPress/wporg-mu-plugins/ adding a block to the blocks plugin. That contains a wp-env which you should be able to build & test within.

To record props against an account, WordPressdotorg\Profiles\add_activity( ... ) can be used - see ​https://github.com/WordPress/wordpress.org/blob/trunk/wordpress.org/public_html/wp-content/mu-plugins/pub/profile-helpers.php (Don't fret about the values you set, a meta-dev will need to refine the handling of it).

I would suggest

• Extends the Paragraph block
• Upon publish/edit-after-publish the @mentions within the block get add_activity() called.
• The message can probably be something as simple as Received props in <link>, or just the content of the block.

[kaitohm]

Following, as this would be something useful on ​https://learn.wordpress.org/, too, to credit reviewers/translators.

[gaambo]

Hi,
I'm interested in giving this a go, but have some questions:

1. How are props linked at the moment? Are links added to the usernames manually or somehow automatically - and if automatically on rendering or on saving?
2. "Extends the Paragraph block" - So at the moment is this just a normal paragraph block? That means that usernames and their roles are just written as text and usernames would have to be parsed out of the text (probably by a regex)
3. If we extend the paragraph block, we would probably just add a toggle to the paragraph block to enable "props syncing" or something like that.
4. I'd actually think a custom block "Props" which uses the RichText component and opts into some block supports (colors, typography,...) would be clearer and not polute the paragraph block (which is used a lot in the posts). But you as the editors using that probably have a better understanding of that.
5. I'm thinking about where to call the add_activity function. A server-side callback on save_post would be one option. This would be another case where a custom block is easier, because we'd just have to check if this custom block exists in the post. If a paragraph block is used we'd have to loop through all the paragraph blocks and check if it has the "props sync" attribute enabled. Another option would be to call a custom REST API endpoint when the block editor publishes the post. But that means it only works on edits through the block editor - I don't know if there are any edits that could happen via REST API or the WordPress mobile app? If yes, we'd need the save_post hook as well.
6. We'd somehow need to save the props that we already sent as activity to .org, so when someone updates the post - and maybe adds new props or deletes some, we can compare them and only sync those. Probably the easiest way would be to store the props that were already handled in a postmeta field.

[dd32]

Replying to gaambo:

1. How are props linked at the moment? Are links added to the usernames manually or somehow automatically - and if automatically on rendering or on saving?

We currently use @mention format which is parsed by o2 on save, and rendered on display.

2. "Extends the Paragraph block" - So at the moment is this just a normal paragraph block? That means that usernames and their roles are just written as text and usernames would have to be parsed out of the text (probably by a regex)

The notion was that it doesn't need anything fancy, just a way for a new block (likely using the Paragraph block as it's base type) that upon being used would mark @mentions within to be triggered as props.
Not that it'd be an option added to all existing paragraph blocks.

5. I'm thinking about where to call the add_activity function. A server-side callback on save_post would be one option.

This is likely the only scenario which could realistically work, it would need to delay processing until post_status = publish, and then figure out any new names added after publish.

Another option would be to call a custom REST API endpoint when the block editor publishes the post.

Doing it client-side is likely too fragile, as it would need to validate usernames and call the PHP functions which wouldn't be exposed publicly.

6. We'd somehow need to save the props that we already sent as activity to .org, so when someone updates the post - and maybe adds new props or deletes some, we can compare them and only sync those. Probably the easiest way would be to store the props that were already handled in a postmeta field.

Correct.

Adds a "props" block as mentioned in #6945.

## How

• Adds a new block wporg/props which is based on the core paragraph block (and similar to the notice block already existing in this repo).
• Block supports are copied from the core paragraph as of Gutenberg version 15.1 which includes text align, colors, typograph and spacing controls
• On save_post it checks for existance of this block (also supports nested blocks) and parses all mentions in this props block.
• The props are then sent to WordPress.org via WordPressdotorg\Profiles\add_activity.
• Synced props are stored as post meta and on updating a post they are compared and only new props are synced.
• It supports multiple props blocks in a post and also props blocks nested in others (like groups).
• It supports all post types atm.

## Questions:

• [ ] How can I test the add_activity call? Is there a test instance or a local instance I can get when running via wp-env?
• [ ] Which values does the type parameter of add_activity allow?
• [ ] I'm assuming existing Make blogs use bbPress and therefore bbp_find_mentions to parse mentions. I'm reusing this function and provide a fallback if this is not available. If bbPress and this function will always be available, we can remove the fallback.
• [ ] It does not handle removing props (because I don't know if there's a remove_activity function?
• [ ] I'm using the generic save_post hook here but if we only want to support the post post type, I can switch that to save_post_post.

## How to test:

1. Checkout this PR and run npm start + npm run wp-env start
2. Create a new post
3. Check the "Props" block is available in the inserter
4. Enter some text in the block like "Props to @xy"
5. You can add multiple props blocks and also nest them in others (like a group)
6. Save the post
7. ‼️ Atm this will trigger an error because on local environments WordPressdotorg\Profiles\add_activity does not exist
8. You can comment out this code, click update again and check that the meta field _wporg_props does exist and has the correct values in it

## Screenshots:

I've used npm run lint:js locally but don't get the error messages that the CI shows me.
Also I didn't commit my package-lock.json but classnames is in package.json so the CI build should get that?

[gaambo]

I've created a draft pull request on GitHub. There's still some questions left and I can't test the API call. But the block is there and the logic to save/update props works.
CI linting still throws some errors which I don't get when linting locally.

[gaambo]

Can I do anything to move this forward or can anyone help me with the open questions (see the PR) and the linting errors?

[bph]

Huge Thank you to @gaambo to take this on!

@dd32 @dufresnesteven What would be necessary to get this to the next step?

Would a trial implementation on the Developer Blog possible and we would report back?

Or what would be a good way to test this?

This PR is closed. Is that correct? I'm under the impression that it should still be open.

This PR is closed. Is that correct? I'm under the impression that it should still be open.

I didn't get any feedback or information if that block is still needed, or if I took the right direction. Also since the last commit the block API has changed and probably a few changes to the block should be made to work perfectly with the newest core versions. Since I had no time (and currently have no time) to work on this, I closed it.
Feel free to take it as-is and build on top of it.

👍 Okay. I've added this to my list of things :)

[bph]

Thank you for pushing it this far @gaambo :-)

@dufresnesteven let me know if I can help testing things.