Size Change: +389 B (0%)

Total Size: 1.06 MB

_{compressed-size-action}

I'd like a confidence check here regarding the new __experimental properties I'm exposing on the editor settings interface.

Tested and works well.

I noticed that newly created pages don't use "pretty permalinks."

I'm also curious about @fabiankaegy's last question.

And I am not able to figure out how it determines wether it should create a new Page or a new Post 🤔 (my assumption would be that it always creates Pages but from the Code I see that there is an allow list for the two post types )

Yeh actually that's a good point. I was just about to make a change to that code but I got hit by a headache and had to stop for a bit.

I think we'll just default to Pages as the UI would need some work to allow us to be able to choose on the fly. If we want to make this more "fancy" in the future we can do that in a followup.

It seems the text isn't quite lined up with the icon.

✅ Fixed. There was a erroneous bottom margin.

I noticed that newly created pages don't use "pretty permalinks."

@Mamaduka this is because the pages are created as drafts and therefore don't have pretty permalinks. Annoyingly due to the way the link data is persisted to the HTML using the format API the value isn't dynamic so it will always remain as the "ugly" permalink even after the Page is published.

However, thanks to Rich Previews, if the editor is able to make a request to retrieve details about the Page (which it cannot do on wp-env localhost so you won't see it) then the title in the preview will get replaced with the actual title of the page.

Thanks for the explanation, Dave.

Also update to use Create Page: ${searchTerm} on the button to make it ultra clear this will create a page not a post.

Dave, I would love to get more eyes on this PR before merging.

Your explanation regarding adding new methods to the Block Editor settings makes sense, but I'm curious if there are any alternative ways.

Exposing this on the editor settings allow us to access it within the format library without creating a dependency on WordPress Core APIs.

Dave, I would love to get more eyes on this PR before merging.

I agree. That's my main area of concern. This seems inordinately difficult, but then again I'm very used to having this level of indirection having worked on:

• fetching link suggestions
• fetching rich previews

Both employ a similar mechanic for exposing WordPress specific APIs to non-WP specific packages.

@gziolo How do you feel about the addition of the two __experimental settings to allow us to create pages and also check the user has permission?

The reason I'm having to expose on the editor package is because these are WP specific APIs. The format API (which is where the LinkControl for inline links resides) is a non-WP specific package. Therefore I've used this method as there's prior art with:

• __experimentalFetchLinkSuggestions
• __experimentalFetchUrlData

If there are other feasible patterns that would simplify this then I'm keen to learn about them.

I tested this PR too for both types of users, and it works fine 🚀

Please note: this PR does not attempt to address any visual updates to the "Create button", although I'm happy to tackle that in a follow up.

The only thing I would change visually is the hover background of the items because the gray we are using (#ddd) is quite dark. This is not related to this PR and happens on the whole component.

I'll open a follow-up ticket.