stackpath/stackpath-wordpress

Place your WordPress site behind the StackPath edge network

StackPath WordPress Plugin

Place your WordPress site behind the power of the StackPath edge network. This plugin gives you performance analysis at-a-glance, web application firewall (WAF) control, and origin monitoring to ensure site uptime, reliability, and speed.

Once installed, this plugin scans your StackPath account for a matching site or lets you make new service to put in front of your WordPress installation. After the plugin is linked to your StackPath site you have the ability to:

• See overall and per-location CDN bandwidth and request metrics.
• Purge content from the CDN cache all at once, by path, and automatically as you change your site's content.
• Optionally skip CDN caching of requests with common WordPress cookies in them.
• See WAF analytics and recent security events against your site.
• Place the WAF into monitoring mode to enable and disable firewall service.
• Configure denial of service protection.
• Block access to your WordPress installation's admin area except for an allowed list of IP addresses or IP ranges.
• View your WordPress installation's uptime as monitored by StackPath's global edge network.

Please Note: This plugin is currently in beta. The following features are still in development:

• Installation from the admin area's plugins page
• Creating new StackPath service
• Firewall control and reporting
• Monitoring reporting

Requirements

• An active StackPath account with API credentials. Visit the API management page in the StackPath customer portal to generate yours.
• An active site on your StackPath account. This won't be a requirement after the beta period.
• A working WordPress version 5.3.0+ installation running at least PHP version 5.6.

Installation

From WP-Admin

Coming soon!

From Releases

Releases are zip files that contain the plugin built without testing, editor, GitHub, and other build files. Install from a release file to use an older or test version that's unavailable on the WordPress plugins directory.

• Create the wp-content/plugins/stackpath-wordpress directory in your WordPress installation.
• Download and extract the latest release zip file to the wp-content/plugins/stackpath-wordpress directory.

From Source

Checking out the project from this repository is a great way to try out a bleeding edge version of the plugin or to contribute to the plugin. Installing from source requires the composer dependency management utility.

• Create the wp-content/plugins/stackpath-wordpress directory in your WordPress installation.
• Check out this project's source into the wp-content/plugins/stackpath-wordpress directory.
• Run composer dumpautoload -o to generate the plugin's class auto-loader or run composer install --dev to build the autoloader and install all development utilities like phpunit and phpcs.

We do not recommend installing development utilities on a live site.

Usage

1. Navigate to your WordPress installation's admin area. If the plugin is installed there should be a "StackPath" item in the menu on the left-hand side.
2. Click that link and run through the setup wizard to link the plugin with your StackPath account and services.
3. After the plugin is installed the StackPath menu item will have sub-menus to view and control your site's behavior on the StackPath network.

Debugging

Set WP_DEBUG to true in your WordPress installation's wp-config.php file to enable a debug display in the "More" dropdown under the StackPath logo. This debug information includes some system information, a list of WordPres plugins installed, and the StackPath plugin's configuration.

Set WP_DEBUG and WP_DEBUG_DISPLAY to true to display low level StackPath API call information in non-AJAX error messages.

Set WP_DEBUG to true and set WP_DEBUG_LOG to a valid value to report low level StackPath API call information to WordPress's error log.

Contributing

We happily accept pull requests! Check out our contributing guide if you'd like to help out.

stackpath-wordpress's Issues

Error on upgrade to PHP 8

