If we do that then we gain speed because it's faster to load PHP than to unserialize arrays and we win free of circular dependencies because PHP storage is independent of CMI (unlike the database based cache). We can dump objects that have get methods so that the language override is built-in. Lots of possibilties.

The challenge is mass hosting. Remember, we do not want PHP in a shared directory. The container allows for local storage because it can be rebuilt and the enabled module config triggers a change. However, now that I think of it, you can store php in memcached or redis and read via a stream wrapper. Just ideas.


sun’s picture

PHP storage is independent of CMI

That part makes this issue won't fix for me. Storage means storage only.

You can create a Drupal\Core\Config\PhpStorage any time, but its features and behavior must be identical to all other storages.

As a result, the only gain you'll have is that you might be able to skip the config.cache (because you can read out PHP arrays directly from files), but the actual data must be identical to data that would be stored by the current FileStorage, DatabaseStorage, and any other storage.

That said, exploring a PhpStorage might be fun.

sun’s picture

Issue tags: +Configuration system
sun’s picture

Issue summary: View changes

Updated issue summary.

alexpott’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)

We've recently moved the active store see #2161591: Change default active config from file storage to DB storage and using CachedStorage and #2228261: Add a local, PhpStorage-based cache backend theoretically makes this possible through altering the container.