PHP7 and the preg_replace problem

[AmigoJack]

http://hurr.org/i/phpbb_preg_replace_callback.png

Not sure why you haven't attached it to your post, as that'd be the most reliable thing when people will read this in 1-2 years and your host might have vanished.

phpbb_preg_replace_callback.png

the 5 line replacement

The error clearly states that /e is not supported anymore. So you have to ask yourself where it is used in the first place. What does "my" code change? You see nowhere turning an /e into /. Since the regexp in any preg_replace*() is always passed as the first argument you should ask "where is $preg populated?" (alternatively: just print out its content and you'll understand the error message much better). And then you would discover it comes thru class bbcode::bbcode_cache_init() (starting with line 211): every time the modifier e is used you have to delete it:

Code: Select all

#\[quote(?:="(.*?)")?:$uid\]((?!\[quote(?:=".*?")?:$uid\]).)?#ise
#\[code(?:=([a-z]+))?:$uid\](.*?)\[/code:$uid\]#ise
#\[list=([^\[]+):$uid\]#e

must become

Code: Select all

#\[quote(?:="(.*?)")?:$uid\]((?!\[quote(?:=".*?")?:$uid\]).)?#is
#\[code(?:=([a-z]+))?:$uid\](.*?)\[/code:$uid\]#is
#\[list=([^\[]+):$uid\]#

Yes, to achieve what you want requires you to understand the problem in general, but also what regular expression modifiers are.

The line 494 replacement works.

I just guess you mean line 488 in an untouched file, as I can't have a clue on how your modified file may look like.


My whole point was: for the development team it should have been a rather easy task, just as it'd be for me (speak: something achievable within days or even hours, not weeks). Hence I have no clue why it needed to wait until 3.2.

[DavidIQ]

My whole point was: for the development team it should have been a rather easy task, just as it'd be for me (speak: something achievable within days or even hours, not weeks). Hence I have no clue why it needed to wait until 3.2.

3.2 was scheduled to be out already so the plan to scrap PHP7 support in 3.1 and give it full support in 3.2 was a very sound one, something I'm sure you're well aware of and probably agreed with in principle. Assuming you're a developer I'm sure you're familiar with how development can fall behind for various reasons. This project has additional ways in which development can fall behind since it's handled by volunteers.

We can expect 3.2 to be out in the foreseeable future though so hopefully this can be put to rest once and for all.

[AmigoJack]

Otherwise, 3.2 should be released at the end of the year, around November. This version should already be compatible with php7

Both things aren't true: 3.2 still has not been released, and the RC1 is not PHP7 compatible either (custom BBCodes still require /e).

[Tomba]

I'm sorry if I'm throwing oil on the fire, but I'm amazed that the phpBB team keeps on using 3.2 in defence of the lack of PHP7 compability.

Being a software developer, I am indeed very aware that planning can slip, but re-planning is part of the process, and this was missed completely here. The result is now that PHP7 is mainstream since Dec 3, 2015, so for 11 months now, there is no phpBB release available that is compatible with the main version of PHP.
In essence, I've got a project with 13 dependencies, and all are compatible, except phpBB.

Anyway, assuming the phpBB team sticks to its stance, I'm wondering if anyone has patched the code?

[Ger]

Well, being a software developer like you say you are, you are quite welcome to provide a patch to make phpBB 3.2 3.1 compatible with PHP 7, including all the old content.

I stand corrected

[Tomba]

Indeed, I intend to, because I must fix it anyway. But I don't like doing duplicate work, so I hope someone else who went through the same could share their efforts.

I'd be happy to compose a pull request if necessary.

[Paul]

3.2RC1 is already compatible with php7

[Tomba]

For those interested to fix their phpbb 3.1.x versions, the commits done on https://tracker.phpbb.com/browse/PHPBB3-13832 are of interest to merge back.

In fact, why not merge them back into 3.1.11 anyway?

[DavidIQ]

In fact, why not merge them back into 3.1.11 anyway?

You don't really want us to rehash and repeat all of the reasons why not right?

[AmigoJack]

commits done on https://tracker.phpbb.com/browse/PHPBB3-13832

No, as that doesn't fix custom BBCodes. Like I commented in PHPBB3-13857 parsing the PHP code stored in the database would be one way to solve this. Currently I do this for 1+ month on a 3.0.14 installation and it works without any flaw.

[Marc]

Please take a look at the latest comments in that ticket. I don't think that the BBCode first pass is used for custom bbcodes in 3.2 anymore and therefore the /e modifier is also no longer used.

[Tomba]

In fact, why not merge them back into 3.1.11 anyway?

You don't really want us to rehash and repeat all of the reasons why not right?

Actually...
But joking aside, seeing these commits, I assume they are covered by automatic tests, and would hence be fairly straightforward to merge. I really think in the future, phpBB needs to try to always have a release available that is compatible with the latest PHP version.

Please take a look at the latest comments in that ticket. I don't think that the BBCode first pass is used for custom bbcodes in 3.2 anymore and therefore the /e modifier is also no longer used.

In noticed, but I'm trying to achieve 3.1 compatibility on PHP7 in the coming weeks, unless you can release 3.2 tomorrow

[DavidIQ]

But joking aside, seeing these commits, I assume they are covered by automatic tests, and would hence be fairly straightforward to merge. I really think in the future, phpBB needs to try to always have a release available that is compatible with the latest PHP version.

Ok let's say we did that and PHP 99 rolled around and completely got rid of preg_replace with no backwards compatibility with the previous PHP version and in it's place is replace_preg. If we followed your suggestion we would go and replace preg_replace with the new replace_preg function throughout current code because, why not...there's a new PHP version and everyone needs to be on it already according to us. Well we've just broken a lot of people's boards and most everyone's unhappy. Adding code throughout to check PHP versions would be pretty ugly and messy and not likely something we'd ever want to do.

Obviously this isn't what has happened in PHP 7 and the PHP developers probably wouldn't do such a thing without ample notice, but changing an already released version to comform to a new underlying platform is almost never a good idea and is why new major versions are released instead by most software vendors I've seen. Plus very few hosting providers are going to all of a sudden dump PHP 5 in place of 7 anytime soon, that is if they want to keep their customers, so this hasn't reached a critical point where we have no choice but to go backwards and into 3.1 to get core things changed for PHP 7 support.

[WelshPaul]

Dion has published a guide on how to make phpBB 3.1.x compatible with PHP 7.
Its straight forward. It's not even a guide its a file replacement...

http://forum.dion-designs.com/t9150/mak ... th-php-70/

Once that is done then you can enable PHP 7 on your server.

[AmigoJack]

Dion has published
a file replacement

Let's see...

Code: Select all

// eval() sucks, but we must use preg_replace_callback() to support
// PHP 7.0, and custom BBcode replacement function is stored as a string
$this->message = preg_replace_callback($regexp, function($matches) use($replacement) {eval('$str=' . $replacement[1]); return $str;}, $this->message);

So PHP7 disables /e, but Dion fixes this by using eval()? That's what e was standing for all along. Good luck to those environments where this function is disabled.

Code: Select all

// convert emojis to HTML entities
$result = preg_replace_callback('/([\x{1f000}-\x{1ffff}])/u', function($matches) {
    return strtolower('&#x' . dechex(substr(mb_convert_encoding($matches[1], 'HTML-ENTITIES', 'UTF-8'), 2, -1)) . ';');
}, $result);

Do not store characters, but instead let's go back using outdated approaches from times when encoding problems were avoided the very same way. (Also inflates byte usage of such characters from 4 to 9.)


No, Dion doesn't fix - he only kludges. It's like avoiding validator errors by splitting up literals: just because it's now supported doesn't mean it's good code now as well.