Refactor with User_Setting class

[aaemnnosttv]

Feature Description

In #859/#995 we introduced a new Setting class to model a single option/setting. This has the benefit of centralizing logic and behavior that belongs to a specific setting in a single class which extends the base.

Site Kit also has many user options which WordPress implements as user meta. User options are slightly different than options or plain meta as the key is optionally prefixed with the blog prefix from wpdb depending on the site. This is because the users and usermeta tables are network-wide tables in multisite, and so prefixes are used to identify site-specific entries.

Classes which could be refactored as sub-classes of User_Setting are:

• Verification
• Verification_File
• Verification_Meta
• Tracking

Similar to what was done in the issue above, we should also add a User_Options_Interface that both existing User_Options and Encrypted_User_Options should implement.

An individual User_Setting would then only require a User_Options_Interface as a constructor dependency. Each sub-class would keep its key defined with its constant.

The User_Setting class would have a register method which calls register_meta internally and registers the option dynamically using methods to populate the arguments array similar to Setting. The registered meta key must be with/without blog prefix according to whether or not the plugin is in network mode. The user options interface could require a get_meta_key( $option ) method to get the underlying meta key as its implementations would have access to Context:is_network_mode() which is needed to conditionally prefix the option name.

User_Setting should also have a method for getting the respective meta key for its option. It would also be useful if there was a static method which could be used to apply the blog prefix to an arbitrary string for use in other places in the codebase, such as uninstall.php.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• There should be a User_Options_Interface interface exposing the following methods:
  • get( $option )
  • set( $option )
  • delete( $option )
  • get_meta_key( $option )
  • get_user_id()
  • switch_user( $user_id )
• User_Options and Encrypted_User_Options should implement User_Options_Interface.
• There should be an abstract User_Setting class that receives a User_Options_Interface as sole constructor parameter and exposes the following methods:
  • register()
    • should call register_meta(), using User_Options_Interface::get_meta_key( static::OPTION ) and protected methods get_type() and get_sanitize_callback() (the value for single should always be true)
    • should also filter in a default user option value via protected method get_default() --> let's see if this is possible based on the filters WordPress core provides
  • has()
  • get()
  • set( $value )
  • delete()
• Verification, Verification_File, Verification_Meta, and Tracking should extend User_Setting.

Implementation Brief

• Add a Core\Storage\User_Options_Interface with methods as defined in AC
  • Should not extend Options_Interface
• Add an abstract Core\Storage\User_Setting class, which implements the above interface
  • Implement default handling in get() as WP does not offer the same kind of filters as for options
    • Potentially add a parse_defaults method as we have used before
  • Only filters for meta are just for short-circuiting cache and DB
• Refactor Verification, Verification_File, Verification_Meta, and Tracking as instances of User_Setting
  • Remove Transients as a constructor dependency of Verification_Meta
    • Move Verification_Meta::get_all() to Site_Verification

Changelog entry

• Register all of the plugin's user options in WordPress via register_meta().

[felixarntz]

A couple of comments on the description:

• User_Option should be User_Setting, consistent with Setting.
• I don't like the idea of exposing Context in User_Options_Interface. User_Options_Interface could match Options_Interface, plus get_user_id() and switch_user(). Since we need Context for the transformation of user option to user meta key only, we should IMO only expose a method like this on User_Options_Interface, e.g. get_meta_key( $option ).

[aaemnnosttv]

Those all sound good to me @felixarntz, I've updated the title and description accordingly.

[felixarntz]

IB ✅

[aaemnnosttv]

@felixarntz This one has a partial dependency on the changes to the Tracking class in #1055.

[tofumatt]

Code here looks solid; settings continue to work for me, so I think this one is QA ✅