[FEATURE]: Dashboard to toggle Alleyvate features

[jakewrfoster]

Description

Not every site will need the EXACT same Alleyvate configuration. This shouldn't prevent a site from using Alleyvate. Currently there are filters for features, but a dashboard would make for a more user-friendly experience. The filters should override the dashboard UX and prevent user interaction with the feature from the dashboard context when set.

Use Case

When a site admin wants to disable a feature in Alleyvate, they should be able to do so quickly and easily without code changes. They also would gain the ability to see all of the features optional features of Alleyvate in on one screen.

[dlh01]

I'm somewhat skeptical that a dashboard for toggling features is appropriate for Alleyvate, for these primary reasons:

• Alleyvate represents "customizations...that are essential to delivering a project meeting Alley's standard of quality," and to allow those customizations to be toggled by an administrator calls into question how essential they are. Moreover, as an administrator, why should I have to think these customizations at all?

• Allowing features to be toggled means that developers can't assume the features are enabled, making the behavior of a site less predictable in the same way that allowing administrators to enable Jetpack modules makes the behavior of a site less predictable.

• There are many planned Alleyvate features where I would be hard-pressed to imagine the benefits that would outweigh the costs of turning the feature off, e.g. [FEATURE]: Remove the “Custom Fields” meta box #23. On the other hand, what features would benefit from being user-controlled more than that would cost?

In line with this last point, perhaps Alleyvate could instead allow a feature to opt in to being included in a Dashboard, so that the default for features was still that they operated without users in the backend having to be aware of them?

[vancoder]

I share @dlh01 's skepticism here, and can't help but think a handful of Alleyvate issues do not conform to the plugin's stated raison d'etre. I see Alleyvate not so much as a suite of optional customizations, and more of an Alley patch, that "fixes" things in core we disapprove of, frankly. The admin users of a site would not normally be the ones deciding if a patch should be applied or not.

Bearing in mind the patch comparison, see also:
#18
#19
#22
#26
#29

[kevinfodness]

We'll discuss during the next tech committee meeting. Generally, I am in agreement that this plugin should use a "set it and forget it" approach, where it's applied with its defaults on all sites we build, and if we have a good reason for turning off a feature (e.g., comments) it's done in code on a per-site basis.

[kevinfodness]

Closing this in favor of #53 which makes the current values of the config options visible while not allowing them to be stored in the database or modified in the admin.