These are sort-of-extensible in a very effort-intensive way right now:

• Subclass PhabricatorFileStorageEngine to implement your engine.
• Subclass PhabricatorDefaultFileStorageEngineSelector to implement a new selector which selects your engine.
• Put your engine and selector in a library.
• Load it at runtime.
• Set storage.engine-selector to choose your selector.

However, this is more complicated than it should be. This "selector class" pattern was one of the earliest approaches we used, and it wasn't that great. I think all other use cases were later replaced with the more modern extension patterns.

This one is a little tricky to replace because it has some unusual concerns: for example, it's reasonable to activate multiple engines to support rules like "very small files go in MySQL for quick access, larger stuff goes in S3", and we should ideally continue to access and read engines which we're no longer writing new files to. However, these use cases are not especially important, and they can still be accommodated with a more modern approach to storage engines.

This might be fixed by D11224.

D12053 marks this as fixed. Specifically:

• It removes the "selector" classes completely.
• Engines must implement a few new methods so Phabricator can tell if they're writable, test engines, filesize limits, etc., and with what priority writes should be attempted to the engine.
• Applicable engines are automatically discovered and selected at runtime and tried in priority order.

So the new requirements are:

• Implement the new methods (all of which should be trivial).
• Load the engine in a library somewhere.
• It should show up on Applications → Files → Help/Options, like this:

• If it's highlighted, that means it's recognized and considered writable.
• You can delete your old Selector class, if you have one.