* Implement fix to not rewrite paths in CSS pipeline when CSS URLs use a path startng at webserver root (e.g. url('/path/to/asset')) - fixes#1382
* Amend CSS pipeline's resource location checking predicates to use Utils::startsWith, and consolidate into a single predicate
* Add back colon to data URL prefix test
Copy error in last commit would have broken any relative path beginning with the string 'data'
To help user that need to install specific version of a package.
So far it wasn't absolutely clear how to achieve and some
users ended up asking for help or opening issues asking
for the feature.
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.
