Forum profile: "Also viewing" checkbox sometimes gets unchecked

[zoonini]

Several people have noticed that the "Enable the Also Viewing feature" checkbox on their profile sometimes gets randomly unchecked on its own.

Profile URL example: /support/users/USERNAME/edit/

To reactivate the feature, the box needs to be manually re-checked.

Slack discussion: ​https://wordpress.slack.com/archives/C02RQC6RW/p1664453148498099

[zoonini]

Forum profile: Also Viewing checkbox

[jeroenrotty]

This is actually happening more often lately, I had it on September 29th, and now again on October 7nd.

[Clorith]

In 12412:

Support Forums: Check intent before updating user preferences.

The bbPress profile page may be triggered by various scenarios that do not have the full context of a profile edit included.

By introducing a hidden input field in the form areas which need a "yes or no" type response, indicated by checkboxes, we can ensure that these are not unintentionally cleared or set from profile modifications made without the options even being presented to the user.

Props zoonini.
Fixes #6509.

[Otto42]

I highly dislike this fix.

The bbPress profile page may be triggered by various scenarios

Could you clarify these scenarios? When does the profile get edited, but is not getting actually edited?

[Clorith]

Initially posted this on Slack to the same remark, but responding here for the sake of history :)

So the reason it's happening is because these profile field updates are hooking into bbp_profile_update, which is just an extension that runs through cores own profile_update action.

The latter of these actions is triggered any time a user is inserted, or updated, and by extension so is the bbPress one then. By having user settings tied to a named checkbox's existence in a request means that the code basically says "if this isn't present, the user decided not to tick the box", which isn't true when the user can be updated from "other" places.

In the most recent case, the Two-Factor plugin, as used under the wporg-two-factor one, will update a user and trigger this cascade of actions, and because we (previously) had no safeguards on these specific form fields, they would be treated as "unticked by the user", and be wiped.

Some alternative approaches though, if you'd rather, could for example be;

• add a nonce for each field, but don't throw a nonce-error if it doesn't pass, just return early.
• Convert checkboxes to select boxes with yes/no type options and a switch statement in the form handler
• Specifically check the referrer URL of a post request

I chose not to go the nonce route, since that would add 2 DB entries per user for nonce-references, which seemed overkill.
Likewise, the idea of select boxes for on/off statements is a bit backwards, and referrals are unreliable.

So with that in mind, the implementation of a can_* field entry, that gets posted alongside the value we check for, was the simplest one to both ensure these non-bbPress-core user settings we've implemented do not get wiped from unintentional "external" actions, in a period where users suddenly got a whiff of a new security feature that's been long requested and are likely to jump on :slightly_smiling_face: (and it's not just the two-factor bit that would potentially cause this, any action that triggers a user update within the w.org/forums subsite would have the potential to clear them previously)