bcosca / fatfree

A powerful yet easy-to-use PHP micro-framework designed to help you build dynamic and robust Web applications - fast!
2.66k stars 446 forks source link

preg_match pattern incompatible with PHP 7.3 #1206

Closed tituspijean closed 4 years ago

tituspijean commented 4 years ago

Hello,

an issue arose with PrettyNoemieCMS' Fatfree dependency after switching to PHP 7.3:

preg_match(): Compilation failed: invalid range in character class at offset 113

[vendor/bcosca/fatfree/lib/base.php:2219] Base->error()
[vendor/bcosca/fatfree/lib/template.php:279] preg_match()
[vendor/bcosca/fatfree/lib/base.php:3008] Template->parse()
[app/controllers/ShowcaseController.php:31] Preview->render()
[vendor/bcosca/fatfree/lib/base.php:1834] ShowCaseController->showVisitor()
[vendor/bcosca/fatfree/lib/base.php:1642] Base->call()
[index.php:28] Base->run()

It seems it is due to PCRE2 becoming more strict in the pattern validations in newer PHP versions. I was able to fix the matter by replacing

https://github.com/bcosca/fatfree/blob/b51905e89d2bf970b34c4fbb37879eeb1572e76c/lib/template.php#L276

with '('.$this->tags.')\b((?:\s+[\w.:@!\-]+'., i.e. by escaping the hyphen.

xfra35 commented 4 years ago

There has to be more than one occurence of this regex pattern in the framework basecode.

But actually PCRE has only become more strict in 2017, between 10.23 and 10.30.

See the changelog:

Version 10.30 14-August-2017
----------------------------
52. Change 3(g) for 10.23 was a bit too zealous. If a hyphen that follows a
character class is the last character in the class, Perl does not give a
warning. PCRE2 now also treats this as a literal.

Version 10.23 14-February-2017
------------------------------
3. There has been a major re-factoring of the pcre2_compile.c file. Most syntax
checking is now done in the pre-pass that identifies capturing groups. This has
reduced the amount of duplication and made the code tidier. While doing this,
some minor bugs and Perl incompatibilities were fixed, including:
  (g) A hyphen appearing immediately after a POSIX character class (for example
      /[[:ascii:]-z]/) now generates an error. Perl does accept this as a
      literal, but gives a warning, so it seems best to fail it in PCRE.

So either we fix all the occurences of that regex pattern -] (but then should we also escape + and *, such as in [*+-] ?) or we just advise people to avoid PCRE versions between 10.23 and 10.29.

What's your opinion guys?

leonardfischer commented 4 years ago

I suppose the more 'safe' option would be to fix all occurences (also for the future) :/ I would not want to be forced to manually handle my PHP Extension versions over this.

ikkez commented 4 years ago

Yeah we probably should escape those

xfra35 commented 4 years ago

Done in https://github.com/bcosca/fatfree-core/commit/cd358aa94ea089763be635725892d83aa8d22fe1