v2.15.6

Fixed

• The self-updater now resets OPcache, so PHP-FPM stops running pre-update code (#425). ApplicationUpdateManager cleared Laravel's caches but never OPcache. With opcache.validate_timestamps=0 (Laravel Forge's OPcache optimisation), PHP-FPM kept the old bytecode for every file it had already compiled, so the site ran a mix of old and new code until PHP-FPM was reloaded. A route cache built afterwards could then name middleware the stale provider never registered, and every page returned 500. opcache_reset() now runs once the files on disk are final: after a successful update, after a rollback, and after a failure that leaves new or half-applied code in place. Inside a PHP-FPM request this clears the pool's cache. From the CLI or a queue worker it can only clear that process's cache, so the updater logs a warning, records php_reload_required in the update state, and update:perform, update:rollback and update:status tell the operator to reload PHP-FPM. The same happens when opcache.restrict_api blocks the reset. The config, route and event caches that were in place before an update are also rebuilt afterwards, each in a fresh PHP process so it is compiled from the new code, instead of leaving a production site uncached. A failed rebuild is logged and does not fail the update.

Performance

• Listing templates, parts and patterns no longer re-queries and re-parses every entity (#424). TemplateResolver::all() and TemplatePartResolver::all() loaded every row for the active theme and then called resolve() per slug, which queried the row again, looked up the theme file and re-parsed it: about 35ms per template on a real site. Both now build each entity from the row and theme file already in hand, through a builder shared with resolve(), with one query and one directory scan per call. Parsed theme templates, parts and patterns are memoised by the new ParsedThemeFileCache for the request and in the cache store, keyed on a hash of the file contents (plus the block hydrator and visual-editor version for templates and parts), so editing a theme file takes effect immediately. The store layer is on by default and can be turned off with cms.themes.parsedFileCacheEnabled (THEMES_PARSED_FILE_CACHE_ENABLED), which is useful while developing blocks; cms.themes.parsedFileCacheTtl sets its lifetime (default one hour). An unavailable cache store falls back to parsing, and a parse whose hydration failed is not stored. The site-editor ap.visual-editor.* filters also stop running Schema::hasTable() once their table has been found.