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

Extensibility: Add publish panels support for plugins #6798

Merged
merged 2 commits into from
May 22, 2018

Conversation

gziolo
Copy link
Member

@gziolo 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:

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 [Type] Enhancement A suggestion for improvement. [Feature] Extensibility The ability to extend blocks or the editing experience [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... labels May 17, 2018
@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 a team May 17, 2018 11:36
@gziolo gziolo added the Needs Design Feedback Needs general design feedback. label May 17, 2018
@@ -84,6 +86,8 @@ function Layout( {
onClose={ closePublishSidebar }
forceIsDirty={ hasActiveMetaboxes }
forceIsSaving={ isSaving }
renderPrePublishExtension={ () => <PluginPrePublishPanel.Slot /> }
Copy link
Member

@jorgefilipecosta jorgefilipecosta May 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@jorgefilipecosta jorgefilipecosta May 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
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
Copy link
Member Author

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
Copy link
Member Author

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 removed the Needs Design Feedback Needs general design feedback. label May 20, 2018
@karmatosed karmatosed self-requested a review May 20, 2018 16:56
Copy link
Member

@karmatosed karmatosed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving a design review 👍

@gziolo gziolo force-pushed the add/plugin-publish-panels branch from 18bc41e to efa8098 Compare May 21, 2018 09:13
@gziolo
Copy link
Member Author

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this belong here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. See:

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect.

@mtias
Copy link
Member

mtias commented May 22, 2018

All good here?

@gziolo
Copy link
Member Author

gziolo commented May 22, 2018

Yes, let's proceed 👍

@gziolo gziolo merged commit 79611cc into master May 22, 2018
@gziolo gziolo deleted the add/plugin-publish-panels branch May 22, 2018 11:14
@@ -84,6 +86,8 @@ function Layout( {
onClose={ closePublishSidebar }
forceIsDirty={ hasActiveMetaboxes }
forceIsSaving={ isSaving }
renderPrePublishExtension={ () => <PluginPrePublishPanel.Slot /> }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done: #6938.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience [Feature] Writing Flow Block selection, navigation, splitting, merging, deletion... [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants