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

Extensibility: Add publish panels support for plugins #6798

Merged
merged 2 commits into from May 22, 2018

Conversation

@gziolo
Member

gziolo commented May 17, 2018

Description

Fixes #3264.

To support the current Publicize integration strategy per Jetpack PR Automattic/jetpack#9144, I'm proposing Gutenberg provide extensibility in a couple areas:

  • Provide extendable pre and publish panels (see strategy in #3264)

Added PluginPrePublishPanel and PluginPostPublishPanel to for plugins to add content to pre-publish sidebar or post-publish sidebar respectively.

Continues work started by @c-shultz in #5795. To make it easier to proceed I moved those changes to the upstream repository. Sorry, for losing commits history @c-shultz and thanks for your initial work which made this change very easy.

How has this been tested?

Code to paste into your browser: https://gist.github.com/gziolo/fd8141f2cde7fcb1b513c09eea45d27f.

Screenshots

Pre-publish

screen shot 2018-05-17 at 13 39 03

Post-publish

Desktop:
screen shot 2018-05-17 at 13 37 15

Mobile:
screen shot 2018-05-17 at 13 37 41

Types of changes

New feature (non-breaking change which adds functionality).

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@gziolo gziolo added this to the 3.0 milestone May 17, 2018

@gziolo gziolo self-assigned this May 17, 2018

@gziolo gziolo requested a review from WordPress/gutenberg-core May 17, 2018

@gziolo gziolo added this to To do in Extensibility via automation May 17, 2018

@gziolo gziolo moved this from To do to In progress in Extensibility May 17, 2018

@@ -84,6 +86,8 @@ function Layout( {
onClose={ closePublishSidebar }
forceIsDirty={ hasActiveMetaboxes }
forceIsSaving={ isSaving }
renderPrePublishExtension={ () => <PluginPrePublishPanel.Slot /> }

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta May 17, 2018

Member

Maybe here we can just have a renderPublishExtension prop, and leave it up to the component to query state and check if we are in pre-publish or post-publish and just render when we are in the desired state ( or both ).
Later we could even change for a more generic sidebar extension mechanism where we just extend all sidebars the component is responsible to query the state to discover if it should render something in a given state or not (e.g: if it is pre-publish) if it is the block sidebar etc...
This would even allow a plugin to extend the sidebars of other plugins :)

This comment has been minimized.

@gziolo

gziolo May 18, 2018

Member

Those two are mutually exclusive. You are either in pre-publish screen or post-publish screen. They are passed down to two different subcomponents. This is limited to publish sidebar only. Can you elaborate on your idea with some code examples? I must admit that I don't quite see how this part could relate to the plugin sidebar.

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta May 22, 2018

Member

Hi @gziolo here is a sample of the generic API for extending sidebars that I was referring: #6899.
Unfortunately, it ended up not being possible to use it in this case, because pre and post-publish state are not available globally for plugins to query. It uses local state.
But the initial idea was to render <SidebarExtender.Slot /> both pre and post-publish panels.

This comment has been minimized.

@gziolo

gziolo May 23, 2018

Member

Right, this component has its own internal state which controls the logic for rendering individual panels. I will check your PR. Thanks for opening 👍

@jorgefilipecosta

This comment has been minimized.

Member

jorgefilipecosta commented May 17, 2018

I tested the PrePublish with the follwing code block and it worked well:

var el = wp.element.createElement;
var PluginPostPublishPanel = wp.editPost.PluginPostPublishPanel;
var sidebarContent = el( wp.components.PanelBody, {}, el( 'h3', {}, 'Hello world!' ) ); 
var mySidebar = el( PluginPostPublishPanel, { initialOpen: true, title: 'test' }, sidebarContent );
wp.plugins.registerPlugin('wordcamp', { render: function(){ return mySidebar } } );

Regarding post publish it also worked well but only when post publish panel appears e.g.: scheduled posts. I think we may need to add a mechanism that allows plugins to change the rules of when post publish appears so they can make the post publish appear even in more common publishing situations.

@gziolo

This comment has been minimized.

Member

gziolo commented May 18, 2018

Regarding post publish it also worked well but only when post publish panel appears e.g.: scheduled posts. I think we may need to add a mechanism that allows plugins to change the rules of when post publish appears so they can make the post publish appear even in more common publishing situations.

Yes, this was confusing also for me. I don't know the details why it works how it works, but it would be nice to be able to change it.

@gziolo

This comment has been minimized.

Member

gziolo commented May 18, 2018

It's a regression. You should always see the post publish panel. It gets immediately closed when publish a post in here:
https://github.com/WordPress/gutenberg/blob/master/editor/components/post-publish-panel/index.js#L48-L50

@karmatosed karmatosed self-requested a review May 20, 2018

@karmatosed

Leaving a design review 👍

@gziolo

This comment has been minimized.

Member

gziolo commented May 21, 2018

It's a regression. You should always see the post publish panel. It gets immediately closed when publish a post in here:
https://github.com/WordPress/gutenberg/blob/master/editor/components/post-publish-panel/index.js#L48-L50

@jorgefilipecosta it was fixed with #6822. You should always see both panels when publishing posts.

```jsx
const { __ } = wp.i18n;
const { PluginPrePublishPanel } = wp.editPost;

This comment has been minimized.

@mtias

mtias May 21, 2018

Contributor

Shouldn't these APIs just be EditorPrePublishPanel instead of Plugin...?

This comment has been minimized.

@gziolo

gziolo May 21, 2018

Member

We prefixed all other occurrences with Plugin in the past, this just keeps the convention.

This comment has been minimized.

This comment has been minimized.

@mtias

mtias May 21, 2018

Contributor

Yes, but I'm not sure it makes a lot of sense for every piece. :) PluginSidebar and the plugin menu item make sense because their entire purpose is plugin based.

This comment has been minimized.

@gziolo

gziolo May 21, 2018

Member

I'm not attached to this, we can update.
What about PluginPostStatustInfo, should we also rename to EditorPostStatusInfo?

This comment has been minimized.

@gziolo

gziolo May 21, 2018

Member

I did some more research. We already have PostPublishPanel. See:
https://github.com/WordPress/gutenberg/blob/master/editor/components/post-publish-panel/index.js#L66
which uses editor-post-publish-panel class name. It might be a bit confusing. Maybe we should keep this Plugin prefix to make it clear that this is meant to be used by plugins.

This comment has been minimized.

@mtias

mtias May 21, 2018

Contributor

Yes, that's fine, was just a comment because it felt a bit weird to go with Plugin as a generic prefix across the board.

@@ -94,3 +94,4 @@ This list is manually curated to include valuable contributions by volunteers th
| @Cloud887 |
| @hblackett |
| @vishalkakadiya |
| @c-shultz |

This comment has been minimized.

@mtias

mtias May 21, 2018

Contributor

does this belong here?

This comment has been minimized.

@gziolo

gziolo May 22, 2018

Member

Yes. See:

Continues work started by @c-shultz in #5795.

This comment has been minimized.

@mtias

mtias May 22, 2018

Contributor

Perfect.

@mtias

This comment has been minimized.

Contributor

mtias commented May 22, 2018

All good here?

@gziolo

This comment has been minimized.

Member

gziolo commented May 22, 2018

Yes, let's proceed 👍

@gziolo gziolo merged commit 79611cc into master May 22, 2018

2 checks passed

codecov/project 46.49% (+0.05%) compared to 0b9de9f
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

Extensibility automation moved this from In progress to Done May 22, 2018

@gziolo gziolo deleted the add/plugin-publish-panels branch May 22, 2018

@@ -84,6 +86,8 @@ function Layout( {
onClose={ closePublishSidebar }
forceIsDirty={ hasActiveMetaboxes }
forceIsSaving={ isSaving }
renderPrePublishExtension={ () => <PluginPrePublishPanel.Slot /> }

This comment has been minimized.

@aduth

aduth May 23, 2018

Member

This will cause render reconciliation more than necessary because it's creating a new function each render.

Why not hoist to a top-level variable? Or could renderPrePublishExtension be interpreted as a component, so we could pass the PluginPrePublishPanel.Slot reference directly instead of a function?

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta May 23, 2018

Member

Interesting, I would also think we would cause render reconciliation more than necessary because we are passing new props on each rerender, but the react samples for the Render Props pattern use something similar https://reactjs.org/docs/render-props.html, they are also creating inline functions and passing them as props. I see this practice being used widely. I'm curious if react has some an optimization for the inline functions rendering React components.

This comment has been minimized.

@gziolo

gziolo May 24, 2018

Member

We probably can pass those slots as components in this case. Opening PR soon.

This comment has been minimized.

@gziolo

@gziolo gziolo referenced this pull request May 24, 2018

Merged

Edit Post: Improve perf for PublishPanel and extenstions #6938

4 of 4 tasks complete

@gziolo gziolo referenced this pull request Jul 16, 2018

Merged

Block settings extensibility #7895

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment