APP_NAME
(the unique name of your app, the root app folder has to be named equally)APP_SECRET
(a secret which is needed for the registration process)manifest.xml
but also in the .platform.app.yaml
.manifest.xml
would be:.env
to develop locally.manifest.xml
-files is the bin/console app:create-manifest
command. This command will generate a manifest from the template. For testing purposes this is the default manifest template from our example app.
In there you can use {{ APP_NAME }}
,{{ APP_SECRET }}
,{{ APP_URL_CLIENT }}
and {{ APP_URL_BACKEND }}
which will get replaced by the values configured in your .env
. Further more you can use your own variables like {{ MY_OWN_VARIABLE }}
and declare them when executing the command like this bin/console app:create-manifest MY_OWN_VARIABLE=MY_OWN_VARIABLE_VALUE
.
This allows you to change URL's in your manifest.xml
without changing the .env
file. The generated manifest.xml
can be found in build/dev
.https://www.my-app.com/registration
.SwagAppsystem\Client
and SwagAppsystem\Event
will be injected in each controller when you need them. For example:tests
and execute them using vendor/bin/phpunit
.vendor/bin/ecs check
to check your code against the provided style or add --fix
to also fix your code.$client->getHttpClient
. This client has already the needed header and token to communicate with the shop. Now you can perform your own requests.shopUrl
, shopId
, appVersion
and the eventData
.shopId
and build your client with it.app.installed
, app.updated
, app.deleted
, app.activated
and app.deactivated
. To use this events you have to create the webhooks in your manifest. If you want to implement your own code you need to implement the AppLifecycleHandler interface and write your own code.app.installed
event gets triggered each time the app gets installed. This will also trigger the app.activated
event. At each of these events the shop is already installed and registered at your app. The webhook could look like this:app.updated
event gets triggered each time a shop updated your app.
The webhook could look like this:app.deleted
event gets triggered each time a shop deletes your app. At this point the shop is deleted using the shopRepository. You need to delete all the shop's data you have saved, and are not legally required to keep, then stop the communication with the shop.
The webhook could look like this:app.activated
event gets triggered each time your app gets installed or activated. At this point you can start the communication with the shop.
The webhook could look like this:app.deactivated
event gets triggered each time your app gets deactivated. At this point you should stop the communication with the shop.
The webhook could look like this:size
key.
You can configure this for your application in your .platform.app.yaml. And configure this for your services in your services.yaml.AUTO
. However, if you want to change it, you can set it to S
, M
, L
, XL
, 2XL
or 4XL
.
This defines how much resources one container gets. If the total resources requested by all apps and services is larger than that what the plan size allows then a production deployment will fail with an error.size
key only has impact on your production environment. The key will be ignored in the development environment and will be set to S
. If you need to increase this you can do it on you plan settings page for a fee.disk
key. It is optional so if you don't set it Platform.sh will handle it for you.
However, if you need much storage for your database then you can change this key in your services.yaml. The value of this key is always in MB. For our example we used 2GB or 2048MB for our application and another 2GB or 2048MB for our database.
The default storage you get with each plan is 5GB or 5120MB. In our case we only used 4GB or 4096MB so you have 1GB or 1024 left which you can give to your application or to your database. Whether you use it or not won't affect your costs.