jamesrwilliams / flagpole Goto Github PK

Hi!

Could you please tag the release?

Thank you in advance :)

I think is_enabled() is a slightly too generic as a function name.

• If another developer sees this function but doesn't know we're using feature flags, it's not immediately obvious what the function does.
• The name is generic enough that there's a reasonable chance of conflict with other functions with the same name.

I'd probably vote for maximal clarity: feature_flag_enabled() or is_feature_flag_enabled().

Long term goal this one but I think we should support translations. Can read more on the WordPress docs: How to Internationalize Your Plugin

This involves migrating any strings to use the WordPress __() functions and to correctly use PO/MO files. I personally need to do a little more reading before I can attempt this but it's on the back burner for now.

As we are using PHPCS with WordPress VIP standards, warnings are thrown for using either get_user_meta() and update_user_meta(). My understanding of this is that currently, WordPress VIP supports *_user_attribute() so we should write a wrapper around these meta calls to use *_user_attribute first if we're in a VIP enviroment?

See:

• https://vip.wordpress.com/functions/get_user_attribute/
• https://vip.wordpress.com/functions/update_user_attribute/

N.B - This stemmed from reading about how this effected WPSEO.

You can only currently preview groups via the query string feature. I suspect it would be super useful to have this feature also applied to the individual flags. Similar to how groups use the group parameter flags should use flags or some other user-configurable string.

• Support custom flag query string values rather than the key.
• Probably should be opt-in rather than on by default.

You currently cannot publish a group of flags but you can publish flags individually. Would there be a use case for needing to be able to publish a group of flags?

I suspect whenever you would need to do this you could just merge the conditionals to use the same flag and then the group becomes a new super-flag?

cmjaimet who has written a similar plugin has a wonderful idea of a JSON configuration option for the flags rather than being written in the theme's code. I think we should add this to our plugin also as another method of delcaring feature flags.

This does open up issues around load order and duplicate keys, however. Maybe the JSON file takes presedance over and PHP delcarations with any duplicates erroring as per #22. Thoughts?

Often feature changes involve PHP and JavaScript changes. It'd be useful to be able to call is_enabled('flag_key') via JavaScript as well.

As this plugin isn't in the official wordpress plugin directory it doesn't get mirrored on wpackagist, which is fair enough. However, any chance of submitting to regular packagist for ease of install with composer?

Allow the administrator to configure which user-role has access to the feature flags interface. This would default to the administrator role or whoever has the edit_themes capability.

We could almost do this on a per flag basis allowing administrators to determine which of their users can enable/disable features for internal testing.

Create plugin-zip without the node_modules folder and upload it to the releases section.

FYI - This is a grouped issue from discussions that took place on #12 (namely here and here).

In summary feature groups are user created groups of issues that can be enabled or disabled as a group and can also be enabled by a single query string.

I envision this being done via a separate tab in the interface where users can create groups that they configure the name and query string for, and then add the associated flags.

This group can then be previewed, queried, and published like any other flag.

I've started working on this on my feature branch feat/groups.

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.

I was just about to write a plugin like this to use on Automattic's VIP hosting service, but yours does most of what I wanted already. I've forked it and I'd like to modify it so it passes VIP coding requirements. Mostly it's escaping, spacing, explicit conditionals, stuff like that. Please let me know if you have any concerns with this.

Thanks,
Charles

An administrator should be able to toggle a feature for all users of their site via the admin area.

The flag group and querystring enable feature is great. If you're intending to keep it, please add to the README.

Firstly we need to come up with a rough visual theme for these, (I personally want this to look as professional as possible) but then again it's not critical to the plugin. These are the assets for the plugin's page in the WordPress Plugin directory and should include the following:

• Header
• Icon
• Screenshots

See a full detailed list here: How Your Plugin Assets Work - WordPress Org docs

These should be added to the repo in a .wordpress-org directory in the root of the project. Fully ripping off woocommerce's directory structure but I feel its clear and concise.

Are you able to tag a new stable release? Or a 0.x if not willing to commit to 1.x+?

Add support for Google Analytics A/B testing. I recall this being done through URL vars but will have to research this more. An A/B test could enable/disable a feature flag.

Please can you tag a new release since #30 was merged.

The reason behind this is we have new relic alerts set up and currently they're constantly firing due to the PHP warning from this plugin. We therefore want to upgrade it to include this fix.

Thanks!

I should write some automated tests to ensure plugin is operating properly with every update. I currently know nothing about automated PHP testing but a good reason to start. Following conditions should be tested as a start:

• On install - Check new DB tables are initialised correctly.
• On uninstall - Check DB tables are removed correctly.
• Test previewing flags
• Test publishing flags
• Test flag groups (full CRUD)
• Test checking group query strings
• Test previewing groups

There needs to be an appropriate error handling mechanism for flags that are declared with the duplicate keys. This should display an error report in the admin area with trace information and a message saying which call was used.

Personally, I think this should use the first declaration found and then ignore all others and then error appropriately via the admin screens and wp_debug if enabled.

Just noticed this feature while trawling the documentation. We should add this to explain the different features and components in the admin area.

See WordPress developer documentation for more: Add contextual help screens

Add the functionality/support of the WordPress screen options tab to hide/display certain fields in the feature flag interface.

The current implementation uses a flakey gulp script to compile SCSS to CSS used in the plugin. Should investigate a more robust approach to this avoiding NPM security issues as much as possible. Probably just use lessc or the command line versions if we thought this was useful.