This change should be revisited since it doesn't account for database-based templates which have no file path. Upon revisit, we might want to consider adding this logic in to the afterFetch() event with detection of file based mode, or even at the lower levels where the file is first extracted from the filesystem. TBA
Logic in ComponentPartial was rolled back and moved to the Controller. Since there are issues with throwing exceptions inside the component partial lookup logic (exceptions are conditionally suppressed), it seems like it would be better to bubble up the security logic to the controller level as a simple base dir security check, which is no longer concerned about any suppression logic. This looks to have logic parity with the previous solution
Refs #4652
Adds a dismissable message to the CMS object code editor indicating that the PHP code section of a CMS object cannot be edited when `cms.enableSafeMode` is `true` (or when debugging is disabled if `null`).
Credit to @mjauvin.
This was a contentious change is generally a bad idea to blanket all requests with a dependant cookie. We will try something else.
Revert enableXsrfCookies setting. Fixes UX issue introduced where the token expires. This should be replaced by a CSRF policy that determines whether this is needed on the front end.
runInternal has been removed because we do not want to blanket our response logic over every single response, only the happy path. This is because it is impossible to remove. So it is better to take the inverted approach, where if you want the CMS' headers in your custom response, add them yourself. This becomes easy via the new makeResponse() method
Credit to @vojtasvoboda. Will avoid asking the database for the currently active theme if there is only one theme present and its code matches the code set in cms.activeTheme
Credit to @Samuell1. Fixes issues related to complexity of the existing approach / cache invalidation by just using the caching built in to YAML::parseFile().
Credit to @vosco88.
When trying to deploy October on shared hosting (www.websupport.sk) it is possible to receive the following error when accessing the frontend pages - ErrorException:> Zend OPcache API is restricted by "restrict_api" configuration directive. This checks not only if the opcache_invalidate exists but also if opcache is enabled. Same check is actually present in twig vendor files - but so far it is working without having the check there.