Hi, when trying to upgrade to PHP 8, we get this error for some admin users. This is on every /wp-admin/* based pageview while an admin is logged in.

I don't see this error myself with an Admin role, but our content manager does while logged in to his Editor role.

PHP Fatal error: Uncaught TypeError: array_shift(): Argument #1 ($array) must be of type array, null given in /wp-content/plugins/stackpath-wordpress/src/WordPress/Plugin.php:191
Stack trace:
#0 /wp-content/plugins/stackpath-wordpress/src/WordPress/Plugin.php(191): array_shift(NULL)
#1 /wp-includes/class-wp-hook.php(307): StackPath\\WordPress\\Plugin->StackPath\\WordPress\\{closure}('')
#2 /wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array)
#3 /wp-includes/plugin.php(474): WP_Hook->do_action(Array)
#4 /wp-admin/includes/menu.php(155): do_action('admin_menu', '')
#5 /wp-admin/menu.php(394): require_once('/nas/content/li...')
#6 /wp-admin/admin.php(158): require('/nas/content/li...')
#7 /wp-admin/index.php(10): require_once('/nas/content/li...')
#8 {main}
 thrown in wp-content/plugins/stackpath-wordpress/src/WordPress/Plugin.php on line 191, referer: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1

Unfortunately, I've had to disable the StackPath plugin as I made some other changes that don't allow us to downgrade back to PHP 7.4 easily.

Error activating plugin

Hi, I am unable to activate plugin:
https://marketinados.us-central-1-s3.netdepot.com/Screenshot%20at%20Nov%2019%2018-23-43.png

Feature request: non-recursive cache purge

At present, the plugin states, If the path is a folder, then all files in that folder will be purged from the CDN. This is a problem when trying to purge only the home page, as it seems everything gets purged when specifying / in the "Custom Purge" box. It would be helpful to, at a minimum, have a way of purging URLs (like in the SP control panel) that purges only the URL, versus only paths.

Critical errors on WordPress 6.2

This plugin will generate a critical error in various places on WordPress 6.2 (and presumably newer) due to its reliance on/assumption that the Requests_Response class is being used by WordPress, when converting Responses to Stackpath's own Response class.

I'll be creating a PR shortly to address the critical errors, though there are other refactors necessary since Requests_Response has been deprecated for awhile now in favor of WpOrg\Requests\Response.

Unable to search for your StackPath site

I have created a site on StackPath. Changed DNS (A, CNAME) record to StackPath. I've entered the correct API client and secret. When I click on submit, this is the error I get -
Loading account stacks
Loading sites from SSL test error Unable to load sites
Unable to search for your StackPath site. Please refresh this page and try again.

I've opened a support ticket with StackPath and included this url and asked them to forward it to you. The support ticket includes the website details along with temporary access. Let me know if you need anything else.

WordPress - 5.4.1
PHP - 7.3.14
Server - Apache
Hosting - GoDaddy Web Hosting with cPanel

Composer support

Hi, I tried adding this Git repo to Composer:

{
  "name": "yadda/yadda",
  "license": "proprietary",
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/stackpath/stackpath-wordpress.git"
    }
  ],
  "extra": {
    "installer-paths": {
      "wp-content/plugins/{$name}/": ["type:wordpress-plugin"]
    }
  },
  "require": {
    "stackpath/stackpath-wordpress": "master"
  }
}

But I get this error when running composer update:

[Composer\Repository\InvalidRepositoryException]                                                                                                  
  No valid composer.json was found in any branch or tag of https://github.com/stackpath/stackpath-wordpress.git, could not load a package from it.

Same issue if I specify a Git tag.

WordPress "logged-in" cookie list is missing a wildcard

I noticed while using StackPath in conjunction with this plugin that, in some cases, logged-in users were still seeing cached content, and that content behind a login form (e.g. members-only resources) were being cached and therefore available to anyone else browsing that URL via a node that had a copy of that cached page. This was despite the fact that we had the "Bypass Cache for WordPress Cookies" feature enabled, and I confirmed via API that the settings were indeed present on the StackPath side.

The issue seems to be that the cookie list was incomplete. It's set to:

wp-*, wordpress, comment_*, woocommerce_*

but in many cases, the only cookie present is a wordpress_logged_in_* (aka, the LOGGED_IN_COOKIE one), and so the cache was being invoked.

I think that the wordpress string in the cookie list is meant to be wordpress_* instead, which would cover the default value for LOGGED_IN_COOKIE as well as AUTH_COOKIE, SECURE_AUTH_COOKIE, and TEST_COOKIE. In my tests, using wordpress_* instead of wordpress solves the issue, so I'll be submitting a PR shortly to address that.

Fatal error trying to decode unknown error detail formats

Hi.

I've just installed this plugin on 2 websites, and on one of them it causes an issue.
7772#0: *2010 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Object of class stdClass could not be converted to string in /var/www/vhosts/domain.com/httpdocs/wp-content/plugins/stackpath-wordpress/src/Exception/API/RequestException.php:167
Stack trace:
#0 /var/www/vhosts/domain.com/httpdocs/wp-content/plugins/stackpath-wordpress/src/Exception/API/RequestException.php(167): implode()
#1 /var/www/vhosts/domain.com/httpdocs/wp-content/plugins/stackpath-wordpress/src/WordPress/Message.php(50): StackPath\Exception\API\RequestException->detailedErrorMessage()
#2 /var/www/vhosts/domain.com/httpdocs/wp-content/plugins/stackpath-wordpress/src/WordPress/Plugin/PostActions.php(222): StackPath\WordPress\Message::fromException()
#3 /var/www/vhosts/domain.com/httpdocs/wp-includes/class-wp-hook.php(287): StackPath\WordPress\Plugin->bypassCacheOnWordPressCookieAction()
#4 /var/www/vhosts/domain.com/httpdocs/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters()
#5 /var/www/vhosts/domain.com/httpdocs/wp-includes/pl" while reading response header from upstream
That only happens when I hit save button for Bypass Cache for WordPress Cookies