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

Cleanup block editor compatibility logic #580

Merged
merged 5 commits into from
Jan 21, 2020

Conversation

WPprodigy
Copy link
Contributor

@WPprodigy WPprodigy commented Jan 16, 2020

First pass as what I was describing earlier. Open for discussion.

Description

No functionality was harmed in the making of this PR.

This is purely development focused, no behavioral changes to the plugin should occur. This same events happen when loading the plugin, the same conditionals are checked, scripts are enqueued the same way and time, etc.

There were three mains reasons for this change:

  1. Modules should have more flexibility around how they integrate with Gutenberg, and being limited to a single unhooking/hooking process is quite restrictive. (metaboxes may also need to be hidden, etc)

  2. The responsibility belongs to the module. The base Edit_Flow class shouldn't need to know about such details. A lot of extra abstractions were removed with the same end result here, though in my opinion it will create a much easier development flow / comprehension.

  3. Gutenberg / Block Support should be a first class citizen moving forward, not shoved away in a corner. I'd prefer to see metaboxes get that treatment in the future 😄

There is more that can be done to clean up how a module reads and the decision tree on whether or not we are loading GB scripts, but I opted to keep this PR as simple as possible with the single purpose of breaking out of the abstraction layers. #565 can take that part further.

There were also quite a bit of unused code/pieces that I removed. Version control has us covered if they are ever needed, though I don't think that will be the case. dde1d2d is the main commit here. And as you can see, we get the same end behavior for much less code, without losing anything.

Steps to Test

Checkout this PR and ensure that the Custom Statuses functionality works the same in Gutenberg as it did before.

@cojennin
Copy link
Contributor

Yea, makes sense. I was looking for more context around the original implementation. Not much there, looks like the reasoning was it meant avoiding modifying the existing module code.

Can you resolve the conflict and the two PHPCS issues (ignoring the indenting issues, the whole file is indented incorrectly). Then I'll test and approve if everything looks good

@WPprodigy
Copy link
Contributor Author

WPprodigy commented Jan 21, 2020

I'm pretty sure I've switched that same short array syntax error in the same spot twice now :shakesfistatclouds:

Will fix, and rebase as well.

Copy link
Contributor

@cojennin cojennin left a comment

Choose a reason for hiding this comment

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

Looks good, think the direction makes sense, and confirmed it works as expected in block and classic editor.

@WPprodigy WPprodigy merged commit 6b88e56 into master Jan 21, 2020
@WPprodigy WPprodigy deleted the cleanup/block-editor-compat branch January 21, 2020 18:27
@cojennin cojennin added this to the 0.9.4 milestone Feb 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants