Hello,
I wrote https://www.drupal.org/files/issues/2513326_34.patch this
monstrosity out of necessity because
https://github.com/php/php-src/blob/6e3e1e31e92fd57f12471461fc3496ac057757b0/ext/opcache/ZendAccelerator.c#L149
is_cacheable_stream_path
hardwires file:// and phar://
Please give us a chance to override this somehow in PHP 7.1 or even 7.2
since it won't be for a good number of years before we can use it but it
would be nice if Drupal 9 didn't need this fun.
Thanks much,
Karoly Negyesi
Hi,
De : Karoly Negyesi [mailto:karoly@negyesi.net]
I wrote https://www.drupal.org/files/issues/2513326_34.patch this
monstrosity out of necessity because
https://github.com/php/php-
src/blob/6e3e1e31e92fd57f12471461fc3496ac057757b0/ext/opcache/ZendAc
celerator.c#L149
is_cacheable_stream_path
hardwires file:// and phar://Please give us a chance to override this somehow in PHP 7.1 or even 7.2
since it won't be for a good number of years before we can use it but it
would be nice if Drupal 9 didn't need this fun.
https://wiki.php.net/rfc/streams-is-cacheable was a first proposal to allow streams to decide what content should be opcode-cached or not. After discussing it with Rasmus, we came to the conclusion that this proposal was too limited, because it assumes that the URI will be used as key, which shouldn't be always the case. The next RFC, planned for 7.1 if time permits, will ask the stream for a 'cache key'. Then, the stream code can decide whether the URI is cacheable or not (off by default) and return the unique key to use. It will be more flexible than the current fixed values and could also solve issues with chrooted environments, where using chrooted paths as keys generates conflicts. I didn't have an extensive look at your code but I think this can solve your concerns.
Regards
François