flarum / issue-archive

0 stars 0 forks source link

TextFormatter cache does not change drivers #154

Open tankerkiller125 opened 3 years ago

tankerkiller125 commented 3 years ago

Flarum is storing the TextFormatter classes in the filesystem cache regardless of if you change the driver to something else (say redis) this makes scaling Flarum up on large systems hard if you need to clear the TextFormatter cache as it won't clear on all of the servers.

This was previously hard coded for a reason but a solution will need to be found in order to scale Flarum for large communities. The main issue here is that TextFormatter needs the classes to be SPL autoloaded.

luceos commented 3 years ago

The Formatter stores by default to the filesystem cache storage/cache a cache key flarum.formatter containing an array of renderer, parser and js. Then on each call when the renderer is retrieved it will inject to the spl_autoload_register function the cache directory storage/formatter.

Then when using the render method on the formatter, eg on the Post class the renderer component will be retrieved executing above logic even if the randomly generated Renderer class isn't available on disk.

This throws the __PHP_Incomplete_Class error: https://discuss.flarum.org/?q=__php_incomplete_class.

The file is missing

So the underlying issue here is that for some reason the file wasn't written to cache/formatter or was removed. Or maybe since the last version was written a new one exists and the old one wasn't invalidated. An easy solution for this would be to check if the getComponent('renderer') returns an __PHP_Incomplete_Class. If so, load from cache and write again or throw if that writing fails.

Horizontal scaling

The above solution is interesting, but not perfect. If one node stores the flarum.formatter cache key to storage/cache then another cannot access that directory unless both share the same disk (not recommended). Centralizing storing the renderer and its version (revision) similar to the logic in the RevisionCompiler children would help.


I don't think having an spl autoload class is necessarily a bad thing. I do think that caching and invalidating the renderer needs to be handled centrally so that nodes can restore/retrieve the newest versions.