Something called Plugins UI should only handle Plugins UI :)

Really confusing that it handles loading the plugins also. Means it needs to be included from the frontend on every request, which is def. sub-optimal.

Refactor that functionality out. Really, it needs to be in mu-plugins directly, not part of VIP Dashboard either.

To reproduce:

1. Add a plugin, e.g. Field Manager, to the plugins directory on your repository
2. Activate the plugin via code, e.g. wpcom_vip_load_plugin( 'fieldmanager/fieldmanager.php' );
3. Visit the WP Admin > Plugins screen

Expected: Field Manager should show as activated with a message "Enabled via your theme's code"

Actual: Field Manager shows as inactive, BUT is actually active

WP 4.6 made some changes to the underlying email handling, which necessitated this change:

Automattic/vip-go-mu-plugins#277

The need for that will go away in 4.6.1 (we can set Sender again), but in the meantime, we're sending emails from the wrong address when creating tickets from the dashboard.

Instead, we should be using [email protected], which we set via a header...but with the wp_mail_from filter, the header is overridden, which breaks it.

So temporarily, we should filter wp_mail_from here, and remove the filter after sending is complete.

There are a few performance improvements, as well as a gulp compress command that we should make consistent across all repos.

Deleted my token from local storage, then attempted to log in with GitHub again. Clicked button and got:

{"status":"error","message":"Invalid redirect_uri"}

SyntaxError: Unexpected token '('. Expected a ':' following the property name 'getInitialState’.

Why are we not seeing this locally? Why is it not being caught by testing?

At the moment activating a featured partner plugin does not work as the plugins are not present on the platform.

Right now we've duct-taped the regular plugins list table into the VIP Plugins UI. This is not great because:

• Activate/deactivate still goes through wp-admin/plugins.php, so you end up on the wrong page
• Includes Bulk Actions
• UI does not support loading regular plugins via code - if a plugin has been loaded via code, the UI needs to display that message

We should make a custom list table for regular plugins in the same way we did for shared plugins, and use that here. Currently, we're using the core plugins table, crammed into our VIP plugins page.

That would include replicating some functionality from wp-admin/plugins.php for activation/deactivation, etc.

