The error thrown by `parseStatic` when there's an unexpected token is now more meaningful as it states the type of token that was encountered as well as the class that it was found in.
Changed error from: Fatal error: Hmm - depth calc wrong, hit negatives in /var/www/tangoio.maori.nz/framework/core/manifest/ConfigStaticManifest.php on line 242
... to ....
Fatal error: Hmm - depth calc wrong, hit negatives, see: /var/www/mysite.maori.nz/mymodule/code/MyClass.php in /var/www/mysite.maori.nz/framework/core/manifest/ConfigStaticManifest.php on line 240
The first error is completely meaningless and impossible to debug...
DO NOT MERGE: to be reviewed. Only i18n & Deprecation classes use
->getModules() as far as I can see. Given that the method still simply
returns an array of modulename => modulepath, I don't think it's really
an API change
The overhead of Zend_Cache in manifests is too high - we don't
need LRU or tags, just somewhere to dump a bunch of data that
persists
You can replace the class used by defining SS_MANIFESTCACHE
to be a class that implements the ManifestCache interface
(we can't use the Config system to set this, as it isn't
initialised yet).
It shouldnt be possible to get ConfigStaticManifest to parse
a user uploaded file, and if you could it shouldnt be possible
to form PHP that token_get_all could parse which would end
up executing any code.
However just in case it is, this changes the eval to assign to a
static, so the eval will give a syntax error if an attacker
manages to make $value look like `ls` or some other expression
Resolves an issue where if not using the themes directory (i.e just a single app folder) you cannot override module templates.
Changes the SS_TemplateManifest constructor with a new $project argument.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
The _config/route rules explicitly mentioned framework by module name,
so if you installed framework in the older sapphire directory youd
always end up with cyclic config requirement errors
It is possible to specify before and after rules on config fragments
that conflict - A before B and B before A isnt possible to solve.
This used to just throw an error with no way to debug. Now if you
specify debug as a GET parameter and the site is not in live mode
youll get a basic dump of the remaining DAG graph
When specifying a specific before rule and a wildcard after rule (or
vice versa), the config system was filtering out any fragment
from the list of fragments that matched the wildcard if it matched
_any_ componenet of the specific rule, not all of them.
Fixed, and added handling of two semi wild-card rules, where a
rule with less wildcards wins over a rule with more.
See http://open.silverstripe.org/ticket/7765 for more
You should be able to specify multiple before and after rules in
a config fragment. This was intended to be a comma seperated string
but that wasnt being split properly
Now if you provide a comma seperated string it is split properly,
but you can also provide an array, which is actually cleaner
- Do not skip the cache if there are currently no environmental specific spec, just use the an empty variantKeySpec.
- When doing a regeneration of the config, clear the previous values from the array before regeneration.
---
In SS-2.4 you can prefix files with an underscore to exclude them from manifest this can be useful for backups of old classes or huge data files.
I think this behaviour should be readded.
(I will add a unit test for this ...)
