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)