With the release of shiny updates (https://wordpress.org/plugins/shiny-updates/) in core, we should switch back to the standard plugins screen and find a different way to feature our partner plugins. Perhaps just a nice admin page or area at the top of the current plugins search screen.

Our minimum is to add a form to the dashboard to request collaborator access on GitHub. This should look and function like Zendesk ticket form... in fact I am guessing it will generate a Zendesk ticket so this can be actioned manually.

Further down the road we’ll need some kind of mass user management, possibly by converting the VIP Go concept of clients to organisations and allowing many organisations to be associated with a single site… but possibly not. At this point the widget can be removed.

when you submit a ticket through the VIP Dashboard for VIP Go sites, the ticket priority does not get properly set. When they submitted a “high” priority ticket, it turns up as “normal” in our queue. This was tested and confirmed.

Currently jsx files aren't being linted by jshint and make lint - we need to tweak the config to make it see them as valid files (and parse / lint them as jsx).

While this functionality would be better in the new client dashboard we should allow clients to request review of PRs through this form.

Todo:

• simplify checkboxes in current form (remove current options, have new ticket and review PR options)
• add $group (currently unused) to email subject

It was removed due to ~54 issues in the compiled files - we should figure out how to fix those and bring it back.

Instead of:

Header = React.createClass( {

Let's do:

var Header = React.createClass( {

Some static HTML mock styles have persisted and should be discarded.

This might be a dupe, but I'd like to record it for triaging. I sent the Dashboard out to a few clients, and one came back with this error…

Some errors in the graphql from the main /apps request:

{"operationName":"Apps","variables":{"first":10,"after":null},"query":"query Apps($first: Int, $after: String) {\n  apps(after: $after, first: $first) {\n    total\n    nextCursor\n    edges {\n      id\n      name\n      repo\n      type\n      primaryEnvironment {\n        isMultisite\n        __typename\n      }\n      organization {\n        id\n        name\n        __typename\n      }\n      environments {\n        id\n        name\n        defaultDomain\n        branch\n        __typename\n      }\n      __typename\n    }\n    __typename\n  }\n}\n"}

We currently have the standard dashboard main widget that asks for you to connect to Jetpack, or 'deactivate jetpack'

We probably need to disable that and replace it with our own, plus a nag.

Since it's impossible to disable Jetpack, we shouldn't show that as an option, and we should keep bugging them until they get it connected.

https://cloudup.com/cyr9wkZlaQm

In case an action is hooked to load_plugins action at priority 5 form within a plugin or mu-plugin, the VIP Dashboard fails to load plugins due to a bug in WordPress core

Also, as a best practice, we should never hook more actions to the hook from which the callback is called.

The VIP Dashboard basically initialises the WPCOM_VIP_Plugins_UI class from within plugins_loaded at standard priority 10 and that class hooks the plugin loading logic to the same hook ( plugins_loaded ) at priority 5.

In case something else is hooked to plugins_loaded at priority 5, the WPCOM_VIP_Plugins_UI:: include_active_plugins method never gets invoked.

Not much of a need to keep this as a separate repo.

We need a decent readme.md with details about gulp, dependencies etc.

require __DIR__ . '/plugins-ui/plugins-ui.php'; has to happen not only when is_admin() equals true, but also on frontend requests in order to have plugins successfully loaded and working.

It breaks eg. Safe redirect manager

https://github.com/Automattic/vip-dashboard/blob/master/vip-dashboard.php#L109

It would be better to use add_query_args() along with rawurlencode() when creating the mailto link.

That will also make it easier to late escape, both the url and the link text.

https://github.com/Automattic/vip-dashboard/blob/dee22cd4135da2d12d30a9eafa87b8f53bdc82c3/vip-dashboard.php#L280

The code was updated locally but never pushed on a new branch.

1. There's a random comma that's hard to see, but comes from this line.

2. The styling of the VIP admin page, to make the top-header full width, removes some default padding on the page.

Here's what the lockout message looks like on the WP default Dashboard page (notice the gap between the right edge of the admin menu, and the left orange strip of the lockout message):

Here's the current view of the lockout message on the VIP Dashboard page (notice there's no gap between the right edge of the admin menu and the orange strip on the left side of the lockout message):

With some amended styling, the top-header could respect the default padding and replicate it on the other side as well:

Is this were I would request the VIP Go sites to have a Go-focused Welcome to VIP widget?

Referring to
https://cldup.com/w41-y16S7Q.png

Links to update for Go sites:
"VIP Go Documentation" -> https://vip.wordpress.com/documentation/vip-go/

"VIP Plugins" - unsure, I'm still thinking on this and "Plugins" link in black bar

"Launch Checklist" -> https://vip.wordpress.com/documentation/vip-go/launch-checklist/

"Your VIP Toolbox" rename to "Accessing VIP Support" -> https://vip.wordpress.com/vip-go-toolbox/ (not yet published)

When someone attempts to activate a plugin containing a fatal error in vanilla WordPress, the plugin is not activated and the UI displays an error message explaining why the plugin wasn't activated.

When someone attempts to activate a plugin containing a fatal error in VIP Go, the plugin is not activated but no error message is shown.

An error message should be displayed as it is in vanilla WordPress.

We should minify the built JavaScript file

This is replaced by the VIP plugins page - we should prevent access to the core page.

A couple of images that were initially used on the static HTML mock have persisted across commits, which are now completely irrelevant and show be discarded.

{"operationName":"GenerateTokenMutation","variables":{},"query":"mutation GenerateTokenMutation($input: UserTokenGenerationInput) {\n  generateUserToken(input: $input) {\n    jwt\n    __typename\n  }\n}\n"}

Response with 401 header:

{"status":"error","message":"Unauthorized"}

That indicates to jshint that your script is using ES 6 syntax, which not all browsers support fully...so it should flag it as an issue.

http://jshint.com/docs/options/#esnext

When trying to add a new domain in the App dashboard (https://dashboard.wpvip.com/apps/{site_id}/domains/production) in the Firefox browser, the browser stops accepting new characters and freezes.

This occurred with multiple

• Site IDs
• character counts

How to reproduce:

• Open Firefox (my version is 72.0.1)
• Navigate to the Domain panel on the App Dashboard
• Click on plus sign to add domain
• Begin typing a string of characters into the text field to the left of the "Add Domain" button

This issue seems specific to Firefox and did not occur on Chrome or Safari.

103632-zen

Core > 4.3.0 ends up calling WP_List_Table::get_columns() via WP_List_Table::get_column_info() -> WP_List_Table::get_primary_column_name().

If WP_List_Table::get_columns() is not overridden, die() is called:

public function get_columns() {
    die( 'function WP_List_Table::get_columns() must be over-ridden in a sub-class.' );
}

This breaks the plugins UI page (though Featured Plugins still work).

Is currently wpcom-vip-plugins, the Dashboard is linking to vip-plugins. I like the latter, let's just register the plugins page there.

For a future iteration, since we're not including Stats right now.

Previously in Stats-land: #24

WPCOM_VIP_Plugins_UI::setup_globals references various shared plugins which we've removed, these should no longer be referenced.

Hopefully a simple removal job. 😄

Add a menu icon. My vote is for #tickets or #wordpress-alt https://developer.wordpress.org/resource/dashicons/