Making WordPress.org

Opened 7 years ago

Closed 2 years ago

#2552 closed enhancement (fixed)

Support Forums: Bring "Also Viewing" Native

Reported by: ipstenu's profile Ipstenu Owned by: dd32's profile dd32
Milestone: Priority: normal
Component: Support Forums Keywords:
Cc:

Description

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

Attachments (2)

2552.1.patch (1.5 KB) - added by vladytimy 3 years ago.
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.
Before_after_2552.1.jpg (691.5 KB) - added by vladytimy 3 years ago.

Download all attachments as: .zip

Change History (26)

This ticket was mentioned in Slack in #bbpress by netweb. View the logs.


7 years ago

This ticket was mentioned in Slack in #forums by ipstenu. View the logs.


7 years ago

#3 @Clorith
7 years ago

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).

#4 @johnjamesjacoby
7 years ago

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.

Last edited 7 years ago by johnjamesjacoby (previous) (diff)

#5 @netweb
7 years ago

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

This ticket was mentioned in Slack in #forums by clorith. View the logs.


6 years ago

#7 @dd32
4 years ago

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.

Last edited 4 years ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #forums by clorith. View the logs.


3 years ago

#9 @Clorith
3 years ago

@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?

#10 @dd32
3 years ago

  • Owner set to dd32
  • Status changed from new to assigned

#11 @dd32
3 years ago

In 10651:

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

See #2552.

#12 @dd32
3 years ago

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.

#13 @dd32
3 years ago

In 10653:

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

See #2552.

#14 @dd32
3 years ago

  • Keywords needs-patch removed

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.

#15 @dd32
3 years ago

In 10654:

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

See #2552.

#16 @dd32
3 years ago

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.

#17 @dd32
3 years ago

In 10656:

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

See #2552.

#18 @dd32
3 years ago

In 10657:

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

See #2552.

#19 @dd32
3 years ago

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.

Last edited 3 years ago by dd32 (previous) (diff)

#20 @dd32
3 years ago

In 10658:

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

See #2552.

This ticket was mentioned in Slack in #forums by tobifjellner. View the logs.


3 years ago

@vladytimy
3 years ago

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.

#22 @dd32
3 years ago

In 10662:

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

See #2552.

#23 @Clorith
3 years ago

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.

#24 @dd32
2 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.