This simple bridge library connects a Symfony Flex-based application to Platform.sh. In the typical case it should be completely fire-and-forget.

Symfony Flex expects all configuration to come in through environment variables with specific names in a specific format. Platform.sh provides configuration information as environment variables in a different specific format. This library handles mapping the Platform.sh variables to the format Symfony Flex expects for common values.

Simply require this package using Composer. When Composer's autoload is included this library will be activated and the environment variables set. As long as that happens before Symfony bootstraps its configuration (which it almost certainly will) everything should work fine with no further user-interaction necessary.

composer require platformsh/symfonyflex-bridge

• If a Platform.sh relationship named database is defined, it will be taken as an SQL database and mapped to the DATABASE_URL environment variable for Symfony Flex. (Note: Due to a bug in Doctrine, the code currently assumes MariaDB 10.2 as the service version. If that Doctrine bug is ever resolved this hard-coding can be removed.)

• If you wish to map multiple database relationships, they can be defined as a comma-separated string (e.g database,database_legacy) in a DATABASE_RELATIONSHIPS environment variable within your Platform.sh environment. These will be mapped to environment variables named by uppercasing the relationship name and appending _URL (e.g., the database_legacy relationship would be mapped to the DATABASE_LEGACY_URL environment variable.)

• The Symfony Flex APP_SECRET is set based on the PLATFORM_PROJECT_ENTROPY variable, which is provided for exactly this purpose.

• The MAILER_URL variable is set based on the PLATFORM_SMTP_HOST variable. That will be used by SwiftMailer if it is installed. If not installed this value will be safely ignored.

• If no APP_ENV value is set, it will default to prod.

If a Platform.sh relationship named elasticsearch is defined, it will be taken as an Elasticsearch index and mapped to appropriate environment variables. Most Elasticsearch packages for Symfony do not have a standard naming convention for environment variables so you will need to modify your Symfony configuration to read them.

For the common Elastica library, you would add the following to your Symfony config/services.yaml file:

# config/services.yaml
parameters:
  es_host: '%env(ELASTICSEARCH_HOST)%'
  es_port: '%env(ELASTICSEARCH_PORT)%'

And then you can reference those parameters in your Elastica configuration file:

# config/packages/fos_elastica.yaml
fos_elastica:
    clients:
        default: { host: '%es_host%', port: '%es_port%' }

If a Platform.sh relationship named mongodatabase is defined, it will be taken as a Doctrine ODM database and mapped to the appropriate environment variables. Note that you may still need to reference those environment variables in your configuration if they are not defined by default. See the DoctrineMongoDBBundle documentation for more details.

Generally, placing the following in your doctrine_mongodb.yaml file should be sufficient:

# config/packages/doctrine_mongodb.yaml
doctrine_mongodb:
    connections:
        default:
            server: '%env(MONGODB_SERVER)%'
            options: { username: '%env(MONGODB_USERNAME)%', password: '%env(MONGODB_PASSWORD)%', authSource: '%env(MONGODB_DB)%' }
    default_database: '%env(MONGODB_DB)%'

If a Platform.sh relationship named rabbitmqqueue is defined, it will be taken as a RabbitMQ messenger backend and mapped to the appropriate environment variable.

If a Platform.sh relationship named solr is defined, it will be taken as a Solr index and mapped to appropriate environment variables.

For the common uses, you would add the following to your Symfony config/services.yaml file:

# config/services.yaml
parameters:
    solr_dsn: '%env(SOLR_DSN)%'
    solr_core: '%env(SOLR_CORE)%'

And then you can reference those parameters in your configuration file:

# config/packages/search_engine_solr.yaml
search_engine_solr:
    endpoints:
        endpoint0:
            dsn: '%solr_dsn%'
            core: '%solr_core%'
    connections:
        default:
            entry_endpoints:
                - endpoint0

If a Platform.sh relationship named rediscache is defined, it will be taken as a the storage engine for a cache pool.

For typical use you will need to define a file looking like this:

#config/packages/cache_pool/cache.redis.yaml
parameters:
    cache_dsn: '%env(CACHE_DSN)%'

services:
    cache.redis:
        public: true
        class: Symfony\Component\Cache\Adapter\RedisTagAwareAdapter
        parent: cache.adapter.redis

For more details see here

If a Platform.sh relationship named redissession is defined, it will be taken as a the storage engine for symfony session.

For typical use you will need to add a couple of service definitions which looks like this:

# config/services.yaml
services:
    # ...
    Redis:
        class: Redis
        calls:
            - connect:
                - '%env(SESSION_REDIS_HOST)%'
                - '%env(int:SESSION_REDIS_PORT)%'
    Symfony\Component\HttpFoundation\Session\Storage\Handler\RedisSessionHandler:
        arguments:
            - '@Redis'

Then to configure symfony to use the new redis handler

# config/packages/framework.yaml
framework:
    session:
        handler_id: Symfony\Component\HttpFoundation\Session\Storage\Handler\RedisSessionHandler

For more details see here