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.