We're calling it without the third, $version, parameter in places.

Example

On wpcom, we're auto loading wpcom-helper.php, which itself sets up an autoloader to include some UI code (such as Post_Selection_UI).

This is required to prevent fatals.

Depending on what direction we take with Shared Plugins, this may be a moot point...but should be addressed if we continue to provide the plugin.

The email wording to the first user includes:

Username: blahblahblah
Password: The password you chose during the install.

We should change this to tell the user to use the forgotten password routine, or perhaps trigger a forgotten password email instead of this email, so they can directly set their password.

We should use the Jetpack Photon module everywhere, but in production, we should use the VIP Go instance of Photon, for some performance and caching benefits.

This means we should filter jetpack_photon_url in production to use the VIP Go urls (which look like regular files urls, with <domain>/wp-content/uploads/...?<params> instead of 'regular' Photon urls.

We should use the Jetpack filters to identify all sites which aren't on VIP Go production infrastructure as staging sites.

This should help when a developer takes a verbatim backup of the data, imports it locally, and causes a Jetpack identity crisis.

Trying to send mail from the Lost Password flow results in:

The e-mail could not be sent.
Possible reason: your host may have disabled the mail() function.

Trying to send a verification email from the support plugin silently fails, and the mail never arrives.

I have tested and BuddyPress emails currently aren't being delivered. Regular WordPress core emails are.

In the upcoming BP 2.5 release, we totally re-implemented how emails are sent. We do not use wp_mail(). We still use phpMailer, but not the global $phpmailer instance of it that WordPress sets.

I see VIP Go uses a helper plugin to configure the phpMailer instance: https://github.com/Automattic/vip-mu-plugins-public/blob/master/vip-mail.php hooked to action phpmailer_init. BP 2.5 has a very similar action that works in the same way: bp_phpmailer_init.

See https://github.com/wpcomvip/buddypress-core-test/issues/5

Query Monitor optionally sets a cookie which allows viewing Query Monitor information on requests where the user is not logged in. We should set no-cache headers on these requests, so the responses (with QM information) don't get caught in caches like Varnish.

johnbillion/query-monitor#170

We should initially patch this here, then also send a PR against the Query Monitor repo issue above.

https://github.com/mboynes/debug-bar-query-count-alert

We don't need to be the gatekeepers of that data, as long as we are careful of what we expose there (absolute paths, other sensitive info).

That would take finding slow queries out of the VIP realm and into client-land.

WPCOM_VIP_Plugins_UI::validate_plugin() doesn't pass for plugins that don't fit the $plugin/$plugin.php pattern, such as WP-API.

This function needs rewritten to allow those, as they are valid plugins, according to get_plugins(), which is what is used to build the list.

See: https://github.com/Automattic/vipv2-mu-plugins/blob/13f18104e7e54428bbe34f0e061abb766277721d/a8c-files.php#L15-L16

FILE_SERVICE_ENPOINT should be spelt FILE_SERVICE_ENDPOINT

Would be good to fix this, in case of accidental correct spellings. 😃

Should all be submoduled instead of committed directly, when possible.

Ideally we can replace the security.php file with Brute Protect.

It would be useful to be able to specify loading a Jetpack beta, or even a specific branch.

Include the require file

Replaces all our current patches on VaultPress

Currently we identify A11n users by having them verify their A8c email address. This is 👍

Then we store the fact they've verified their email in meta, where any developer or person with CLI access could add spoofed data. This is 👎

We should have a way to determine if someone is an A11n, probably by looking at whether they are proxied or not.

It would be useful for us to be able to purge the Varnish cache for pages and/or files from a CLI command.

Some args that would be useful for this:

• local (i.e. sandbox) vs global (i.e. "production) caches
• full cache vs specific URL

Instead of using get_plugins() to load a given plugin (via slug), which is a slow function and sub-optimal from the frontend, we should:

• support 'common' non-standard plugin file paths, such as $folder/plugin.php
• support loading a plugin via file path (passing the $folder/$plugin.php to wpcom_vip_load_plugin())

Since everything is in version control, there should never be a UI to upload or browse themes to install.

/wp-admin/theme-install.php

Those want to have their own files, so let's ignore (at least)

README.md
CONTRIBUTING
HACKING

(the last two don't exist right now, but could in the future).

It should be possible to optionally force Akismet and VaultPress to not load in a local development environment.

At the minimum:

/*
Plugin Name: <Name>
*/

NR will inject the client side JS to the page by default, but that breaks the idea of AMP (and AMP validation), so we should disable it automatically on AMP pages.

Props to @mjangda for this code snippet:

add_action( 'pre_amp_render_post', function() {  newrelic_disable_autorum(); } );

We probably also want to expose this functionality as a wpcom_vip_ helper function that clients can use anywhere. h/t @david-binda and @sboisvert

I think we should switch the priority to:

1. /wp-content/plugins/
2. /wp-content/mu-plugins/shared-plugins/

I think this means swapping these two lines:

https://github.com/Automattic/vipv2-mu-plugins/blob/master/vip-helpers/vip-utils.php#L996-L997

This means people can override the general (our MU plugins) with the specific (their site repo). Any objections, @nickdaugherty ?

MU Plugins got deployed today, but QM doesn't seem to be spinning up.

I tried forcing wpcom_vip_qm_enable to true on for test-03.go-vip.co but still no-go.

Should be prefixed - WPCOM_VIP_Cache_Manager.

Was: https://github.com/Automattic/vipv2-support (private)
Now: https://github.com/Automattic/vip-support (public)

Error:

phpunit
Installing...
Running as single site... To run multisite, use -c tests/phpunit/multisite.xml
PHP Fatal error:  Class 'WP_REST_Server' not found in /tmp/wordpress-tests-lib/includes/spy-rest-server.php on line 3
PHP Stack trace:
PHP   1. {main}() /home/travis/.phpenv/versions/5.5.21/bin/phpunit:0
PHP   2. PHPUnit_TextUI_Command::main() /home/travis/.phpenv/versions/5.5.21/bin/phpunit:722
PHP   3. PHPUnit_TextUI_Command->run() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/TextUI/Command.php:104
PHP   4. PHPUnit_TextUI_Command->handleArguments() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/TextUI/Command.php:114
PHP   5. PHPUnit_TextUI_Command->handleBootstrap() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/TextUI/Command.php:622
PHP   6. PHPUnit_Util_Fileloader::checkAndLoad() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/TextUI/Command.php:792
PHP   7. PHPUnit_Util_Fileloader::load() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/Util/Fileloader.php:42
PHP   8. include_once() phar:///home/travis/.phpenv/versions/5.5.21/bin/phpunit/phpunit/Util/Fileloader.php:58
PHP   9. require() /home/travis/build/Automattic/vipv2-mu-plugins/tests/bootstrap.php:15
PHP  10. require() /tmp/wordpress-tests-lib/includes/bootstrap.php:101

See Automattic/Co-Authors-Plus@7f70994 for a possible solution

deleted_term_taxonomy action only takes the $tt_id param, we're expecting a $term_id and `$taxonomy

https://github.com/Automattic/vipv2-mu-plugins/blob/c18b9a4d5f36e7d9da250ee1382d64c94956e476/vip-helpers/vip-caching.php#L118

http://wpseek.com/hook/deleted_term_taxonomy/

Query Monitor has been asked for a few times now, but we've traditionally limited access to these tools because they disclose too much information about our systems (full server paths, namely).

Fortunately, Query monitor uses relative paths throughout its output, and allows panels to be removed via remove_filter() calls, so we can suppress the environment panel, at the least.

/wp-admin/admin.php?page=vip-plugins shows 2 plugins tables, one for plugins from wp-content/plugins, the second from non-FPP shared plugins.

This is confusing, and the first table is the Core plugins table, which doesn't respect loading plugins via code, which is another issue.

All need prefixed, like wpcom_vip_login_limiter, wpcom_vip_login_limiter_on_success...

removed not need parm ($user) from the function as the calling action doesn't pass it

– Automattic/vip-go-mu-plugins-built#1

Some tidying work proposed by a VIP client developer.

Just like the debug bar on wpcom, we should see full PHP backtrace for the code that called each query, to track down where slow ones are coming from.

Not all plugins follow the $plugin/$plugin.php convention, including shared plugins.

By requiring that rigid filepath, we prevent submoduling some shared plugins (like WP-API), as we can't add our own bootstrap file there.

We're using get_plugins() internally to get valid plugins, so we should support loading any plugin that it returns, regardless of path to plugin file.

We should have names and descriptions for VIP mu-plugins.

https://cloudup.com/c-hpvhPFrwk

Patterns like this do not allow unhooking, we should refactor to allow developers to unhook the functionality (e.g. remove_action) if they wish to. Perhaps using a singleton pattern?

Fatal error: Call to undefined function get_plugins() in wp-content/mu-plugins/vip-helpers/vip-utils.php on line 970

This happens because get_plugins() hasn't been included on the frontend, as it's defined in wp-admin/includes/plugin.php.

get_plugins() is used to properly load plugins that don't have a 1:1 folder name -> php file correlation; i.e, it finds the right plugin file to load.

Adding require_once( ABSPATH . 'wp-admin/includes/plugin.php' ); to vip-helpers/vip-utils.php works - thoughts?

We should really be triggering a fatal error when wpcom_vip_load_plugin bails. This will print a backtrace in dev environments, which makes it much easier to debug.

This plugin is loaded in code, but the Plugins UI shows:

https://cloudup.com/c7SLMT5E-Np

This is because we're just printing the core plugins table here, instead of a custom one that includes logic for plugins loaded in code.

See #105

48495b9#diff-2c060c3aba4d888f535c9173a3c0b81d

Many SSL issuers allow you to use domain validation for an SSL, typically by having your website at the domain respond with a particular string at a particular path.

We should make it easy to define the path and string, so we can efficiently validate sites on our platform for SSL.

Was: https://github.com/Automattic/vipv2-jetpack/ (private)
Now: https://github.com/Automattic/vip-jetpack/ (public)

https://github.com/Automattic/vip-mu-plugins-public/blob/master/a8c-files.php#L369 et al

$requests isn't defined.

See wpcomvip/buddypress-core-test/issues/8

It's not compatible with V2 (it requires batcache).

We can make it V2 compatible later, if there is demand.