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

Enable post locking in Gutenberg #4217

Merged
merged 119 commits into from Oct 4, 2018

Conversation

@adamsilverstein
Contributor

adamsilverstein commented Jan 1, 2018

Description

Enable the post locking feature in gutenberg:

Fixes #4331

  • uses the existing mechanism to set the post as locked.
  • works in both and between classic/gutenberg editors.
  • uses the existing core code, slightly refactored to pass Gutenberg linting.
  • show the locked dialog when opening a post that is already opened by another user.
  • show the takeover dialog shown when someone tries to take over a locked post.

How Has This Been Tested?

  • Create or edit a post.
  • Log in as a separate user and go to the posts screen, note the post is locked.
  • Test the three buttons: preview, take over and post list
  • Take over the post, make some edits without saving, then toggle back to the browser where the other user had the post open, this user will get an autosave fired and the 'another user has take over' dialog.

Screenshots (jpeg or gifs if applicable):


Types of changes

  • Add heartbeat.js in editor/utils, exporting setupHearthbeat
  • call setupHearthbeat before initial editor render.
  • monitor heartbeat for lock events - displaying a "user has taken over" modal when another user takes over the post
  • localize data for existing locks, displaying an "Already Locked" modal

Checklist:

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

@adamsilverstein adamsilverstein referenced this pull request Jan 1, 2018

Closed

Improve autosaves #4156

1 of 3 tasks complete
@adamsilverstein

This comment has been minimized.

Show comment
Hide comment
@adamsilverstein

adamsilverstein Jan 1, 2018

Contributor

Closing in favor of #4218 which builds on this and adds heartbeat based autosaves as well.

Contributor

adamsilverstein commented Jan 1, 2018

Closing in favor of #4218 which builds on this and adds heartbeat based autosaves as well.

@gziolo gziolo deleted the feature/post-locking branch May 7, 2018

@adamsilverstein adamsilverstein restored the feature/post-locking branch Jun 8, 2018

@adamsilverstein

This comment has been minimized.

Show comment
Hide comment
@adamsilverstein

adamsilverstein Jun 8, 2018

Contributor

Reopening to work on standalone post locking since we took a different route with autosaves.

Contributor

adamsilverstein commented Jun 8, 2018

Reopening to work on standalone post locking since we took a different route with autosaves.

@adamsilverstein adamsilverstein self-assigned this Jul 27, 2018

@afercia afercia referenced this pull request Sep 25, 2018

Closed

Improve saving #1295

@mcsf

Good stuff overall. Left some comments, the really important of which are the ones on i18n.

Show outdated Hide outdated packages/editor/src/store/selectors.js
Show outdated Hide outdated packages/editor/src/store/selectors.js
type: 'UPDATE_POST_LOCK',
lock,
};
}

This comment has been minimized.

@mcsf

mcsf Sep 25, 2018

Contributor

Action creators are also useful as contracts on the data expected to be flowing through the system, and can be either manually consulted by the developer or relied upon via text editors' completion features. In this case, lock is a bit opaque, whereas we could have something like:

updatePostLock( lockStatus, user, … ) {
  return {
    type: 'UPDATE_POST_LOCK',
    lockStatus,
    user,
    …
  };
}

alternatively:

return {
  type: 'UPDATE_POST_LOCK',
  lock: { lockStatus, user, … },
};

I don't mind keeping the action creator as it is now, but this was worth pointing out.

@mcsf

mcsf Sep 25, 2018

Contributor

Action creators are also useful as contracts on the data expected to be flowing through the system, and can be either manually consulted by the developer or relied upon via text editors' completion features. In this case, lock is a bit opaque, whereas we could have something like:

updatePostLock( lockStatus, user, … ) {
  return {
    type: 'UPDATE_POST_LOCK',
    lockStatus,
    user,
    …
  };
}

alternatively:

return {
  type: 'UPDATE_POST_LOCK',
  lock: { lockStatus, user, … },
};

I don't mind keeping the action creator as it is now, but this was worth pointing out.

Show resolved Hide resolved packages/editor/src/components/post-locked-modal/index.js
Show outdated Hide outdated packages/editor/src/components/post-locked-modal/index.js
Show outdated Hide outdated packages/editor/src/components/post-locked-modal/index.js
Show outdated Hide outdated packages/editor/src/components/post-locked-modal/index.js

