Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter Peter Egelberg

    (@egelberg)

    Saumya,

    I want test the build locally on my laptop first. How can I enable just the preloading and local caching without enabling Cloudflare caching?

    One my laptop the plugin is configured identically to how our site is configure but with a nonsense api-key to keep my laptop from altering the live CF settings. Right now the plugin refuses to enable the local cache after updating the plugin as it receives an error from CF.

    Can I put the plugin in some “ignore CF error” debug mode or do I need to patch the code somewhere.

    Thread Starter Peter Egelberg

    (@egelberg)

    100% correct! It would allow the theme to only keep parameters that are known to affect page output.

    Furthermore, if you allow swcfpc_fallback_cache_get_current_page_cache_key to return false the filter could tell you when the theme doesn’t want the url to be cached by returning a falsy value. When there is a filter and to make it less confusing, I suppose it would be sensible to ignore the configuration settings that determine if a url should be cached. The filter can check the cookies as well, if needed.

    In other words, when there is a filter, it takes on the responsibility of deciding which urls to cache and preload.

    If well written, such a filter would make it much harder to overload the server deliberately or by mistake by repeatedly requesting a page with a varying query string. For many businesses, it is not an option to only cache ulrs that do not have a query string, as url parameters are used to assess the efficiency of email marketing campaigns.

    I would be happy to test it out on our site https://phiab.com and in one of our email campaigns.

    Thread Starter Peter Egelberg

    (@egelberg)

    Yes, that would also work. But it suppose the simplest solution is not to add the / to result of reg_replace so $cache_key is always calculated without a trailing /.

    By the way, a possibility to filter $current_uri just before $cache_key is calculated would be really nice. It would allow the theme to remove parameters that doesn’t affect the page output, like the utm parameters. The current method would then be the default filtering when there is no filter.

    We use customers ids from our CRM system in our mail campaigns to identify that a mail recipient has visited our website. Without a filter we must add a dummy utm parameter so that the entire query string is removed, otherwise each visit to the same landing page will generate a new cache file. An innocent mail blast from the marketing department can thus result in thousands of identical cache files as each mail contains the same url but with a unique customer id parameter.

    Thread Starter Peter Egelberg

    (@egelberg)

    Yes, but the $cache_key of https://example.com/sample/ will be based on https://example.com/sample without a trailing / as swcfpc_fallback_cache_remove_url_parameters only adds a trailing / when there is a utm parameter after removing the query string with the preg_replace.

    swcfpc_fallback_cache_remove_url_parameters doesn’t do anything if there is no utm paramaterer. It just returns $current_uri without a trailing /, which was removed before the call swcfpc_fallback_cache_remove_url_parameters.

    When https://example.com/sample/, $cache_key is based on https://example.com/sample.
    When https://example.com/sample/?utm_campaign=test, $cache_key is based on https://example.com/sample/, which results in two different but identical cache files.

    Thread Starter Peter Egelberg

    (@egelberg)

    Hi Saumya,

    Yes, that may be true, but the code first removes unwanted trailing / and reintroduces a trailing / when there is an utm parameter, creating a different cache filename for the same path:

    // Remove trailing /
    if( substr($current_uri, -1, 1) == '/' )
      $current_uri = substr($current_uri, 0, -1);
    
    $cache_key = str_replace( $replacements, '_', 
    swcfpc_fallback_cache_remove_url_parameters($current_uri) ); // If utm parameter, replace query string with trailing /. 
    
    // Create cache filename
    $cache_key = sha1( $cache_key );

    This seems to be a general problem. After including

    "settings": {
        "layout": {
          "contentSize": "768px",
          "wideSize": "1024px"
        },

    in theme.json only the top-level headings will have the wide/full alignment option. When a heading or any other alignable block is inside a group/container block, only the alignment option None is shown in Gutenberg 11.7.0. In Gutenberg 11.6 the alignment button was completely missing. Additionally, old alignment set without theme.json are ignored in the editor but not in page preview.

    The simplest way to recreate the problem is to group a heading. Without theme.json it is possible to align the heading. With theme.json it is not.

    This issue makes it impossible for us to transition to theme.json, as close to all pages contain wide or full alignment inside a group block.

Viewing 6 replies - 1 through 6 (of 6 total)