Enable users to switch flags on/off using querystring

[peterhartree]

There are a bunch of use cases where it'd be convenient to be able to send WordPress users a link with querystring variables that switch flags on or off.

For example, I want to show a colleague a thing I'm working on. I just want to send them a link to the site with feature flags configured as required for them to preview. I don't want to have to tell them to go to the WordPress admin settings page and then configure flags.

A couple of implementation details that come to mind:

• It'd be great if the WordPress admin settings page automatically generates a link I can copy paste, which replicates the current logged in users feature flag settings.
• If a non logged in user follows a link which feature flag variables in querystring, should redirect to WordPress login screen and then apply flags once they login.

[jamesrwilliams]

Hey @peterhartree,

I've made a start on this on via a feature branch feat/query-string which at the moment enables a flag (even if it's disabled by the current user) if the following conditions are met:

• A query value is passed ?flag=foo
• The feature is set as queryable (enable via registration function arg)
• User is logged in (redirects to log in and back if not logged in)

E.g: Visiting https://example.com/page/?flag=foo would enable the foo feature flag.

I'm probably going to make the login requirement configurable also as I can see that being useful for certain demos where you don't want the hassle of user accounts. I've now added this. See the private arugment added in feat/query-string.

I'm interested to hear more about replicating the current flag statues. Are you thinking it would be useful to have a query string that can enable multiple flags at once?

[peterhartree]

Nice!!

Are you thinking it would be useful to have a query string that can enable multiple flags at once?

Yes. I think it should be possible to disable flags via querystring as well.

I'm imagining a query string that looks something like

https://example.com/page/?flag__foo=1&flag__bar=0

I can imagine a case where we have e.g. 10 flags registered and I don't know which flags the user currently has enabled. To avoid confusion, I may want to send a link that sets all the users flags to the exactly intended state.

So it'd be useful if, from the WP admin flag settings page, I could copy-paste a link that sets all flags to the state they're in for the currently logged in user.

[jamesrwilliams]

Ah, I see. Chaining a lot of flags could get a little messy, maybe the facility for people to set up groups of flags that are enabled by a custom list parameter? This would give you the option to setup say ?set=april-demo would enable a set of flags at once.

I'm imagining these groups being shared by all WordPress admin users rather than the current per user activation. So you would create the "April Demo" feature group/set and then add specific flags to the set and those are enabled whenever you use the custom defined query string.

[peterhartree]

Yep, flag groups sounds like the ideal solution here.

Chaining ungrouped flags with any easy to copy-paste URL seems like a "good enough" approach, so if it's much easier to implement maybe that's the way to go initially.

[jamesrwilliams]

This is pinned to be my next core feature to work on before an initial release. Made a note to also potentially make the query string configurable by the users rather than lumping them with variations of ?flag=.

[jamesrwilliams]

Had a thought while working on an implementation for this. Would it make sense for a user to be able to publish/preview a group of flags?

I've just realised my plan with the groups would only allow them to be queried but this is quite limiting. Wouldn't it make sense to be able to preview a group of features at once?

N.B Going to move this to its own issue rather than polluting the original idea of toggling features with a query string.

[jamesrwilliams]

Closing this as the toggle by query string feature has been implemented and I've split the groups' discussion into #21.