Support Forums: Bring "Also Viewing" Native

[Ipstenu]

We love Also Viewing: ​https://gist.github.com/Clorith/20596176f85495da865cf41a90b43576

But wouldn't it be nice to have native? If we can do this without giving Heartbeat API a heart attack, we should.

See also:

​https://github.com/pippinsplugins/bbPress-Topic-Lock

cc @otto42

[Clorith]

Just some concerns/thoughts I had about bringing this into .org:

We're currently offloading it and doing everything our selves to avoid giving .org a stroke by allowing it for all users.

Now, to avoid overloading things, we would perhaps want to limit this to moderators+ only, but this alienates other contributors that are not in these groups but are still using the scripts as well because it helps them when providing support and avoids overlap.

We can't enable it for -all- users o n.org, the system would not like that, not one bit and I do not want Barry coming after any of us :)

Potentially a way for admins to enable this feature on a per-account basis would be a possibility, but relies heavily on us actually getting user editing fixed (right now nobody can edit other users except the brass with network admin via wp-admin it self, see #1985).

[johnjamesjacoby]

Agree with everything.

The edit_lock implementation in bbPress now is basically the same as what's in wp-admin already, minus the heart-attack API that would inevitably kill some things.

It means when someone with an edit_topic capability is actually editing a topic from the front-end, it adds some meta data to the topic to say so. It's good for 3 minutes. Once three minutes are up, either they're done editing, or they've taken too long. Once they hit update, the lock goes away. Once three minutes are up, the lock goes away.

It's a decent and inexpensive middle-ground that should help dodge the toggle problem, too. And everything in wp-admin continues to play nicely and work the same as before.

[netweb]

Related: ​#bb3005 - Notification to moderators when administrative tasks are being carried out

[dd32]

If we were to bring this in-house, I think adding it as a toggle menu item under the Profile menu in the Admin Bar would be a good way to allow those who know what it is to opt-in, even if we could handle the load of everyone using it.

Ideally it would be implemented through not-post_meta and rather through an in-memory thing like memcache to avoid the DB writes, but unfortunately I can't think of an easy way to do that with Memcache due to it's non-support for multiple distinct values for a single key.

I guess it could potentially be implemented as a ​MySQL MEMORY table which would at least avoid the DB load of querying/writing the post_meta table constantly.
edit: As it turns out, ​it's probably not a good idea to use MEMORY tables with replication (like we do on WordPress.org), as although it can handle the primary restarting (and loosing the data is fine), secondaries being restarted can cause sync issues. Implemented as it's own table, just on-disk would ultimately be fine I guess.

[Clorith]

@dd32 What do you think would be needed to move forward here, in terms of time (the good old cost vs benefit equation), is the demand high enough to warrant investing time in the infrastructure and setup of this, or should we leave it as a community project for now?

[dd32]

In 10651:

Support Forum: add a native implementation of the bbPress Also Viewing user script.

See #2552.

[dd32]

In 10652:

Support Forum: add a native implementation of the bbPress Also Viewing user script.

[10651] didn't quite import how I anticipated it to.

See #2552.

[dd32]

In 10653:

Support Forums: Also Viewing: Don't show the current user as viewing the page, and importantly, add an oxford comma.

See #2552.

[dd32]

I've added this with an admin-bar toggle for now, I don't actually like that though and would like to move this to a more hidden profile settings page, so that we can enable it for more users.

The other option, is to only enable it for users with more replies (ie. 500+ replies is 1.5k users, 100+ replies is 6k users) and not have a toggle at all. The number of users who are active at any given time shouldn't be too high.

At the same time, I wouldn't want to concern any regular users that they're being "spied on" so enabling it for everyone without an opt-in seems like a bad idea :)

I also have a few ideas on how to get rid of the database backing, at the risk of slightly less reliable data, but given how often it's being updated I don't think that'll be a problem.

[dd32]

In 10654:

Support: Also Viewing: Fix the cron task to cleanup old viewers from the storage table.

See #2552.

[dd32]

In 10655:

Support Forums: Also Viewing: Move the toggle into the forum profile screen.

This allows non-moderators with at least 20 replies to opt-in to the feature.

This change also adds a heading to the user options page to give the checkboxes a heading, and makes the banner fixing to the page smoother and more inline with the forum styling.

See #2552.

[dd32]

In 10656:

Support Forums: Also Viewing: Allow moderators to edit other users also viewing opt-in.

See #2552.

[dd32]

In 10657:

Support Forums: Also Viewing: Have the profile option respect the displayed user during edit.

See #2552.

[dd32]

The one feature that I haven't yet added is the Privacy feature from the user script,

Privacy
Make my user anonymous

I can see value in allowing others to only see that "someone else" is viewing it, but I think for moderators I'd want to leave it unmasked. (edit: To clarify, I mean, show the real user to moderators, while non-mods just see 'anonymous user')

Seeking feedback on that.

[dd32]

In 10658:

Support Forums: Also Viewing: If a unique "page name" cannot be determined for a page, don't initialise.

See #2552.

[vladytimy]

By moving the inline css of the banner to a stylesheet we can fix its position on mobile devices. This is just a proposal, maybe there's a better approach.

[dd32]

In 10662:

Support: Also Viewing: Link the option to the support doc page.

See #2552.

[Clorith]

Hmm, I don't think there's really any reason to exempt moderators when someone chooses the "anonymize me" option, I'm just not seeing any scenario where it would be needed to bypass that.

I do agree that we should move the styles away form inline styles, these are a remnant of it being a userscript originally. I've also experience some weird behaviors in scroll-detection where I have to scroll multiple replies down before it becomes sticky, but these are all minor things that we can polish.

[dd32]

Marking as fixed as there's been no follow up in a year.

The positioning that @vladytimy mentions above was fixed in r11568 via Javascript, due to the recent header changes.