stackpath / stackpath-wordpress Goto Github PK

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

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.

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.

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

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.

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.

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

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.