Version 1.0.1

[lukasbestle]

Fixes

• Staticache now handles cache values that are set by other plugins (e.g. the Meta plugin by @fabianmichael) more gracefully. sitemap.xml throws error #20

Documentation

• Add more information to the README on required changes to the server setup for custom roots
• The PHP loader example code now also tries to determine the content type from the static files
• Clean up indentation in code examples

---

After merging:

• Create release
• Update https://github.com/getkirby/getkirby.com/blob/main/content/plugins/getkirby/staticache/plugin.txt with new README changes

[lukasbestle]

@jaro-io @jonasfeige @bnomei @fabianmichael Could you please test the develop branch to see if this fixes the issue for you?

[bnomei]

i guess it would work if the plugins do honor the array format the pages cache expects for the data, not a plain string.

[bnomei]

[lukasbestle]

@bnomei Thanks for testing. You are right, this requires additional changes to the plugin. See my comment in #20 (comment).

[bnomei]

apart from that it works. thanks.

[fabianmichael]

@lukasbestle Another issue that still exists is, that the PHP-loader currently does not work for content representations, as it does not send any content-type header on its own … it should be possible to use e.g. PHP’s built-in mimetype functions to bypass the loading of Kirby’s toolkit, though I don’t have any experience with using them. Please be a ware, that this function can throw an E_WARNING that has to be dealt with:

    if ($mime = @mime_content_type($path)) {
      header("Content-type: $mime");
    };
  
    die(file_get_contents($path));

Apart from that, it seems to work great so far. I’ll revert my updates to the meta plugin, so it uses staticache again.

[lukasbestle]

@fabianmichael Which PHP loader are you referring to? Staticache does not provide one, do you mean @bnomei's?

[fabianmichael]

@fabianmichael Which PHP loader are you referring to? Staticache does not provide one, do you mean @bnomei's?

@lukasbestle I’m talking about that loader mentioned in the README: https://github.com/getkirby/staticache/#:~:text=index.php%3F%24query_string%3B%0A%7D-,PHP%20loader%3A,-If%20you%20don%27t

[lukasbestle]

Ah, yes. Completely forgot about that one. 🙈😅

I'll see what I can do. The header mode is certainly more reliable in this case, but automatic detection could already be good enough in 99% of cases.

[fabianmichael]

@lukasbestle It works much better now, but when enabling the headers option, it still fails with virtual pages:

Undefined array key "response" (StatiCache.php L58)

It would probably make sense use automatic testing at this point and provide a few common use cases (built-in pages, content representations, virtual pages) as test scenarios.

I am also wondering, if there are any situations, where one does not want fo use the headers option when using the PHP loader. I guess it’s more performant than using PHP’s built-in mime config and very likely way more reliable (I don’t have much experience with PHP’s mime functions, but there’s probably a reason why almost every CMS has its own implementation).

[lukasbestle]

TBH I feel like we are mixing different issues into the discussion. If this version solves the compatibility issues with your Meta plugin, I suggest we already publish it. We can then work on fixes for any other issues separately for 1.0.2 and in separate GitHub issues.

It works much better now, but when enabling the headers option, it still fails with virtual pages:

Could you please open an issue for that with steps to reproduce?

It would probably make sense use automatic testing at this point and provide a few common use cases (built-in pages, content representations, virtual pages) as test scenarios.

I agree. So far we did not find the time to write tests, but we need them anyway before we can include Staticache in the Kirby core at some point.

I am also wondering, if there are any situations, where one does not want fo use the headers option when using the PHP loader. I guess it’s more performant than using PHP’s built-in mime config and very likely way more reliable (I don’t have much experience with PHP’s mime functions, but there’s probably a reason why almost every CMS has its own implementation).

We already state the performance disadvantages of the PHP loader, but I think you are right: If one wants to use the PHP loader, it is better in most cases to go for the header variant. I've added a note to the README.

[fabianmichael]

Could you please open an issue for that with steps to reproduce?

@lukasbestle Thanks for the update, unfortunately I don’t really have time at the moment for dealing with additional contributions. Test setup for the issue is: Install plainkit, staticache and meta plugin, enable static cache with headers, use PHP loader and point for browser to plainkit.whatever/sitemap.xml to reproduce the issue.

[lukasbestle]

@fabianmichael Ah, I see. If I understand it correctly, this is not actually about virtual pages but about manually storing cache values in the page cache. See #22 (comment).

[bnomei]

its a bit about virtual pages since the sitemap would be treated like a page and be available for apache just like any other statically cached page as html document.
but yes technically its just about storing the data in cache properly.

[fabianmichael]

@lukasbestle @bnomei Would it be safer to just use a custom page model for the Sitemap and a template? That way, caching and rendering would be handled by $page->render() like for any other page? That would probably make the whole implementation more robust and future-proof than trying to replicate that by myself. What would you recommend? It’s probably a good idea to come up with a general solution for virtual pages and add a paragraph to the readme about how to deal with them.

[lukasbestle]

I wouldn't expect changes to Kirby's storage format for the page cache, however I cannot guarantee that we will never need to make any changes there. But if we did, it would be clearly communicated as a breaking change.

So I think both ways are fine: Either you adapt your plugin to the existing storage format for the cache or you perform a larger rewrite (which may be a breaking change for the users of your plugin though).

[bnomei]

i just tested dev branches of both plugins together and it works fine.