@mtias mtias modified the milestones: Merge: Editor, 4.1 Oct 3, 2018

@youknowriad youknowriad modified the milestones: 4.1, 4.0 Oct 4, 2018

Show resolved Hide resolved gutenberg.php
Show resolved Hide resolved lib/client-assets.php
Show resolved Hide resolved lib/client-assets.php
Show outdated Hide outdated packages/components/src/modal/README.md
/**
* External dependencies
*/
import jQuery from 'jquery';

This comment has been minimized.

@aduth

aduth Oct 4, 2018

Member

We should add jquery as a dependency of the wp-editor script

This still needs to be done.

@aduth

aduth Oct 4, 2018

Member

We should add jquery as a dependency of the wp-editor script

This still needs to be done.

Show outdated Hide outdated packages/editor/src/components/post-locked-modal/index.js
Show resolved Hide resolved packages/editor/src/components/post-locked-modal/index.js
Show outdated Hide outdated packages/editor/src/components/post-locked-modal/index.js
Show resolved Hide resolved packages/editor/src/store/reducer.js
Show resolved Hide resolved packages/editor/src/store/reducer.js
@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Oct 4, 2018

Member

Looks good to me. Thanks for all the hard work.

Member

karmatosed commented Oct 4, 2018

Looks good to me. Thanks for all the hard work.

@mcsf

Added i18n feedback, which I'll address right now. (By typing it out I can refer to it later.)

@youknowriad youknowriad merged commit 37bd1e6 into master Oct 4, 2018

2 checks passed

codecov/project 49.21% (-0.18%) compared to 0332aa9
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@youknowriad youknowriad deleted the feature/post-locking branch Oct 4, 2018

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Oct 4, 2018

Contributor

Thanks for the hard work everyone. Now it's in we can enhance it with API endpoints at a more reasonable pace :)

Contributor

youknowriad commented Oct 4, 2018

Thanks for the hard work everyone. Now it's in we can enhance it with API endpoints at a more reasonable pace :)

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Oct 4, 2018

Member

Now it's in we can enhance it with API endpoints at a more reasonable pace :)

Is this tracked as an issue somewhere I can follow?

Member

aduth commented Oct 4, 2018

Now it's in we can enhance it with API endpoints at a more reasonable pace :)

Is this tracked as an issue somewhere I can follow?

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Oct 4, 2018

Member

Is this tracked as an issue somewhere I can follow?

There's https://core.trac.wordpress.org/ticket/44862

Member

danielbachhuber commented Oct 4, 2018

Is this tracked as an issue somewhere I can follow?

There's https://core.trac.wordpress.org/ticket/44862

// https://developer.wordpress.org/plugins/javascript/heartbeat-api/
jQuery( document )
.on( 'heartbeat-send.refresh-lock', this.sendPostLock )
.on( 'heartbeat-tick.refresh-lock', this.receivePostLock );

This comment has been minimized.

@dmsnell

dmsnell Oct 11, 2018

Contributor

@adamsilverstein is there a reason we need to rely on jQuery here? could we have gotten by with addEventListener() (and for IE attachEvent)?

given the assumption that WordPress is already loaded jQuery seems free, but for external uses these few lines can pull in a huge dependency

thoughts?

@dmsnell

dmsnell Oct 11, 2018

Contributor

@adamsilverstein is there a reason we need to rely on jQuery here? could we have gotten by with addEventListener() (and for IE attachEvent)?

given the assumption that WordPress is already loaded jQuery seems free, but for external uses these few lines can pull in a huge dependency

thoughts?

This comment has been minimized.

@aduth

aduth Oct 16, 2018

Member

We should do similar as to what was done in #8311 as a short-term solution.

@aduth

aduth Oct 16, 2018

Member

We should do similar as to what was done in #8311 as a short-term solution.

This comment has been minimized.

@aduth

aduth Oct 16, 2018

Member

In fact, at least for the heartbeat-tick event, we should already have the action provided through #8311.

@aduth

aduth Oct 16, 2018

Member

In fact, at least for the heartbeat-tick event, we should already have the action provided through #8311.

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