Forum Replies Created

Viewing 15 replies - 16 through 30 (of 254 total)
  • Plugin Author digitalpoint

    (@digitalpoint)

    Maybe… I don’t see anything from skimming the code, but I didn’t go so far as to install it. Either way, the underlying issue does seem to only be an issue with some combination of multiple other plugins installed. One is making all notices dismissible, and the other is then hiding dismissible notices.

    Plugin Author digitalpoint

    (@digitalpoint)

    Well, I couldn’t help but check. That plugin really is only adding a tiny bit of CSS. Interestingly, none of that CSS would cause what you are seeing though. That page *does* make use of the WordPress .notice CSS class, but it’s not using the .is-dissmissible class, so nothing should be hidden even with that plugin.

    One possibility I can think of is a *different* plugin is altering non-dissmissible notices, and making them dismissible. Then that plugin would do what you are seeing.

    Plugin Author digitalpoint

    (@digitalpoint)

    Great!

    I was going to install it and try to figure out why it thinks that particular page is a notice, but I might just let this one go considering it’s been half a decade since it’s been updated (for WordPress 3). 😂

    Plugin Author digitalpoint

    (@digitalpoint)

    Hmmm…. Honestly never have seen anything like that. Is it only that one page (are other pages looking as expected)?

    Is there any unusual showing in the browser console when you are on that page?

    Plugin Author digitalpoint

    (@digitalpoint)

    There shouldn’t be a reason coming from this plugin. If you have guest page caching enabled, putting the site into development mode (on Cloudflare’s side) will bypass the edge cache for you. You can also just purge the entire cache if you think it’s a case where some stuff is in Cloudflare’s cache.

    But fundamentally, there’s really nothing this plugin does that changes files or structure or anything along those lines. The exception to that would be the Pro version of this plugin does allow you to store images in a Cloudflare R2 bucket, so they wouldn’t exist locally in the filesystem, but if you aren’t doing that with the Pro version, then it’s not that.

    Are you able to dig into the specifics of what’s failing? Like is an image missing via the web request, but exists in the expected place in the filesystem? Should be able to narrow down if it’s a missing file, or the web server looking in the wrong place or something at least.

    Plugin Author digitalpoint

    (@digitalpoint)

    I assume you figured it out since it marked as resolved, but just in case someone else stumbles on this thread:

    https://ww.wp.xz.cn/support/topic/version-1-9-6-new-permissions-needed/

    Plugin Author digitalpoint

    (@digitalpoint)

    When I test that URL, I get the expected result of: cf-cache-status: HIT

    Have you tried a new Incognito window to make sure there isn’t something in your browser session that could be making it fetch a non-cached version? Normally that would just be if you were logged in, but there’s a few other things that could cause it (like a guest leaving a comment on a post).

    Normally, EXPIRED means exactly that (that there is a cache available in Cloudflare’s server, but the cache is expired). I did see some strange headers in your site… for example something is setting a directive saying the page expired in 1981 (that header isn’t coming from this plugin).

    Plugin Author digitalpoint

    (@digitalpoint)

    Gross.

    It was a bit of a unique situation where the method was misplaced, so it worked in some scenarios (including testing), but not others.

    I went ahead and pushed out a new version (1.9.6.1) with the fix (sorry about that).

    Plugin Author digitalpoint

    (@digitalpoint)

    It’s under Public Page Caching. There is a toggle to enable it.

    Plugin Author digitalpoint

    (@digitalpoint)

    Yes, that’s correct.

    Plugin Author digitalpoint

    (@digitalpoint)

    It’s done with a single Cache Rule that tells Cloudflare to consider all requests as cache “eligible” (eligible doesn’t necessarily mean all requests will be cached). Then the plugin can make the determination for which requests should actually be cached and passes that determination along to Cloudflare by adding the appropriate Cache-Control HTTP headers.

    APO probably made more sense for Cloudflare to rollout at the time, because Cache Rules weren’t a thing back then. Today, APO doesn’t make a ton of sense as a subscription (probably why they haven’t updated their APO plugin in a very long time).

    Plugin Author digitalpoint

    (@digitalpoint)

    Can’t think of anything that would slow anything down. No API calls (including purge cache) should be made in the same PHP thread as a post deletion. The purge cache call is intentionally spun out to a separate cron task for exactly that reason (so it runs as a separate background process that doesn’t slow anything down).

    Plugin Author digitalpoint

    (@digitalpoint)

    I haven’t tested that Worker code (I also don’t have LiteSpeed installed anywhere), but I don’t see anything in there that would interfere with this plugin.

    If your Cloudflare zone is on a paid plan (anything except “Free”), you may want to look at Snippets. They are lightweight Workers that have no per request cost (Workers are free for up to 100,000 requests/day, but there’s a cost after that). That’s fairly simple Worker code, so should work just fine as a Snippet.

    Plugin Author digitalpoint

    (@digitalpoint)

    1. There isn’t anything that would make it automatically incompatible, but the things you can do with Workers is basically limitless. If a Worker is doing things like altering Cache Control headers, it certainly could interfere with parts of the plugin. Again, not inherently incompatible, but it really would depend on what the Worker was doing to the underlying HTTP request.
    2. This plugin handles things like browser cache already. It’s probably not a great idea to have two plugins trying to do the exact same thing, but it would *probably* be okay. Might be a little weird if you think one plugin is doing something specific (like setting length of time for browser cache), then the other plugin sets it to something different. Handling it with multiple plugins isn’t going to make it better/faster or anything, only slightly slower (double the code running) and possibly confusing when one plugin uses its settings when you expect the settings from the other one.
    3. I personally wouldn’t, but it would be specific to your site. It would make sense to benchmark it and see if having what is effectively a cache for a cache makes your site faster or slower. This plugin avoids the request even going to your origin server when it can (serves direct from Cloudflare data center closest to the user), so there may not be a ton of value in having a cache that resides on your origin server.

    Yep, you are basically creating a cache for a cache. Seems like a lot of added complexity and potential for something to break for little upside. Maybe there are cases where a site gets a crazy amount of traffic (like thousands of page views per second) and a secondary cache that is automatically distributed to multiple web servers and generated before requests are made for the pages or something. I could see edge cases like that where it makes sense. But best thing to do is benchmark it and see if having a cache for a cache is beneficial for your site or not.

    Plugin Author digitalpoint

    (@digitalpoint)

    Going to go ahead and close this one out (feel free to reopen or continue discussion if anything else comes up). I finished what I wanted to finish for the Turnstile stuff, so I’m shooting for a late Monday next version release, which will include the thing for Image Transformations on sites outside of the root domain.

Viewing 15 replies - 16 through 30 (of 254 total)