Heartbeat API: consider changing the min allowed time

[annezazu]

In conversations with folks about phase 3 of WordPress compiled in ​ Summary and Insights of Phase 3 related conversations , getting locked out of a post and dealing with pain points around residual locking continually came up. While waiting for more collaborative workflows to be built, improving the locking experience in the interim would be a big improvement to day to day workflows. I chatted with @jorbin who mentioned that the heartbeat can be sped up so it checks every 15 seconds as it was originally set here:

https://core.trac.wordpress.org/changeset/24406

Historically, it seems this was done over a decade ago due to performance concerns on shared hosts: https://core.trac.wordpress.org/ticket/23216#comment:57 Is there space to revisit this and move it back to the original 5 seconds? Rather than dealing with getting locked out "hundreds of times a day" as one recent interviewee said, we could offer a way to lower the lock out time and ease people's workflows today.

If a trac ticket has been open for this previously, I apologize! I did look around first before opening this one and appreciate being pointed to the right place as this does come up a fair amount when chatting with folks.

[jorbin]

I like the idea of allowing for setting a quicker heartbeat, especially in light of the discussion in ​https://github.com/WordPress/gutenberg/discussions/65012 and to further collaborative editing.

While not every host is going to work well with a quick heartbeat which was the original reason for pushing it to 15, many hosts now can accommodate more requests now than they did 11 years ago.

Moving to 6.7 for visibility and to encourage discussion.

cc/ @kirasong @azaozz due to your knowledge and experience with heartbeat.

[azaozz]

heartbeat can be sped up

. ...

it seems this was done over a decade ago due to performance concerns

Sure, there doesn't seem to be a good reason to keep that imitation any more. As far as I see it can be removed completely (min = 1 second?) so it can be sped up when needed.

I'll be a bit hesitant to set the default to 5 seconds though. Heartbeat is used on most wp-admin screens only to check for expiring user logins. This user case doesn't need very frequent checks. Seems better to remove the limitation and speed it up when more than one user is writing/editing, but not change the default frequency.

[peterwilsoncc]

The authentication cookie is set to expire 12 hours after the login session expires (which is stored in the cookie itself), see source code.

This gives the heartbeat API plenty of time to prompt a user to log in when the session expires before the cookie expires.

I know there have been issues in the past with nonces expiring while posts are open in a background tab as browsers pause JavaScript execution. I don't know that allowing for faster refreshes of the heartbeat will solve that issue as they too rely on JavaScript.

However...

Increasing the cookie retention period to 24 hours may help partly resolve this. Typically there are 16 hours between someone wrapping up for one day and starting the next. If the session expires shortly after logging off, then the 12 hour grace period will expire before they return to their browser.

[kirasong]

@annezazu, thanks so much for the ticket!

I'm not opposed to reducing the time between the heartbeat requests, but I'm having a hard time understanding how to reproduce the issues that users are having.

Would you mind providing a specific example or two, please?

It's possible I missed them on the link you included, and apologies if so!

[peterwilsoncc]

Re-reading this, it looks like I got confused between types of locking. On a re-read I think this is referring to post locking rather than a user getting their account locked while away from their browser. Sorry about that.

[annezazu]

Would you mind providing a specific example or two, please?

Sure! I'll try to get some specific examples from some larger sites. The root issue is a large number of users working on many posts per day, including needing to jump in, review a post, then jump out. The issue is that there's often a huge lag when someone is in a post vs when they are seen as out of the post. Even without real time collaboration happening, improving this so there's less lag would be a big step in improving collaboration in general.

[azaozz]

The issue is that there's often a huge lag when someone is in a post vs when they are seen as out of the post.

The 15 seconds "default" for checking post locks is set from (old) JS: post.js and inline-edit-post.js. but doesn't seem to be set when the block editor is used so it runs on a 60 seconds interval (thought this was set there before). This can be set from JS or PHP, will make a quick patch.

Also set it to 10 seconds (down from 15) on the Posts screen so post locks can be set and removed faster.

Update Heartbeat: remove interval limitations; now the interval can be from 1 to 3600 seconds.

Trac ticket: https://core.trac.wordpress.org/ticket/61960

Hoping that web servers have somewhat evolved and became more powerful over the last 11 years :)

However if doing an AJAX request every 10 seconds while editing a post is still too much for some shared hosting, this can be reverted to the old setting of 15 seconds.

Should the classic editor's default interval be lowered too?

Sure, lets change it there too. Was a bit hesitant as it seems every little change on the (old) Edit Post screen could trigger something unexpected, and it is in a "deep maintenance" mode so few people would test it, but seems this should be okay.

Yeah, let's give the classic editor a go to. It's yolo Friday in your part of the world tomorrow so (pending @getsource's feedback) unless someone else picks up a blocker, maybe you can do the commit honours then so the hosting folks can offer feedback