Discussed with @mahagr.
Saved YAML configs gave undesired extra parameter (!!float 1 for example) because floats were not being cast back to integers upon save. This was even true when the filterNumber function was giving back a correct parameter. filter_var from validateFloat was actually perserving the float variable type which the YAML engine perserved upon Yaml::dump.
This is a unconventional fix, but it is the simplest way to handle this edge case.
The function validateNumber only checks for numeric values.
**By PHP isNumeric**
"42",
1337,
0x539,
02471,
0b10100111001,
1337e0,
"not numeric",
array(),
9.1
**Will evaluate respectively**
'42' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'1337' is numeric
'not numeric' is NOT numeric
'Array' is NOT numeric
'9.1' is numeric
Grav though does not support all value types for a variety of reasons. One being YAML Blueprint definitions, where it makes sense to make a new type value for a more specialized format. Specifically for numbers if a more advance number format it would make sense to make a new type for that number format.
YAML spec specifically allows both Integer or Float contexts, as seen in the validate class validateInt and validateFloat. This is useful when the output formats explicitly needs to be a certain format.
However, in the case of generic numeric contexts, which numbers could be floats or ints dynamically, the values are cast back to an int currently in Grav numeric validation. Having dynamic primitive number formats is important, true in an interpreted language like JavaScript where 1 and 1.0 will both work for a number value.
The reason to cast the type of the variable still is to prevent wide selection of number formats, and to keep Grav in line with primitive YAML field formats.
Resets the page_extensions value.
Useful to re-initialize the pages and change site language at runtime,
example:
```
$this->grav['language']->setActive('it');
$this->grav['language']->resetFallbackPageExtensions();
$this->grav['pages']->init();
```
* Fixes to allow not just ‘default/file’ cache in CLI
* vendor updates
* Better solution
* Added cli_compatibility to system blueprint
* Fall back to ‘file’ if cli_compatibility and (auto or volatile)
* Don’t set default param_sep, use system constant, but still allow override
* Automatically fix param_sep on windows
* Reverted back to original system.yaml syntax
* Comment fix
* PSR formating fixes
* Ensure automatic override of `param_sep` is only in cases where it’s different from system + windows + apache
