Surge is a very simple and fast page caching plugin for WordPress.

I'm trying to cache a WP Rest API response that calls to a 3rd party API, the 3rd party API takes few seconds to query.

Surge caches the response by default, everything is fine, except if I want the Rest API to hit the 3rd party API again after the max-age expires.

Looks like Surge only checks for no-cache and max-age=0, are there any plans to support variable number of max-age like header( 'Cache-Control: max-age=60' ); ?

The values in the config array are hardcoded. Sometimes, it could be useful to change the values.

The hook surge/config (but name can be changed if required), allows values to be changed.

Upon install, whatever the value of WP_CACHE is in wp-config.php is removed it would be good to be able to disable this behaviour, useful for cases where config is configured from env vars and plugins are installed as part of a build process for example.

I'm happy to provide a PR, but just wanted to run it by you first. Would you be happy with wrapping in a conditional with a filter?

Some users reported a PHP warning in foreach() in include/serve.php on line 76, which is the loop through the headers, saved in the cache metadata. It seems like in some cases, when WordPress doesn't send any headers at all, or only ones that we choose to skip:

https://github.com/kovshenin/surge/blob/main/include/cache.php#L39

The $headers variable is never defined as an array, and is thus saved as null in the metadata, which then causes the warning on display.

Following up on #1 here. Unfortunately the proposed solution in that PR doesn't quite work as part of the configuration code is executed way too early for any WordPress actions or filters to be called. In this PR users are allow dot create their own configuration file, and attach it with the WP_CACHE_CONFIG constant in wp-config.php, for example:

define( 'WP_CACHE', true );
define( 'WP_CACHE_CONFIG', __DIR__ . '/cache-config.php' );

The file itself has access to the original Surge $config but must return a valid configuration array. You can not unset any of the configuration keys, but you can extend them or override them. For example, if you wish to add your own ignored query variable, you would have the following config:

$config['ignore_query_vars'][] = 'custom_query_var';
return $config;

You can prevent the request from being cached by setting the TTL to zero, for example:

if ( false !== stripos( $_SERVER['HTTP_USER_AGENT'], 'googlebot' ) ) {
    $config['ttl'] = 0;
}

return $config;

If you wish to cache mobile visitors in a different cache bucket, you can use the variants array, like so:

function is_mobile() {
    // Your mobile check implementation
    return true; // or false
}

$config['variants']['mobile'] = is_mobile();
return $config;

Looking forward to your feedback @edwinsiebel!

Spotted by @roytanck. Publishing a new post does not invalidate the home page cache (or other related archives) because it's not been flagged with this new post ID. Untrashing a post has the same problem for the same reasons.

Reproduce:

• Make sure home is set to list latest 10 posts
• Prime the home page cache in incognito mode
• Publish a new post
• Check home page, the new post will be missing until the TTL runs out

The published post permalink will still work immediately as it's invalidated correctly by post ID, but things like "latest posts" widgets, etc. will also have a hard time picking up the new post until it expires due to TTL.

In HTTP headers it is allowed to specify the same name. In particular, it can be useful to specify links for preload:

Link: <https://example.com/other/styles.css>; rel=preload; as=style
Link: </theme/styles.css>; rel=preload; as=style

Some info about multiple headers https://stackoverflow.com/questions/3241326/set-more-than-one-http-header-with-the-same-name

Seems like there is some code in Core that converts / to %2F in unknown query arguments performing a redirect, but the redirect is cached under the same cache key as the %2F version, resulting in a redirect loop. Ideally these requests are cached under different keys.

Multiple concurrent requests could be attempting to write flags.json, and the current file_put_contents() approach will blindly overwrite whatever another request may have written at the same time.

In this PR we move the LOCK_EX lock before we're about to read the contents of the file, and release the lock right after we've written to the file. So a concurrent request will wait for the lock to be released, before attempting to read the flags.

This get_post_type_object() call in some cases can return null when transitioning objects of unknown types (auto-draft if I had to guess), causing a PHP notice: Trying to get property 'public' of non-object.

Reported on the forums here.

Should check the $obj variable prior to accessing its properties.

In this PR:

• Flag requests with non-singular queries for a specific post_type
• Flag WooCommerce products to work around various caches
• Invalidate post_type caches on transition_post_status

This is work in progress, some of it related to #2.

Will also need to look at nav_menu_items, because those queries run with suppress_filters by-passing our the_posts. Also a very old but still in-use function get_pages does its own thing, but has some filters we can hook into.

cc @soulseekah

PHP version 7.4.30 Surge version 1.0.4

This combination results in the following PHP warnings

PHP Warning: Use of undefined constant DIR - assumed 'DIR' (this will throw an Error in a future version of PHP) in /var/www/doma.in/config/application.php on line 70

PHP Warning: include(DIR/cache-config.php): failed to open stream: No such file or directory in /var/www/doma.in/content/plugins/surge/include/common.php on line 56

We are using bedrock based structure, hence the content/plugins.

Hi!

While playing around with Surge, I noticed the plugin makes changes to PHP globals at various places:

• https://github.com/kovshenin/surge/blob/e68d4be79ab7fafe54799413962d9ea9a9150768/include/common.php#L143
• https://github.com/kovshenin/surge/blob/e68d4be79ab7fafe54799413962d9ea9a9150768/include/common.php#L115-L118
• https://github.com/kovshenin/surge/blob/e68d4be79ab7fafe54799413962d9ea9a9150768/include/common.php#L107-L108

Is it intended?

Since key() is called on every request, you may end up messing with third party code that relies on those globals and not only on edge cases.

Hey, first of all thanks for the excellent plugin, it works incredibly well out of the box!

I have been poking through the plugin source code and I can't seem to find the logic that disables/prevents caching for logged in users.

What I am hoping is possible is that I can create a custom config file like this Surge Configuration Example. And setup some logic to enable caching for logged in users with a certain custom role (essentially a role that only has frontend access).

If you could point me in the direction of how Surge currently identifies logged in users I'd really appreciate it.

I'm trying out Surge on a low-traffic site and it doesn't seem like crawling is enough to negate the need for preloading. I visited the homepage, recent posts, and main-menu items periodically over the course of an hour, and frequently got cache-misses.

I bumped the TTL to a week as a workaround, but I'm worried that'll still result in a lot of misses. This type of site has ~300 posts, but isn't updated frequently, and is on shared hosting. So I'm more worried about slow load times on the long tail of older posts than I am about edge cases where the cache isn't invalidated fast enough.

Hey 👋🏻   I noticed this:

https://github.com/kovshenin/surge/blob/e68d4be79ab7fafe54799413962d9ea9a9150768/include/common.php#L239

FYI, I dug into that recently for another project, and it seems like it's not possible ☹️

I'd be happy to be wrong if you found something I missed, though!