Add WordPress Area CPT #15014

jorgefilipecosta · 2019-04-17T11:14:22Z

Description

This PR is straight to the point and just proposes an implementation for the wp_area CPT required to implement the widgets RFC described in https://github.com/WordPress/gutenberg/blob/add/blocks-in-widget-areas-rfc/docs/rfcs/blocks-in-widget-areas.md

How has this been tested?

I verified the CPT works as expected by going to /edit.php?post_type=wp_area (this probably should be disabled but it is useful for testing).
I verified I can use the rest API with this CPT e.g:

wp.apiFetch({
    path: '/wp/v2/block-areas',
    method: 'GET',
}).then(console.log);

youknowriad · 2019-04-17T11:25:22Z

lib/widgets.php

+		'wp_area',
+		array(
+			'labels'                => array(
+				'name'                     => _x( 'WordPress Area', 'post type general name' ),


Block Area is probably a better name like suggested by @mapk

youknowriad · 2019-04-17T11:26:05Z

lib/widgets.php

+			'public'                => false,
+			'show_ui'               => true,
+			'show_in_menu'          => false,
+			'show_in_rest'          => true,


Are we following-up with the REST endpoints PR? we might want to disable the built-in ones if it's the case?

My plan was to leave the built-in ones. The REST endpoints that we are following up are specific to widget areas, and they receive as the identifier a widget area name. What if I want to change wp_area by its id (numeric)? What if I want to do other actions (list all areas widget/navigations..., search areas or use other nice features from the posts endpoint)?
It seemed to allow direct access to the wp_areas endpoint did have big cons and had some advantages.
The new endpoint may end up referencing the same thing but it references using a different identifier, and the new endpoint is widget specific (returning widget specific information besides the post itself being referenced)

youknowriad · 2019-04-17T11:26:17Z

lib/widgets.php

+				'item_updated'             => __( 'WordPress area updated.' ),
+			),
+			'public'                => false,
+			'show_ui'               => true,


This should probably be false?

Yes, show_ui should be false, it is true to make testing easier.

aduth · 2019-04-29T19:49:05Z

lib/widgets.php

 add_filter( 'block_editor_settings', 'gutenberg_legacy_widget_settings' );
+
+
+function create_wp_area_post_type() {


Should it be prefixed with gutenberg_ ? I'd suggest it, unless the plan is for this function to be ported upstream directly, which I don't think is how it would be adopted.

Prior art: https://github.com/WordPress/wordpress-develop/blob/23867a2d7748d911d36107d39a6ea36dc834f763/src/wp-includes/post.php#L13-L432

lib/widgets.php

aduth · 2019-04-29T19:49:13Z

lib/widgets.php

 add_filter( 'block_editor_settings', 'gutenberg_legacy_widget_settings' );
+
+
+function create_wp_area_post_type() {


Missing PHPDoc?

jorgefilipecosta · 2019-04-30T10:09:19Z

Hi @aduth, thank you for the review, your comments were addressed.

youknowriad · 2019-05-07T11:39:13Z

Do you think we can start landing some of these widgets related PRs to move forward?

jorgefilipecosta · 2019-05-07T15:15:04Z

Do you think we can start landing some of these widgets related PRs to move forward?

Hi @youknowriad, yes I think widget related PR's should be merged allowing us to have a prototype and try different approaches if we find problems.

aduth · 2019-05-07T15:23:05Z

lib/widgets.php

+			'public'       => false,
+			'show_ui'      => false,
+			'show_in_menu' => false,
+			'show_in_rest' => true,


Should we assign a rest_base ? The post type wp_block was defined with rest_base of 'blocks' (source), following the general pattern of exposing on the plural form of the base name "block".

Suggested change

'show_in_rest' => true,

'show_in_rest' => true,

'rest_base' => 'areas',

Alternatively, the original RFC proposed the base 'widget-areas':

https://github.com/WordPress/gutenberg/blob/add/blocks-in-widget-areas-rfc/docs/rfcs/blocks-in-widget-areas.md#rest-api

Perhaps 'block-areas' if that's the desired naming, per prior review comments in this pull request.

Good point, I updated the rest_base to 'block-areas'.

I'd also wonder if it's worth considering to include in an experimental namespace, like at #15015

In CPT's adding a namespace does not work. I used __experimental/block-areas as the rest base which works well but is a little bit "hacky". I can revert this change if people prefer the previous version without "__experimental/".

aduth · 2019-05-07T15:29:54Z

lib/widgets.php

+			'capabilities' => array(
+				// You need to be able to edit posts, in order to read blocks in their raw form.
+				'read'                   => 'edit_posts',
+				// You need to be able to publish posts, in order to create blocks.


These comments seem to be copy-paste from the registration of 'wp_block', but aren't representative of what the actual values are (i.e. you need to be able to edit theme options, not publish posts).

https://github.com/WordPress/wordpress-develop/blob/96649a5ad1a80cd8aaea15b955a48e292c406135/src/wp-includes/post.php#L293-L294

Are they necessary at all to include? At least need to be updated.

I agree I don't think comments are required in this situation and I removed them.

aduth

I left a related comment on the Widgets RFC at #14812 (comment) which, if considered, might call into question whether this post type be necessary at all.

That being said, I'd like to see some iterations in this space, and the proposed implementation looks in good shape for the current proposal.

aduth · 2019-05-08T19:13:30Z

lib/widgets.php

+			'public'       => false,
+			'show_ui'      => false,
+			'show_in_menu' => false,
+			'show_in_rest' => true,


I'd also wonder if it's worth considering to include in an experimental namespace, like at #15015

jorgefilipecosta requested review from aduth, gziolo and youknowriad as code owners April 17, 2019 11:14

jorgefilipecosta added [Type] Task Issues or PRs that have been broken down into an individual action to take [Feature] Widgets Screen The block-based screen that replaced widgets.php. labels Apr 17, 2019

jorgefilipecosta mentioned this pull request Apr 17, 2019

Add widget-areas endpoint #15015

Merged

youknowriad reviewed Apr 17, 2019

View reviewed changes

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from 61f7fd7 to f4c17ed Compare April 17, 2019 16:12

jorgefilipecosta mentioned this pull request Apr 19, 2019

Connnect gutenberg widgets screen to widget area endpoints #15074

Merged

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from f4c17ed to a64d42a Compare April 19, 2019 16:11

aduth reviewed Apr 29, 2019

View reviewed changes

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from a64d42a to 1868ca2 Compare April 30, 2019 10:06

jorgefilipecosta added the [Status] In Progress Tracking issues with work in progress label Apr 30, 2019

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from 1868ca2 to db638b0 Compare April 30, 2019 14:10

jorgefilipecosta removed the [Status] In Progress Tracking issues with work in progress label Apr 30, 2019

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from db638b0 to 6c278e6 Compare May 2, 2019 13:16

youknowriad requested a review from aduth May 7, 2019 11:39

aduth reviewed May 7, 2019

View reviewed changes

aduth mentioned this pull request May 7, 2019

Add Blocks in Widget Areas RFC #14812

Closed

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from 6c278e6 to 13c93a3 Compare May 7, 2019 20:08

aduth approved these changes May 8, 2019

View reviewed changes

Add WordPress Area CPT

1358940

jorgefilipecosta force-pushed the add/wordpress-area-cpt branch from 13c93a3 to 1358940 Compare May 8, 2019 21:52

jorgefilipecosta merged commit 5924233 into master May 8, 2019

jorgefilipecosta deleted the add/wordpress-area-cpt branch May 8, 2019 22:48

youknowriad added this to the 5.7 (Gutenberg) milestone May 10, 2019

		add_filter( 'block_editor_settings', 'gutenberg_legacy_widget_settings' );


		function create_wp_area_post_type() {

	'show_in_rest' => true,
	'show_in_rest' => true,
	'rest_base' => 'areas',

Add WordPress Area CPT #15014

Add WordPress Area CPT #15014

Uh oh!

Conversation

jorgefilipecosta commented Apr 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How has this been tested?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jorgefilipecosta commented Apr 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

youknowriad commented May 7, 2019

Uh oh!

jorgefilipecosta commented May 7, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jorgefilipecosta May 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aduth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jorgefilipecosta commented Apr 17, 2019 •

edited

Loading

jorgefilipecosta commented Apr 30, 2019 •

edited

Loading

jorgefilipecosta May 8, 2019 •

edited

Loading