FIX several issues with the config system #741

merged 4 commits into from Aug 27, 2012


None yet

3 participants

  • Fixes issue where a fragment has a wildcard before or after rule and a more specific opposing rule
  • Fixes issue where a fragment has more than one before or after rule
  • Adds ability to get dump of config fragment rule graph when a cyclic conflict occurs
Hamish Fried... added some commits Aug 27, 2012
Hamish Friedlander FIX Config frag could only have one before or after rule
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
Hamish Friedlander FIX Config wasnt filtering wildcards properly
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 for more
Hamish Friedlander NEW Allow debugging of config cyclic 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

Can we test?


Yeah. Working on a couple of tests now.


?debug=1 seems like a very generic name for debugging this. Quick fix would be to make it ?debug_config=1 and include a mention of that in the relevant documentation.

For a more serious fix, we should look at the 'developer ergonomics' GSOC project and see if it provides a better place to organise this output. I'd expect we'd allow multiple categorised streams of debug data with the ability to show/hide any of them based on a developer's needs.


?debug=1 is what is already used for debugging routing issues - since this is most likely to come up in the context of routing issues I thought is was best to just use the same variable.

sminnee commented Aug 27, 2012

Hrm, okay. It's still a bit rough, but I guess it'll be fine until we get better debug logging facilities, hopefully in 3.1.


Yeah, the whole "just jam magic GET variables into the request" is a bit stink, especially when trying to debug ajax requests, etc.


This pull request passes (merged 8b6e4f5 into 0a6a3fa).


This pull request fails (merged 6009cfa into 0a6a3fa).

sminnee commented Aug 27, 2012

Don't worry about that failure, the pass is the correct one.


This pull request passes (merged 6009cfa into 0a6a3fa).

@sminnee sminnee merged commit dd97da0 into silverstripe:3.0 Aug 27, 2012

1 check passed

default The Travis build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment