Cache\PhpBackend expands $foo and ${bar()}

Major (at minimum).

Oh boy. PHP. I like #2 much better. Nowdoc is php 5.3.0 in case anyone wonders. Now i wonder, are we going to bump against the 2gb limit of a string? I'd guess not cos other backends store $cache->data too. I hope there are no more landmines buried in phpbackend...

Pretty sure this sort of rewriting is going to need tests. Flagging for a do-able Sprint task.
(I see one test - so that's a good base for novice to think up and add a few other ways to break things)

Installed the patch and tested successfully. But get unexpected results when the input test string has three backslashes. The test passes but the display shows four backslashes, not the three expected.

Input:
$with_variable = array('foo' => '"three backslashes \\\"');

Test result:
Value array ( 'foo' => '"three backslashes \\\\"', ) is identical to value array ( 'foo' => '"three backslashes \\\\"', )

@quietone thanks for the report. Which patch did you test?

I would like to see:

$content = "<?php return unserialize(" . var_export(serialize($item)) . ");";

Which is the proper way of doing this.

But really, I would like to see this whole craziness go away. Storing cache entry in the opcode cache sounds like a terrible idea (even if I suggested it a long time ago). This is especially true because:

(1) The current implementation relies of the Opcode cache stating the file;
(2) MTimeProtectedFileStorage triggers at least an additional stat() call anyway (to get the mtime of the containing directory)

At this point (small file, with a stat() on it just done), loading the content of the file should be pretty cheap.

- if serializing before var_export means we don't have to force callers of the API to implement extra methods on their data, then yay, that is cleaner.

No, var_export() is just used to export of the serialized string into PHP code. That doesn't change anything functionally.

-    if (!$unsafe_eof_in_data) {
-      $content = "<?php return unserialize(<<<$EOF
-$data
-$EOF
-);";

Erm. We were not even quoting the string? :)

This whole thing was only working because:

(1) PHP casts unknown constants to strings and
(2) We just silence all errors when including the file.

Let's get this in and stop the bleeding...

Actually, bumping to critical because of the very real risk this opens up remote code execution possibilities.

Committed to 8.x. Thanks!