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

Templates: Assign default post format block as template setting #9287

Merged
merged 1 commit into from Aug 29, 2018

Conversation

Projects
None yet
2 participants
@aduth
Member

aduth commented Aug 23, 2018

This pull request seeks to refactor default block by post format to be effected as a template.

This is being proposed for two primary reasons:

  • It is a simplification, reusing existing template mechanisms in place of an additional step for enacting the default post format block
  • As an extension of the previous point, it will serve to benefit a planned subsequent refactoring of editor initialization aimed at eliminating "setup" steps of the editor, for which the default post format block is otherwise difficult to mimic in state without a designated start point.

There are two notable differences from how this behaves in master:

  • The template is not enacted except when editing a new post.
    • Arguably, I find this behavior, both for the default post format block and templates in general, to be buggy. For example, on master try:
      1. Set default post format to Image on Settings > Writing
      2. Navigate to Posts > Add New
      3. Add a title
      4. Remove the default image block
      5. Save the post
      6. Reload the editor
        • Expected: My changes are reflected (i.e. the removal of the default block)
        • Actual: The image placeholder block returns! Again, I acknowledge this could be an argued as intentional, but to me it seems like the default block should serve as a starting point niceity, but ultimately we respect the user's decisions to manipulate or remove those defaults.
  • The default block is no longer inserted when changing Post Format field
    • Another niceity, but I don't find it to be a worrisome change

Testing instructions:

Verify there are no regressions in the behavior of the default block by post format.

Ensure new end-to-end tests pass:

npm run test-e2e

@aduth aduth added the Templates API label Aug 23, 2018

@aduth aduth requested a review from jorgefilipecosta Aug 23, 2018

@aduth aduth requested a review from WordPress/gutenberg-core Aug 27, 2018

@aduth aduth added this to the 3.7 milestone Aug 27, 2018

@@ -228,6 +229,11 @@ export function getDefaultBlockName() {
* @return {string} Block name.
*/
export function getDefaultBlockForPostFormat( postFormat ) {
deprecated( 'getDefaultBlockForPostFormat', {

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta Aug 27, 2018

Member

I'm not sure if we should deprecate this selector as it may be a useful selector for plugins, that may want to have a UI based on post formats. We also have a possible use case of this selector, the getSuggestedPostFormat selector. Currently is not using this selector but I think we may do a refactor there to use it instead of removing the selector.

@jorgefilipecosta

jorgefilipecosta Aug 27, 2018

Member

I'm not sure if we should deprecate this selector as it may be a useful selector for plugins, that may want to have a UI based on post formats. We also have a possible use case of this selector, the getSuggestedPostFormat selector. Currently is not using this selector but I think we may do a refactor there to use it instead of removing the selector.

This comment has been minimized.

@jorgefilipecosta

jorgefilipecosta Aug 27, 2018

Member

On a second thought, a refactor of getSuggestedPostFormat may not be possible as in this selector we may have multiple blocks mapping to a single post format.
I still think getDefaultBlockForPostFormat may be useful for plugins but If we don't have a use case for it we should not be sending its bytes so probably what we have now is the best option.

@jorgefilipecosta

jorgefilipecosta Aug 27, 2018

Member

On a second thought, a refactor of getSuggestedPostFormat may not be possible as in this selector we may have multiple blocks mapping to a single post format.
I still think getDefaultBlockForPostFormat may be useful for plugins but If we don't have a use case for it we should not be sending its bytes so probably what we have now is the best option.

This comment has been minimized.

@aduth

aduth Aug 29, 2018

Member

I tend to optimize toward avoiding keeping things around because we'd anticipate them to possibly be useful. In this particular case, it's also a heavy maintenance burden to maintain mapping between post formats and default block both within JavaScript and in PHP. If it's something we want in the future, I think it'd be better for us to refactor how we provide it, bootstrapping from some constant (optionally filtered) defined server-side.

@aduth

aduth Aug 29, 2018

Member

I tend to optimize toward avoiding keeping things around because we'd anticipate them to possibly be useful. In this particular case, it's also a heavy maintenance burden to maintain mapping between post formats and default block both within JavaScript and in PHP. If it's something we want in the future, I think it'd be better for us to refactor how we provide it, bootstrapping from some constant (optionally filtered) defined server-side.

@jorgefilipecosta

I did some tests on the post formats (post init and suggestions) and the tests went well, everything seems to be working correctly. I think removing this system of starting a post with a block already inserted and using the one from templates is a positive change 👍

@aduth aduth merged commit 540778b into master Aug 29, 2018

2 checks passed

codecov/project 50.23% (-0.01%) compared to 5a630c2
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@aduth aduth deleted the update/default-post-format-block branch Aug 29, 2018

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