diff --git a/contributing/styles/Platform/link-text.yml b/contributing/styles/Platform/link-text.yml index c0c8b1a483..179a34ba14 100644 --- a/contributing/styles/Platform/link-text.yml +++ b/contributing/styles/Platform/link-text.yml @@ -3,7 +3,7 @@ message: "Try to use meaningful text for links." link: "https://github.com/platformsh/platformsh-docs/blob/main/contributing/content-style.md#use-meaningful-link-text" level: warning nonword: true -scope: link +scope: raw tokens: - \b(?}} is a second-generation Platform-as-a-Service built especially for continuous deployment. It allows you to host web applications on the cloud while making your development and testing workflows more productive. -If you're new to Platform.sh, we recommend starting with the **Big Picture**, in particular [Structure](/overview/structure.md), and [Build & Deploy](/overview/build-deploy.md) will get you started on the right track to best use Platform.sh. +If you're new to {{< vendor/name >}}, we recommend starting with the **Big Picture**, in particular [Structure](/overview/structure.md), and [Build & Deploy](/overview/build-deploy.md) will get you started on the right track to best use {{< vendor/name >}}. -The main requirement of Platform.sh is that you use Git to manage your application code. +The main requirement of {{< vendor/name >}} is that you use Git to manage your application code. Your project's configuration is driven almost entirely by a small number of YAML files in your Git repository. The **Configuration** section covers those in more detail and can serve as both a tutorial and a quick reference. -Platform.sh is built on Debian, supports many different programming **Languages** and environments, +{{< vendor/name >}} is built on Debian, supports many different programming **Languages** and environments, and features recommended optimizations for several **Featured Frameworks**. -Finally, you can also get tips for setting up your own **Development** workflow and **Administering** your Platform.sh account. +Finally, you can also get tips for setting up your own **Development** workflow and **Administering** your {{< vendor/name >}} account. ### Git Driven Infrastructure -As a Platform as a Service, or PaaS, Platform.sh automatically manages everything your application needs to run. +As a Platform as a Service, or PaaS, {{< vendor/name >}} automatically manages everything your application needs to run. That means you can, and should, view your infrastructure needs as part of your application and address them under version control. ### Infrastructure as code -Platform.sh covers not only all of your hosting needs but also most of your DevOps needs. It is a single tool that covers the application life-cycle from development to production and scaling. +{{< vendor/name >}} covers not only all of your hosting needs but also most of your DevOps needs. It is a single tool that covers the application life-cycle from development to production and scaling. You only need to write your code, including a few YAML files that specify your desired infrastructure, commit it to Git, and push. You don't need to set up anything manually. The web server is already set up and configured, as is any database, search engine, or cache that you specify. @@ -40,11 +40,11 @@ It really is "what would my site look like if I merged this to production?" ever You can use these concepts to replicate a traditional development/staging/production workflow or even to give every feature its own effective staging environment before merging to production (empowering you to use git-flow like methodologies even better). You could also have an intermediary integration branch for several other branches. -Platform.sh respects the structure of branches. It's entirely up to you. +{{< vendor/name >}} respects the structure of branches. It's entirely up to you. ### Full stack management -Managing your full stack on Platform.sh gives you the following unique features: +Managing your full stack on {{< vendor/name >}} gives you the following unique features: 1. **Unified Environment:** All of your services (MySQL, ElasticSearch, MongoDB, etc.) are managed inside the cluster and included in the price, with no external single-points-of-failure. When you back up an environment, you get a fully consistent snapshot of your whole application. 2. **Multi-Services & Multi-App:** You can deploy multiple applications (for example, in a microservice-based architecture), using multiple data backends (MySQL, PostgreSQL, Redis, etc.) written in multiple frameworks (Drupal + NodeJS + Flask, for example) in multiple languages, all in the same cluster. diff --git a/sites/platform/.yaml b/sites/platform/.yaml deleted file mode 100644 index 082fef4884..0000000000 --- a/sites/platform/.yaml +++ /dev/null @@ -1,1049 +0,0 @@ -chrome-headless: - description: '' - disk: false - docs: - relationship_name: chromeheadlessbrowser - service_name: headlessbrowser - url: /add-services/headless-chrome.html - endpoint: http - min_disk_size: null - name: Headless Chrome - repo_name: chrome-headless - runtime: false - type: chrome-headless - versions: - deprecated: [] - supported: - - '113' - - '95' - - '91' - - '86' - - '84' - - '83' - - '81' - - '80' - - '73' - legacy: - - '86' - - '84' - - '83' - - '81' - - '80' - - '73' - versions-dedicated-gen-3: - deprecated: [] - supported: - - '95' -dotnet: - description: ASP.NET 5 application container. - repo_name: dotnet - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/dotnet.html - web: - commands: - start: dotnet application.dll - locations: - /: - root: wwwroot - allow: true - passthru: true - hooks: - build: - - '|' - - set -e - - >- - dotnet publish --output "$PLATFORM_OUTPUT_DIR" - -p:UseRazorBuildServer=false -p:UseSharedCompilation=false - endpoint: null - min_disk_size: null - name: C#/.Net Core - runtime: true - type: dotnet - versions: - deprecated: - - '5.0' - - '3.1' - - '2.2' - - '2.1' - - '2.0' - supported: - - '7.0' - - '6.0' - legacy: - - '3.1' - - '2.2' - - '2.1' - - '2.0' -elasticsearch: - description: A manufacture service for Elasticsearch - disk: true - docs: - relationship_name: essearch - service_name: searchelastic - url: /add-services/elasticsearch.html - endpoint: elasticsearch - min_disk_size: 256 - name: Elasticsearch - repo_name: elasticsearch - runtime: false - type: elasticsearch - versions: - deprecated: - - '7.10' - - '7.9' - - '7.7' - - '7.5' - - '7.2' - - '6.8' - - '6.5' - - '5.4' - - '5.2' - - '2.4' - - '1.7' - - '1.4' - supported: - - '8.5' - - '7.17' - versions-dedicated-gen-2: - supported: - - '8.5' - - '7.17' - deprecated: - - '7.10' - - '7.9' - - '7.7' - - '7.6' - - '7.5' - - '7.2' - - '6.8' - - '6.5' - - '5.6' - - '5.2' - - '2.4' - - '1.7' - versions-dedicated-gen-3: - deprecated: - - '7.10' - - '7.9' - - '7.7' - - '7.5' - - '7.2' - - '6.8' - - '6.5' - supported: [] -elixir: - description: '' - repo_name: elixir - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/elixir.html - web: - commands: - start: mix run --no-halt - locations: - /: - allow: false - root: web - passthru: true - hooks: - build: - - '|' - - mix local.hex --force - - mix local.rebar --force - - mix do deps.get --only prod, deps.compile, compile - endpoint: null - min_disk_size: null - name: Elixir - runtime: true - type: elixir - versions: - deprecated: - - '1.11' - - '1.10' - - '1.9' - supported: - - '1.14' - - '1.13' - - '1.12' - legacy: - - '1.10' - - '1.9' -golang: - description: '' - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/go.html - web: - upstream: - socket_family: tcp - protocol: http - commands: - start: ./bin/app - locations: - /: - allow: false - passthru: true - hooks: - build: - - go build -o bin/app - endpoint: null - min_disk_size: null - name: Go - repo_name: golang - runtime: true - type: golang - versions: - deprecated: - - '1.18' - - '1.17' - - '1.16' - - '1.15' - - '1.14' - - '1.13' - - '1.12' - - '1.11' - - '1.10' - - '1.9' - - '1.8' - supported: - - '1.20' - - '1.19' -influxdb: - description: '' - disk: true - docs: - relationship_name: influxtimedb - service_name: timedb - url: /add-services/influxdb.html - endpoint: influxdb - min_disk_size: null - name: InfluxDB - repo_name: influxdb - runtime: false - type: influxdb - versions: - deprecated: - - '2.2' - - '1.8' - - '1.7' - - '1.3' - - '1.2' - supported: - - '2.7' - - '2.3' -java: - description: '' - docs: - relationship_name: null - service_name: null - url: /languages/java.html - web: - commands: - start: java -jar target/application.jar --server.port=$PORT - hooks: - build: - - mvn clean install - endpoint: null - min_disk_size: null - name: Java - repo_name: java - runtime: true - type: java - versions: - deprecated: - - '19' - - '18' - - '14' - - '13' - - '12' - supported: - - '17' - - '11' - - '8' - versions-dedicated-gen-2: - supported: - - '17' - - '11' - - '8' - deprecated: - - '15' - - '13' - - '7' -kafka: - description: '' - disk: true - docs: - relationship_name: kafkaqueue - service_name: queuekafka - url: /add-services/kafka.html - endpoint: kafka - min_disk_size: 512 - name: Kafka - repo_name: kafka - runtime: false - type: kafka - versions: - deprecated: - - '2.7' - - '2.6' - - '2.5' - - '2.4' - - '2.3' - - '2.2' - - '2.1' - supported: - - '3.2' - - '3.4' - legacy: - - '2.6' - - '2.5' - - '2.4' - - '2.3' - - '2.2' - - '2.1' -lisp: - description: '' - id: 1102 - repo_name: lisp - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/lisp.html - web: - commands: - start: ./example - locations: - /: - allow: false - passthru: true - endpoint: null - min_disk_size: null - name: Lisp - runtime: true - type: lisp - versions: - deprecated: [] - supported: - - '2.1' - - '2.0' - - '1.5' -mariadb: - description: A manufacture-based container for MariaDB - repo_name: mariadb - disk: true - docs: - relationship_name: database - service_name: db - url: /add-services/mysql.html - endpoint: mysql - min_disk_size: 256 - name: MariaDB/MySQL - runtime: false - type: mariadb - versions: - deprecated: - - '10.2' - - '10.1' - - '10.0' - - '5.5' - supported: - - '11' - - '10.11' - - '10.6' - - '10.5' - - '10.4' - - '10.3' - versions-dedicated-gen-2: - supported: - - 10.8 Galera - - 10.7 Galera - - 10.6 Galera - - 10.5 Galera - - 10.4 Galera - - 10.3 Galera - deprecated: - - 10.2 Galera - - 10.1 Galera - - 10.0 Galera - versions-dedicated-gen-3: - supported: - - 10.11 Galera - - 10.6 Galera - - 10.5 Galera - - 10.4 Galera - - 10.3 Galera - deprecated: - - 10.2 Galera - - 10.1 Galera -mysql: - description: A manufacture-based container for MariaDB - repo_name: mariadb - disk: true - docs: - relationship_name: database - service_name: db - url: /add-services/mysql.html - endpoint: mysql - min_disk_size: 256 - name: MariaDB/MySQL - runtime: false - type: mysql - versions: - deprecated: - - '10.2' - - '10.1' - - '10.0' - - '5.5' - supported: - - '10.11' - - '10.6' - - '10.5' - - '10.4' - - '10.3' - versions-dedicated-gen-2: - supported: - - 10.5 Galera - - 10.4 Galera - - 10.3 Galera - deprecated: - - 10.2 Galera - - 10.1 Galera - - 10.0 Galera - versions-dedicated-gen-3: - supported: - - 10.11 Galera - - 10.6 Galera - - 10.5 Galera - - 10.4 Galera - - 10.3 Galera - deprecated: - - 10.2 Galera - - 10.1 Galera -memcached: - description: Memcached service. - repo_name: memcached - disk: false - docs: - relationship_name: memcachedcache - service_name: cachemc - url: /add-services/memcached.html - endpoint: memcached - min_disk_size: null - name: Memcached - runtime: false - type: memcached - versions: - deprecated: [] - supported: - - '1.6' - - '1.5' - - '1.4' - versions-dedicated-gen-2: - supported: - - '1.4' -mongodb: - description: Experimental MongoDB support on Platform.sh - repo_name: mongodb - disk: true - docs: - relationship_name: mongodatabase - service_name: dbmongo - url: /add-services/mongodb.html - endpoint: mongodb - min_disk_size: 512 - name: MongoDB - runtime: false - type: mongodb - versions: - deprecated: - - 4.0.3 - - '3.6' - - '3.4' - - '3.2' - - '3.0' - supported: [] -mongodb-enterprise: - description: Support for the enterprise edition of MongoDB - repo_name: mongodb - disk: true - docs: - relationship_name: mongodatabase - service_name: dbmongo - url: /add-services/mongodb.html - endpoint: mongodb - min_disk_size: 512 - name: MongoDB - runtime: false - type: mongodb-enterprise - premium: true - versions: - supported: - - '6.0' - - '5.0' - - '4.4' - - '4.2' - deprecated: - - '4.0' - versions-dedicated-gen-2: - supported: - - '6.0' - - '5.0' - - '4.4' - - '4.2' - deprecated: - - '4.0' -network-storage: - description: '' - repo_name: network-storage - disk: true - docs: - relationship_name: 'null' - service_name: files - url: /add-services/network-storage.html - endpoint: something - min_disk_size: null - name: Network Storage - runtime: false - type: network-storage - versions: - deprecated: - - '1.0' - supported: - - '2.0' - versions-dedicated-gen-3: - deprecated: [] - supported: - - '2.0' -nodejs: - description: NodeJS service for Platform - repo_name: nodejs - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/nodejs.html - web: - commands: - start: node index.js - endpoint: null - min_disk_size: null - name: JavaScript/Node.js - runtime: true - type: nodejs - versions: - deprecated: - - '14' - - '12' - - '10' - - '8' - - '6' - - '4.8' - - '4.7' - - '0.12' - supported: - - '18' - - '16' - versions-dedicated-gen-2: - supported: [] - deprecated: - - '14' - - '12' - - '10' - - '9.8' -opensearch: - description: A manufacture service for OpenSearch - disk: true - docs: - relationship_name: ossearch - service_name: searchopen - url: /add-services/opensearch.html - endpoint: opensearch - min_disk_size: 256 - name: OpenSearch - repo_name: opensearch - runtime: false - type: opensearch - versions: - deprecated: [] - supported: - - '2' - - '1.2' - - '1.1' - legacy: - - '1.1' - versions-dedicated-gen-2: - deprecated: [] - supported: - - '2.5' - - '2.4' - - '1.2' - versions-dedicated-gen-3: - deprecated: [] - supported: - - '2' -oracle-mysql: - description: >- - Images using MySQL from Oracle instead of MariaDB still providing mysql - endpoints - repo_name: oracle-mysql - disk: true - docs: - relationship_name: mysqldatabase - service_name: dbmysql - url: /add-services/mysql.html - endpoint: mysql - min_disk_size: 256 - name: Oracle MySQL - runtime: false - type: oracle-mysql - versions: - deprecated: [] - supported: - - '8.0' - - '5.7' -php: - description: PHP service for Platform.sh. - repo_name: php - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/php.html - web: - locations: - /: - root: web - passthru: /index.php - hooks: - build: - - '|' - - set -e - deploy: - - '|' - - set -e - build: - flavor: composer - endpoint: null - min_disk_size: null - name: PHP - runtime: true - type: php - versions-dedicated-gen-2: - supported: - - '8.2' - - '8.1' - - '8.0' - deprecated: - - '7.4' - - '7.3' - - '7.2' - - '7.1' - - '7.0' - versions: - deprecated: - - '7.4' - - '7.3' - - '7.2' - - '7.1' - - '7.0' - - '5.6' - - '5.5' - - '5.4' - supported: - - '8.2' - - '8.1' - - '8.0' -postgresql: - description: PostgreSQL service for Platform.sh. - repo_name: postgresql - disk: true - docs: - relationship_name: postgresdatabase - service_name: dbpostgres - url: /add-services/postgresql.html - endpoint: postgresql - min_disk_size: null - name: PostgreSQL - runtime: false - type: postgresql - versions: - deprecated: - - '10' - - '9.6' - - '9.5' - - '9.4' - - '9.3' - supported: - - '15' - - '14' - - '13' - - '12' - - '11' - versions-dedicated-gen-2: - deprecated: - - 9.6* - - '9.5' - - '9.4' - - '9.3' - supported: - - 11* - versions-dedicated-gen-3: - deprecated: - - '10' - supported: - - '15' - - '14' - - '13' - - '12' - - '11' -python: - description: '' - repo_name: python - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/python.html - web: - commands: - start: python server.py - hooks: - build: - - '|' - - pipenv install --system --deploy - dependencies: - python3: - pipenv: 2018.10.13 - endpoint: null - min_disk_size: null - name: Python - runtime: true - type: python - versions: - deprecated: - - '3.7' - - '3.6' - - '3.5' - - 2.7* - supported: - - '3.11' - - '3.10' - - '3.9' - - '3.8' -rabbitmq: - description: A manufacture-based container for RabbitMQ - repo_name: rabbitmq - disk: true - docs: - relationship_name: rabbitmqqueue - service_name: queuerabbit - url: /add-services/rabbitmq.html - endpoint: rabbitmq - min_disk_size: 512 - name: RabbitMQ - runtime: false - type: rabbitmq - versions: - deprecated: - - '3.8' - - '3.7' - - '3.6' - - '3.5' - supported: - - '3.12' - - '3.11' - - '3.10' - - '3.9' - legacy: - - '3.8' - - '3.7' - - '3.6' - - '3.5' - versions-dedicated-gen-2: - supported: - - '3.11' - - '3.10' - - '3.9' - deprecated: - - '3.8' - - '3.7' - versions-dedicated-gen-3: - deprecated: [] - supported: - - '3.12' - - '3.11' - - '3.10' - - '3.9' -redis: - description: 'A manufacture-based Redis container ' - repo_name: redis - disk: false - docs: - relationship_name: rediscache - service_name: cacheredis - url: /add-services/redis.html - endpoint: redis - min_disk_size: null - name: Redis - runtime: false - type: redis - versions: - deprecated: - - '6.0' - - '5.0' - - '4.0' - - '3.2' - - '3.0' - - '2.8' - supported: - - '7.0' - - '6.2' - legacy: - - '6.0' - versions-dedicated-gen-2: - supported: - - '7.0' - - '6.2' - deprecated: - - '6.0' - - '5.0' - - '3.2' - versions-dedicated-gen-3: - deprecated: - - '6.0' - - '5.0' - - '4.0' - - '3.2' - - '3.0' - - '2.8' - supported: - - '7.0' - - '6.2' -ruby: - description: '' - repo_name: ruby - disk: false - docs: - relationship_name: null - service_name: null - url: /languages/ruby.html - web: - upstream: - socket_family: unix - commands: - start: unicorn -l $SOCKET -E production config.ru - locations: - /: - root: public - passthru: true - expires: 1h - allow: true - hooks: - build: - - '|' - - bundle install --without development test - deploy: - - '|' - - RACK_ENV=production bundle exec rake db:migrate - endpoint: null - min_disk_size: null - name: Ruby - runtime: true - type: ruby - versions: - deprecated: - - '2.7' - - '2.6' - - '2.5' - - '2.4' - - '2.3' - supported: - - '3.2' - - '3.1' - - '3.0' - legacy: - - '2.7' - - '2.6' - - '2.5' - - '2.4' - - '2.3' -rust: - description: '' - repo_name: rust - disk: true - docs: - relationship_name: null - service_name: null - url: /languages/rust.html - web: - commands: - start: ./target/debug/hello - endpoint: null - min_disk_size: null - name: Rust - runtime: true - type: rust - versions: - deprecated: [] - supported: - - '1' -solr: - description: '' - repo_name: solr - disk: true - docs: - relationship_name: solrsearch - service_name: searchsolr - url: /add-services/solr.html - endpoint: solr - min_disk_size: 256 - name: Solr - runtime: false - type: solr - versions: - deprecated: - - '8.6' - - '8.4' - - '8.0' - - '7.7' - - '7.6' - - '6.6' - - '6.3' - - '4.10' - - '3.6' - supported: - - '9.2' - - '9.1' - - '8.11' - versions-dedicated-gen-2: - supported: - - '8.11' - deprecated: - - '8.6' - - '8.0' - - '7.7' - - '6.6' - - '6.3' - - '4.10' - versions-dedicated-gen-3: - supported: - - '9.2' - - '9.1' - - '8.11' - deprecated: [] -varnish: - description: '' - repo_name: varnish - disk: false - docs: - relationship_name: varnishstats - service_name: varnish - url: /add-services/varnish.html - endpoint: http+stats - min_disk_size: null - configuration: |- - vcl: !include - type: string - path: config.vcl - service_relationships: 'application: ''app:http''' - name: Varnish - runtime: false - type: varnish - versions: - deprecated: - - '5.2' - - '5.1' - - '7.1' - - '6.0' - supported: - - '7.2' - - '6.3' -vault-kms: - description: '' - disk: true - docs: - relationship_name: vault_service - service_name: vault-kms - url: /add-services/vault.html - endpoint: manage_keys - min_disk_size: 512 - configuration: |- - endpoints: - : - - policy: - key: "" - type: - name: Vault KMS - repo_name: vault-kms - runtime: false - type: vault-kms - versions: - supported: - - '1.12' - deprecated: - - '1.8' - - '1.6' - legacy: - - '1.6' - versions-dedicated-gen-2: - supported: - - '1.6' - versions-dedicated-gen-3: - supported: - - '1.12' - deprecated: - - '1.8' - - '1.6' -redis-persistent: - description: 'A manufacture-based Redis container ' - repo_name: redis - disk: true - docs: - relationship_name: redisdata - service_name: data - url: /add-services/redis.html - endpoint: redis - min_disk_size: null - name: Persistent Redis - runtime: false - type: redis-persistent - versions: - deprecated: - - '6.0' - - '5.0' - - '4.0' - - '3.2' - - '3.0' - - '2.8' - supported: - - '7.0' - - '6.2' - legacy: - - '6.0' - versions-dedicated-gen-2: - supported: - - '7.0' - - '6.2' - deprecated: - - '6.0' - - '5.0' - - '3.2' - versions-dedicated-gen-3: - deprecated: - - '6.0' - - '5.0' - - '4.0' - - '3.2' - - '3.0' - - '2.8' - supported: - - '7.0' - - '6.2' diff --git a/sites/platform/config/_default/params.yaml b/sites/platform/config/_default/params.yaml index e942ad9176..57efc6c4cb 100644 --- a/sites/platform/config/_default/params.yaml +++ b/sites/platform/config/_default/params.yaml @@ -13,7 +13,18 @@ vendor: name: Platform.sh cli: platform env_prefix: PLATFORM + urls: + main: https://platform.sh/ + docs: https://docs.platform.sh/ + support: https://support.platform.sh/ + sales: https://platform.sh/contact + console: https://console.platform.sh/ + api: https://api.platform.sh/ config_dir: .platform + files: + routes: .platform/routes.yaml + services: .platform/services.yaml + apps: .platform.app.yaml # Images (kept in static/) logo: "images/logos/Platformsh_logo_white.svg" diff --git a/sites/platform/src/_index.md b/sites/platform/src/_index.md index 979717a3b5..49e0826779 100644 --- a/sites/platform/src/_index.md +++ b/sites/platform/src/_index.md @@ -5,25 +5,25 @@ title: Introduction {{< vendor/name >}} is a second-generation Platform-as-a-Service built especially for continuous deployment. It allows you to host web applications on the cloud while making your development and testing workflows more productive. -If you're new to Platform.sh, we recommend starting with the **Big Picture**, in particular [Structure](/overview/structure.md), and [Build & Deploy](/overview/build-deploy.md) will get you started on the right track to best use Platform.sh. +If you're new to {{< vendor/name >}}, we recommend starting with the **Big Picture**, in particular [Structure](/overview/structure.md), and [Build & Deploy](/overview/build-deploy.md) will get you started on the right track to best use {{< vendor/name >}}. -The main requirement of Platform.sh is that you use Git to manage your application code. +The main requirement of {{< vendor/name >}} is that you use Git to manage your application code. Your project's configuration is driven almost entirely by a small number of YAML files in your Git repository. The **Configuration** section covers those in more detail and can serve as both a tutorial and a quick reference. -Platform.sh is built on Debian, supports many different programming **Languages** and environments, +{{< vendor/name >}} is built on Debian, supports many different programming **Languages** and environments, and features recommended optimizations for several **Featured Frameworks**. -Finally, you can also get tips for setting up your own **Development** workflow and **Administering** your Platform.sh account. +Finally, you can also get tips for setting up your own **Development** workflow and **Administering** your {{< vendor/name >}} account. ## Git Driven Infrastructure -As a Platform as a Service, or PaaS, Platform.sh automatically manages everything your application needs to run. +As a Platform as a Service, or PaaS, {{< vendor/name >}} automatically manages everything your application needs to run. That means you can, and should, view your infrastructure needs as part of your application and address them under version control. ### Infrastructure as code -Platform.sh covers not only all of your hosting needs but also most of your DevOps needs. It is a single tool that covers the application life-cycle from development to production and scaling. +{{< vendor/name >}} covers not only all of your hosting needs but also most of your DevOps needs. It is a single tool that covers the application life-cycle from development to production and scaling. You only need to write your code, including a few YAML files that specify your desired infrastructure, commit it to Git, and push. You don't need to set up anything manually. The web server is already set up and configured, as is any database, search engine, or cache that you specify. @@ -34,11 +34,11 @@ It really is "what would my site look like if I merged this to production?" ever You can use these concepts to replicate a traditional development/staging/production workflow or even to give every feature its own effective staging environment before merging to production (empowering you to use git-flow like methodologies even better). You could also have an intermediary integration branch for several other branches. -Platform.sh respects the structure of branches. It's entirely up to you. +{{< vendor/name >}} respects the structure of branches. It's entirely up to you. ### Full stack management -Managing your full stack on Platform.sh gives you the following unique features: +Managing your full stack on {{< vendor/name >}} gives you the following unique features: 1. **Unified Environment:** All of your services (MySQL, ElasticSearch, MongoDB, etc.) are managed inside the cluster and included in the price, with no external single-points-of-failure. When you back up an environment, you get a fully consistent snapshot of your whole application. 2. **Multi-Services & Multi-App:** You can deploy multiple applications (for example, in a microservice-based architecture), using multiple data backends (MySQL, PostgreSQL, Redis, etc.) written in multiple frameworks (Drupal + NodeJS + Flask, for example) in multiple languages, all in the same cluster. diff --git a/sites/platform/src/add-services/_index.md b/sites/platform/src/add-services/_index.md index 1a861caed3..09838166f9 100644 --- a/sites/platform/src/add-services/_index.md +++ b/sites/platform/src/add-services/_index.md @@ -7,7 +7,7 @@ keywords: - "services.yaml" --- -Platform.sh includes many services, so you don't have to subscribe to external cache or search engine services. +{{< vendor/name >}} includes many services, so you don't have to subscribe to external cache or search engine services. Because the services are included in your project, you can manage them through Git and they're backed up together with the rest of your project. @@ -81,7 +81,7 @@ The following table presents the keys you can define for each service: Resources are distributed across all containers in a project from the total available from your [plan size](../administration/pricing/_index.md). -By default, Platform.sh allocates CPU and memory resources to each container automatically. +By default, {{< vendor/name >}} allocates CPU and memory resources to each container automatically. Some services are optimized for high CPU load, some for high memory load. If your plan is sufficiently large for bigger containers, you can increase the size of your service container. @@ -150,7 +150,7 @@ You can connect through your app or by opening an SSH tunnel to access the servi title=In an app +++ -When connecting to a service from an app, you may want to use one of the Platform.sh [configuration readers](https://github.com/platformsh/?q=config+reader). +When connecting to a service from an app, you may want to use one of the {{< vendor/name >}} [configuration readers](https://github.com/platformsh/?q=config+reader). These tools make it easier to get credentials inside your app. Alternatively, once a service is running and exposed as a relationship, diff --git a/sites/platform/src/add-services/elasticsearch.md b/sites/platform/src/add-services/elasticsearch.md index c1bdacb10f..20c40e1a2d 100644 --- a/sites/platform/src/add-services/elasticsearch.md +++ b/sites/platform/src/add-services/elasticsearch.md @@ -24,8 +24,8 @@ See the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsea ## Supported versions Elasticsearch is now a premium service. -This means that from version 7.11 onwards, you need to add Elasticsearch to your project at an additional cost. -To do so, contact [Sales](https://platform.sh/contact/). +This means that from version 7.11 onward, you need to add Elasticsearch to your project at an additional cost. +To do so, contact {{< vendor/url "sales" "Sales" >}}. The following premium versions are supported: @@ -216,7 +216,7 @@ There are two ways to do so. In your `services.yaml` file, change the version *and* name of your Elasticsearch service. Then update the name in the `.platform.app.yaml` relationships block. -When you push that to Platform.sh, the old service is deleted and a new one with the new name is created with no data. +When you push that to {{< vendor/name >}}, the old service is deleted and a new one with the new name is created with no data. You can then have your application reindex data as appropriate. This approach has the downsides of temporarily having an empty Elasticsearch instance, diff --git a/sites/platform/src/add-services/headless-chrome.md b/sites/platform/src/add-services/headless-chrome.md index 53692813ed..0040520c21 100644 --- a/sites/platform/src/add-services/headless-chrome.md +++ b/sites/platform/src/add-services/headless-chrome.md @@ -2,7 +2,7 @@ title: "Headless Chrome" weight: -90 description: | - Headless Chrome is a headless browser that can be configured on projects like any other service on Platform.sh. + Headless Chrome is a headless browser that can be configured on projects like any other service on {{< vendor/name >}}. --- {{% description %}} @@ -81,7 +81,7 @@ exports.getBrowser = async function (url) { Puppeteer allows your application to [create screenshots](https://pptr.dev/#?product=Puppeteer&version=v13.0.1&show=api-pagescreenshotoptions), [emulate a mobile device](https://pptr.dev/#?product=Puppeteer&version=v13.0.1&show=api-pageemulateoptions), [generate PDFs](https://pptr.dev/#?product=Puppeteer&version=v13.0.1&show=api-pagepdfoptions), and much more. -You can find some useful examples of using headless Chrome and Puppeteer on Platform.sh on the Community Portal: +You can find some useful examples of using headless Chrome and Puppeteer on {{< vendor/name >}} on the Community Portal: * [How to take screenshots using Puppeteer and Headless Chrome](https://community.platform.sh/t/how-to-take-screenshots-using-puppeteer-and-headless-chrome/305) * [How to generate PDFs using Puppeteer and Headless Chrome](https://community.platform.sh/t/how-to-generate-pdfs-using-puppeteer-and-headless-chrome/306) diff --git a/sites/platform/src/add-services/influxdb.md b/sites/platform/src/add-services/influxdb.md index 4dbd52b457..d2726dcac7 100644 --- a/sites/platform/src/add-services/influxdb.md +++ b/sites/platform/src/add-services/influxdb.md @@ -88,7 +88,7 @@ if (getenv('PLATFORM_RELATIONSHIPS')) { To export your data from InfluxDB, follow these steps: 1. Install and set up the [`influx` CLI](https://docs.influxdata.com/influxdb/cloud/tools/influx-cli/). -2. Connect to your InfluxDB service with the [Platform.sh CLI](../administration/cli/_index.md): +2. Connect to your InfluxDB service with the [{{< vendor/name >}} CLI](../administration/cli/_index.md): ```bash platform tunnel:single @@ -116,17 +116,17 @@ To export your data from InfluxDB, follow these steps: ### From a previous 2.x version -From version 2.3 onwards, the structure of relationships changes. +From version 2.3 onward, the structure of relationships changes. If you're using a prior 2.x version, your app might currently rely on pulling the `bucket`, `org`, `api_token`, -or `user` values available in the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables). +or `user` values available in the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-provided-variables). If so, to ensure your upgrade is successful, make the following changes to your connection logic: - Rename the `user` key to `username`. - Move the `org`, `bucket` and `api_token` keys so they're contained in a dictionary under the `query` key. -If you're relying on any other attributes connecting to InfluxDB, they remain accessible as top-level keys from the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables), aside from those addressed above: +If you're relying on any other attributes connecting to InfluxDB, they remain accessible as top-level keys from the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-provided-variables), aside from those addressed above: ```yaml @@ -156,7 +156,7 @@ If you're relying on any other attributes connecting to InfluxDB, they remain ac ### From a 1.x version -From version 2.3 onwards, InfluxDB includes an upgrade utility that can convert databases from previous versions to version 2.3 or later. +From version 2.3 onward, InfluxDB includes an upgrade utility that can convert databases from previous versions to version 2.3 or later. To upgrade from a 1.x version to 2.3 or later, change the service version in your `.platform/services.yaml` file and push your project. @@ -167,6 +167,6 @@ Any existing data you had in your 1.x system is automatically upgraded for you i During an upgrade from a 1.x version to a 2.3 version or later, a new admin password and a new admin API token are automatically generated. Previous credentials can't be retained.
-You can retrieve your new credentials through the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables) or by running `platform relationships`. +You can retrieve your new credentials through the [`PLATFORM_RELATIONSHIPS` environment variable](../development/variables/use-variables.md#use-provided-variables) or by running `platform relationships`. {{< /note >}} \ No newline at end of file diff --git a/sites/platform/src/add-services/memcached.md b/sites/platform/src/add-services/memcached.md index 4c649ba89b..e6737e722d 100644 --- a/sites/platform/src/add-services/memcached.md +++ b/sites/platform/src/add-services/memcached.md @@ -10,7 +10,7 @@ sidebarTitle: "Memcached" See the [Memcached documentation](https://memcached.org) for more information. -Both Memcached and Redis can be used for application caching. As a general rule, Memcached is simpler and thus more widely supported while Redis is more robust. Platform.sh recommends using Redis if possible but Memcached is fully supported if an application favors that cache service. +Both Memcached and Redis can be used for application caching. As a general rule, Memcached is simpler and thus more widely supported while Redis is more robust. {{< vendor/name >}} recommends using Redis if possible but Memcached is fully supported if an application favors that cache service. {{% frameworks %}} diff --git a/sites/platform/src/add-services/mongodb.md b/sites/platform/src/add-services/mongodb.md index 62801b9d35..365d973c58 100644 --- a/sites/platform/src/add-services/mongodb.md +++ b/sites/platform/src/add-services/mongodb.md @@ -134,7 +134,7 @@ mongo mongodb.internal The most straightforward way to export data from a MongoDB database is to open an SSH tunnel to it and export the data directly using MongoDB's tools. -First, open an SSH tunnel with the Platform.sh CLI: +First, open an SSH tunnel with the {{< vendor/name >}} CLI: ```bash platform tunnel:open diff --git a/sites/platform/src/add-services/mysql/_index.md b/sites/platform/src/add-services/mysql/_index.md index ce0cd238ac..8836c16673 100644 --- a/sites/platform/src/add-services/mysql/_index.md +++ b/sites/platform/src/add-services/mysql/_index.md @@ -6,7 +6,7 @@ description: See how to configure a MariaDB/MySQL server to store your data. layout: single --- -Platform.sh supports both MariaDB and Oracle MySQL to manage your relational databases. +{{< vendor/name >}} supports both MariaDB and Oracle MySQL to manage your relational databases. Their infrastructure setup is nearly identical, though they differ in some features. See the [MariaDB documentation](https://mariadb.org/learn/) or [MySQL documentation](https://dev.mysql.com/doc/refman/en/) for more information. @@ -389,7 +389,7 @@ To change the timezone for a given connection, run `SET time_zone = {{< variable ## Exporting data -To download all data from your SQL database, use the Platform.sh CLI. +To download all data from your SQL database, use the {{< vendor/name >}} CLI. If you have a single SQL database, the following command exports all data to a local file: ```bash @@ -429,7 +429,7 @@ To load data into a database, pipe an SQL dump through the `platform sql` comman platform sql < my_database_backup.sql ``` -That runs the database backup against the SQL database on Platform.sh. +That runs the database backup against the SQL database on {{< vendor/name >}}. That works for any SQL file, so the usual caveats about importing an SQL dump apply (for example, it's best to run against an empty database). diff --git a/sites/platform/src/add-services/mysql/mysql-replication.md b/sites/platform/src/add-services/mysql/mysql-replication.md index 997e7d7e91..7f53ed25be 100644 --- a/sites/platform/src/add-services/mysql/mysql-replication.md +++ b/sites/platform/src/add-services/mysql/mysql-replication.md @@ -1,7 +1,7 @@ --- title: "MariaDB/MySQL External Replication" sidebarTitle: "MariaDB/MySQL Replication" -description: In rare cases, it may be useful to maintain a replica instance of your MySQL/MariaDB database outside of Platform.sh. +description: In rare cases, it may be useful to maintain a replica instance of your MySQL/MariaDB database outside of {{< vendor/name >}}. --- {{% description %}} @@ -9,7 +9,7 @@ description: In rare cases, it may be useful to maintain a replica instance of y Normally an automated backup is better for short-term usage and a `mysqldump` for longer term storage, but in some cases the data set is large enough that `mysqldump` is prohibitive. In that case, you can enable external replication using an extra permission. -Note that this guide covers the Platform.sh side; you need to set up and maintain your own replica instance. +Note that this guide covers the {{< vendor/name >}} side; you need to set up and maintain your own replica instance. Consult the MySQL or MariaDB documentation for steps to do so. ## Create a replication user @@ -121,7 +121,7 @@ And reload the replica instance for the changes to take an effect. ### Set up SSH tunneling You need to set up an SSH tunnel from the replica server to the primary, tunneled through the application. -To do so using the Platform.sh CLI, run the following +To do so using the {{< vendor/name >}} CLI, run the following (replacing `{{< variable "BRANCH_NAME" >}}` with the name of your production branch): ```bash @@ -136,7 +136,7 @@ The SSH connection is interrupted every time the environment redeploys. For repl ### Starting the Replica -Once the data has been imported, you are ready to start replicating. Begin by running a `CHANGE MASTER TO`, making sure that `MASTER_LOG_FILE` matches the file and `MASTER_LOG_POS` the position returned by the earlier `SHOW MASTER STATUS` on the Platform.sh database. For example: +Once the data has been imported, you are ready to start replicating. Begin by running a `CHANGE MASTER TO`, making sure that `MASTER_LOG_FILE` matches the file and `MASTER_LOG_POS` the position returned by the earlier `SHOW MASTER STATUS` on the {{< vendor/name >}} database. For example: ```sql mysql> CHANGE MASTER TO diff --git a/sites/platform/src/add-services/mysql/troubleshoot.md b/sites/platform/src/add-services/mysql/troubleshoot.md index 1f12bc93ae..335f7d7ff7 100644 --- a/sites/platform/src/add-services/mysql/troubleshoot.md +++ b/sites/platform/src/add-services/mysql/troubleshoot.md @@ -82,4 +82,4 @@ The best approach is to wrap your connection logic in code that detects a "serve and tries to re-establish the connection. Alternatively, if your worker is idle for too long it can self-terminate. -Platform.sh automatically restarts the worker process and the new process can establish a new database connection. +{{< vendor/name >}} automatically restarts the worker process and the new process can establish a new database connection. diff --git a/sites/platform/src/add-services/network-storage.md b/sites/platform/src/add-services/network-storage.md index 9c215f9a01..1473efb85b 100644 --- a/sites/platform/src/add-services/network-storage.md +++ b/sites/platform/src/add-services/network-storage.md @@ -3,7 +3,7 @@ title: "Network Storage" weight: -30 --- -Platform.sh supports internal "storage as a service" to provide a file store that can be shared between different application containers. +{{< vendor/name >}} supports internal "storage as a service" to provide a file store that can be shared between different application containers. The network storage service enables a new kind of [mount](../create-apps/app-reference.md#mounts) that refers to a shared service rather than to a local directory. @@ -27,7 +27,7 @@ If your app does this regularly, a local mount is more effective. |------|-------------------------------|------------------------------ | | {{< image-versions image="network-storage" status="supported" environment="grid" >}} | {{< image-versions image="network-storage" status="supported" environment="dedicated-gen-3" >}} | {{< image-versions image="network-storage" status="supported" environment="dedicated-gen-2" >}} | -This service is the Platform.sh network storage implementation, not to a version of a third-party application. +This service is the {{< vendor/name >}} network storage implementation, not to a version of a third-party application. {{< note theme="warning">}} diff --git a/sites/platform/src/add-services/opensearch.md b/sites/platform/src/add-services/opensearch.md index 3015ed3359..f5f315ad2b 100644 --- a/sites/platform/src/add-services/opensearch.md +++ b/sites/platform/src/add-services/opensearch.md @@ -138,7 +138,7 @@ There are two ways to do so. In your `services.yaml` file, change the version *and* name of your OpenSearch service. Then update the name in the `.platform.app.yaml` relationships block. -When you push that to Platform.sh, the old service is deleted and a new one with the new name is created with no data. +When you push that to {{< vendor/name >}}, the old service is deleted and a new one with the new name is created with no data. You can then have your application reindex data as appropriate. This approach has the downsides of temporarily having an empty OpenSearch instance, diff --git a/sites/platform/src/add-services/postgresql.md b/sites/platform/src/add-services/postgresql.md index 9d211ae2b5..08ea300bb8 100644 --- a/sites/platform/src/add-services/postgresql.md +++ b/sites/platform/src/add-services/postgresql.md @@ -151,7 +151,7 @@ The easiest way to load data into a database is to pipe an SQL dump through the platform sql < my_database_backup.sql ``` -That runs the database backup against the SQL database on Platform.sh. +That runs the database backup against the SQL database on {{< vendor/name >}}. That works for any SQL file, so the usual caveats about importing an SQL dump apply (for example, it's best to run against an empty database). As with exporting, you can also specify a specific environment to use and a specific database relationship to use, if there are multiple. @@ -216,7 +216,7 @@ This example creates a single PostgreSQL service named `dbpostgres`. The server * `reporter`: has `SELECT` query access to the `main` database, but no access to `legacy`. * `importer`: has `SELECT`/`INSERT`/`UPDATE`/`DELETE` access (but not DDL access) to the `legacy` database. It doesn't have access to `main`. -If a given endpoint has access to multiple databases you should also specify which is listed by default in the relationships array. If one isn't specified, the `path` property of the relationship is `null`. While that may be acceptable for an application that knows the name of the database it's connecting to, automated tools like the Platform.sh CLI can't access the database on that relationship. For that reason, defining the `default_database` property is always recommended. +If a given endpoint has access to multiple databases you should also specify which is listed by default in the relationships array. If one isn't specified, the `path` property of the relationship is `null`. While that may be acceptable for an application that knows the name of the database it's connecting to, automated tools like the {{< vendor/name >}} CLI can't access the database on that relationship. For that reason, defining the `default_database` property is always recommended. Once these endpoints are defined, you need to expose them to your application as a relationship. Continuing with the above example, your `relationships` in `.platform.app.yaml` might look like: @@ -274,7 +274,7 @@ To change the timezone for the current session, run `SET TIME ZONE {{< variable ## Extensions -Platform.sh supports a number of PostgreSQL extensions. To enable them, list them under the `configuration.extensions` key in your `services.yaml` file, like so: +{{< vendor/name >}} supports a number of PostgreSQL extensions. To enable them, list them under the `configuration.extensions` key in your `services.yaml` file, like so: ```yaml db: diff --git a/sites/platform/src/add-services/rabbitmq.md b/sites/platform/src/add-services/rabbitmq.md index 57d192eaeb..1706d730a9 100644 --- a/sites/platform/src/add-services/rabbitmq.md +++ b/sites/platform/src/add-services/rabbitmq.md @@ -81,7 +81,7 @@ In each case, you need the login credentials that you can obtain from the [relat ### Via SSH To connect directly to your RabbitMQ service in an environment, -open an SSH tunnel with the [Platform.sh CLI](../administration/cli/_index.md). +open an SSH tunnel with the [{{< vendor/name >}} CLI](../administration/cli/_index.md). To open an SSH tunnel to your service with port forwarding, run the following command: diff --git a/sites/platform/src/add-services/redis.md b/sites/platform/src/add-services/redis.md index 7c7633873a..c6b1ea5f1c 100644 --- a/sites/platform/src/add-services/redis.md +++ b/sites/platform/src/add-services/redis.md @@ -6,7 +6,7 @@ sidebarTitle: "Redis" [Redis](https://redis.io/documentation) is a multi-model database that allows you to store data in memory for high-performance data retrieval and key-value storage. -Platform.sh supports two different Redis configurations: +{{< vendor/name >}} supports two different Redis configurations: - [Ephemeral](#ephemeral-redis): to set up a non-persistent cache for your application - [Persistent](#persistent-redis): to set up fast persistent storage for your application @@ -220,7 +220,7 @@ After you've [configured your Redis service](#usage-example), you can access it using the [Redis CLI](https://redis.io/docs/ui/cli/). Retrieve the hostname and port you can connect to -through the `PLATFORM_RELATIONSHIPS` [environment variable](../../development/variables/use-variables.md#use-platformsh-provided-variables). +through the `PLATFORM_RELATIONSHIPS` [environment variable](../../development/variables/use-variables.md#use-provided-variables). To do so, run the `platform relationships` command. After you've retrieved the hostname and port, [open an SSH session](../development/ssh/_index.md). diff --git a/sites/platform/src/add-services/solr.md b/sites/platform/src/add-services/solr.md index 8790d992bf..229865fa97 100644 --- a/sites/platform/src/add-services/solr.md +++ b/sites/platform/src/add-services/solr.md @@ -85,7 +85,7 @@ highlight=python ## Solr 4 -For Solr 4, Platform.sh supports only a single core per server called `collection1`. +For Solr 4, {{< vendor/name >}} supports only a single core per server called `collection1`. You must provide your own Solr configuration via a `core_config` key in your ``.platform/services.yaml``: @@ -109,7 +109,7 @@ searchsolr: ## Solr 6 and later -For Solr 6 and later Platform.sh supports multiple cores via different endpoints. Cores and endpoints are defined separately, with endpoints referencing cores. Each core may have its own configuration or share a configuration. It is best illustrated with an example. +For Solr 6 and later {{< vendor/name >}} supports multiple cores via different endpoints. Cores and endpoints are defined separately, with endpoints referencing cores. Each core may have its own configuration or share a configuration. It is best illustrated with an example. ```yaml searchsolr: @@ -278,7 +278,7 @@ There are two ways of doing that. In your `services.yaml` file, change the version of your Solr service *and* its name. Then update the name in the `.platform.app.yaml` relationships block. -When you push that to Platform.sh, the old service is deleted and a new one with the name is created, with no data. You can then have your application re-index data as appropriate. +When you push that to {{< vendor/name >}}, the old service is deleted and a new one with the name is created, with no data. You can then have your application re-index data as appropriate. This approach has the downside of temporarily having an empty Solr instance, which your application may or may not handle gracefully, and needing to rebuild your index afterward. Depending on the size of your data that could take a while. diff --git a/sites/platform/src/add-services/varnish.md b/sites/platform/src/add-services/varnish.md index 9f18544855..0eaf5f0079 100644 --- a/sites/platform/src/add-services/varnish.md +++ b/sites/platform/src/add-services/varnish.md @@ -4,7 +4,7 @@ weight: 40 --- Varnish is a popular HTTP proxy server, often used for caching. -You usually don't need it with Platform.sh as the standard router includes HTTP cache +You usually don't need it with {{< vendor/name >}} as the standard router includes HTTP cache and a CDN would cover more advanced uses. But you can include Varnish as a service. @@ -47,7 +47,7 @@ The `path` defines the file relative to the `.platform` directory. To tell Varnish how to handle traffic, in the `.platform` directory add a [Varnish Configuration Language (VCL) template](https://www.varnish-software.com/developers/tutorials/example-vcl-template/). -This template is supplemented by automatic additions from Platform.sh. +This template is supplemented by automatic additions from {{< vendor/name >}}. So you MUST NOT include certain features that you might elsewhere: - A `vcl_init()` function: @@ -68,7 +68,7 @@ The logic varies based on whether you have one or more apps. {{< note >}} Misconfigured VCL files can result in incorrect and confusing behavior that's hard to debug. -Platform.sh doesn't help with VCL configuration options beyond the basic connection logic documented here. +{{< vendor/name >}} doesn't help with VCL configuration options beyond the basic connection logic documented here. You can see any compilation errors with the [stats endpoint](#stats-endpoint). @@ -156,7 +156,7 @@ import xkey; ## Circular relationships -At this time, Platform.sh doesn't support circular relationships between services and apps. +At this time, {{< vendor/name >}} doesn't support circular relationships between services and apps. That means you can't add a relationship from an app fronted by Varnish to the Varnish service. If you do so, then one of the relationships is skipped and the connection doesn't work. @@ -175,7 +175,7 @@ and add logic similar to the following to your VCL template: import vsthrottle; sub vcl_recv { - # The Platform.sh router provides the real client IP as X-Client-IP + # The {{< vendor/name >}} router provides the real client IP as X-Client-IP # This replaces client.identity in other implementations if (vsthrottle.is_denied(req.http.X-Client-IP, 20, 10s, 120s)) { # Client has exceeded 20 requests in 10 seconds. @@ -215,7 +215,7 @@ The following example shows how to set up purging. ```bash {location=".platform/config.vcl"} sub vcl_recv { if (req.method == "PURGE") { - # The Platform.sh router provides the real client IP as X-Client-IP + # The {{< vendor/name >}} router provides the real client IP as X-Client-IP # Use std.ip to convert the string to an IP for comparison if (!std.ip(req.http.X-Client-IP, "0.0.0.0") ~ purge) { # Deny all purge requests not from the allowed IPs diff --git a/sites/platform/src/add-services/vault.md b/sites/platform/src/add-services/vault.md index 6ddbab3e0e..f445cedf5b 100644 --- a/sites/platform/src/add-services/vault.md +++ b/sites/platform/src/add-services/vault.md @@ -5,7 +5,7 @@ weight: 50 --- The Vault key management service (KMS) provides key management and access control for your secrets. -The Platform.sh Vault KMS offers the [transit secrets engine](https://developer.hashicorp.com/vault/docs/secrets/transit) +The {{< vendor/name >}} Vault KMS offers the [transit secrets engine](https://developer.hashicorp.com/vault/docs/secrets/transit) to sign, verify, encrypt, decrypt, and rewrap information. Vault doesn't store the data sent to the transit secrets engine, diff --git a/sites/platform/src/administration/_index.md b/sites/platform/src/administration/_index.md index 75d2352f12..4accc1347a 100644 --- a/sites/platform/src/administration/_index.md +++ b/sites/platform/src/administration/_index.md @@ -2,5 +2,5 @@ title: "Administration" weight: -60 description: | - Administration tasks for your Platform.sh projects is accessible from within the Console and through the CLI. + Administration tasks for your {{< vendor/name >}} projects is accessible from within the Console and through the CLI. --- diff --git a/sites/platform/src/administration/cli/_index.md b/sites/platform/src/administration/cli/_index.md index 9af08da86d..7cdfd4ee92 100644 --- a/sites/platform/src/administration/cli/_index.md +++ b/sites/platform/src/administration/cli/_index.md @@ -2,7 +2,7 @@ title: Command line interface (CLI) weight: -10 description: | - See how to use and manage your Platform.sh projects directly from your terminal. Anything you can do within the Console can be done with the CLI. + See how to use and manage your {{< vendor/name >}} projects directly from your terminal. Anything you can do within the Console can be done with the CLI. layout: single keywords: - CLI @@ -12,7 +12,7 @@ keywords: {{% description %}} -The CLI uses the git interface and the [Platform.sh REST API](https://api.platform.sh/docs/) to accomplish tasks. +The CLI uses the git interface and the [{{< vendor/name >}} REST API](https://api.platform.sh/docs/) to accomplish tasks. Its source code is hosted on [GitHub](https://github.com/platformsh/cli). ## 1. Install @@ -36,7 +36,7 @@ If you experience authentication issues or want to force a login, run the comman ## 3. Use Now you can run actions on your projects such as branching and merging. -You can also simulate a local build of your codebase as if you were pushing a change to Platform.sh, +You can also simulate a local build of your codebase as if you were pushing a change to {{< vendor/name >}}, including your services and data. Get a list of all available commands with: @@ -87,7 +87,7 @@ Examples: ### Select the right project and environment -When you are in an empty directory or a directory not associated with a specific Platform.sh project, +When you are in an empty directory or a directory not associated with a specific {{< vendor/name >}} project, if you run a command that requires a specific project and environment, you are prompted to select them. For example, if you run the following command: @@ -210,7 +210,7 @@ eval $(platform completion) ### Run commands on your container -You can use the Platform.sh CLI to run commands on your container. +You can use the {{< vendor/name >}} CLI to run commands on your container. You can use any command you've added in [dependencies](../../create-apps/app-reference.md#dependencies) or a [hook](../../create-apps/app-reference.md#hooks). diff --git a/sites/platform/src/administration/cli/api-tokens.md b/sites/platform/src/administration/cli/api-tokens.md index cf4be6e52d..83a7545876 100644 --- a/sites/platform/src/administration/cli/api-tokens.md +++ b/sites/platform/src/administration/cli/api-tokens.md @@ -4,13 +4,13 @@ sidebarTitle: "API tokens" weight: 1 --- -You need to set up an API token to authenticate the Platform.sh CLI for any of the following tasks: +You need to set up an API token to authenticate the {{< vendor/name >}} CLI for any of the following tasks: - Running automated tasks on a CI system - Running automated tasks directly on app container, for example in a cron job ## Before you begin -You might need the [Platform.sh CLI](../cli/_index.md) to perform certain tasks. +You might need the [{{< vendor/name >}} CLI](../cli/_index.md) to perform certain tasks. For example, you need the CLI to do the following: - [Check the validity of an API token](#optional-check-the-validity-of-your-api-token). - [Load the CLI SSH certificate for non-CLI commands](#use-the-cli-ssh-certificate-for-non-cli-commands). @@ -19,7 +19,7 @@ For example, you need the CLI to do the following: ## 1. Create a machine user To safely run automated tasks, first create machine users. -Each machine user has its own Platform.sh account associated with a unique email address. +Each machine user has its own {{< vendor/name >}} account associated with a unique email address. You can grant them restrictive [access permissions](../users.md) to handle specific automated tasks. For security purposes, create a machine user for each type of task you want to automate. @@ -39,7 +39,7 @@ title=Using the CLI Note that you can further [adjust user roles](../users.md#environment-type-roles) depending on your needs and each environment type. 2. In the email invitation, click **Create account**. -3. To create a Platform.sh account for the machine user, click **Sign up** and follow the instructions. +3. To create a {{< vendor/name >}} account for the machine user, click **Sign up** and follow the instructions. <---> +++ @@ -55,7 +55,7 @@ title=In the Console {{< /codetabs >}} -## 2. Create a Platform.sh API token +## 2. Create an API token 1. Log in to the Console as your machine user. 2. Open the user menu (your name or profile picture). @@ -86,12 +86,12 @@ You are logged in. For security reasons, rotate your API tokens regularly. When an API token is compromised, revoke it immediately. -## 3. Authenticate the Platform.sh CLI using your API token +## 3. Authenticate the CLI using your API token After you create your API token, you can use it to do the following: -- Allow a CI system to run automated tasks using the Platform.sh CLI. -- Run automated tasks on an app container using the Platform.sh CLI, +- Allow a CI system to run automated tasks using the {{< vendor/name >}} CLI. +- Run automated tasks on an app container using the {{< vendor/name >}} CLI, for example in a cron job. Note that when running CLI commands in these cases, @@ -101,16 +101,16 @@ use the `--no-wait` flag. ### Authenticate in a CI system -You can allow your CI system to run automated tasks using the Platform.sh CLI. +You can allow your CI system to run automated tasks using the {{< vendor/name >}} CLI. To do so, create an environment variable named `PLATFORMSH_CLI_TOKEN` with your API token as its value. For more information, see your CI system's official documentation. -To run SSH-based commands that aren't specific to the Platform.sh CLI, +To run SSH-based commands that aren't specific to the {{< vendor/name >}} CLI, see how to [load the proper SSH certificate](#use-the-cli-ssh-certificate-for-non-cli-commands). -### Authenticate in a Platform.sh environment +### Authenticate in an environment -You can run automated tasks on an app container using the Platform.sh CLI. +You can run automated tasks on an app container using the {{< vendor/name >}} CLI. To do so, set your API token as a [top-level environment variable](../../development/variables/_index.md#top-level-environment-variables). {{< note theme="warning" >}} @@ -154,16 +154,16 @@ Then add a build hook to your app configuration to install the CLI as part of th hooks: build: | set -e - echo "Installing Platform.sh CLI" + echo "Installing {{< vendor/name >}} CLI" curl -fsSL https://raw.githubusercontent.com/platformsh/cli/main/installer.sh | bash - echo "Testing Platform.sh CLI" + echo "Testing {{< vendor/name >}} CLI" platform ``` You can now call the CLI from within the shell on the app container or in a cron job. -To run SSH-based commands that aren't specific to the Platform.sh CLI, +To run SSH-based commands that aren't specific to the {{< vendor/name >}} CLI, see how to [load the proper SSH certificate](#use-the-cli-ssh-certificate-for-non-cli-commands). You can set up a cron job on a specific type of environment. diff --git a/sites/platform/src/administration/organizations.md b/sites/platform/src/administration/organizations.md index 5ba06c6f37..b9b1bf278d 100644 --- a/sites/platform/src/administration/organizations.md +++ b/sites/platform/src/administration/organizations.md @@ -1,10 +1,10 @@ --- title: Organizations weight: -1 -description: See how to manage multiple Platform.sh projects at once through organizations. +description: See how to manage multiple {{< vendor/name >}} projects at once through organizations. --- -Organizations allow you to manage your Platform.sh projects, users, and billing. +Organizations allow you to manage your {{< vendor/name >}} projects, users, and billing. You can group multiple projects in one organization and manage them together. To manage users within your organization, see how to [manage organization users](./users.md#manage-organization-users). diff --git a/sites/platform/src/administration/pricing/_index.md b/sites/platform/src/administration/pricing/_index.md index 6b80518159..fe3f6823d7 100644 --- a/sites/platform/src/administration/pricing/_index.md +++ b/sites/platform/src/administration/pricing/_index.md @@ -1,11 +1,11 @@ --- title: Pricing weight: 3 -description: See the basics of the plans Platform.sh offers and how to adjust them. +description: See the basics of the plans {{< vendor/name >}} offers and how to adjust them. layout: single --- -Platform.sh offers a variety of plans to fit your needs, including a free trial. +{{< vendor/name >}} offers a variety of plans to fit your needs, including a free trial. Full pricing information is available at https://platform.sh/pricing/. The resources listed there are for [production environments](#production-environments). @@ -180,8 +180,8 @@ If you have any questions, don't hesitate to [contact Sales](https://platform.sh ## Sponsored sites -Platform.sh provides sponsored hosting for Free Software projects, tech community events and organizations as part of our effort to support the Free Software community. -That offering can include either a project on Platform.sh, or profilable environments through Blackfire.io, depending on the needs of the project. +{{< vendor/name >}} provides sponsored hosting for Free Software projects, tech community events and organizations as part of our effort to support the Free Software community. +That offering can include either a project on {{< vendor/name >}}, or profilable environments through Blackfire.io, depending on the needs of the project.
diff --git a/sites/platform/src/administration/servers.md b/sites/platform/src/administration/servers.md index a64757f8a4..33450b2e4c 100644 --- a/sites/platform/src/administration/servers.md +++ b/sites/platform/src/administration/servers.md @@ -1,10 +1,10 @@ --- title: Server upgrades -description: Information about how some Platform.sh servers delivering features are updated. +description: Information about how some {{< vendor/name >}} servers delivering features are updated. weight: 10 --- -Platform.sh runs a variety of servers to deliver its services. +{{< vendor/name >}} runs a variety of servers to deliver its services. To ensure your projects get the newest features, these servers are occasionally updated. You don't have to do anything to get the updates. diff --git a/sites/platform/src/administration/sso.md b/sites/platform/src/administration/sso.md index 38db6fd669..d3fe679983 100644 --- a/sites/platform/src/administration/sso.md +++ b/sites/platform/src/administration/sso.md @@ -2,22 +2,22 @@ title: "Single sign-on (SSO)" weight: 4 description: | - Platform.sh allows you to set up mandatory SSO with a third-party identity provider (IdP) for all your users. + {{< vendor/name >}} allows you to set up mandatory SSO with a third-party identity provider (IdP) for all your users. banner: type: tiered-feature --- {{% description %}} -Your SSO provider can be enabled for a specific email domain, for example `@example.com`. Every user with a matching email address needs to log in or register on Platform.sh using your SSO provider. Such users can't use an alternative provider, or register a password, or change their email address. +Your SSO provider can be enabled for a specific email domain, for example `@example.com`. Every user with a matching email address needs to log in or register on {{< vendor/name >}} using your SSO provider. Such users can't use an alternative provider, or register a password, or change their email address. ## Mitigation controls -If you deactivate a user on your identity provider, they can't log in or register on Platform.sh. +If you deactivate a user on your identity provider, they can't log in or register on {{< vendor/name >}}. -If the user is already logged in to Platform.sh, they are automatically deactivated after their access token has expired (generally after 1 hour). +If the user is already logged in to {{< vendor/name >}}, they are automatically deactivated after their access token has expired (generally after 1 hour). -A deactivated user can no longer use SSH, Git, or other Platform.sh APIs. +A deactivated user can no longer use SSH, Git, or other {{< vendor/name >}} APIs. ## Service users @@ -35,11 +35,11 @@ Enforce your users to authenticate with Google. Please open a support ticket to #### Issue with re-authenticating every 15 minutes -If your organization has Google SSO enabled on Platform.sh, you may be required to re-authenticate with Google every 15 minutes. This happens when Platform.sh doesn't possess a valid refresh token from your Google account. +If your organization has Google SSO enabled on {{< vendor/name >}}, you may be required to re-authenticate with Google every 15 minutes. This happens when {{< vendor/name >}} doesn't possess a valid refresh token from your Google account. To resolve that, you need to: -1. Go to [https://myaccount.google.com/permissions](https://myaccount.google.com/permissions) and revoke the access from the `Platform.sh` application that has `Access given to auth.api.platform.sh`. +1. Go to [https://myaccount.google.com/permissions](https://myaccount.google.com/permissions) and revoke the access from the `{{< vendor/name >}}` application that has `Access given to auth.api.platform.sh`. 2. Go to [https://auth.api.platform.sh/auth/authorize/google?prompt=consent](https://auth.api.platform.sh/auth/authorize/google?prompt=consent) for the system to obtain a valid refresh token for your Google account. ### OpenId Connect diff --git a/sites/platform/src/administration/users.md b/sites/platform/src/administration/users.md index 3fb3740fa5..e1f03b3686 100644 --- a/sites/platform/src/administration/users.md +++ b/sites/platform/src/administration/users.md @@ -5,7 +5,7 @@ sidebarTitle: Users description: Manage user access and permissions across all your projects and organizations. --- -Platform.sh offers very granular and flexible user permissions across projects and organizations. +{{< vendor/name >}} offers very granular and flexible user permissions across projects and organizations. When a user is added to a project, they are automatically added to your organization. ## Manage project access diff --git a/sites/platform/src/administration/web/_index.md b/sites/platform/src/administration/web/_index.md index e62f3be8eb..e1ef358ba0 100644 --- a/sites/platform/src/administration/web/_index.md +++ b/sites/platform/src/administration/web/_index.md @@ -3,7 +3,7 @@ title: "Console" weight: -9 layout: single description: | - Platform.sh provides a web console so you can interact with your projects and manage your environments. + {{< vendor/name >}} provides a web console so you can interact with your projects and manage your environments. --- {{% description %}} diff --git a/sites/platform/src/administration/web/configure-environment.md b/sites/platform/src/administration/web/configure-environment.md index 81c6f35f01..77ce63fcd9 100644 --- a/sites/platform/src/administration/web/configure-environment.md +++ b/sites/platform/src/administration/web/configure-environment.md @@ -39,10 +39,10 @@ There are also additional options: * **URLs** to access the deployed environment from the web. * **SSH** to access your project using SSH. * **Code** - * **CLI** for the command to get your project set up locally with the [Platform.sh CLI](../cli/_index.md). + * **CLI** for the command to get your project set up locally with the [{{< vendor/name >}}CLI](../cli/_index.md). * **Git** for the command to clone the codebase via Git. - If you're using Platform.sh as your primary remote repository, the command clones from the project. + If you're using {{< vendor/name >}} as your primary remote repository, the command clones from the project. If you have set up an [external integration](../../integrations/source/_index.md), the command clones directly from the integrated remote repository. @@ -107,7 +107,7 @@ Under **HTTP access control**, you can [control access to your environment using Under **Variables**, you can define [environment variables](../../development/variables/_index.md): -![Configure Platform.sh environment variables](/images/management-console/settings-variables-environment.png "0.6") +![Configure {{< vendor/name >}} environment variables](/images/management-console/settings-variables-environment.png "0.6") ## Service information diff --git a/sites/platform/src/administration/web/configure-project.md b/sites/platform/src/administration/web/configure-project.md index 90fa5f8dc7..6f0172ef4d 100644 --- a/sites/platform/src/administration/web/configure-project.md +++ b/sites/platform/src/administration/web/configure-project.md @@ -40,7 +40,7 @@ See how to [set up your domain](../../domains/steps/_index.md). ## Deploy Key The **Deploy Key** section shows you the public SSH key you can add to your private repositories. -Adding it lets Platform.sh access the repositories during the build process. +Adding it lets {{< vendor/name >}} access the repositories during the build process. This is useful if you want to reuse some code components across multiple projects and manage those components as dependencies of your project. ![Project deploy key](/images/management-console/settings-deploy-key.png "0.7") diff --git a/sites/platform/src/administration/web/mfa.md b/sites/platform/src/administration/web/mfa.md index 2ac03ca188..b0e97097a9 100644 --- a/sites/platform/src/administration/web/mfa.md +++ b/sites/platform/src/administration/web/mfa.md @@ -8,7 +8,7 @@ keywords: - two factor - mfa - multifactor authentication -description: Enable multi-factor authentication on your Platform.sh account for enhanced security. +description: Enable multi-factor authentication on your {{< vendor/name >}} account for enhanced security. --- For improved security, you can enable multi-factor authentication (MFA) for the Console and CLI. diff --git a/sites/platform/src/bestpractices/_index.md b/sites/platform/src/bestpractices/_index.md index ac86377ec5..c0951b774f 100644 --- a/sites/platform/src/bestpractices/_index.md +++ b/sites/platform/src/bestpractices/_index.md @@ -1,5 +1,5 @@ --- title: "Best practices" weight: -100 -description: Here are some tips for getting the most out of Platform.sh's many features. +description: Here are some tips for getting the most out of {{< vendor/name >}}'s many features. --- diff --git a/sites/platform/src/bestpractices/clean-repository.md b/sites/platform/src/bestpractices/clean-repository.md index e516abe1b9..d382efc547 100644 --- a/sites/platform/src/bestpractices/clean-repository.md +++ b/sites/platform/src/bestpractices/clean-repository.md @@ -15,12 +15,12 @@ keywords: - remove branches --- -When a Git repository contains a high number of references and files, Git's performance can decrease. +When a Git repository contains a high number of references and files, the performance of Git can decrease. This is why most Git providers have repository size limits in place (for more information, see the [GitHub](https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github), [GitLab](https://docs.gitlab.com/ee/user/gitlab_com/index.html#account-and-limit-settings) and [Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/reduce-repository-size/) documentation). -The Platform.sh API and [Console](../administration/web/_index.md) are closely tied to Git. -When Git's performance decreases, Platform.sh API servers also become slower. +The {{< vendor/name >}} API and [Console](../administration/web/_index.md) are closely tied to Git. +When the performance of Git decreases, {{< vendor/name >}} API servers also become slower. As a user, you can then experience significant latencies. If your repository becomes too large, your Console may even become unresponsive, leaving you unable to access your project. @@ -33,7 +33,7 @@ see how you can [troubleshoot a sizeable Git repository](#troubleshoot-a-sizeabl ## Enable the automated pruning of old branches in your project To keep your repository size to a minimum, -make sure that branches that don't exist anymore in your repository have also been deleted from Platform.sh. +make sure that branches that don't exist anymore in your repository have also been deleted from {{< vendor/name >}}. To automate this process, when setting up a [source integration](../integrations/_index.md), enable the `prune-branches` option. @@ -82,7 +82,7 @@ title=In the Console ## Upload your files through mounts Keeping too many files, especially large binary files, in your Git repository can cause performance and stability issues. -Therefore, Platform.sh recommends that you only commit your source code in Git. +Therefore, {{< vendor/name >}} recommends that you only commit your source code in Git. To upload any other files to your app, [create mounts](https://docs.platform.sh/create-apps/app-reference.html#mounts) and [transfer your files directly to them](https://docs.platform.sh/development/file-transfer.html#transfer-a-file-to-a-mount). @@ -95,7 +95,7 @@ To do so, follow these instructions: 1. Remove old, unwanted files from your repository (especially large files). You can do it manually, or use a tool such as [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/). -2. Remove stale branches from your repository and Platform.sh project. +2. Remove stale branches from your repository and {{< vendor/name >}} project. 3. Rebase and/or squash commits to clean up your history. 4. Make sure you [enable the automated pruning of old branches in your project](#enable-the-automated-pruning-of-old-branches-in-your-project) and [upload your files through mounts](#upload-your-files-through-mounts) to avoid facing the same situation in the future. \ No newline at end of file diff --git a/sites/platform/src/bestpractices/http-caching.md b/sites/platform/src/bestpractices/http-caching.md index 201776a533..e39a1020ed 100644 --- a/sites/platform/src/bestpractices/http-caching.md +++ b/sites/platform/src/bestpractices/http-caching.md @@ -2,16 +2,16 @@ title: "HTTP caching" weight: 1 toc: false -description: See your options for HTTP caching with Platform.sh. +description: See your options for HTTP caching with {{< vendor/name >}}. --- -You can configure HTTP caching for your site on Platform.sh in several ways. +You can configure HTTP caching for your site on {{< vendor/name >}} in several ways. Which one you should use depends on your specific use case. You should use only one of these at a time and disable any others. Mixing them together most likely results in stale cache that can't be cleared. -## The Platform.sh router cache +## The {{< vendor/name >}} router cache Every project includes a router instance that includes [optional HTTP caching](../define-routes/cache.md). It's reasonably configurable and obeys HTTP cache directives, but doesn't support push-based clearing. @@ -21,7 +21,7 @@ It's enough for most uses. ## A Content Delivery Network (CDN) -Platform.sh is compatible with most commercial CDNs. +{{< vendor/name >}} is compatible with most commercial CDNs. If you have a Dedicated instance, it comes with the [Fastly CDN](../domains/cdn/fastly.md). CDNs generally offer the best performance as they're the only option that includes multiple geographic locations. @@ -32,11 +32,11 @@ The methods for other CDNs are similar. ## Varnish -Platform.sh offers a [Varnish service](../add-services/varnish.md) that you can insert between the router and your app. +{{< vendor/name >}} offers a [Varnish service](../add-services/varnish.md) that you can insert between the router and your app. It has roughly the same performance as the router cache. Varnish is more configurable, but it requires you to be comfortable with Varnish Configuration Language (VCL). -Platform.sh doesn't help with VCL configuration and a misconfiguration may be difficult to debug. +{{< vendor/name >}} doesn't help with VCL configuration and a misconfiguration may be difficult to debug. Varnish supports [clearing cache with a push](../add-services/varnish.md#clear-cache-with-a-push), but access control is complicated by the inability to have [circular relationships](../add-services/varnish.md#circular-relationships). diff --git a/sites/platform/src/bestpractices/oneormany.md b/sites/platform/src/bestpractices/oneormany.md index ac70db64bc..bc73060929 100644 --- a/sites/platform/src/bestpractices/oneormany.md +++ b/sites/platform/src/bestpractices/oneormany.md @@ -5,7 +5,7 @@ weight: 2 description: Choose the best app topology depending on your needs. --- -With Platform.sh, you can run multiple application containers in a single environment. +With {{< vendor/name >}}, you can run multiple application containers in a single environment. This gives you access to a large variety of setups and allows you to seamlessly upgrade your app from a monolith with a single application server to a more elaborate and effective topology. @@ -14,7 +14,7 @@ You can set up multiple apps to achieve the following: - Run workers alongside your main app - Or even go for a full microservices architecture -Platform.sh makes implementing such setups and switching from one to the other pain-free. +{{< vendor/name >}} makes implementing such setups and switching from one to the other pain-free. The same flexibility applies to any supported services, from relational databases to search engines and message queues. Depending on your specific use case, you can run a single database, @@ -22,7 +22,7 @@ multiple databases inside a single instance, or multiple databases in multiple v It's up to you! Whether you embrace a mono-repo approach with a single Git repository describing your entire setup, -or divide your project into multiple repositories, Platform.sh allows you to build the best architecture for your needs. +or divide your project into multiple repositories, {{< vendor/name >}} allows you to build the best architecture for your needs. But while the possibilities are endless, making the right choice between creating one big project with multiple apps or keeping each app in its own project can be a tough formula to crack. @@ -32,12 +32,12 @@ So read on for guidance! If you have multiple apps sharing the same code but each of them has its own data, keep your apps in separate projects. -Platform.sh provides the automation to deploy multiple projects from the same code base, +{{< vendor/name >}} provides the automation to deploy multiple projects from the same code base, which makes their maintenance effortless. {{< note >}} -By design, Platform.sh doesn't allow your app to access services in another project through HTTP. +By design, {{< vendor/name >}} doesn't allow your app to access services in another project through HTTP. {{< /note >}} @@ -59,7 +59,7 @@ Clustered applications can range from a straightforward headless architecture, w to micro-services with dozens of apps in multiple runtimes and frameworks forming a consistent whole. Meaning, removing one of the app services would break the others. -Platform.sh allows you to configure access from one service to another +{{< vendor/name >}} allows you to configure access from one service to another without having to worry about service discovery or complex _ingress controllers_. [Configuring incoming routes](../define-routes/_index.md) is straightforward. You can have services that are only exposed to another service as well as services that are exposed to the internet. @@ -82,7 +82,7 @@ which is significantly more efficient than defining multiple services. [Redis](../add-services/redis.md), [Memcached](../add-services/memcached.md), [Elasticsearch](../add-services/elasticsearch.md), and [RabbitMQ](../add-services/rabbitmq.md) natively support multiple bins (also called _queues_ or _indexes_) defined by the client application as part of the request. -Therefore, they don't need additional configuration on Platform.sh. +Therefore, they don't need additional configuration on {{< vendor/name >}}. Clustered applications are appropriate in the following cases: @@ -93,11 +93,11 @@ Clustered applications are appropriate in the following cases: ## A note on "multi-site" applications Some Content Management Systems or other applications support running multiple logical "sites" off of a single code base. -This approach isn't recommended on Platform.sh. +This approach isn't recommended on {{< vendor/name >}}. -This multi-site logic is often dependent on the domain name of the incoming request, which on Platform.sh varies by branch. +This multi-site logic is often dependent on the domain name of the incoming request, which on {{< vendor/name >}} varies by branch. Running multiple databases, as is often recommended with this approach, -is supported on Platform.sh but makes the setup process for each site more difficult. +is supported on {{< vendor/name >}} but makes the setup process for each site more difficult. Leveraging the multi-site capabilities of an app are appropriate only in the following cases: diff --git a/sites/platform/src/create-apps/_index.md b/sites/platform/src/create-apps/_index.md index d42dbcb753..dc452b9bd4 100644 --- a/sites/platform/src/create-apps/_index.md +++ b/sites/platform/src/create-apps/_index.md @@ -2,7 +2,7 @@ title: Configure apps weight: -210 description: | - Control your apps and how they're built and deployed on Platform.sh with YAML configuration. + Control your apps and how they're built and deployed on {{< vendor/name >}} with YAML configuration. layout: single keywords: - ".platform.app.yaml" @@ -62,7 +62,7 @@ See the various ways to set up a [multi-app project](./multi-app/_index.md). ## Connect to services -If you want to use one of the [databases or other services Platform.sh provides](../add-services/_index.md), +If you want to use one of the [databases or other services {{< vendor/name >}} provides](../add-services/_index.md), set it up by following these steps: 1. Configure the service based on the documentation for that service. @@ -95,11 +95,11 @@ doing so when the response includes any user-specific information, including a s opens up an attack vector over SSL/TLS connections. For that reason, you generally shouldn't compress generated responses. -Requests for static files that are served directly by Platform.sh are compressed automatically +Requests for static files that are served directly by {{< vendor/name >}} are compressed automatically using either gzip or Brotli compression if: * The request headers for the file support gzip or Brotli compression. -* The file is served directly from disk by Platform.sh and not passed through your application. +* The file is served directly from disk by {{< vendor/name >}} and not passed through your application. * The file would be served with a cache expiration time in the future. * The file type is one of: HTML, JavaScript, JSON, PDF, PostScript, SVG, CSS, CSV, plain text, or XML. diff --git a/sites/platform/src/create-apps/app-reference.md b/sites/platform/src/create-apps/app-reference.md index cb2fb8ca5b..187034fa74 100644 --- a/sites/platform/src/create-apps/app-reference.md +++ b/sites/platform/src/create-apps/app-reference.md @@ -1,7 +1,7 @@ --- title: "App reference" weight: 4 -description: See all of the options for controlling your apps and how they're built and deployed on Platform.sh. +description: See all of the options for controlling your apps and how they're built and deployed on {{< vendor/name >}}. --- {{% description %}} @@ -220,7 +220,7 @@ This command runs every time your app is restarted, regardless of whether or not Never "background" a start process using `&`. That's interpreted as the command terminating and the supervisor process starts a second copy, creating an infinite loop until the container crashes. -Just run it as normal and allow the Platform.sh supervisor to manage it. +Just run it as normal and allow the {{< vendor/name >}} supervisor to manage it. {{< /note >}} @@ -259,8 +259,8 @@ Where to listen depends on your setting for `web.upstream.socket_family` (defaul | `socket_family` | Where to listen | | --------------- | --------------- | -| `tcp` | The port specified by the [`PORT` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables) | -| `unix` | The Unix socket file specified by the [`SOCKET` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables) | +| `tcp` | The port specified by the [`PORT` environment variable](../development/variables/use-variables.md#use-provided-variables) | +| `unix` | The Unix socket file specified by the [`SOCKET` environment variable](../development/variables/use-variables.md#use-provided-variables) | If your application isn't listening at the same place that the runtime is sending requests, you see `502 Bad Gateway` errors when you try to connect to your website. @@ -384,7 +384,7 @@ access: ## Variables -Platform.sh provides a number of ways to set [variables](../development/variables/_index.md). +{{< vendor/name >}} provides a number of ways to set [variables](../development/variables/_index.md). Variables set in your app configuration have the lowest precedence, meaning they're overridden by any conflicting values provided elsewhere. @@ -392,7 +392,7 @@ All variables set in your app configuration must have a prefix. Some [prefixes have specific meanings](../development/variables/_index.md#variable-prefixes). Variables with the prefix `env` are available as a separate environment variable. -All other variables are available in the [`$PLATFORM_VARIABLES` environment variable](../development/variables/use-variables.md#use-platformsh-provided-variables). +All other variables are available in the [`$PLATFORM_VARIABLES` environment variable](../development/variables/use-variables.md#use-provided-variables). The following example sets two variables: @@ -611,7 +611,7 @@ if other hooks fail, the app is still deployed. #### Automated testing It’s preferable that you set up and run automated tests in a dedicated CI/CD tool. -Relying on Platform.sh hooks for such tasks can prove difficult. +Relying on {{< vendor/name >}} hooks for such tasks can prove difficult. During the `build` hook, you can halt the deployment on a test failure but the following limitations apply: diff --git a/sites/platform/src/create-apps/hooks/_index.md b/sites/platform/src/create-apps/hooks/_index.md index 7ededd8432..885092f605 100644 --- a/sites/platform/src/create-apps/hooks/_index.md +++ b/sites/platform/src/create-apps/hooks/_index.md @@ -98,7 +98,7 @@ The template uses [Drush](https://www.drush.org/latest/) to handle routine tasks For its configuration, Drush needs the URL of the site. That means the configuration can't be done in the `build` hook. During the `build` hook, the site isn't yet deployed and so there is no URL to use in the configuration. -(The [`PLATFORM_ROUTES` variable](../../development/variables/use-variables.md#use-platformsh-provided-variables) isn't available.) +(The [`PLATFORM_ROUTES` variable](../../development/variables/use-variables.md#use-provided-variables) isn't available.) Add the configuration during the `deploy` hook. This way you can access the URL before the site accepts requests (unlike in the `post_deploy` hook). diff --git a/sites/platform/src/create-apps/hooks/hooks-comparison.md b/sites/platform/src/create-apps/hooks/hooks-comparison.md index 60a2a2542e..c4770e995d 100644 --- a/sites/platform/src/create-apps/hooks/hooks-comparison.md +++ b/sites/platform/src/create-apps/hooks/hooks-comparison.md @@ -20,7 +20,7 @@ The `build` hook is run after any [build flavor](../app-reference.md#build). During this hook, no services (such as a database) or any persistent file mounts are available as the application hasn't yet been deployed. -The `build` hook can only use [environment variables](../../development/variables/use-variables.md#use-platformsh-provided-variables) +The `build` hook can only use [environment variables](../../development/variables/use-variables.md#use-provided-variables) that are available at build time. During the `build` hook, there are three writeable directories: diff --git a/sites/platform/src/create-apps/hooks/vary-hooks-by-environment.md b/sites/platform/src/create-apps/hooks/vary-hooks-by-environment.md index 33a74621d4..a822065e55 100644 --- a/sites/platform/src/create-apps/hooks/vary-hooks-by-environment.md +++ b/sites/platform/src/create-apps/hooks/vary-hooks-by-environment.md @@ -7,7 +7,7 @@ You might have certain commands you want to run only in certain environments. For example enabling detailed logging in development environments or purging your CDN cache for production environments. -The `deploy` and `post_deploy` hooks can access all [runtime environment variables](../../development/variables/use-variables.md#use-platformsh-provided-variables). +The `deploy` and `post_deploy` hooks can access all [runtime environment variables](../../development/variables/use-variables.md#use-provided-variables). Use this to vary those hooks based on the environment. Check the `PLATFORM_ENVIRONMENT_TYPE` variable to see if it's in a production environment: diff --git a/sites/platform/src/create-apps/multi-app/relationships.md b/sites/platform/src/create-apps/multi-app/relationships.md index b483525238..e1c3265de4 100644 --- a/sites/platform/src/create-apps/multi-app/relationships.md +++ b/sites/platform/src/create-apps/multi-app/relationships.md @@ -33,7 +33,7 @@ app1: ``` Once they're both built, `app1` can access `app2` at the following URL: `http://api.internal`. -The specific URL is always available through the [`PLATFORM_RELATIONSHIPS` variable](/development/variables/use-variables.md#use-platformsh-provided-variables): +The specific URL is always available through the [`PLATFORM_RELATIONSHIPS` variable](/development/variables/use-variables.md#use-provided-variables): ```bash $ echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq '.api[0].host' diff --git a/sites/platform/src/create-apps/runtime-operations.md b/sites/platform/src/create-apps/runtime-operations.md index ce14ff3ac5..303117a91c 100644 --- a/sites/platform/src/create-apps/runtime-operations.md +++ b/sites/platform/src/create-apps/runtime-operations.md @@ -1,13 +1,13 @@ --- title: Runtime operations -description: Set up runtime operations to run one-off commands on your project through the Platform.sh API. +description: Set up runtime operations to run one-off commands on your project through the {{< vendor/name >}} API. weight: 6 --- Runtime operations allow you to trigger one-off commands or scripts on your project. Similar to [crons](../create-apps/app-reference.md#crons), they run in the app container but not on a specific schedule. You can [define runtime operations](#define-a-runtime-operation) in your [app configuration](../create-apps/app-reference.md) -and [trigger them](#run-a-runtime-operation) at any time through the Platform.sh API using a cURL command. +and [trigger them](#run-a-runtime-operation) at any time through the {{< vendor/name >}} API using a cURL command. For example, if you have a static website, you may want to set up a runtime operation to occasionally fetch content from a backend system @@ -55,7 +55,7 @@ For more possibilities, see other [runtime operation examples](#runtime-operatio ## Run a runtime operation Once you've [defined a runtime operation](#define-a-runtime-operation), -you can trigger it through the Platform.sh API. +you can trigger it through the {{< vendor/name >}} API. To do so, run a cURL command similar to the following: ```bash @@ -76,7 +76,7 @@ platform project:curl /environments/{{< variable "ENVIRONMENT_ID" >}}/deployment ### Build your app when using a static site generator -During every Platform.sh deployment, a standard [`build` step](../overview/build-deploy.md#the-build) is run. +During every {{< vendor/name >}} deployment, a standard [`build` step](../overview/build-deploy.md#the-build) is run. When you use a static site generator like [Gatsby](../guides/gatsby/_index.md) or [Next.js](../guides/nextjs/_index.md) with [a headless backend](../guides/gatsby/headless/_index.md), you need to run a second `build` step to get your app ready for production. @@ -84,7 +84,7 @@ you need to run a second `build` step to get your app ready for production. This is because, as its framework is being built, your frontend needs to pull content-related data from your backend’s API (to generate all the static HTML pages your site is to serve). -To accomplish this on Platform.sh, where each app goes through a build-deploy pipeline in parallel, +To accomplish this on {{< vendor/name >}}, where each app goes through a build-deploy pipeline in parallel, your frontend’s build must be delayed _until after_ your backend has fully deployed. It's often delayed up until the [`post_deploy` hook](../create-apps/hooks/hooks-comparison.md#post-deploy-hook) stage, when the filesystem is read-only. @@ -92,7 +92,7 @@ when the filesystem is read-only. You can use a runtime operation to trigger the second `build` step after the initial deployment of your app or after a redeployment. You can also trigger it when you need to fetch content from your backend -but want to avoid going through the whole Platform.sh [build and deploy processes](../overview/build-deploy.md) again. +but want to avoid going through the whole {{< vendor/name >}} [build and deploy processes](../overview/build-deploy.md) again. {{< note >}} @@ -100,7 +100,7 @@ The following examples assume that the frontend and backend containers are inclu This isn’t necessary for the commands to run successfully.
What _is_ necessary is that the build destination for your frontend **is writable at runtime** (meaning, you must [define a mount](../create-apps/app-reference.md#mounts) for it). -If you don’t want to include a build within a mount (especially if your data source **isn’t** on Platform.sh), +If you don’t want to include a build within a mount (especially if your data source **isn’t** on {{< vendor/name >}}), you can use [source operations](../create-apps/source-operations.md) to achieve a similar effect, but through generating a new commit. diff --git a/sites/platform/src/create-apps/source-operations.md b/sites/platform/src/create-apps/source-operations.md index af2a46f6d0..48ea3f75b1 100644 --- a/sites/platform/src/create-apps/source-operations.md +++ b/sites/platform/src/create-apps/source-operations.md @@ -8,7 +8,7 @@ banner: To upgrade your plan or request a trial, [contact Sales](https://platform.sh/contact/). --- -On Platform.sh, you can run automated code updates through a feature called **source operations**. +On {{< vendor/name >}}, you can run automated code updates through a feature called **source operations**. Defined in your [app configuration](./_index.md), source operations let you specify commands that can commit changes to your project's repository when called. @@ -16,7 +16,7 @@ For example, you can set up a source operation to [automatically update your app [update a site from an upstream repository](#update-a-site-from-an-upstream-repository-or-template), or [revert to the last commit](#revert-to-the-last-commit) pushed to your Git repository. -To run your source operations, you can use the [Platform.sh CLI](../administration/cli/_index.md) or the [Console](https://console.platform.sh). +To run your source operations, you can use the [{{< vendor/name >}} CLI](../administration/cli/_index.md) or the [Console](https://console.platform.sh). If you want to run your source operations and update your code automatically, you can also define [cron jobs](./app-reference.md#crons). @@ -169,7 +169,7 @@ platform source-operation:run update-file --variable env:FILE="example.txt" If your project is using a [source integration](../integrations/source/_index.md), any new commits resulting from a source operation are first pushed to your external Git repository. -Then the source integration pushes those commits to Platform.sh and redeploys the environment. +Then the source integration pushes those commits to {{< vendor/name >}} and redeploys the environment. When using a source integration, you can't run source operations on environments created from pull or merge requests created on the external repository. @@ -188,8 +188,8 @@ You can use cron to automatically run your source operations. Note that it’s best not to run source operations on your production environment, but rather on a dedicated environment where you can test changes. -Make sure you have the [Platform.sh CLI](../administration/cli/_index.md) installed -and [an API token](../administration/cli/api-tokens.md#2-create-a-platformsh-api-token) +Make sure you have the [{{< vendor/name >}} CLI](../administration/cli/_index.md) installed +and [an API token](../administration/cli/api-tokens.md#2-create-an-api-token) so you can run a cron job in your app container. 1. Set your API token as a top-level environment variable: @@ -236,10 +236,10 @@ Make sure you carefully check your [user access on this project](../administrati hooks: build: | set -e - echo "Installing Platform.sh CLI" + echo "Installing {{< vendor/name >}} CLI" curl -fsSL https://raw.githubusercontent.com/platformsh/cli/main/installer.sh | bash - echo "Testing Platform.sh CLI" + echo "Testing {{< vendor/name >}} CLI" platform ``` diff --git a/sites/platform/src/create-apps/timezone.md b/sites/platform/src/create-apps/timezone.md index 158bee8bf5..b4be61f003 100644 --- a/sites/platform/src/create-apps/timezone.md +++ b/sites/platform/src/create-apps/timezone.md @@ -1,26 +1,26 @@ --- title: "Timezones" -description: Learn more about the different timezones on Platform.sh and when you can customize them. +description: Learn more about the different timezones on {{< vendor/name >}} and when you can customize them. --- -On Platform.sh, there are several timezones you might want to keep in mind. +On {{< vendor/name >}}, there are several timezones you might want to keep in mind. All timezones default to UTC time. You can customize some of them, but in most cases, it's best if you leave them in UTC and store user data with an associated timezone instead. -The different timezones on Platform.sh are the following: +The different timezones on {{< vendor/name >}} are the following: | Timezone | Description |Customizable | |----------------------|----------------------------------------------|--------------| -| Container timezone | The timezone for all Platform.sh containers (UTC). |No | +| Container timezone | The timezone for all {{< vendor/name >}} containers (UTC). |No | | App runtime timezone | [Set an app runtime timezone](#set-an-app-runtime-timezone) if you want your app runtime to use a specific timezone instead of the container timezone.
The app runtime timezone only affects your app itself. | Yes | | Cron timezone | [Set a cron timezone](#set-a-cron-timezone) if you want your crons to run in a specific timezone instead of the app runtime timezone (or instead of the container timezone if no app runtime timezone is set on your project).
The cron timezone only affects your cron jobs. | Yes | -| Log timezone | The timezone for all Platform.sh logs (UTC). | No | +| Log timezone | The timezone for all {{< vendor/name >}} logs (UTC). | No | {{< note >}} -Each Platform.sh project also has a **project timezone** that only affects [automated backups](../environments/backup.md#use-automated-backups). +Each {{< vendor/name >}} project also has a **project timezone** that only affects [automated backups](../environments/backup.md#use-automated-backups). By default, the project timezone is based on the [region](../development/regions.md) where your project is hosted. You can [change it from the Console](../projects/change-project-timezone.md) at any time. diff --git a/sites/platform/src/create-apps/troubleshoot-mounts.md b/sites/platform/src/create-apps/troubleshoot-mounts.md index 3c30efb814..1eca679817 100644 --- a/sites/platform/src/create-apps/troubleshoot-mounts.md +++ b/sites/platform/src/create-apps/troubleshoot-mounts.md @@ -75,7 +75,7 @@ web: ## Mounts starting with a dot ignored -Platform.sh ignores YAML keys that start with a dot. +{{< vendor/name >}} ignores YAML keys that start with a dot. This causes a mount like `.myhiddenfolder` to be ignored. To mount a directory starting with a dot, put a `/` at the start of its definition: diff --git a/sites/platform/src/create-apps/web/custom-headers.md b/sites/platform/src/create-apps/web/custom-headers.md index 7c224dc61f..b541d25d17 100644 --- a/sites/platform/src/create-apps/web/custom-headers.md +++ b/sites/platform/src/create-apps/web/custom-headers.md @@ -102,4 +102,4 @@ in your [routes configuration](../../define-routes/_index.md). Note that once HSTS is enabled, configuration capabilities depend on the [HSTS properties](https://docs.platform.sh/define-routes/https.html#enable-http-strict-transport-security-hsts) set in your routes configuration. -For example, the `max-age` value is set to `31536000` by Platform.sh and can't be customized. \ No newline at end of file +For example, the `max-age` value is set to `31536000` by {{< vendor/name >}} and can't be customized. \ No newline at end of file diff --git a/sites/platform/src/create-apps/web/static.md b/sites/platform/src/create-apps/web/static.md index efef28e825..0394b8ea67 100644 --- a/sites/platform/src/create-apps/web/static.md +++ b/sites/platform/src/create-apps/web/static.md @@ -7,17 +7,17 @@ description: Serve completely static sites Static site generators are a popular way to create fast sites. Because there's no need to wait for responses from servers, the sites may load faster. -As an example, this documentation is built using a tool called Hugo and served by Platform.sh as a static site. +As an example, this documentation is built using a tool called Hugo and served by {{< vendor/name >}} as a static site. You can see the [entire repository on GitHub](https://github.com/platformsh/platformsh-docs), including its [app configuration](https://github.com/platformsh/platformsh-docs/blob/main/docs/.platform.app.yaml). -To learn how to serve your static site using Platform.sh, +To learn how to serve your static site using {{< vendor/name >}}, you can start with the required [minimal app configuration](#minimal-app-configuration) and build on it, or jump straight to an [example of a complete configuration](#complete-example-configuration). ## Minimal app configuration -To successfully serve a static site using Platform.sh, +To successfully serve a static site using {{< vendor/name >}}, you need to set up a minimal app configuration similar to the following: ```yaml {location=".platform.app.yaml"} diff --git a/sites/platform/src/create-apps/workers.md b/sites/platform/src/create-apps/workers.md index 31d4d7d605..3de6bfd7f2 100644 --- a/sites/platform/src/create-apps/workers.md +++ b/sites/platform/src/create-apps/workers.md @@ -12,9 +12,9 @@ Note that to have enough resources to support a worker and a service, you need a ## Access the worker container Like with any other application container, -Platform.sh allows you to connect to the worker instance through SSH to inspect logs and interact with it. +{{< vendor/name >}} allows you to connect to the worker instance through SSH to inspect logs and interact with it. -Use the `--worker` switch in the Platform.sh CLI, like so: +Use the `--worker` switch in the {{< vendor/name >}} CLI, like so: ```bash platform ssh --worker=queue @@ -243,7 +243,7 @@ The `web` instance starts a Gunicorn process to serve a web application. * It has an environment variable named `TYPE` with value `web`. * It has a writable mount at `/app/uploads` with a maximum space of 2048 MB. * It has access to both a MySQL database and a RabbitMQ server, both of which are defined in `services.yaml`. -* Platform.sh automatically allocates resources to it as available on the plan, once all fixed-size containers are allocated. +* {{< vendor/name >}} automatically allocates resources to it as available on the plan, once all fixed-size containers are allocated. The `queue` instance is a worker that isn't web-accessible. diff --git a/sites/platform/src/dedicated-gen-2/architecture/deploying.md b/sites/platform/src/dedicated-gen-2/architecture/deploying.md index dded578f23..36a22f837a 100644 --- a/sites/platform/src/dedicated-gen-2/architecture/deploying.md +++ b/sites/platform/src/dedicated-gen-2/architecture/deploying.md @@ -19,9 +19,9 @@ Deploys of other branches don't trigger rebuilds of the {{% names/dedicated-gen- ## Deployment process -When deploying to the {{% names/dedicated-gen-2 %}} cluster the process is slightly different than when working with Platform.sh on the Grid. +When deploying to the {{% names/dedicated-gen-2 %}} cluster the process is slightly different than when working with {{< vendor/name >}} on the Grid. -* The new application image is built in the exact same fashion as for Platform.sh Professional. +* The new application image is built in the exact same fashion as for {{< vendor/name >}} Professional. * Any active background tasks on the cluster, including cron tasks, are terminated. * The cluster (production or staging) is closed, meaning it doesn't accept new requests. Incoming requests receive an HTTP 500 error. @@ -40,6 +40,6 @@ Authenticated traffic that can't be served by the CDN still sees a brief interru ## Deployment philosophy -Platform.sh values consistency over availability, +{{< vendor/name >}} values consistency over availability, which means that deployments can cause your app to be unavailable for a short amount of time. For more information, see the [overview of the build and deploy phases](../../overview/build-deploy.md). diff --git a/sites/platform/src/dedicated-gen-2/architecture/development.md b/sites/platform/src/dedicated-gen-2/architecture/development.md index 39c1a28116..3bce4543fc 100644 --- a/sites/platform/src/dedicated-gen-2/architecture/development.md +++ b/sites/platform/src/dedicated-gen-2/architecture/development.md @@ -1,13 +1,13 @@ --- -title: "Platform.sh development environments" +title: "{{< vendor/name >}} development environments" weight: 2 sidebarTitle: "Dev environments" -description: "{{% names/dedicated-gen-2 %}} customers have a development environment for their project that consists of a Platform.sh Grid project, typically provisioned by the Platform.sh team to reflect the amount of storage in your contract. This environment provides you with all the DevOps, Continuous Integration, Continuous Deployment, and other workflow tooling of the professional product, but segregates the performance impacts from your production hardware." +description: "{{% names/dedicated-gen-2 %}} customers have a development environment for their project that consists of a {{< vendor/name >}} Grid project, typically provisioned by the {{< vendor/name >}} team to reflect the amount of storage in your contract. This environment provides you with all the DevOps, Continuous Integration, Continuous Deployment, and other workflow tooling of the professional product, but segregates the performance impacts from your production hardware." --- ## Architecture (Development Environments) -![Platform.sh Professional architecture](/images/dedicated/PS-Arch-NoHA.svg "0.6") +![{{< vendor/name >}} Professional architecture](/images/dedicated/PS-Arch-NoHA.svg "0.6") ## Default limits diff --git a/sites/platform/src/dedicated-gen-2/architecture/options.md b/sites/platform/src/dedicated-gen-2/architecture/options.md index 44411f7cf8..ac528d552a 100644 --- a/sites/platform/src/dedicated-gen-2/architecture/options.md +++ b/sites/platform/src/dedicated-gen-2/architecture/options.md @@ -48,7 +48,7 @@ the CDN continues to serve cached pages during the few seconds of deploy, so for the vast majority of users there is no downtime or even slow down. If a request does pass the CDN during a deploy, it isn't counted as downtime covered by our Service Level Agreement. -By default, Platform.sh serves generic Platform.sh-branded error pages for errors generated before a request reaches the application. +By default, {{< vendor/name >}} serves generic {{< vendor/name >}}-branded error pages for errors generated before a request reaches the application. (500 errors, some 400 errors, etc.) Alternatively you may provide a static error page for each desired error code via a ticket for us to configure with the CDN. This file may be any static HTML file but is limited to 64 KB in size. @@ -69,7 +69,7 @@ There is no cost for this functionality. ## IP restrictions -Platform.sh supports [project-level IP restrictions (allow/deny) and HTTP Basic authentication](../../environments/http-access-control.md). These may be configured through the Development Environment and are automatically replicated from the production and staging branches to the production and staging environments, respectively. +{{< vendor/name >}} supports [project-level IP restrictions (allow/deny) and HTTP Basic authentication](../../environments/http-access-control.md). These may be configured through the Development Environment and are automatically replicated from the production and staging branches to the production and staging environments, respectively. Changing access control triggers a new deploy of the current environment. However, the changes aren’t propagated to child environments until they’re manually redeployed. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/_index.md b/sites/platform/src/dedicated-gen-2/overview/_index.md index aa6baf25e6..b304a851f5 100644 --- a/sites/platform/src/dedicated-gen-2/overview/_index.md +++ b/sites/platform/src/dedicated-gen-2/overview/_index.md @@ -3,7 +3,7 @@ title: "{{% names/dedicated-gen-2 %}}" weight: 1 sidebarTitle: "Overview" layout: single -description: "{{% names/dedicated-gen-2 %}} is a robust, redundant layer. It's well-suited for those who like the Platform.sh development experience but need more resources and redundancy for their production environment. It's available only with an Enterprise contract." +description: "{{% names/dedicated-gen-2 %}} is a robust, redundant layer. It's well-suited for those who like the {{< vendor/name >}} development experience but need more resources and redundancy for their production environment. It's available only with an Enterprise contract." --- {{% description %}} @@ -17,11 +17,11 @@ The default branches are slightly different, as noted in the [default limits](.. ## The {{% names/dedicated-gen-2 %}} cluster -The {{% names/dedicated-gen-2 %}} cluster is a three-host redundant configuration provisioned by Platform.sh for each customer. +The {{% names/dedicated-gen-2 %}} cluster is a three-host redundant configuration provisioned by {{< vendor/name >}} for each customer. Every service is replicated across all three hosts in a failover configuration (as opposed to sharding), allowing a site to remain up even if one of the hosts is lost entirely. The build process for your application is identical for both the Development Environment and the {{% names/dedicated-gen-2 %}} cluster. -However, because the hosts are provisioned by Platform.sh, not as a container, -service configuration must be done by Platform.sh's Customer Success team. +However, because the hosts are provisioned by {{< vendor/name >}}, not as a container, +service configuration must be done by {{< vendor/name >}}'s Customer Success team. By and large the same flexibility is available but only via filing a support ticket. diff --git a/sites/platform/src/dedicated-gen-2/overview/backups.md b/sites/platform/src/dedicated-gen-2/overview/backups.md index cf51010cdc..67da62f148 100644 --- a/sites/platform/src/dedicated-gen-2/overview/backups.md +++ b/sites/platform/src/dedicated-gen-2/overview/backups.md @@ -5,7 +5,7 @@ toc: false description: See when backups of {{% names/dedicated-gen-2 %}} environments are taken. --- -Platform.sh takes a byte-for-byte snapshot of {{% names/dedicated-gen-2 %}} production environments every 6 hours. +{{< vendor/name >}} takes a byte-for-byte snapshot of {{% names/dedicated-gen-2 %}} production environments every 6 hours. Backups are retained for different durations depending on when they're taken. For details, see the [retention policy for backups](../../security/data-retention.md#dedicated-gen-2-backups). @@ -15,7 +15,7 @@ An EBS snapshot is immediate, but the time it takes to write to the storage serv * **Recovery Point Objective (RPO)** is 6 hours (maximum time to last backup). * **Recovery Time Objective (RTO)** depends on the size of the storage. Large EBS volumes take more time to restore. -These backups are only used in cases of catastrophic failure and can only be restored by Platform.sh. A support ticket must be opened to request a restoration. +These backups are only used in cases of catastrophic failure and can only be restored by {{< vendor/name >}}. A support ticket must be opened to request a restoration. The restoration process may take a few hours, depending on the infrastructure provider in use. In the ticket, specify if you want backups of files, MySQL, or both. diff --git a/sites/platform/src/dedicated-gen-2/overview/monitoring.md b/sites/platform/src/dedicated-gen-2/overview/monitoring.md index 4bb40bbcf2..a2ee93e06e 100644 --- a/sites/platform/src/dedicated-gen-2/overview/monitoring.md +++ b/sites/platform/src/dedicated-gen-2/overview/monitoring.md @@ -8,6 +8,6 @@ description: | {{% description %}} -For more information, see which [monitoring systems](../../dedicated-gen-3/monitoring.md) Platform.sh uses to [monitor application performance](../../dedicated-gen-3/monitoring.md#application-performance-monitoring) +For more information, see which [monitoring systems](../../dedicated-gen-3/monitoring.md) {{< vendor/name >}} uses to [monitor application performance](../../dedicated-gen-3/monitoring.md#application-performance-monitoring) and detect [availability incidents](../../dedicated-gen-3/monitoring.md#availability-incident-handling-procedure) on both {{% names/dedicated-gen-2 %}} and {{% names/dedicated-gen-3 %}} projects. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-2/overview/security.md b/sites/platform/src/dedicated-gen-2/overview/security.md index e15fb6ff73..34a69a873d 100644 --- a/sites/platform/src/dedicated-gen-2/overview/security.md +++ b/sites/platform/src/dedicated-gen-2/overview/security.md @@ -5,7 +5,7 @@ sidebarTitle: "Security and privacy" --- Security and data privacy are handled in a similar way for all Dedicated projects. -See [how Platform.sh manages incidents](../../dedicated-gen-3/security.md#security-incident-handling-procedure), +See [how {{< vendor/name >}} manages incidents](../../dedicated-gen-3/security.md#security-incident-handling-procedure), and [how data is encrypted](../../dedicated-gen-3/security.md#encryption) on both {{% names/dedicated-gen-2 %}} and {{% names/dedicated-gen-3 %}} projects. diff --git a/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md b/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md index f46f998ed1..3db2ce5a26 100644 --- a/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md +++ b/sites/platform/src/dedicated-gen-2/overview/updates-upgrades.md @@ -3,7 +3,7 @@ title: "Updates and upgrades" weight: 3 --- -Platform.sh updates the core software of the {{% names/dedicated-gen-2 %}} cluster (operating system, web server, PHP, MySQL, etc.) periodically, and after any significant security vulnerability is disclosed. +{{< vendor/name >}} updates the core software of the {{% names/dedicated-gen-2 %}} cluster (operating system, web server, PHP, MySQL, etc.) periodically, and after any significant security vulnerability is disclosed. These updates are deployed automatically with no additional work required by you. We attempt to maintain parity with your development environment, but we don't guarantee absolute parity of point versions of your {{% names/dedicated-gen-2 %}} environments with their corresponding development environments. I.e, your development environment may have a PHP container running 5.6.30, but your production environment may lag behind at 5.6.22. diff --git a/sites/platform/src/dedicated-gen-3/_index.md b/sites/platform/src/dedicated-gen-3/_index.md index 726e1cfd78..a47a068f50 100644 --- a/sites/platform/src/dedicated-gen-3/_index.md +++ b/sites/platform/src/dedicated-gen-3/_index.md @@ -16,7 +16,7 @@ stricter isolation requirements, as well as additional compliance frameworks. To set up a {{% names/dedicated-gen-3 %}} project on [any supported cloud provider](../development/regions.md#regions), -[contact Platform.sh](https://platform.sh/contact). +[contact {{< vendor/name >}}](https://platform.sh/contact). Note that existing Grid and {{% names/dedicated-gen-2 %}} projects can't be migrated to {{% names/dedicated-gen-3 %}} at this time. ## Highlights @@ -44,7 +44,7 @@ of [the following benefits](https://platform.sh/blog/the-ultimate-generation-of- - **Better compliance.**
Your apps and configurations are fully independent from the machines they run on. - This allows Platform.sh to perform non-disruptive system upgrades to ensure you're always secure and compliant. + This allows {{< vendor/name >}} to perform non-disruptive system upgrades to ensure you're always secure and compliant. ## Storage @@ -84,7 +84,7 @@ Just like {{% names/dedicated-gen-3 %}}, [{{% names/dedicated-gen-2 %}}](../../dedicated-gen-2/overview/_index.md) ensures increased uptime and availability for your apps and services. But as a {{% names/dedicated-gen-2 %}} user, -you have to go through the Platform.sh Customer Success team to make configuration or application topology changes. +you have to go through the {{< vendor/name >}} Customer Success team to make configuration or application topology changes. {{% names/dedicated-gen-3 %}} gives you both the high availability of {{% names/dedicated-gen-2 %}} and the self-service flexibility and features of Grid projects. diff --git a/sites/platform/src/dedicated-gen-3/monitoring.md b/sites/platform/src/dedicated-gen-3/monitoring.md index 8ac34724cd..aaec2eb987 100644 --- a/sites/platform/src/dedicated-gen-3/monitoring.md +++ b/sites/platform/src/dedicated-gen-3/monitoring.md @@ -2,19 +2,19 @@ title: "Resource and incident monitoring" weight: 2 sidebarTitle: "Incident monitoring" -description: Learn how Platform.sh monitors your clusters and handles availability incidents. +description: Learn how {{< vendor/name >}} monitors your clusters and handles availability incidents. --- -Platform.sh monitors Dedicated clusters 24/7 to maintain uptime and performance. +{{< vendor/name >}} monitors Dedicated clusters 24/7 to maintain uptime and performance. A wide range of server metrics, including disk space, memory, and disk usage are continuously measured using in-house tools. These metrics provide a complete picture of the health of your application infrastructure. -As soon as a metric goes out of bounds, Platform.sh Support and Operations teams are alerted. +As soon as a metric goes out of bounds, {{< vendor/name >}} Support and Operations teams are alerted. When an outage is detected, a Point in Time report is generated -so Platform.sh Support can triage the cause of the outage. +so {{< vendor/name >}} Support can triage the cause of the outage. -On top of internal Platform.sh tools, +On top of internal {{< vendor/name >}} tools, a third-party availability monitoring system is configured for every Dedicated project. This further guarantees that issues are spotted and addressed as quickly as possible. @@ -23,14 +23,14 @@ to support automated monitoring and guarantee high SLA. ## Application performance monitoring -As the official, in-house Platform.sh observability tool, [Blackfire](../../increase-observability/integrate-observability/blackfire.md) provides unparalleled monitoring, profiling, and performance testing technologies. -Using Blackfire on Platform.sh enhances your experience +As the official, in-house {{< vendor/name >}} observability tool, [Blackfire](../../increase-observability/integrate-observability/blackfire.md) provides unparalleled monitoring, profiling, and performance testing technologies. +Using Blackfire on {{< vendor/name >}} enhances your experience and allows you to enjoy greater support as well as unique upcoming features. You can subscribe to Blackfire in two different ways: - As an Enterprise or Elite customer, - you can sign up for the Platform.sh [Observability Suite](https://platform.sh/features/observability-suite/), + you can sign up for the {{< vendor/name >}} [Observability Suite](https://platform.sh/features/observability-suite/), which offers application performance monitoring by Blackfire packaged with infrastructure monitoring. The Observability suite includes all Blackfire features, support, and usage that scales with your needs. To subscribe to the Observability Suite, [contact Sales](https://platform.sh/contact/). @@ -40,7 +40,7 @@ You can subscribe to Blackfire in two different ways: Note that if you subscribe to Blackfire separately, features and usage may cost more than the equivalent bundled in the Observability Suite. -Platform.sh also supports third-party observability services +{{< vendor/name >}} also supports third-party observability services such as [New Relic](../increase-observability/integrate-observability/new-relic/_index.md) and [Tideways](../increase-observability/integrate-observability/tideways.md). You need to get your own license for them. @@ -53,7 +53,7 @@ Automated monitoring is used to keep an eye on your production environment at al If automated monitoring triggers an alert, or if a customer files an urgent priority ticket, an on-call engineer is immediately paged so they can respond and begin to triage the issue. -Cloud infrastructure issues are handled by the Platform.sh Customer Success team. +Cloud infrastructure issues are handled by the {{< vendor/name >}} Customer Success team. Note that application problems are returned to the user and may be downgraded. -![Diagram of the Platform.sh availability incident handling procedure](/images/dedicated/incident-monitoring.svg "0.4") \ No newline at end of file +![Diagram of the {{< vendor/name >}} availability incident handling procedure](/images/dedicated/incident-monitoring.svg "0.4") \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/multiple-az.md b/sites/platform/src/dedicated-gen-3/multiple-az.md index c875f3f9b2..93789a0e93 100644 --- a/sites/platform/src/dedicated-gen-3/multiple-az.md +++ b/sites/platform/src/dedicated-gen-3/multiple-az.md @@ -20,7 +20,7 @@ If you prefer the peace of mind of hosting across multiple AZs, you can request a different configuration. But note that multiple-AZ configurations don't improve the contractual 99.99% uptime SLA (nor does the standard, single-AZ configuration decrease the 99.99% uptime SLA). -Platform.sh is responsible for meeting the 99.99% uptime SLA no matter what, +{{< vendor/name >}} is responsible for meeting the 99.99% uptime SLA no matter what, so multiple-AZ deployments should only be considered in cases where they're truly appropriate. Multi-AZ deployments are available only on select AWS regions. \ No newline at end of file diff --git a/sites/platform/src/dedicated-gen-3/security.md b/sites/platform/src/dedicated-gen-3/security.md index 33aff031f1..6f58c6c788 100644 --- a/sites/platform/src/dedicated-gen-3/security.md +++ b/sites/platform/src/dedicated-gen-3/security.md @@ -4,17 +4,17 @@ weight: 3 description: Learn how security and data privacy are handled on {{% names/dedicated-gen-3 %}} projects. --- -Platform.sh is committed to protecting your data and keeping your site safe, secure, and available at all times. +{{< vendor/name >}} is committed to protecting your data and keeping your site safe, secure, and available at all times. All Dedicated projects are isolated and their data is fully encrypted. -Should a security breach occur, Platform.sh follows a strict [security incident handling procedure](#security-incident-handling-procedure) +Should a security breach occur, {{< vendor/name >}} follows a strict [security incident handling procedure](#security-incident-handling-procedure) to deal with the issue as promptly and efficiently as possible. {{% project-isolation plan="true" %}} ## Security incident handling procedure -Should Platform.sh become aware of a security incident — such as an active or past hacking attempt, virus or worm, or data breach — +Should {{< vendor/name >}} become aware of a security incident — such as an active or past hacking attempt, virus or worm, or data breach — senior personnel, including the CTO, are promptly notified. The security incident procedure includes the following steps: @@ -24,26 +24,26 @@ The security incident procedure includes the following steps: 3. Restoring normal operations. Once normal service is restored, a root cause analysis is performed to determine exactly what happened. -Upon request, Platform.sh can provide you with a Reason for Outage report that summarizes the incident, cause, and steps taken. +Upon request, {{< vendor/name >}} can provide you with a Reason for Outage report that summarizes the incident, cause, and steps taken. -Platform.sh cooperates with relevant law enforcement, +{{< vendor/name >}} cooperates with relevant law enforcement, and informs law enforcement in the event of an attempted malicious intrusion. -Depending on the type of incident, the root cause analysis may be conducted by law enforcement rather than Platform.sh personnel. +Depending on the type of incident, the root cause analysis may be conducted by law enforcement rather than {{< vendor/name >}} personnel. -Platform.sh endeavors to notify affected customers within 24 hours in case of a personal data breach +{{< vendor/name >}} endeavors to notify affected customers within 24 hours in case of a personal data breach and 72 hours in case of a project data breach. Under the European General Data Protection Regulation (GPDR), -Platform.sh is required to notify its supervising authority within 72 hours of a discovered breach +{{< vendor/name >}} is required to notify its supervising authority within 72 hours of a discovered breach that may result in risk to the rights and freedoms of individuals. -The supervising authority for Platform.sh is the French [Commission Nationale de l'Informatique et des Libertés](https://www.cnil.fr/). +The supervising authority for {{< vendor/name >}} is the French [Commission Nationale de l'Informatique et des Libertés](https://www.cnil.fr/). ### Audit trail -As part of the security incident process, Platform.sh records a log of all steps taken to identify, +As part of the security incident process, {{< vendor/name >}} records a log of all steps taken to identify, isolate, and respond to the incident. This log may include: @@ -57,7 +57,7 @@ This log may include: ### AWS -AWS EBS Volumes are encrypted on Platform.sh, +AWS EBS Volumes are encrypted on {{< vendor/name >}}, which means {{% names/dedicated-gen-3 %}} and {{% names/dedicated-gen-2 %}} sites are fully encrypted. Keys are managed by the AWS Key Management Service. AWS automatically rotates these keys every three years. diff --git a/sites/platform/src/define-routes/_index.md b/sites/platform/src/define-routes/_index.md index 7e8e212da6..488109da76 100644 --- a/sites/platform/src/define-routes/_index.md +++ b/sites/platform/src/define-routes/_index.md @@ -83,7 +83,7 @@ So you might define routes for 2 apps named `app` and `api` as follows: ``` Both of these routes would be resolved with trailing slashes. -So if you check your [`PLATFORM_ROUTES` variable](../development/variables/use-variables.md#use-platformsh-provided-variables), +So if you check your [`PLATFORM_ROUTES` variable](../development/variables/use-variables.md#use-provided-variables), you see the following resolved routes (assuming `example.com` is your default domain): ```json @@ -235,7 +235,7 @@ Requests to your default domain are served by `app1`. ## Wildcard routes -Platform.sh supports wildcard routes, so you can map multiple subdomains to the same application. +{{< vendor/name >}} supports wildcard routes, so you can map multiple subdomains to the same application. Both `redirect` and `upstream` routes support wildcard routes. Prefix a route with an asterisk (`*`), for example `*.{default}`. If you have configured `example.com` as your default domain, @@ -340,7 +340,7 @@ You can use this `id` to look up the domain of the route in every environment. You might want to add extra information to routes to identify them in your app. Route `attributes` are arbitrary key-value pairs attached to a route. -This metadata has no impact on Platform.sh, but is available in the `PLATFORM_ROUTES` environment variable. +This metadata has no impact on {{< vendor/name >}}, but is available in the `PLATFORM_ROUTES` environment variable. So you can define a route like this: @@ -404,7 +404,7 @@ You can configure each route separately with the following properties: ## CLI access -The [Platform.sh CLI](../administration/cli/_index.md) can show you the routes you have configured for an environment. +The [{{< vendor/name >}} CLI](../administration/cli/_index.md) can show you the routes you have configured for an environment. These are the routes as defined in the `.platform/routes.yaml` file with the [placeholders](#route-placeholders) plus the default redirect from HTTP to HTTPS. They aren't the final generated routes. @@ -474,8 +474,8 @@ which is a requirement for the router caching. ## `.htaccess` files -Platform.sh uses Nginx servers, not Apache ones. +{{< vendor/name >}} uses Nginx servers, not Apache ones. You [can't use `.htaccess` files with Nginx](https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/), -they are therefore ignored on Platform.sh. +they are therefore ignored on {{< vendor/name >}}. You can accomplish the same redirect and rewrite goals with your [routes](../define-routes/_index.md) and [web server locations](../create-apps/web/_index.md). diff --git a/sites/platform/src/define-routes/cache.md b/sites/platform/src/define-routes/cache.md index 561b5651f2..95b427a9d7 100644 --- a/sites/platform/src/define-routes/cache.md +++ b/sites/platform/src/define-routes/cache.md @@ -2,14 +2,14 @@ title: HTTP cache weight: 2 description: | - Platform.sh supports HTTP caching at the server level. Caching is enabled by default, but is only applied to `GET` and `HEAD` requests. + {{< vendor/name >}} supports HTTP caching at the server level. Caching is enabled by default, but is only applied to `GET` and `HEAD` requests. --- {{% description %}} The cache can be controlled using the `cache` key in your `.platform/routes.yaml` file. -If a request is can be cached, Platform.sh builds a cache key from several request properties and stores the response associated with this key. When a request comes with the same cache key, the cached response is reused. +If a request is can be cached, {{< vendor/name >}} builds a cache key from several request properties and stores the response associated with this key. When a request comes with the same cache key, the cached response is reused. When caching is on... @@ -18,7 +18,7 @@ When caching is on... * cookies bypass the cache; * responses with the `Cache-Control` header set to `Private`, `No-Cache`, or `No-Store` aren't cached. -You should _not_ use the Platform.sh HTTP cache if you're using Varnish or an external CDN +You should _not_ use the {{< vendor/name >}} HTTP cache if you're using Varnish or an external CDN such as [Fastly](../domains/cdn/fastly.md) or [Cloudflare](../domains/cdn/cloudflare.md). Mixing cache services together most likely results in caches that are stale and can't be cleared. For more details, see [best practices on HTTP caching](../bestpractices/http-caching.md). @@ -61,7 +61,7 @@ https://{default}/: ### The cache key -If a request can be cached, Platform.sh builds a cache key from several request properties and stores the response associated with this key. When a request comes with the same cache key, the cached response is reused. +If a request can be cached, {{< vendor/name >}} builds a cache key from several request properties and stores the response associated with this key. When a request comes with the same cache key, the cached response is reused. There are two parameters that let you control this key: `headers` and `cookies`. @@ -114,7 +114,7 @@ Turns the cache on or off for a route. Adds specific header fields to the cache key, enabling caching of separate responses for those headers. -For example, if the `headers` key is the following, Platform.sh caches a different response for each value of the `Accept` HTTP request header only: +For example, if the `headers` key is the following, {{< vendor/name >}} caches a different response for each value of the `Accept` HTTP request header only: ```yaml {location=".platform/routes.yaml"} https://{default}/: @@ -210,7 +210,7 @@ All static assets have a Cache-Control header with a max age defaulting to 0 (wh ## Debugging -Platform.sh adds an `X-Platform-Cache` header to each request which show whether your request is a cache `HIT`, `MISS` or `BYPASS`. This can be useful when trying to determine whether it's your application, the HTTP cache, or another proxy or CDN which isn't behaving as expected. +{{< vendor/name >}} adds an `X-Platform-Cache` header to each request which show whether your request is a cache `HIT`, `MISS` or `BYPASS`. This can be useful when trying to determine whether it's your application, the HTTP cache, or another proxy or CDN which isn't behaving as expected. If in doubt, disable the cache using `cache: false`. diff --git a/sites/platform/src/define-routes/https.md b/sites/platform/src/define-routes/https.md index caad26264f..8ae217a725 100644 --- a/sites/platform/src/define-routes/https.md +++ b/sites/platform/src/define-routes/https.md @@ -15,32 +15,32 @@ To enable HTTPS on your site, you need [Transport Layer Security (TLS) certifica ## TLS certificates -Platform.sh automatically provides TLS certificates for all sites and environments. +{{< vendor/name >}} automatically provides TLS certificates for all sites and environments. These certificates are issued at no charge by [Let's Encrypt](https://letsencrypt.org/) and cover most needs. They're valid for 90 days and automatically renewed 28 days before expiration. To use them, you only need to [specify HTTPS routes](../define-routes/https.md#enable-https). Note that [limitations](../define-routes/https.md#lets-encrypt-limitations) apply. -If you encounter issues with the TLS certificates provided by Platform.sh, +If you encounter issues with the TLS certificates provided by {{< vendor/name >}}, check that [TLS encryption is up-and-running](../domains/troubleshoot.md#verify-ssltls-encryption). -If you don't want to use the TLS certificates provided by Platform.sh, +If you don't want to use the TLS certificates provided by {{< vendor/name >}}, configure your own [third-party TLS certificates](../domains/steps/tls.md). ### Let's Encrypt limitations -When you use the Let's Encrypt [TLS certificates](#tls-certificates) provided by Platform.sh, +When you use the Let's Encrypt [TLS certificates](#tls-certificates) provided by {{< vendor/name >}}, the following limitations apply. {{% lets_encrypt_limitations %}} If you need more hostnames, you can obtain additional certificates or a wildcard certificate from a [third-party issuer](../domains/steps/tls.md). -Alternatively, consider splitting your project up into multiple Platform.sh projects. +Alternatively, consider splitting your project up into multiple {{< vendor/name >}} projects. ### Certificate renewals -When you use the [TLS certificates](#tls-certificates) provided by Platform.sh, +When you use the [TLS certificates](#tls-certificates) provided by {{< vendor/name >}}, certificate renewals are automatic. They trigger a redeployment of your environment. During this redeployment, required security and system upgrades are applied to your containers. diff --git a/sites/platform/src/define-routes/proxy.md b/sites/platform/src/define-routes/proxy.md index cff8126ce8..be43e8f19a 100644 --- a/sites/platform/src/define-routes/proxy.md +++ b/sites/platform/src/define-routes/proxy.md @@ -1,6 +1,6 @@ --- title: Proxy routes -description: Pass requests to a location outside your Platform.sh project using proxy routes. +description: Pass requests to a location outside your {{< vendor/name >}} project using proxy routes. --- {{< note theme="warning" title="Warning">}} @@ -11,10 +11,10 @@ To expose your app to the outside world, see [how to define routes](../define-ro {{< /note >}} ​ -Sometimes you want your app to pass requests on to a different Platform.sh project. +Sometimes you want your app to pass requests on to a different {{< vendor/name >}} project. Basic redirects only work within the same project, so use proxy routes for routes elsewhere.​ -You can define an external proxy on your Platform.sh project by defining a route like the following: +You can define an external proxy on your {{< vendor/name >}} project by defining a route like the following: ```yaml {location=".platform/routes.yaml"} https://{default}/foo: @@ -61,12 +61,12 @@ This route passes requests for `https://{default}/foo/index.html` to `https://ww ## Multiple apps with the same base URL -You can use proxy routes to map a single domain to multiple Platform.sh projects with their own subdomain/domain names. +You can use proxy routes to map a single domain to multiple {{< vendor/name >}} projects with their own subdomain/domain names. You might have a need to access multiple projects, each hosting specific applications for different languages. You want to serve them all at the same base URL with different paths (`https://example.com/en`, `https://example.com/fr`, and so on). -Because domains can't be reused at Platform.sh, you can't just set the same domain for all projects. +Because domains can't be reused at {{< vendor/name >}}, you can't just set the same domain for all projects. Use proxy routes so a single project can access different projects using the same base URL. In the following example, a single project specifies proxy routes to three apps with the same `default` base URL. diff --git a/sites/platform/src/define-routes/redirects.md b/sites/platform/src/define-routes/redirects.md index 9569f4b2cc..5e4de1074f 100644 --- a/sites/platform/src/define-routes/redirects.md +++ b/sites/platform/src/define-routes/redirects.md @@ -6,7 +6,7 @@ description: | {{% description %}} -You can manage redirection rules on your Platform.sh projects in two different ways, which we describe here. If neither of these options satisfy your redirection needs, you can still implement redirects directly from within your application, which if implemented with the appropriate caching headers would be almost as efficient as using the configuration options provided by Platform.sh. +You can manage redirection rules on your {{< vendor/name >}} projects in two different ways, which we describe here. If neither of these options satisfy your redirection needs, you can still implement redirects directly from within your application, which if implemented with the appropriate caching headers would be almost as efficient as using the configuration options provided by {{< vendor/name >}}. ## Whole-route redirects @@ -137,6 +137,6 @@ If neither of the above options satisfy your redirection needs, you can still im ## Query-strings based redirect are unsupported -Platform.sh does not support redirects based on query strings. +{{< vendor/name >}} does not support redirects based on query strings. If you want to redirect based on query strings, this logic has to be implemented by your application. diff --git a/sites/platform/src/development/_index.md b/sites/platform/src/development/_index.md index 2d685b5081..82ee4e629c 100644 --- a/sites/platform/src/development/_index.md +++ b/sites/platform/src/development/_index.md @@ -2,5 +2,5 @@ title: "Development" weight: -80 description: | - This section contains resources related to tools and troubleshooting information related to developing with Platform.sh + This section contains resources related to tools and troubleshooting information related to developing with {{< vendor/name >}} --- diff --git a/sites/platform/src/development/deploy-button.md b/sites/platform/src/development/deploy-button.md index bfb67e845e..c59603b3b1 100644 --- a/sites/platform/src/development/deploy-button.md +++ b/sites/platform/src/development/deploy-button.md @@ -1,14 +1,14 @@ --- -title: Deploy on Platform.sh +title: Deploy on {{< vendor/name >}} --- -Platform.sh offers a number of project templates as part of the Project Creation Wizard to help bootstrap a new project. -However, you can also create arbitrary links to spawn projects on Platform.sh from an arbitrary Git repository or prepared template. +{{< vendor/name >}} offers a number of project templates as part of the Project Creation Wizard to help bootstrap a new project. +However, you can also create arbitrary links to spawn projects on {{< vendor/name >}} from an arbitrary Git repository or prepared template. There are two ways to create such a link, shown below. -In each case, when a user clicks on the link they are redirected to create a new Platform.sh project, +In each case, when a user clicks on the link they are redirected to create a new {{< vendor/name >}} project, with the template selection step skipped in favor of the template specified. -If the user doesn't have a Platform.sh account yet they're prompted to create one. +If the user doesn't have a {{< vendor/name >}} account yet they're prompted to create one. You may include the link on your own project's website, your company's internal Wiki, or anywhere else a link can go to make launching your code base as straightforward as possible. @@ -16,7 +16,7 @@ or anywhere else a link can go to make launching your code base as straightforwa ## Preparation To have a deployable template, you need to first prepare the repository. -The Deploy on Platform.sh button works with any Git repository that's deployable on Platform.sh. +The Deploy on {{< vendor/name >}} button works with any Git repository that's deployable on {{< vendor/name >}}. It needs [app configuration](../create-apps/_index.md) and [`.platform/routes.yaml` file](../define-routes/_index.md). If you are using any [services](../add-services/_index.md), @@ -28,7 +28,7 @@ or any other publicly accessible Git URL. ### (Optional) Make a template definition file -You can create a Deploy on Platform.sh button for any compatible repository; +You can create a Deploy on {{< vendor/name >}} button for any compatible repository; however, you can also provide a YAML template definition file. A template definition file is a YAML file that references a Git repository but can also include additional information, such as limiting the resulting project to a certain minimum project size or only allowing it to be deployed in certain regions. @@ -40,7 +40,7 @@ Note that if it's in the template repository then it's included in every deploye (It doesn't hurt anything as it has no effect at runtime, but users have a copy of the file in their code base and may be confused by it.) -A list of all [Platform.sh-supported templates](https://github.com/platformsh/template-builder/tree/master/templates) is available on GitHub. +A list of all [{{< vendor/name >}}-supported templates](https://github.com/platformsh/template-builder/tree/master/templates) is available on GitHub. [3rd party templates](https://github.com/platformsh/templates-external/) are also available. You can also create your own template file and host it anywhere you wish. @@ -49,11 +49,11 @@ in the 3rd party template repository. ## Making a button (with a widget) -The easiest way to make a Deploy on Platform.sh button is to use the [button builder widget](https://platform.sh/deploy/). +The easiest way to make a Deploy on {{< vendor/name >}} button is to use the [button builder widget](https://platform.sh/deploy/). You provide it with either the Git URL of the repository or a URL to a corresponding template definition file. The button builder widget gives you an HTML fragment to copy and paste to wherever you want the button hosted. -It also includes a tracking code to know whose Deploy on Platform.sh button was clicked, but doesn't add any cookies to the site. +It also includes a tracking code to know whose Deploy on {{< vendor/name >}} button was clicked, but doesn't add any cookies to the site. ## Making a button manually @@ -66,7 +66,7 @@ https://console.platform.sh/org/create-project?template=GIT_URL ``` Where `GIT_URL` is the URL of a publicly visible Git repository. -For example, to install Platform.sh's [Drupal 10 template on GitHub](https://github.com/platformsh-templates/drupal10) you would use: +For example, to install {{< vendor/name >}}'s [Drupal 10 template on GitHub](https://github.com/platformsh-templates/drupal10) you would use: ```text https://console.platform.sh/org/create-project/?template=https://github.com/platformsh-templates/drupal10.git @@ -76,7 +76,7 @@ https://console.platform.sh/org/create-project/?template=https://github.com/plat A new project is created and then initialized with whatever code is at the tip of the default branch of that repository. This method works for any publicly visible Git repository, -provided that it includes the necessary Platform.sh YAML configuration files. +provided that it includes the necessary {{< vendor/name >}} YAML configuration files. If those are missing the project still initializes but fails to build. ### Defined Template @@ -88,21 +88,21 @@ https://console.platform.sh/org/create-project?template=TEMPLATE_URL ``` Where `TEMPLATE_URL` is the URL of a publicly visible template definition file. -For example, to install Platform.sh's [Drupal 10 template](https://github.com/platformsh-templates/drupal10) you would use: +For example, to install {{< vendor/name >}}'s [Drupal 10 template](https://github.com/platformsh-templates/drupal10) you would use: ```text https://console.platform.sh/org/create-project/?template=https://github.com/platformsh/template-builder/blob/master/templates/drupal10/.platform.template.yaml ``` A new project is created, initialized with whatever code is at the tip of the default branch of the repository referenced by that file, -provided that it includes the necessary Platform.sh YAML configuration files. +provided that it includes the necessary {{< vendor/name >}} YAML configuration files. If those are missing the project still initializes but fail to build. ## Listing a repository -Platform.sh welcomes project templates produced by the application vendor. -If you have a Free Software application you want available in the Platform.sh setup wizard, +{{< vendor/name >}} welcomes project templates produced by the application vendor. +If you have a Free Software application you want available in the {{< vendor/name >}} setup wizard, create a template definition file and submit a pull request against the [3rd party templates repository](https://github.com/platformsh/templates-external/). The Developer Relations team reviews and evaluate the application and template, and may offer feedback before merging. -Generally speaking, any Free Software application that's actively maintained and runs well on Platform.sh is welcome. +Generally speaking, any Free Software application that's actively maintained and runs well on {{< vendor/name >}} is welcome. Projects released under a non-Free license aren't accepted. diff --git a/sites/platform/src/development/email.md b/sites/platform/src/development/email.md index 2184c47fc4..6ed7d34394 100644 --- a/sites/platform/src/development/email.md +++ b/sites/platform/src/development/email.md @@ -2,10 +2,10 @@ title: Send email weight: 9 sidebarTitle: Email -description: Send email from your Platform.sh environments. +description: Send email from your {{< vendor/name >}} environments. --- -You can configure your Platform.sh environments to send emails via an SMTP proxy. +You can configure your {{< vendor/name >}} environments to send emails via an SMTP proxy. Emails aren't guaranteed to be deliverable and you can't white-label them. The SMTP proxy is intended as a zero-configuration, best-effort service. @@ -117,7 +117,7 @@ When outgoing emails are on, `PLATFORM_SMTP_HOST` is the address of the SMTP hos When outgoing emails are off, the variable is empty. When using `PLATFORM_SMTP_HOST`, send email through port 25 (often the default). -Your emails are proxied through the Platform.sh SMTP host and encrypted over port 465 +Your emails are proxied through the {{< vendor/name >}} SMTP host and encrypted over port 465 before being sent to the outside world. The precise way to send email depends on the language and framework you use. diff --git a/sites/platform/src/development/file-transfer.md b/sites/platform/src/development/file-transfer.md index bf7074521b..48825b98bd 100644 --- a/sites/platform/src/development/file-transfer.md +++ b/sites/platform/src/development/file-transfer.md @@ -12,7 +12,7 @@ To do so, you need to configure mounts or use an SSH client. [Mounts](../create-apps/app-reference.md#mounts) let you set up directories that remain writable after the build is complete. You can then transfer files directly to and from mounts inside your app -with a single command via the [Platform.sh CLI](../administration/cli/_index.md). +with a single command via the [{{< vendor/name >}} CLI](../administration/cli/_index.md). Alternatively, you can transfer files to and from your built app using an SSH client such as `scp` or `rsync`. @@ -113,7 +113,7 @@ scp "$(platform ssh --pipe)":web/uploads/diagram.png . The `diagram.png` file is copied to the current local directory. -To copy files from your local directory to the Platform.sh environment, +To copy files from your local directory to the {{< vendor/name >}} environment, reverse the order of the parameters: ```bash @@ -134,7 +134,7 @@ run the following command: rsync -azP "$(platform ssh --pipe)":web/uploads/ ./uploads/ ``` -To copy files from your local directory to the Platform.sh environment, +To copy files from your local directory to the {{< vendor/name >}} environment, reverse the order of the parameters: ```bash diff --git a/sites/platform/src/development/headers.md b/sites/platform/src/development/headers.md index 6ccfc765e5..d08f63f282 100644 --- a/sites/platform/src/development/headers.md +++ b/sites/platform/src/development/headers.md @@ -2,7 +2,7 @@ title: "HTTP Headers" weight: 8 description: | - Platform.sh adds a number of HTTP headers to both inbound and outbound messages. We don't modify or block existing headers on either request or response. + {{< vendor/name >}} adds a number of HTTP headers to both inbound and outbound messages. We don't modify or block existing headers on either request or response. sidebarTitle: "Headers" --- @@ -10,7 +10,7 @@ sidebarTitle: "Headers" ## Request headers -Platform.sh adds the following HTTP headers in the router to give the application information about the connection. These are stable and may be examined by the application as necessary. +{{< vendor/name >}} adds the following HTTP headers in the router to give the application information about the connection. These are stable and may be examined by the application as necessary. * `X-Forwarded-Proto`: The protocol forwarded to the application, for example: `http`, `https`. * `X-Client-IP`: The remote IP address of the request. @@ -20,7 +20,7 @@ Platform.sh adds the following HTTP headers in the router to give the applicatio ## Response headers -Platform.sh adds a number of response headers automatically to assist in debugging connections. These headers should be treated as a semi-private API. Do not code against them, but they may be inspected to help determine how Platform.sh handled the request to aid in debugging. +{{< vendor/name >}} adds a number of response headers automatically to assist in debugging connections. These headers should be treated as a semi-private API. Do not code against them, but they may be inspected to help determine how {{< vendor/name >}} handled the request to aid in debugging. * `X-Platform-Cache`: Either `HIT` or `MISS` to indicate if the router in your cluster served the response from its own cache or if the request was passed through to the application. * `X-Platform-Cluster`: The ID of the cluster that received the request. The cluster name is formed from the project ID and environment ID. diff --git a/sites/platform/src/development/local/_index.md b/sites/platform/src/development/local/_index.md index 51d1b4c7df..586a41a0d6 100644 --- a/sites/platform/src/development/local/_index.md +++ b/sites/platform/src/development/local/_index.md @@ -9,14 +9,14 @@ layout: single To make changes to your app's code and test them without affecting your production environment, set up a local development environment on your computer. -For the most effective testing, you want your local environment to match your Platform.sh environments. +For the most effective testing, you want your local environment to match your {{< vendor/name >}} environments. The best way to do this is to use a cross-platform tool based on Docker. -This ensures the changes you make locally appear as they would on your Platform.sh environments. +This ensures the changes you make locally appear as they would on your {{< vendor/name >}} environments. It also means you don't have to worry about configuring your machine with the various dependencies, certificates, and connections your app needs to run. -The **recommended tool** for local development with Platform.sh is **[DDEV](./ddev.md)**. -The integration with DDEV is maintained by Platform.sh to ensure it works smoothly. +The **recommended tool** for local development with {{< vendor/name >}} is **[DDEV](./ddev.md)**. +The integration with DDEV is maintained by {{< vendor/name >}} to ensure it works smoothly. Other Docker-based tools are also supported, such as [Docksal](./docksal.md) and [Lando](./lando.md). If you choose to use a Docker-based tool, follow the steps on its page. @@ -27,13 +27,13 @@ Otherwise, follow these steps to run your app on your computer. You need to have: -- A Platform.sh account: +- A {{< vendor/name >}} account: new users can sign up for a [free trial account](https://auth.api.platform.sh/register) - A working project, either started from a [template](../../development/templates.md) - or with your own code pushed to Platform.sh + or with your own code pushed to {{< vendor/name >}} - [Git](https://git-scm.com/downloads) -- The [Platform.sh CLI](../../administration/cli/_index.md) +- The [{{< vendor/name >}} CLI](../../administration/cli/_index.md) ## 1. Get your code @@ -53,8 +53,8 @@ You can now access your code from the project directory on your computer. The CLI created a `.platform/local` directory that's excluded from Git. It contains builds and local metadata about your project. -You can now make changes to your project without pushing to Platform.sh each time to test them. -Instead, you can locally build your application using the Platform.sh CLI. +You can now make changes to your project without pushing to {{< vendor/name >}} each time to test them. +Instead, you can locally build your application using the {{< vendor/name >}} CLI. Note that if your app contains services, you need to open an SSH tunnel to connect to them. For more information, see how to [connect services](../../add-services#2-connect-the-service). @@ -64,7 +64,7 @@ For more information, see how to [connect services](../../add-services#2-connect If your app requires services to run, you have two options for developing locally: - [Tethered local development](./tethered.md) involves running your app on a local web server - but keeping all other services on Platform.sh and connecting to them over an SSH tunnel. + but keeping all other services on {{< vendor/name >}} and connecting to them over an SSH tunnel. - [Untethered local development](./untethered.md) involves running your entire site locally, including all services. diff --git a/sites/platform/src/development/local/ddev.md b/sites/platform/src/development/local/ddev.md index 03f2d07894..09acef7290 100644 --- a/sites/platform/src/development/local/ddev.md +++ b/sites/platform/src/development/local/ddev.md @@ -10,7 +10,7 @@ keywords: {{% ddev/definition %}} -This guide assumes you have a project already running with Platform.sh and you have the code on your computer. +This guide assumes you have a project already running with {{< vendor/name >}} and you have the code on your computer. If you're starting from scratch, first [create a project from a PHP template]({{% create-project-link template=true %}}). ## Before you begin @@ -60,7 +60,7 @@ Now your project is ready to run: ddev start ``` -This runs all your hooks and builds your project like on Platform.sh. +This runs all your hooks and builds your project like on {{< vendor/name >}}. The command returns the project URL `http://{{< variable "PROJECT_NAME" >}}.ddev.site/` as well as a specific port on `http://127.0.0.1`. diff --git a/sites/platform/src/development/local/docksal.md b/sites/platform/src/development/local/docksal.md index 929ae05868..6f787e5551 100644 --- a/sites/platform/src/development/local/docksal.md +++ b/sites/platform/src/development/local/docksal.md @@ -5,12 +5,12 @@ weight: 1 sectionBefore: Supported environments --- -[Docksal](https://docksal.io) is a Docker-based local development tool that plays nicely with Platform.sh. +[Docksal](https://docksal.io) is a Docker-based local development tool that plays nicely with {{< vendor/name >}}. It allows you to have fully containerized environments to run everything locally -without having to install tools (such as the Platform.sh CLI) on your machine. -It's maintained by a community of developers and is a viable option for most Platform.sh projects. +without having to install tools (such as the {{< vendor/name >}} CLI) on your machine. +It's maintained by a community of developers and is a viable option for most {{< vendor/name >}} projects. -This guide assumes you have a project already running within Platform.sh. +This guide assumes you have a project already running within {{< vendor/name >}}. If you're starting from scratch, first [create a project from a template]({{% create-project-link template=true %}}). ## Before you begin @@ -32,16 +32,16 @@ See all [restrictions on the projects directory](https://docs.docksal.io/getting ## 3. Add an API token -To connect Docksal with your Platform.sh account, use a Platform.sh API token. +To connect Docksal with your {{< vendor/name >}} account, use a {{< vendor/name >}} API token. -1. [Create an API token](../../administration/cli/api-tokens.md#2-create-a-platformsh-api-token) in the Console. +1. [Create an API token](../../administration/cli/api-tokens.md#2-create-an-api-token) in the Console. 2. Add the token to your Docksal configuration by running this command: ```bash fin config set --global SECRET_PLATFORMSH_CLI_TOKEN="{{< variable "API_TOKEN" >}}" ``` -Now you can run `fin platform {{< variable "COMMAND" >}}` from your computer without needing to install the Platform.sh CLI. +Now you can run `fin platform {{< variable "COMMAND" >}}` from your computer without needing to install the {{< vendor/name >}} CLI. ## 4. Get your project @@ -53,13 +53,13 @@ fin pull init --hosting-platform='platformsh' --hosting-site={{< variable "PROJE This creates a directory with the specified name with all your files and code. It also adds a `.docksal` directory with all necessary Docksal configuration. -These files are ignored by Platform.sh. +These files are ignored by {{< vendor/name >}}. ## 5. Add commands Docksal doesn't automatically copy over any commands you have in your [build flavor](../../create-apps/app-reference.md#build) and [hooks](../../create-apps/hooks/_index.md). -To get your project running like on Platform.sh, you have to add the commands to Docksal. +To get your project running like on {{< vendor/name >}}, you have to add the commands to Docksal. The `.docksal/commands` directory should already have one command (`init`) such as the following: @@ -185,9 +185,9 @@ fin config set CLI_IMAGE='docksal/cli:latest' You can also customize the `.docksal/docksal.yml` file. Use it for a docker-compose definition for your [custom configurations](https://docs.docksal.io/stack/custom-configuration/#custom-configuration). -### Import MySQL data from Platform.sh into Docksal +### Import MySQL data into Docksal -To download your data from Platform.sh and load it into your Docksal database container, run the following commands: +To download your data from {{< vendor/name >}} and load it into your Docksal database container, run the following commands: ```bash fin platform db:dump --gzip -f /tmp/database.sql.gz diff --git a/sites/platform/src/development/local/lando.md b/sites/platform/src/development/local/lando.md index da7c3c8068..2fe503225c 100644 --- a/sites/platform/src/development/local/lando.md +++ b/sites/platform/src/development/local/lando.md @@ -6,7 +6,7 @@ weight: 1 --- [Lando](https://docs.lando.dev) is a third-party local development tool for which several stacks are available (LAMP, LEMP, MEAN). -Lando works with most services supported by Platform.sh [except for](https://docs.lando.dev/platformsh/caveats.html#unsupported-things) Vault KMS and network storage. +Lando works with most services supported by {{< vendor/name >}} [except for](https://docs.lando.dev/platformsh/caveats.html#unsupported-things) Vault KMS and network storage. See a list of [supported services](https://docs.lando.dev/platformsh/config.html#services-yaml). {{< note >}} @@ -17,7 +17,7 @@ See a list of [supported services](https://docs.lando.dev/platformsh/config.html For a complete reference, consult the following resources: -- [Lando Platform.sh plugin documentation](https://docs.lando.dev/platformsh/) and [source code](https://github.com/lando/platformsh) +- [Lando {{< vendor/name >}} plugin documentation](https://docs.lando.dev/platformsh/) and [source code](https://github.com/lando/platformsh) - [Lando documentation](https://docs.lando.dev/) ## Before you begin @@ -36,7 +36,7 @@ Follow the [Lando installation instructions](https://docs.lando.dev/getting-star ## 2. Create an access token -To authorize Lando to communicate with Platform.sh, create an [API token](../../administration/cli/api-tokens.md#2-create-a-platformsh-api-token). +To authorize Lando to communicate with {{< vendor/name >}}, create an [API token](../../administration/cli/api-tokens.md#2-create-an-api-token). Copy the value. ## 3. Initialize Lando @@ -44,12 +44,12 @@ Copy the value. {{< codetabs >}} +++ -title=On an existing Platform.sh project +title=On an existing {{< vendor/name >}} project +++ If your code isn't present locally, retrieve your codebase with one of these methods: -- Using the [Platform.sh CLI](../../administration/cli/_index.md) by running platform get {{< variable "PROJECT_ID" >}} +- Using the [{{< vendor/name >}} CLI](../../administration/cli/_index.md) by running platform get {{< variable "PROJECT_ID" >}} - Using [Git](../../administration/web/configure-environment.md#actions-on-environments) Otherwise, access the directory with your project. @@ -58,9 +58,9 @@ Run lando init --recipe platformsh --source cwd --platformsh-auth {{% vari {{< note >}} -If for some reason you get an error using the Platform.sh recipe, +If for some reason you get an error using the {{< vendor/name >}} recipe, be sure to -[install the latest version of the Platform.sh plugin](https://docs.lando.dev/platformsh/getting-started.html#custom-installation) +[install the latest version of the {{< vendor/name >}} plugin](https://docs.lando.dev/platformsh/getting-started.html#custom-installation) and run the command again. {{< /note >}} @@ -68,16 +68,16 @@ and run the command again. <---> +++ -title=On a new Platform.sh project without code +title=On a new {{< vendor/name >}} project without code +++ -For a quicker start, create a project based on the Platform.sh [PHP template](https://github.com/platformsh-templates/php). +For a quicker start, create a project based on the {{< vendor/name >}} [PHP template](https://github.com/platformsh-templates/php). The template provides the most basic configuration for running a custom PHP project built with Composer. -It also includes the required Platform.sh configuration files out of the box. +It also includes the required {{< vendor/name >}} configuration files out of the box. 1. [Create a new project based on the PHP template]({{% create-project-link template="php" %}}). 2. Clone that project locally in one of these ways: - - Using the [Platform.sh CLI](../../administration/cli/_index.md) by running platform get {{< variable "PROJECT_ID" >}}. + - Using the [{{< vendor/name >}} CLI](../../administration/cli/_index.md) by running platform get {{< variable "PROJECT_ID" >}}. - Using [Git](../../administration/web/configure-environment.md#actions-on-environments) 3. In the project's folder, run lando init --recipe platformsh --source platformsh --platformsh-auth {{% variable "API_TOKEN" %}}. 4. Follow the instructions provided by the interactive prompt. @@ -99,8 +99,8 @@ Access your app and services by opening the according URLs in your browser. ## What's next -- [Import data and download files](https://docs.lando.dev/platformsh/sync.html) from your remote Platform.sh site. -- If you make changes in the Platform.sh [configuration files](../../overview/structure.md) during development, run `lando rebuild` for these to be taken into account in Lando. +- [Import data and download files](https://docs.lando.dev/platformsh/sync.html) from your remote {{< vendor/name >}} site. +- If you make changes in the {{< vendor/name >}} [configuration files](../../overview/structure.md) during development, run `lando rebuild` for these to be taken into account in Lando. - To keep your Lando image up-to-date, see how to [update Lando](https://docs.lando.dev/getting-started/updating.html). ## Troubleshooting @@ -111,7 +111,7 @@ Access your app and services by opening the according URLs in your browser. {{< /note >}} -- Make sure that the [Platform.sh configuration files](../../overview/structure.md) are present in your local repository. +- Make sure that the [{{< vendor/name >}} configuration files](../../overview/structure.md) are present in your local repository. - Check that your [services](https://docs.lando.dev/platformsh/config.html#services-yaml) are supported by Lando. - Check [caveats and known issues](https://docs.lando.dev/platformsh/caveats.html). - Carefully check the output of the Lando commands you run to spot warnings and errors. diff --git a/sites/platform/src/development/local/tethered.md b/sites/platform/src/development/local/tethered.md index 6ef998cd28..dd914eec18 100644 --- a/sites/platform/src/development/local/tethered.md +++ b/sites/platform/src/development/local/tethered.md @@ -5,7 +5,7 @@ weight: 2 --- To test changes locally, you can connect your locally running web server -to service containers on an active Platform.sh environment. +to service containers on an active {{< vendor/name >}} environment. This method requires less configuration than tools such as [DDEV](./ddev.md), but may not perform well enough for everyday use. Because it replies on a local web server, it's also less consistent across your team. @@ -17,9 +17,9 @@ Because it replies on a local web server, it's also less consistent across your {{% tethered-dev/steps-start %}} 1. Run your application locally. - Make sure it's set up to read configuration from Platform.sh environment variables. + Make sure it's set up to read configuration from {{< vendor/name >}} environment variables. - If you app relies on other Platform.sh environment configuration, such as routes or secret variables, + If you app relies on other {{< vendor/name >}} environment configuration, such as routes or secret variables, make sure to mock those variables as well. Your options for running the app depend on the language and configuration. diff --git a/sites/platform/src/development/local/untethered.md b/sites/platform/src/development/local/untethered.md index 5e4799861c..638b207551 100644 --- a/sites/platform/src/development/local/untethered.md +++ b/sites/platform/src/development/local/untethered.md @@ -7,10 +7,10 @@ weight: 2 It's possible to run your entire site locally on your computer. That way you get better performance as there's no extra latency to connect to a remote database and doesn't require an active Internet connection to work. But it does require running all necessary services (databases, search servers, and so on) locally. -These can be set up however you prefer, although Platform.sh recommends using a virtual machine to make it easier to share configuration between developers. +These can be set up however you prefer, although {{< vendor/name >}} recommends using a virtual machine to make it easier to share configuration between developers. If you already have a development workflow in place that works for you, you can keep using it with virtually no changes. -To synchronize data from an environment on Platform.sh, consult the documentation for each [service](../../add-services/_index.md). -Each service type has its own native data import/export process and Platform.sh doesn't get in the way of that. +To synchronize data from an environment on {{< vendor/name >}}, consult the documentation for each [service](../../add-services/_index.md). +Each service type has its own native data import/export process and {{< vendor/name >}} doesn't get in the way of that. It's also straightforward to [download user files](../../tutorials/exporting.md) from your application using rsync. diff --git a/sites/platform/src/development/private-repository.md b/sites/platform/src/development/private-repository.md index 934460ee52..0765afa753 100644 --- a/sites/platform/src/development/private-repository.md +++ b/sites/platform/src/development/private-repository.md @@ -2,10 +2,10 @@ title: Pull code from a private Git repository weight: 10 sidebarTitle: Private repositories -description: See how to pull code from a private Git repository into your Platform.sh build process. +description: See how to pull code from a private Git repository into your {{< vendor/name >}} build process. --- -To complete its build, your Platform.sh project may need to access pieces of code stored in private Git repositories. +To complete its build, your {{< vendor/name >}} project may need to access pieces of code stored in private Git repositories. Examples include themes, libraries, and modules. Configure these repositories to grant access to your project. @@ -29,7 +29,7 @@ add the project's public SSH key to your Git repository's deploy keys. If you're only pulling code, the key doesn't need write permissions. -Now your Platform.sh project can access your private repository via SSH, including to add dependencies. +Now your {{< vendor/name >}} project can access your private repository via SSH, including to add dependencies. This means you can access the private repository through links like: git@{{% variable "GIT_PROVIDER" %}}:{{% variable "PATH_OR_USERNAME" %}}/{{% variable "REPOSITORY" %}}.git. diff --git a/sites/platform/src/development/regions.md b/sites/platform/src/development/regions.md index b1aa7ab240..60d963ed3e 100644 --- a/sites/platform/src/development/regions.md +++ b/sites/platform/src/development/regions.md @@ -4,23 +4,23 @@ # Table shortcode: See `docs/layouts/shortcodes/regions.html`. title: Regions weight: 14 -description: See information about Platform.sh regions, including their environmental impact and IP addresses. +description: See information about {{< vendor/name >}} regions, including their environmental impact and IP addresses. --- -Platform.sh offers several regions for hosting project data. +{{< vendor/name >}} offers several regions for hosting project data. You can choose a region based on criteria such as its closeness to your users and its environmental impact. ## Environmental impact -At Platform.sh, we are committed to reducing our environmental impact. Whenever you create a project with us, we provide information about the electricity grid provider for that region. You can view the average carbon intensity of the energy grid in grams of CO2 equivalent per kilowatt-hour. +At {{< vendor/name >}}, we are committed to reducing our environmental impact. Whenever you create a project with us, we provide information about the electricity grid provider for that region. You can view the average carbon intensity of the energy grid in grams of CO2 equivalent per kilowatt-hour. These data are sourced from an annual average, which we update as new information becomes available. If you want to see real-time emissions generated by each power grid, we recommend checking out [Electricity Maps](https://app.electricitymap.org/map). You can also access a public GitHub page of Electricity Maps [data sources](https://github.com/electricitymap/electricitymap-contrib/blob/master/DATA_SOURCES.md). -Summary of data being used in Platform.sh’s Region Picker when creating a new Project: +Summary of data being used in {{< vendor/name >}}’s Region Picker when creating a new Project: | Source | Last update of this page | Previous versions of this page | |--------|--------------------------|--------------------------------| | Electricity Maps 2022 annual averages (previous to May 2023, we had used annual averages from the IEA).
See our [blog post](https://platform.sh/blog/platformsh-is-now-using-annual-carbon-intensities-from-electricity-maps/) for more information.| 11 May 2023 | Available [here](https://github.com/platformsh/platformsh-docs/commits/main/docs/src/development/regions.md) | -Information on carbon intensity is also available in the Platform.sh API. +Information on carbon intensity is also available in the {{< vendor/name >}} API. For example, to get a list of the regions and their carbon intensities, run the following command: ```bash @@ -49,7 +49,7 @@ The returned list contains, for each available region, its name, provider, geogr ### Legacy regions -A legacy region is a region running an older version of the Platform.sh orchestration system. +A legacy region is a region running an older version of the {{< vendor/name >}} orchestration system. It doesn't include all available features. If you’re on a legacy region and want all features now, diff --git a/sites/platform/src/development/sanitize-db/_index.md b/sites/platform/src/development/sanitize-db/_index.md index 34f4457e4b..654747cc83 100644 --- a/sites/platform/src/development/sanitize-db/_index.md +++ b/sites/platform/src/development/sanitize-db/_index.md @@ -11,7 +11,7 @@ keywords: When working on a new feature on your website, you want to use a new branch. Using a new branch makes sure that you don't risk breaking your live, production website. -Creating a branch on Platform.sh copies both the code and the database to that new development branch. +Creating a branch on {{< vendor/name >}} copies both the code and the database to that new development branch. These code and database changes need to be tested before being merged into production. Depending on your processes, internal or external teams may interact with the development environment branch. diff --git a/sites/platform/src/development/sanitize-db/postgresql-symfony.md b/sites/platform/src/development/sanitize-db/postgresql-symfony.md index 3a039d018a..4b9aa97c49 100644 --- a/sites/platform/src/development/sanitize-db/postgresql-symfony.md +++ b/sites/platform/src/development/sanitize-db/postgresql-symfony.md @@ -275,7 +275,7 @@ Set up a script by following these steps: ``` {{< note >}} -You can find the organization identifier for a specific project, within the Platform.sh console, by clicking on your name, and then on “Settings”, in the top right corner. +You can find the organization identifier for a specific project, within the {{< vendor/name >}} console, by clicking on your name, and then on “Settings”, in the top right corner. {{< /note >}} diff --git a/sites/platform/src/development/ssh/_index.md b/sites/platform/src/development/ssh/_index.md index 0164e627e7..b792913ab0 100644 --- a/sites/platform/src/development/ssh/_index.md +++ b/sites/platform/src/development/ssh/_index.md @@ -1,7 +1,7 @@ --- title: Connect securely with SSH weight: 12 -description: Keep your project and apps safe by connecting with SSH when you're interacting with your deployed environments or using the Platform.sh CLI. +description: Keep your project and apps safe by connecting with SSH when you're interacting with your deployed environments or using the {{< vendor/name >}} CLI. layout: single keywords: - 2fa @@ -24,13 +24,13 @@ All secured through SSH. To connect to an app securely with SSH, follow two steps. -### 1. Authenticate with the Platform.sh CLI +### 1. Authenticate with the CLI To authenticate with the CLI: -1. Install the [Platform.sh CLI](/administration/cli/_index.md). +1. Install the [{{< vendor/name >}} CLI](/administration/cli/_index.md). 2. Run `platform login`. -3. In the open browser window, log in with your Platform.sh account credentials. +3. In the open browser window, log in with your {{< vendor/name >}} account credentials. (This webpage is encrypted with HTTPS [HTTP over TLS], making it secure.) 4. Authorize the CLI to use your account. @@ -162,9 +162,9 @@ To connect to a service, fill in the details with the rest of your [service cred ## Alternative authentication methods -There are three basic ways to authenticate with Platform.sh: +There are three basic ways to authenticate with {{< vendor/name >}}: -* [Through the CLI](#1-authenticate-with-the-platformsh-cli) +* [Through the CLI](#1-authenticate-with-the-cli) * The fastest and easiest method. * Supports multifactor authentication. * Automatically generates new certificates to keep your connection safe. diff --git a/sites/platform/src/development/ssh/ssh-keys.md b/sites/platform/src/development/ssh/ssh-keys.md index 1d572e1c28..042a8ac9ce 100644 --- a/sites/platform/src/development/ssh/ssh-keys.md +++ b/sites/platform/src/development/ssh/ssh-keys.md @@ -7,7 +7,7 @@ sidebarTitle: SSH keys To connect to your app using SSH keys, you need two keys: * A **private key** you must keep _secret_ -* A **public key** stored in your Platform.sh account +* A **public key** stored in your {{< vendor/name >}} account A given SSH key pair can only be linked to a single user account. @@ -17,8 +17,8 @@ If you have a key pair available, you aren't prompted to login. To keep connection secure, you need to regularly update the keys you use. A well-encrypted key is no substitute for regular key rotation. -If you used GitHub to sign up for your Platform.sh account -your public keys from GitHub are automatically synced to your Platform.sh account. +If you used GitHub to sign up for your {{< vendor/name >}} account +your public keys from GitHub are automatically synced to your {{< vendor/name >}} account. So you can use them already with the CLI or to [connect to your app](./_index.md#2-connect-to-an-app-with-ssh). ## Add SSH keys @@ -54,14 +54,14 @@ To find your public key file: ``` If you find a file ending in `.pub`, -copy the location and [add it to your Platform.sh account](#2-add-an-ssh-key-to-your-platform-account). +copy the location and [add it to your {{< vendor/name >}} account](#2-add-an-ssh-key-to-your-platform-account). If you don't find an existing key, [generate new keys](#1b-generate-new-keys). ### 1B. Generate new keys -If you're logged in using the [Platform.sh CLI](./_index.md#1-authenticate-with-the-platformsh-cli), -generate a key and have it added to your Platform.sh account automatically. +If you're logged in using the [{{< vendor/name >}} CLI](./_index.md#1-authenticate-with-the-cli), +generate a key and have it added to your {{< vendor/name >}} account automatically. 1. In a terminal, run `platform ssh-key:add`. 1. If necessary, log in to a browser. @@ -76,13 +76,13 @@ generate a key and have it added to your Platform.sh account automatically. To generate a key otherwise, GitHub has a good [walk-through for creating SSH key pairs](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) on various operating systems. -Then you need to [add it to your Platform.sh account](#2-add-an-ssh-key-to-your-platform-account). +Then you need to [add it to your {{< vendor/name >}} account](#2-add-an-ssh-key-to-your-platform-account). ### 2. Add an SSH key to your Platform account -Once you have the location of your public key, add it to your Platform.sh account. +Once you have the location of your public key, add it to your {{< vendor/name >}} account. -If you're logged in using the [Platform.sh CLI](./_index.md#1-authenticate-with-the-platformsh-cli), +If you're logged in using the [{{< vendor/name >}} CLI](./_index.md#1-authenticate-with-the-cli), in a terminal run the following command (replacing `{{< variable "PATH_TO_YOUR_KEY" >}}` with the location of your public key): ```bash @@ -98,7 +98,7 @@ Now you are ready to use the key to [connect to an environment](./_index.md#2-co To connect to a server using SSH keys, find the details in the Console: -1. Open the [Platform.sh Console](https://console.platform.sh/). +1. Open the [{{< vendor/name >}} Console](https://console.platform.sh/). 1. Select a project. 1. In the **Environment** dropdown, select the environment you want to access. 1. Click the **SSH** dropdown. @@ -111,7 +111,7 @@ you need to [redeploy your environment](./troubleshoot-ssh.md#redeploy-your-envi ## Forwarding keys by default -It may be helpful to set your SSH client to always forward keys to Platform.sh servers, which can simplify other SSH or rsync commands. +It may be helpful to set your SSH client to always forward keys to {{< vendor/name >}} servers, which can simplify other SSH or rsync commands. To do so, include a block in your local `~/.ssh/config` file like so: ```text @@ -121,5 +121,5 @@ Host *.eu.platform.sh ForwardAgent yes ``` -Include one `Host` entry for each Platform.sh region you want to connect to, such as `us-2` or `eu-4`. +Include one `Host` entry for each {{< vendor/name >}} region you want to connect to, such as `us-2` or `eu-4`. (You can include other configuration as desired.) diff --git a/sites/platform/src/development/ssh/troubleshoot-ssh.md b/sites/platform/src/development/ssh/troubleshoot-ssh.md index 898c469ab4..14b7346b8c 100644 --- a/sites/platform/src/development/ssh/troubleshoot-ssh.md +++ b/sites/platform/src/development/ssh/troubleshoot-ssh.md @@ -28,7 +28,7 @@ git push origin main ## Check your public key -Make sure your public key has been uploaded to your user account. Check it in the [Platform.sh Console](https://console.platform.sh/). +Make sure your public key has been uploaded to your user account. Check it in the [{{< vendor/name >}} Console](https://console.platform.sh/). ## SSH key can not be duplicated @@ -60,7 +60,7 @@ Check that your key is properly added to your SSH agent. This is an authenticati ## Specify your identity file -If your identity (SSH key) associated with Platform.sh isn't in a default file name +If your identity (SSH key) associated with {{< vendor/name >}} isn't in a default file name (as may be explained in your SSH software manual, for example), you may have to append a specification like the one below so that the SSH software finds the correct key. @@ -70,7 +70,7 @@ IdentityFile ~/.ssh/id_platformsh ``` Be aware that, above, `platform.sh` stands for a hostname. -Each different hostname you connect to Platform.sh at may have to be specified in the host line, separated by spaces. +Each different hostname you connect to {{< vendor/name >}} at may have to be specified in the host line, separated by spaces. ## Check your git integrations diff --git a/sites/platform/src/development/submodules.md b/sites/platform/src/development/submodules.md index d0029c8991..a9c40d7283 100644 --- a/sites/platform/src/development/submodules.md +++ b/sites/platform/src/development/submodules.md @@ -6,9 +6,9 @@ sidebarTitle: "Git submodules" ## Clone submodules during deployment -Platform.sh allows you to use submodules in your Git repository. +{{< vendor/name >}} allows you to use submodules in your Git repository. They're usually listed in a `.gitmodules` file at the root of your Git repository. -When you push via Git, Platform.sh tries to clone them automatically. +When you push via Git, {{< vendor/name >}} tries to clone them automatically. The following example is based on [a Bigfoot multi-app project](https://github.com/platformsh-templates/bigfoot-multiapp/tree/multiapp-subfolders-applications) which uses the following submodules: @@ -103,7 +103,7 @@ title= Automated update {{< note theme="warning" title="Tier availability" >}} This feature is available for **Elite** and **Enterprise** customers. -[Compare the Platform.sh tiers](https://platform.sh/pricing/) on our pricing page, +[Compare the {{< vendor/name >}} tiers](https://platform.sh/pricing/) on our pricing page, or [contact our Sales team](https://platform.sh/contact/) for more information. {{< /note >}} @@ -118,15 +118,6 @@ To do so, follow these steps: app: ... source: - ###################################################################################################################### - ## ## - ## This source operation is part of the Platform.sh process of updating and maintaining our collection of ## - ## templates. For more information see https://docs.platform.sh/create-apps/source-operations.html and ## - ## https://github.com/platformsh/source-operations ## - ## ## - ## YOU CAN SAFELY DELETE THIS COMMENT AND THE LINES BENEATH IT ## - ## ## - ###################################################################################################################### operations: rebuild: command: | @@ -164,15 +155,6 @@ To do so, follow these steps: # Information on the app's source code and operations that can be run on it. # More information: https://docs.platform.sh/create-apps/app-reference.html#source source: - ###################################################################################################################### - ## ## - ## This source operation is part of the Platform.sh process of updating and maintaining our collection of ## - ## templates. For more information see https://docs.platform.sh/create-apps/source-operations.html and ## - ## https://github.com/platformsh/source-operations ## - ## ## - ## YOU CAN SAFELY DELETE THIS COMMENT AND THE LINES BENEATH IT ## - ## ## - ###################################################################################################################### operations: update-submodules: command: | @@ -195,7 +177,7 @@ To do so, follow these steps: Select the operation you want to run.
Click **Run**. - Alternatively, to run your source operation from the [Platform.sh CLI](../administration/cli/_index.md), + Alternatively, to run your source operation from the [{{< vendor/name >}} CLI](../administration/cli/_index.md), run the following command: ```bash @@ -219,7 +201,7 @@ E: Error validating submodules in tree: - git@github.com:platformsh-templates/bigfoot-multiapp-admin.git: HangupException: The remote server unexpectedly closed the connection. ``` -This is due to the fact that the Platform.sh Git server can't connect to GitHub via SSH without being granted an SSH key to do so. +This is due to the fact that the {{< vendor/name >}} Git server can't connect to GitHub via SSH without being granted an SSH key to do so. To solve this issue, use an HTTPS URL (`https://github.com/...`) instead. ## Use private Git repositories @@ -253,7 +235,7 @@ To fix this, follow these steps: ``` 2. Add the [project's public key to your remote Git repository](./private-repository.md). - This allows your Platform.sh project to pull the repository from the remote Git service. + This allows your {{< vendor/name >}} project to pull the repository from the remote Git service. {{< note >}} @@ -269,7 +251,7 @@ If your server needs access to multiple repositories, follow these steps: ## Removing submodules -These steps aren't specific to Platform.sh, but kept as a reference for Git so that submodules are effectively removed before entering the build process. +These steps aren't specific to {{< vendor/name >}}, but kept as a reference for Git so that submodules are effectively removed before entering the build process. 1. In your `.gitmodules` and `.git/config` files, delete the information related to the submodule you want to remove. diff --git a/sites/platform/src/development/templates.md b/sites/platform/src/development/templates.md index 2e8a493539..e97218b2e2 100644 --- a/sites/platform/src/development/templates.md +++ b/sites/platform/src/development/templates.md @@ -9,7 +9,7 @@ description: | {{% template-intro %}} -You can click the **Deploy on Platform.sh** button to launch a new project using a template, or you can visit and clone the repository and push to an empty project you have created using the CLI or in the Console. +You can click the **Deploy on {{< vendor/name >}}** button to launch a new project using a template, or you can visit and clone the repository and push to an empty project you have created using the CLI or in the Console. ## C#/.NET Core diff --git a/sites/platform/src/development/transfer-dedicated.md b/sites/platform/src/development/transfer-dedicated.md index 4316e551c9..8e513412a7 100644 --- a/sites/platform/src/development/transfer-dedicated.md +++ b/sites/platform/src/development/transfer-dedicated.md @@ -8,7 +8,7 @@ Transferring data to and from [a {{% names/dedicated-gen-2 %}} cluster](../other ## Back up your files -Platform.sh automatically creates backups of the Staging and Production environments of a {{% names/dedicated-gen-2 %}} cluster every six hours. +{{< vendor/name >}} automatically creates backups of the Staging and Production environments of a {{% names/dedicated-gen-2 %}} cluster every six hours. These are only useful to fully restore an environment and are managed by the support team. You can make a manual local backup yourself by downloading data from your environment to your local system by running the following command: diff --git a/sites/platform/src/development/troubleshoot.md b/sites/platform/src/development/troubleshoot.md index cc40329d7a..d679648bbc 100644 --- a/sites/platform/src/development/troubleshoot.md +++ b/sites/platform/src/development/troubleshoot.md @@ -56,7 +56,7 @@ To rerun the `build` and `deploy` hooks, [manually trigger a build](#manually-tr ### Manually trigger builds To increase performance and keep applications the same across environments, -Platform.sh reuses built applications if its code and build time configuration (variables and such) remain the same. +{{< vendor/name >}} reuses built applications if its code and build time configuration (variables and such) remain the same. There may be times where you want to force your application to be built again without changing its code, for example to test an issue in a build hook or when external dependencies change. @@ -112,7 +112,7 @@ Typical causes and potential solutions include: - Your app is listening at the wrong place. - Check your app's [upstream properties](../create-apps/app-reference.md#upstream). - - If your app listening at a port, make sure it's using the [`PORT` environment variable](./variables/use-variables.md#use-platformsh-provided-variables). + - If your app listening at a port, make sure it's using the [`PORT` environment variable](./variables/use-variables.md#use-provided-variables). - Your `.platform.app.yaml` configuration has an error and a process isn't starting or requests can't be forwarded to it correctly. - Check your `web.commands.start` entry or your `passthru` configuration. @@ -130,7 +130,7 @@ Typical causes and potential solutions include: ## Site outage If you can't access some part of your project, whether it's the live site, development environment, or Console, -check the [Platform.sh status page](https://status.platform.sh/). +check the [{{< vendor/name >}} status page](https://status.platform.sh/). There you can see planned maintenance and subscribe to updates for any potential outages. If the status is operational, [contact support](../overview/get-support.md). @@ -157,7 +157,7 @@ Instead, call the app/shell/runtime directly passing your script file to that ex ## Missing commits -If you push code to Platform.sh without the full Git history, sometimes commits are missing. +If you push code to {{< vendor/name >}} without the full Git history, sometimes commits are missing. This can happen if you're pushing code from an external CI/CD pipeline, such as a GitHub action. Such pipelines often do only shallow clones by default. @@ -174,7 +174,7 @@ or using the [`GIT_DEPTH` variable](https://docs.gitlab.com/ee/ci/large_reposito When trying to upload a large JSON file to your API, you might see a 400 response code (`Malformed request`). -Platform.sh enforces a 10 MB limit on files with the `application/json` `Content-Type` header. +{{< vendor/name >}} enforces a 10 MB limit on files with the `application/json` `Content-Type` header. To send large files, use the `multipart/form-data` header instead: ```bash @@ -189,7 +189,7 @@ For MySQL specific errors, see how to [troubleshoot MySQL](../add-services/mysql If you try to use a user to create a database, you get an error saying `permission denied to create database`. The database is created for you -and can be found in the `path` key of the `PLATFORM_RELATIONSHIPS` [environment variable](./variables/use-variables.md#use-platformsh-provided-variables). +and can be found in the `path` key of the `PLATFORM_RELATIONSHIPS` [environment variable](./variables/use-variables.md#use-provided-variables). ## Storage diff --git a/sites/platform/src/development/variables/_index.md b/sites/platform/src/development/variables/_index.md index 3f429b60f3..d2c8a84fa4 100644 --- a/sites/platform/src/development/variables/_index.md +++ b/sites/platform/src/development/variables/_index.md @@ -23,10 +23,10 @@ The following table defines what types of variables are available to you: | [Application](./set-variables.md#set-variables-in-your-app) | Application | Application | 4 | Yes | Yes | Non-secret values that are the same across all environments | | [Project](./set-variables.md#create-project-variables) | User | Project | 3 | Yes | Yes | Secret values that are the same across all environments, such as database credentials | | [Environment](./set-variables.md#create-environment-specific-variables) | User | Environment | 2 | Some | Yes | Values that vary by environment, such as which database to connect to or which payment API keys to use | -| [Platform.sh](./use-variables.md#use-platformsh-provided-variables) | Pre-defined | Environment | 1 | Some | Yes | For information about your Platform.sh project | +| [{{< vendor/name >}}](./use-variables.md#use-provided-variables) | Pre-defined | Environment | 1 | Some | Yes | For information about your {{< vendor/name >}} project | If there are conflicts between variables with the same name, variables [take precedence](#overrides) from 1 down. -So Platform.sh-provided values (1) override environment variables (2), which override project variables (3), +So {{< vendor/name >}}-provided values (1) override environment variables (2), which override project variables (3), which override application-provided variables (4). All of the variables can also be [overridden via a script](./set-variables.md#set-variables-via-script). @@ -51,7 +51,7 @@ Other configurations should vary between environment types. For example: - Service configuration for databases and such. - This information be read from the Platform.sh-provided [`PLATFORM_RELATIONSHIPS` variable](./use-variables.md#use-platformsh-provided-variables). + This information be read from the {{< vendor/name >}}-provided [`PLATFORM_RELATIONSHIPS` variable](./use-variables.md#use-provided-variables). It varies by environment automatically. - Mode toggles such as enabling `debug` mode, disabling certain caches, and displaying more verbose errors. This information might vary by environment type and should be set on the [environment level](./set-variables.md#create-environment-specific-variables). @@ -141,7 +141,7 @@ and as **Overridden** when there is a conflict and the parent environment's valu ## Variable prefixes Certain variable name prefixes have special meanings. -Some are defined by Platform.sh and apply automatically. +Some are defined by {{< vendor/name >}} and apply automatically. Others are just available as a convention for your application code to follow. ### Top-level environment variables @@ -213,7 +213,7 @@ platform variable:create --name "drupalsettings:system.site:name" --value "{{< v The same logic applies for other configuration options, such as the global `$config` array, which uses the variable prefix `drupalconfig`. -You need to name your Platform.sh variables to match the ones used in your script. -Make sure that the Platform.sh variables start with a string present in your `switch` statement. +You need to name your {{< vendor/name >}} variables to match the ones used in your script. +Make sure that the {{< vendor/name >}} variables start with a string present in your `switch` statement. You can apply similar logic for [other frameworks and languages](../../development/variables/use-variables.md#access-variables-in-your-app). diff --git a/sites/platform/src/development/variables/set-variables.md b/sites/platform/src/development/variables/set-variables.md index 967f7c1e99..c149905aed 100644 --- a/sites/platform/src/development/variables/set-variables.md +++ b/sites/platform/src/development/variables/set-variables.md @@ -160,7 +160,7 @@ To make the new value accessible to those environments, [trigger a redeploy](../ ### Example environment variable -Environment variables are a good place to store values that apply only on Platform.sh and not on your local development environment. +Environment variables are a good place to store values that apply only on {{< vendor/name >}} and not on your local development environment. This includes API credentials for third-party services, mode settings, and which server (development vs. production) to use. One example would be to define a Node.js application's build on a production branch (`NODE_ENV=production`), @@ -242,8 +242,8 @@ To solve the issue, remove the printed output from your `.environment` file. ## Map variables -If your app needs different names for environment variable than those set by Platform.sh, which is common for database connections, -map the Platform.sh's variable names to those required by the application. +If your app needs different names for environment variable than those set by {{< vendor/name >}}, which is common for database connections, +map the {{< vendor/name >}}'s variable names to those required by the application. Do this in the app with the help of the [Config Reader library](./use-variables.md#access-variables-in-your-app) or via a shell script. For example, the following [`.environment` script](#set-variables-via-script) exports variables that are visible to the application. diff --git a/sites/platform/src/development/variables/use-variables.md b/sites/platform/src/development/variables/use-variables.md index 6159c1b844..4e88017c9f 100644 --- a/sites/platform/src/development/variables/use-variables.md +++ b/sites/platform/src/development/variables/use-variables.md @@ -25,7 +25,7 @@ Variables on the project Example (abcdef123456), environment main: Project and environment variables with the [prefix](./_index.md#top-level-environment-variables) `env:` are available as Unix environment variables in all caps. -Access these variables and Platform.sh-provided variables directly like this: +Access these variables and {{< vendor/name >}}-provided variables directly like this: ```bash echo $FOO @@ -55,7 +55,7 @@ Variables available during builds can be accessed in `build` hooks and those ava ## Access variables in your app -To access environment variables in your app, you can use the Platform.sh Config Reader for the given language: +To access environment variables in your app, you can use the {{< vendor/name >}} Config Reader for the given language: * [PHP](https://github.com/platformsh/config-reader-php) * [Python](https://github.com/platformsh/config-reader-python) @@ -322,9 +322,9 @@ console.log(stuffColors); {{< /codetabs >}} -## Use Platform.sh-provided variables +## Use provided variables -Platform.sh also provides a series of variables to inform your app about its runtime configuration. +{{< vendor/name >}} also provides a series of variables to inform your app about its runtime configuration. They're mostly prefixed with `PLATFORM_` to differentiate them from user-provided values. You can't set or update them directly. @@ -343,8 +343,8 @@ and at runtime. | `{{< vendor/prefix >}}_BRANCH` | No | Yes | The name of the Git branch. | | `{{< vendor/prefix >}}_CACHE_DIR` | Yes | No | The directory where files are cached from one build to the next. The directory is shared among all branches, so the same cache is used for all environments. | | `{{< vendor/prefix >}}_DOCUMENT_ROOT` | No | Yes | The absolute path to the web document root, if applicable. | -| `{{< vendor/prefix >}}_ENVIRONMENT` | No | Yes | The name of the Platform.sh environment. | -| `{{< vendor/prefix >}}_ENVIRONMENT_TYPE` | No | Yes | The environment type of the Platform.sh environment (`development`, `staging`, or `production`). | +| `{{< vendor/prefix >}}_ENVIRONMENT` | No | Yes | The name of the {{< vendor/name >}} environment. | +| `{{< vendor/prefix >}}_ENVIRONMENT_TYPE` | No | Yes | The environment type of the {{< vendor/name >}} environment (`development`, `staging`, or `production`). | | `{{< vendor/prefix >}}_OUTPUT_DIR` | Yes | No | The output directory for compiled languages at build time. Equivalent to `PLATFORM_APP_DIR` in most cases. | | `{{< vendor/prefix >}}_PROJECT` | Yes | Yes | The project ID. | | `{{< vendor/prefix >}}_PROJECT_ENTROPY` | Yes | Yes | A random, 56-character value created at project creation and then stable throughout the project's life. Can be used for Drupal hash salts, Symfony secrets, and other similar values. | @@ -396,7 +396,7 @@ The `PLATFORM_APPLICATION` variable is available both at build time and in the r But the specific attributes it contains differ in each case. Each environment's build is associated with a configuration ID that identifies it uniquely so builds can be reused. -The ID is a product of your app code and some of its [configuration for Platform.sh](../../create-apps/_index.md). +The ID is a product of your app code and some of its [configuration for {{< vendor/name >}}](../../create-apps/_index.md). Not every attribute your app configuration is relevant to the build. Only those attributes that are relevant to builds are accessible at build time from `PLATFORM_APPLICATION`. @@ -425,7 +425,7 @@ and don't support reading from environment variables. To populate these files with variables you set yourself, make sure the variables are set to be [visible at build time](./set-variables.md#variable-options). -The files can't be populated with Platform.sh-provided variables not available at build time (such as `PLATFORM_RELATIONSHIPS`). +The files can't be populated with {{< vendor/name >}}-provided variables not available at build time (such as `PLATFORM_RELATIONSHIPS`). You also can't write to them in a `deploy` hook as the file system is read only. One workaround is to create a symbolic link to a writable location and then write to it in a [`deploy` hook](../../create-apps/hooks/hooks-comparison.md#deploy-hook). diff --git a/sites/platform/src/domains/_index.md b/sites/platform/src/domains/_index.md index 1cae226418..9567ea0795 100644 --- a/sites/platform/src/domains/_index.md +++ b/sites/platform/src/domains/_index.md @@ -2,5 +2,5 @@ title: "Custom domains" weight: -70 description: | - By default, a Platform.sh app is available at its Platform.sh domain. The following resources help you take your app live with the domain that you wish. + By default, a {{< vendor/name >}} app is available at its {{< vendor/name >}} domain. The following resources help you take your app live with the domain that you wish. --- diff --git a/sites/platform/src/domains/cdn/_index.md b/sites/platform/src/domains/cdn/_index.md index fdafb63993..26f7503f5e 100644 --- a/sites/platform/src/domains/cdn/_index.md +++ b/sites/platform/src/domains/cdn/_index.md @@ -12,8 +12,8 @@ These edge servers behave like local caches to nearby users. Bringing content closer to users helps enhance your site's perceived performance and so can improve user engagement and retention. -Fastly is the recommended CDN for Platform.sh projects. -By default, Dedicated projects include a [Fastly CDN managed by Platform.sh](./managed-fastly.md). +Fastly is the recommended CDN for {{< vendor/name >}} projects. +By default, Dedicated projects include a [Fastly CDN managed by {{< vendor/name >}}](./managed-fastly.md). Self-service Grid plans don't include a CDN by default, but you can set up one at any time, such as [Fastly](./fastly.md) or [Cloudflare](./cloudflare.md). @@ -36,10 +36,10 @@ it can use the `Host` header to identify which domain to access to handle the re When a request is made from a client to fetch a resource on a CDN edge server, the `Host` header value is rewritten to point to the CDN. If the requested resource isn't cached on the edge server, -the edge server makes a request to the Platform.sh server to pull and cache the resource. +the edge server makes a request to the {{< vendor/name >}} server to pull and cache the resource. For this process to be successful, -set an `X-Forwarded-Host` header to forward the original `Host` header value to the Platform.sh server. +set an `X-Forwarded-Host` header to forward the original `Host` header value to the {{< vendor/name >}} server. Use your root domain as the value of your `X-Forwarded-Host` header, for example: `example.com`. @@ -48,9 +48,9 @@ you might need to adjust your app configuration. For more information on how to set up an `X-Forwarded-Host` HTTP header, see your CDN provider's official documentation. -## Disable the Platform.sh router cache +## Disable the router cache -When you use a CDN, the Platform.sh router [HTTP caching](../../define-routes/cache.md) becomes redundant. +When you use a CDN, the {{< vendor/name >}} router [HTTP caching](../../define-routes/cache.md) becomes redundant. To disable it, change your cache configuration for the routes behind a CDN to the following: ```yaml {location=".platform/routes.yaml"} @@ -66,18 +66,18 @@ To disable it, change your cache configuration for the routes behind a CDN to th {{< premium-features/tiered "Enterprise and Elite" >}} -If your plan includes high SLA, configure your CDN so that Platform.sh can perform automated monitoring using NodePing. +If your plan includes high SLA, configure your CDN so that {{< vendor/name >}} can perform automated monitoring using NodePing. To do so, [add all NodePing IP addresses](https://nodeping.com/faq.html#ip-addresses) to your CDN's allowlist. -If you want Platform.sh to limit checks to one or more of the following regions, [contact Support](../../overview/get-support.md): +If you want {{< vendor/name >}} to limit checks to one or more of the following regions, [contact Support](../../overview/get-support.md): - North America - Europe - East Asia / Oceania -## Prevent direct access to your Platform.sh server +## Prevent direct access to your server -When you use a CDN, you might want to prevent direct access to your Platform.sh server for security purposes. +When you use a CDN, you might want to prevent direct access to your {{< vendor/name >}} server for security purposes. ### HTTP basic authentication @@ -141,7 +141,7 @@ The procedure can vary depending on your CDN. Contact your CDN provider for specific assistance. Note that client-authenticated TLS is a mutual authentication process. -It allows your CDN to check that it's communicating with your Platform.sh server +It allows your CDN to check that it's communicating with your {{< vendor/name >}} server and vice versa. So in addition to the CA certificate supplied by your CDN provider, you need to [create your own TLS certificate](../../define-routes/https.md). \ No newline at end of file diff --git a/sites/platform/src/domains/cdn/cloudflare.md b/sites/platform/src/domains/cdn/cloudflare.md index 14fa195a02..16f5ca98b1 100644 --- a/sites/platform/src/domains/cdn/cloudflare.md +++ b/sites/platform/src/domains/cdn/cloudflare.md @@ -11,7 +11,7 @@ You can [use a CDN](./_index.md) to deliver your site's content to users more qu You need: -- An up-and-running Platform.sh project +- An up-and-running {{< vendor/name >}} project - A [Cloudflare](https://www.cloudflare.com/) CDN subscription {{% disable-cache CDN="Cloudflare" %}} @@ -42,10 +42,10 @@ and can't be downgraded to HTTP. To do so, [enable full strict SSL/TLS encryption](https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/full-strict/). Any communication between a client and Cloudflare -or between Cloudflare and your Platform.sh server is then encrypted through HTTPS. -In addition, Cloudflare checks that your Platform.sh server's [TLS certificate](../../other/glossary.md#transport-layer-security-tls) +or between Cloudflare and your {{< vendor/name >}} server is then encrypted through HTTPS. +In addition, Cloudflare checks that your {{< vendor/name >}} server's [TLS certificate](../../other/glossary.md#transport-layer-security-tls) was issued by a trusted certificate authority. -This confirms the client is truly communicating with your Platform.sh server. +This confirms the client is truly communicating with your {{< vendor/name >}} server. For enhanced security, make sure your HTTPS connections can't be downgraded to HTTP. To do so, in your Cloudflare account, diff --git a/sites/platform/src/domains/cdn/fastly.md b/sites/platform/src/domains/cdn/fastly.md index 5da0f49e40..955e557392 100644 --- a/sites/platform/src/domains/cdn/fastly.md +++ b/sites/platform/src/domains/cdn/fastly.md @@ -10,15 +10,15 @@ You can [use a CDN](./_index.md) to deliver your site's content to users more qu To set up a Fastly CDN with your own Fastly subscription, follow the instructions on this page. -If you are using a Fastly CDN provided by Platform.sh, +If you are using a Fastly CDN provided by {{< vendor/name >}}, for example as part of a Dedicated project, -see guidance about [Fastly CDNs managed by Platform.sh](./managed-fastly.md). +see guidance about [Fastly CDNs managed by {{< vendor/name >}}](./managed-fastly.md). ## Before you begin You need: -- An up-and-running Platform.sh project +- An up-and-running {{< vendor/name >}} project - A [Fastly](https://www.fastly.com/) CDN subscription {{% disable-cache CDN="Fastly" %}} diff --git a/sites/platform/src/domains/cdn/managed-fastly.md b/sites/platform/src/domains/cdn/managed-fastly.md index 52660af839..ed7b1fe746 100644 --- a/sites/platform/src/domains/cdn/managed-fastly.md +++ b/sites/platform/src/domains/cdn/managed-fastly.md @@ -2,15 +2,15 @@ title: "Managed Fastly CDN" sidebarTitle: "Managed Fastly CDN" weight: 2 -description: Bring your content closer to users with a Fastly CDN fully managed by Platform.sh. +description: Bring your content closer to users with a Fastly CDN fully managed by {{< vendor/name >}}. banner: type: tiered-feature --- Instead of starting your own Fastly subscription and [managing your CDN yourself](./fastly.md), -you can take advantage of a Fastly CDN provided by Platform.sh. +you can take advantage of a Fastly CDN provided by {{< vendor/name >}}. For example, Dedicated projects include a managed Fastly CDN by default. -These CDNs are exclusively set up and managed by Platform.sh. +These CDNs are exclusively set up and managed by {{< vendor/name >}}. To modify any settings for a managed Fastly CDN, [open a support ticket](https://console.platform.sh/-/users/~/tickets/open). @@ -20,7 +20,7 @@ To add a managed Fastly CDN to your project, ### Domain control validation When you request for a new domain to be added to your Fastly service, -Platform.sh support provides you with a [`CNAME` record](../../domains/steps/dns.md) for [domain control validation](../troubleshoot.md#ownership-verification). +{{< vendor/name >}} support provides you with a [`CNAME` record](../../domains/steps/dns.md) for [domain control validation](../troubleshoot.md#ownership-verification). To add this `CNAME` record to your domain settings, see how to [configure your DNS provider](../steps/_index.md#3-configure-your-dns-provider). @@ -30,15 +30,15 @@ By default, Enterprise and Elite plans include two [TLS certificates](../../othe an apex and a wildcard one. This allows for encryption of all traffic between your users and your app. -If you use a Fastly CDN provided by Platform.sh, +If you use a Fastly CDN provided by {{< vendor/name >}}, you can provide your own third-party TLS certificates for an additional fee. To do so, if you don't have one, set up a [mount](../../create-apps/app-reference.md#mounts) that isn't accessible to the web. -Use an environment with access limited to Platform.sh support and trusted users. +Use an environment with access limited to {{< vendor/name >}} support and trusted users. [Transfer](../../development/file-transfer.md) each certificate, its unencrypted private key, and the intermediate certificate to the mount. -To notify Platform.sh that a certificate is to be added to your CDN configuration, +To notify {{< vendor/name >}} that a certificate is to be added to your CDN configuration, [create a support ticket](../../overview/get-support.md#create-a-support-ticket). If you need an Extended Validation TLS certificate, diff --git a/sites/platform/src/domains/steps/_index.md b/sites/platform/src/domains/steps/_index.md index b0f7c0f45a..e03ba2be1d 100644 --- a/sites/platform/src/domains/steps/_index.md +++ b/sites/platform/src/domains/steps/_index.md @@ -22,7 +22,7 @@ You need: * If you are on a development plan, you need to [upgrade your tier to a production plan](#1-change-your-plan-to-a-production-plan). If you are planning to use several subdomains of the same domain on different projects, -see how to [manage multiple subdomains](/domains/steps/subdomains.md) *before* you add your domain to Platform.sh. +see how to [manage multiple subdomains](/domains/steps/subdomains.md) *before* you add your domain to {{< vendor/name >}}. ## 1. Change your plan to a production plan @@ -66,7 +66,7 @@ You can find [more information on plan tiers](https://platform.sh/pricing). You want to point your DNS record to the automatically generated URL. Your domain needs to point to that target for your site to go live. -For Dedicated plans, get the target for your project from your Platform.sh contact. +For Dedicated plans, get the target for your project from your {{< vendor/name >}} contact. {{< codetabs >}} @@ -145,9 +145,9 @@ To configure your CDN and your domain name to point to your project: The address or `CNAME` record to use varies by CDN provider. Refer to the official documentation of your DNS provider and CDN provider. 5. Check that redirects and subdomains are set correctly for the [TLS certificate ownership verification](../troubleshoot.md#ownership-verification). -6. [Disable the router cache](../cdn/_index.md#disable-the-platformsh-router-cache). +6. [Disable the router cache](../cdn/_index.md#disable-the-router-cache). 7. Optional: For increased security and to prevent the CDN from being bypassed, - you can force all traffic to [go through the CDN](../cdn/_index.md#prevent-direct-access-to-your-platformsh-server). + you can force all traffic to [go through the CDN](../cdn/_index.md#prevent-direct-access-to-your-server). 8. Optional: If you have multiple domains you want to be served by the same app, add a `CNAME` record for each of them. That includes the `www` subdomain if you are using it in your [routes configuration](../../define-routes/_index.md). @@ -157,7 +157,7 @@ See how you can further [configure your CDN](../cdn/_index.md). {{< /codetabs >}} -## 4. Set your domain in Platform.sh +## 4. Set your domain Add a single domain to your project: diff --git a/sites/platform/src/domains/steps/custom-non-production-domains.md b/sites/platform/src/domains/steps/custom-non-production-domains.md index 802f518efe..9749737f2c 100644 --- a/sites/platform/src/domains/steps/custom-non-production-domains.md +++ b/sites/platform/src/domains/steps/custom-non-production-domains.md @@ -10,7 +10,7 @@ banner: When a custom domain is [set up on your production environment](../steps/_index.md), it can't be used for the other, non-production environments in your project. Therefore, by default and for each non-production environment, -Platform.sh automatically replaces the custom production domain +{{< vendor/name >}} automatically replaces the custom production domain with an automatically generated URL. If you don't want to use these default URLs, @@ -39,7 +39,7 @@ and still access your production environment through `example.com`. If you have multiple custom domains on your production environment, when you create a custom non-production domain, you don't need to update your [routes configuration](../../define-routes/_index.md) either. -Platform.sh automatically figures out the routing of your non-production environment +{{< vendor/name >}} automatically figures out the routing of your non-production environment based on the following elements: - The custom production domains in your existing [routes configuration](../../define-routes/_index.md) @@ -64,10 +64,10 @@ You need: For more information, contact [Support](https://console.platform.sh/-/users/~/tickets/open). - A production environment with at least one custom domain already set up - At least one non-production (staging or development) environment -- The [Platform.sh CLI](../../administration/cli/_index.md) (v4.8.0+)
+- The [{{< vendor/name >}} CLI](../../administration/cli/_index.md) (v4.8.0+)
In the current Beta version, you can only add and manage non-production custom domains - through the [Platform.sh CLI](../../administration/cli/_index.md). - In future versions, you'll be able to do so in the [Platform.sh Console](../../administration/web/_index.md) too. + through the [{{< vendor/name >}} CLI](../../administration/cli/_index.md). + In future versions, you'll be able to do so in the [{{< vendor/name >}} Console](../../administration/web/_index.md) too. To prevent abuse, by default you can add custom domains to up to 5 environments per project only. This limit doesn't include the production environment, @@ -122,7 +122,7 @@ title=In the Console {{< note >}} Using the target of your production environment to configure your DNS provider is technically possible, - but Platform.sh recommends using the target of your non-production environment as a best practice. + but {{< vendor/name >}} recommends using the target of your non-production environment as a best practice. {{< /note >}} diff --git a/sites/platform/src/domains/steps/dns.md b/sites/platform/src/domains/steps/dns.md index 0f6dafc66d..2894acbafa 100644 --- a/sites/platform/src/domains/steps/dns.md +++ b/sites/platform/src/domains/steps/dns.md @@ -12,9 +12,9 @@ Available workarounds depend on your DNS provider. ## `CNAME` records -Each site on Platform.sh is made up of a set of containers. +Each site on {{< vendor/name >}} is made up of a set of containers. To map incoming requests to the appropriate container, -Platform.sh runs routers in [each region](../../development/regions.md). +{{< vendor/name >}} runs routers in [each region](../../development/regions.md). A router's IP address can change in two cases: - During an upgrade or maintenance operation, routers can be taken offline while changes are applied. - During a region upscale or downscale, routers can be added or removed. diff --git a/sites/platform/src/domains/steps/subdomains.md b/sites/platform/src/domains/steps/subdomains.md index 86815d01d2..b48e4587c0 100644 --- a/sites/platform/src/domains/steps/subdomains.md +++ b/sites/platform/src/domains/steps/subdomains.md @@ -28,20 +28,20 @@ The `TXT` record should look like the following: _public-suffix-root.{{}} TXT "public-suffix-root={{}}" ``` -This adds your domain to the [Platform.sh implementation of the Public Suffix List](#why-this-is-necessary). +This adds your domain to the [{{< vendor/name >}} implementation of the Public Suffix List](#why-this-is-necessary). After you add your subdomains, remove the `TXT` record to reinstate [subdomain hijacking protection](#subdomain-hijacking-protection). This ensures no other users can possibly add a subdomain of your domain to their project. Even if you don’t remove the record, your DNS records should prevent others from using a subdomain -as long as you don’t use wildcards records pointing at Platform.sh. +as long as you don’t use wildcards records pointing at {{< vendor/name >}}. However, if you don't remove the `TXT` record, restrictions apply on the apex domain. For example, you can't add the apex domain to another project until you remove the `TXT` record. ## Bypass locked domains -In certain cases (such as if your domain was added manually by Platform.sh support), +In certain cases (such as if your domain was added manually by {{< vendor/name >}} support), your domain may be reserved for the project you added it to. Then you can't set up a second project with the bare domain (`example.com`) or a subdomain (`foo.example.com`). @@ -86,22 +86,22 @@ and using that to set cookies on your `example.com` website. When you add a domain to a project, the first level of the domain not in the [PSL](#the-public-suffix-list) is reserved. So if you add `foo.bar.baz.example.com` to a project, -that project has `example.com` reserved within Platform.sh +that project has `example.com` reserved within {{< vendor/name >}} and no other project can have a domain anywhere in `*.example.com`. You can add multiple subdomains within that one project. Subdomain hijacking protection ensures that no other users can add a subdomain to their project -as long as you don't use wildcard DNS records pointing at Platform.sh. +as long as you don't use wildcard DNS records pointing at {{< vendor/name >}}. In most cases, that's a desirable added layer of security. But you may run into a problem when you want multiple subdomains from the same organization as separate projects. One option would be to add `example.com` to the PSL, but you might not want or be able to do that. -To limit what domains get protected, Platform.sh supports a small extension to the PSL. -When you add a `TXT` record for your domain, Platform.sh treats that domain as part of the PSL. +To limit what domains get protected, {{< vendor/name >}} supports a small extension to the PSL. +When you add a `TXT` record for your domain, {{< vendor/name >}} treats that domain as part of the PSL. So when you add a `TXT` record for `example.com`, -Platform.sh treats `example.com` as a top-level domain. +{{< vendor/name >}} treats `example.com` as a top-level domain. That means it isn't reserved and is open for other projects. Then when you add a domain, the next level down from `example.com` is reserved. diff --git a/sites/platform/src/domains/steps/tls.md b/sites/platform/src/domains/steps/tls.md index 97216291ef..28cbfc9fd1 100644 --- a/sites/platform/src/domains/steps/tls.md +++ b/sites/platform/src/domains/steps/tls.md @@ -4,18 +4,18 @@ weight: 2 sidebarTitle: "Custom TLS certificates" --- -Platform.sh automatically provides standard Transport Layer Security (TLS) certificates for all sites and environments. +{{< vendor/name >}} automatically provides standard Transport Layer Security (TLS) certificates for all sites and environments. These certificates are issued at no charge by [Let's Encrypt](https://letsencrypt.org/) and cover most needs. To use them, you need to [specify HTTPS routes](../../define-routes/https.md#enable-https). Note that some [limitations](../../define-routes/https.md#lets-encrypt-limitations) apply. -Platform.sh allows you to use third-party TLS certificates free of charge. +{{< vendor/name >}} allows you to use third-party TLS certificates free of charge. You can use many kinds of custom certificates, including domain-validated, extended validation, high-assurance, or wildcard certificates. Consult your TLS issuer for pricing and instructions on how to generate a TLS certificate. Seven days before a third-party custom certificate is due to expire, -Platform.sh replaces it with a new default Let’s Encrypt certificate. +{{< vendor/name >}} replaces it with a new default Let’s Encrypt certificate. This helps prevent downtime. To avoid switching to a default certificate, make sure you replace your custom certificate with an updated one diff --git a/sites/platform/src/domains/troubleshoot.md b/sites/platform/src/domains/troubleshoot.md index 973c721544..06c167ebe2 100644 --- a/sites/platform/src/domains/troubleshoot.md +++ b/sites/platform/src/domains/troubleshoot.md @@ -113,9 +113,9 @@ To pass this verification, there are requirements you need to meet. title=Without a CDN +++ -Platform.sh checks that all the routes you defined are pointing to your project. +{{< vendor/name >}} checks that all the routes you defined are pointing to your project. For the challenge to complete, -domains and subdomains must point directly to your Platform.sh project. +domains and subdomains must point directly to your {{< vendor/name >}} project. Otherwise, you get an error similar to: @@ -199,7 +199,7 @@ On the command line type `platform logs app` and `platform logs error`. ## Use ASCII for the domain -Platform.sh expects an ASCII representation of your domain. +{{< vendor/name >}} expects an ASCII representation of your domain. To use an internationalized domain name (IDN), convert it to ASCII. Use a tool such as the [conversion tool provided by Verisign](https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-conversion-tool/index.xhtml). diff --git a/sites/platform/src/environments/_index.md b/sites/platform/src/environments/_index.md index f1adf2619b..43bda30b6f 100644 --- a/sites/platform/src/environments/_index.md +++ b/sites/platform/src/environments/_index.md @@ -1,12 +1,12 @@ --- -title: "Manage Platform.sh environments" +title: "Manage {{< vendor/name >}} environments" weight: -75 layout: single sidebarTitle: Manage environments -description: Learn what environments on Platform.sh are and how to take advantage of them. +description: Learn what environments on {{< vendor/name >}} are and how to take advantage of them. --- -A Platform.sh environment contains one instance of an app (or [group of apps](../create-apps/multi-app/_index.md)) +A {{< vendor/name >}} environment contains one instance of an app (or [group of apps](../create-apps/multi-app/_index.md)) with all the services needed for it to run. Each project can include multiple environments, @@ -33,7 +33,7 @@ When you branch an environment, you might want to create exact replicas of it. In this case, each new environment inherits all of the data and services from its parent environment. This includes databases, network storage, queues, and routing configurations. -You can create Platform.sh environments on demand. +You can create {{< vendor/name >}} environments on demand. Each environment is tied to a Git branch. If you use a source integration, you can even have environments created automatically for your pull requests and branches. @@ -90,7 +90,7 @@ You can [change an environment's status](./deactivate-environment.md) at any tim ![Environment hierarchy](/images/management-console/environments.png "0.5") -In Platform.sh, your environments are organized in a hierarchy featuring parent and child environments. +In {{< vendor/name >}}, your environments are organized in a hierarchy featuring parent and child environments. When you [branch](../other/glossary.md#branch) an environment, the parent of the new environment is the environment it was created from. @@ -191,7 +191,7 @@ Staging Development environments are often used for a limited time and then abandoned. To prevent unnecessary consumption of resources, -Platform.sh automatically pauses development environments that haven't been redeployed in 14 days. +{{< vendor/name >}} automatically pauses development environments that haven't been redeployed in 14 days. {{< note >}} diff --git a/sites/platform/src/environments/backup.md b/sites/platform/src/environments/backup.md index c3a1773ea3..c8db42c207 100644 --- a/sites/platform/src/environments/backup.md +++ b/sites/platform/src/environments/backup.md @@ -18,14 +18,14 @@ Note that you can only create backups and restore active environments. To work with an [inactive environment](../other/glossary.md#inactive-environment), first activate it. -## How backup and restore works on Platform.sh +## How backup and restore works 1. As an [admin user](../administration/users.md), you can do a backup of your environment. This backup includes the complete data and code of the environment. All persistent data from all running [services](../add-services/_index.md) and any files stored on [mounts](../create-apps/app-reference.md#mounts) are included. - The backup is stored internally on Platform.sh. - That is, the backup can be applied to environments on Platform.sh, but it can't be downloaded. + The backup is stored internally on {{< vendor/name >}}. + That is, the backup can be applied to environments on {{< vendor/name >}}, but it can't be downloaded. If you need to download backups, instead [export your mount and service data](../tutorials/exporting.md)). 2. You restore your environment using the backup. @@ -34,7 +34,7 @@ first activate it. {{< note theme="warning" title="Warning" >}} - But Platform.sh doesn’t modify your Git repository. So by default, any further changes you make use the latest code in your repository. + But {{< vendor/name >}} doesn’t modify your Git repository. So by default, any further changes you make use the latest code in your repository. {{< /note >}} @@ -173,7 +173,7 @@ title=In the Console You can also automate the process of creating manual backups through [cron jobs](../create-apps/app-reference.md#crons). The cron job uses the CLI command to back up the environment. -It requires you to [set up the CLI on the environment with an API token](../administration/cli/api-tokens.md#authenticate-in-a-platformsh-environment). +It requires you to [set up the CLI on the environment with an API token](../administration/cli/api-tokens.md#authenticate-in-an-environment). Although this process is automated, backups created in this way count as manual for the [backup schedule](#backup-schedule). diff --git a/sites/platform/src/environments/default-environment.md b/sites/platform/src/environments/default-environment.md index 207ab055ff..0676799d08 100644 --- a/sites/platform/src/environments/default-environment.md +++ b/sites/platform/src/environments/default-environment.md @@ -30,7 +30,7 @@ To change the default branch, you need to be an [admin for the project](../admin The following steps depend of whether your project has a [source integration](../integrations/source/_index.md). -If it doesn't, Platform.sh is your primary remote repository for the project. +If it doesn't, {{< vendor/name >}} is your primary remote repository for the project. If it does, GitHub, GitLab, or BitBucket hosts your primary remote repository for the project. ## 1. Create a `main` environment @@ -63,7 +63,7 @@ git checkout -b main git push origin main ``` -Source integrations include all branches, but don't activate the corresponding environments in Platform.sh. +Source integrations include all branches, but don't activate the corresponding environments in {{< vendor/name >}}. Activate the `main` environment by running the following command: ```bash @@ -109,13 +109,13 @@ platform environment:info -e parent main title=With a source integration +++ -To preserve your data on Platform.sh, +To preserve your data on {{< vendor/name >}}, it's best to switch your work in progress to be based off of `main`. Close any open pull/merge requests and resubmit them against `main`. If you want to continue working on branches after switching the default branch, rebase them by running `git rebase --onto main `. -Once you resubmit a request, it appears under the `main` environment on Platform.sh. +Once you resubmit a request, it appears under the `main` environment on {{< vendor/name >}}. {{< /codetabs >}} @@ -146,7 +146,7 @@ platform project:info default_branch main title=With a source integration +++ -Once `old` has been deactivated, set the project's default branch in Platform.sh to `main`: +Once `old` has been deactivated, set the project's default branch in {{< vendor/name >}} to `main`: ```bash platform project:info default_branch main @@ -163,7 +163,7 @@ Follow the instructions to change the default branch to `main` for your provider ## 7. Update DNS records Whether or not you're using a CDN, -if your site is live you have probably added a Platform.sh address somewhere when configuring a [custom domain](../domains/steps/_index.md). +if your site is live you have probably added a {{< vendor/name >}} address somewhere when configuring a [custom domain](../domains/steps/_index.md). If you have a CDN, it's with the CDN provider. If you don't have a CDN, it's probably a `CNAME` record. diff --git a/sites/platform/src/environments/restore.md b/sites/platform/src/environments/restore.md index c04a5dad46..bc486f2aba 100644 --- a/sites/platform/src/environments/restore.md +++ b/sites/platform/src/environments/restore.md @@ -84,13 +84,13 @@ This deployment uses the built app, including variables, from when the backup wa {{< note theme="warning" title="Warning" >}} -The code is also initially restored, but Platform.sh doesn't modify your Git repository. +The code is also initially restored, but {{< vendor/name >}} doesn't modify your Git repository. So any future (re)deployments use the current Git repository to build the environment. To restore your code to its previous state when the backup was taken, use Git commands such as [revert](https://git-scm.com/docs/git-revert). -See [how backup and restore works on Platform.sh](../environments/backup.md#how-backup-and-restore-works-on-platformsh). +See [how backup and restore works on {{< vendor/name >}}](../environments/backup.md#how-backup-and-restore-works). {{< /note >}} diff --git a/sites/platform/src/environments/scalability.md b/sites/platform/src/environments/scalability.md index d9b6046b33..5673c79ad8 100644 --- a/sites/platform/src/environments/scalability.md +++ b/sites/platform/src/environments/scalability.md @@ -34,7 +34,7 @@ If these spikes are causing application errors, your site is automatically scaled up to the next largest size to handle the traffic. The process is initiated and run automatically and a support ticket is opened. -The upscaling process is then monitored by the Platform.sh team. +The upscaling process is then monitored by the {{< vendor/name >}} team. The team determines whether the upscaling is working as intended and is necessary or can be avoided by, for example, blocking a malicious bot. @@ -53,10 +53,10 @@ There are two classes of measurement that trigger an autoscaling event: {{< premium-features/tiered "Enterprise and Elite" >}} If your plan includes managed scaling, -Platform.sh proactively monitors your apps to make sure they don't have errors from overuse. +{{< vendor/name >}} proactively monitors your apps to make sure they don't have errors from overuse. If the monitoring determines a load is causing issues for your site, a support ticket is opened. -The Platform.sh team determines whether upscaling is necessary +The {{< vendor/name >}} team determines whether upscaling is necessary or can be avoided by, for example, blocking a malicious bot. If upscaling is necessary, it's handled for you and you're kept up to date in the support ticket. diff --git a/sites/platform/src/environments/search-engine-visibility.md b/sites/platform/src/environments/search-engine-visibility.md index 6e3f437a18..fdf84eb3d6 100644 --- a/sites/platform/src/environments/search-engine-visibility.md +++ b/sites/platform/src/environments/search-engine-visibility.md @@ -37,7 +37,7 @@ title=In the Console {{< /codetabs >}} -Platform.sh can't guarantee that indexers follow the instructions. +{{< vendor/name >}} can't guarantee that indexers follow the instructions. If you're concerned about access, set up [HTTP access control](./http-access-control.md). ## How it's done @@ -62,4 +62,4 @@ Your app can serve this as a static file from its disk or as a dynamic response Control either with the [`location` section of your app configuration](../create-apps/app-reference.md#locations). If your `robots.txt` file includes instructions to ignore a page, -search engine indexers may ignore it even if you have configured Platform.sh to not send the header. +search engine indexers may ignore it even if you have configured {{< vendor/name >}} to not send the header. diff --git a/sites/platform/src/get-started/_index.md b/sites/platform/src/get-started/_index.md index d43db3fa11..b0c01e94d0 100644 --- a/sites/platform/src/get-started/_index.md +++ b/sites/platform/src/get-started/_index.md @@ -2,5 +2,5 @@ title: Get started weight: -110 description: | - The easiest way to get started with Platform.sh is to try it out yourself. Follow this guide to see what's possible. + The easiest way to get started with {{< vendor/name >}} is to try it out yourself. Follow this guide to see what's possible. --- diff --git a/sites/platform/src/get-started/add-data/merge.md b/sites/platform/src/get-started/add-data/merge.md index 45d2d534a8..2396b5fb4c 100644 --- a/sites/platform/src/get-started/add-data/merge.md +++ b/sites/platform/src/get-started/add-data/merge.md @@ -9,7 +9,7 @@ Next, add a service to your development environment. ## Add a service -Platform.sh includes many services such as databases, cache, and search engines. +{{< vendor/name >}} includes many services such as databases, cache, and search engines. These are included in your project, so you can manage them with Git and back them up with your project. Add a database service (or choose [another service](../../add-services/_index.md)) by following these steps: diff --git a/sites/platform/src/get-started/deploy/commit.md b/sites/platform/src/get-started/deploy/commit.md index a37dec3355..761396cf16 100644 --- a/sites/platform/src/get-started/deploy/commit.md +++ b/sites/platform/src/get-started/deploy/commit.md @@ -1,7 +1,7 @@ --- title: Git commit weight: -9 -description: Start getting your project into Platform.sh. +description: Start getting your project into {{< vendor/name >}}. --- Once you have your project initialized, it's time to add the basics to get it deployed. @@ -27,7 +27,7 @@ Commit your changes (to save your changes): ```bash git add . -git commit -m "Add Platform.sh files" +git commit -m "Add {{< vendor/name >}} files" ``` Push your changes (to share your changes with everyone with access to your project/repository): diff --git a/sites/platform/src/get-started/deploy/init.md b/sites/platform/src/get-started/deploy/init.md index f3addec5f2..0678449de4 100644 --- a/sites/platform/src/get-started/deploy/init.md +++ b/sites/platform/src/get-started/deploy/init.md @@ -4,14 +4,14 @@ weight: -10 description: Initialize your project --- -The basic unit for organizing work within Platform.sh is a project. +The basic unit for organizing work within {{< vendor/name >}} is a project. Each project represents one Git repository, a centralized place to store code and work history. -For now, Platform.sh represents the source of truth for your repository. +For now, {{< vendor/name >}} represents the source of truth for your repository. You can later set up an integration with GitHub, Bitbucket, or GitLab. -To deploy your app, you need to connect its repository to a project in Platform.sh. +To deploy your app, you need to connect its repository to a project in {{< vendor/name >}}. -First, create a Platform.sh project by running the following command: +First, create a {{< vendor/name >}} project by running the following command: ```bash platform project:create @@ -32,7 +32,7 @@ Then go through each of the steps to create the project: 6. Choose a default branch. This defaults to `main`, but you can always [change it later](../../environments/default-environment.md). -A Git repository is automatically initialized and Platform.sh is set as a remote. +A Git repository is automatically initialized and {{< vendor/name >}} is set as a remote. Now your project is initialized and ready for you to make changes. diff --git a/sites/platform/src/get-started/introduction.md b/sites/platform/src/get-started/introduction.md index ed75b48e3c..0e8d4c5c0f 100644 --- a/sites/platform/src/get-started/introduction.md +++ b/sites/platform/src/get-started/introduction.md @@ -2,15 +2,15 @@ title: Introduction weight: -10 description: | - Get started with Platform.sh. Start by learning why you should be interested. + Get started with {{< vendor/name >}}. Start by learning why you should be interested. --- -Platform.sh is a cloud platform for responsibly building, running, and scaling fleets of websites and applications. +{{< vendor/name >}} is a cloud platform for responsibly building, running, and scaling fleets of websites and applications. It enables you to run your web apps in the cloud with productive and consistent development and testing workflows. You spend your time creating amazing experiences, not managing infrastructure. -Get started with Platform.sh by following this guide. +Get started with {{< vendor/name >}} by following this guide. ## Why @@ -18,11 +18,11 @@ The process of testing, deploying, and monitoring web applications (often groupe can be complicated. You want to scale your offerings while maintaining consistency and reliability across your applications. -Platform.sh simplifies your development workflows and helps you automate manual tasks across a fleet of websites. +{{< vendor/name >}} simplifies your development workflows and helps you automate manual tasks across a fleet of websites. You can create build images you can test and then deploy with confidence, knowing the changes work the same in production as they have in your development process. -See a more detailed overview of Platform.sh and how it can fit within your workflow in this video: +See a more detailed overview of {{< vendor/name >}} and how it can fit within your workflow in this video: {{< youtube ny2YeD6Qt3M >}} @@ -30,9 +30,9 @@ See a more detailed overview of Platform.sh and how it can fit within your workf You need a few things before you can start creating projects. -### A Platform.sh account +### An account -To get started, you need a Platform.sh account. +To get started, you need a {{< vendor/name >}} account. You can start with a free 30-day trial that should contain everything you need to complete this guide. If you don't have an account yet, [register for an account](https://auth.api.platform.sh/register). @@ -46,14 +46,14 @@ It enables you to use familiar developer tools to manage Continuous Deployment i Use the same version control system for your infrastructure as for your app development. You get a history of changes with an audit log. -Git is at the center of work with Platform.sh. +Git is at the center of work with {{< vendor/name >}}. That's why each step in this guide is connected to a common Git command. Make sure your computer has [Git installed](https://git-scm.com/downloads). ### CLI -To facilitate working with Platform.sh, you can use the Platform.sh command-line interface (CLI). +To facilitate working with {{< vendor/name >}}, you can use the {{< vendor/name >}} command-line interface (CLI). This lets you carry out various actions from a terminal. {{< cli-installation >}} @@ -61,11 +61,11 @@ This lets you carry out various actions from a terminal. ### Code To start a project, you should have code on your computer that you'd like to deploy. -It can be a basic "Hello World" site, such as you can find in the [Platform.sh demos](https://github.com/platformsh-demos). +It can be a basic "Hello World" site, such as you can find in the [{{< vendor/name >}} demos](https://github.com/platformsh-demos). Just something that you know runs. -An alternative is one of the [Platform.sh templates](../development/templates.md). -These are example apps that come with everything needed to run on Platform.sh. +An alternative is one of the [{{< vendor/name >}} templates](../development/templates.md). +These are example apps that come with everything needed to run on {{< vendor/name >}}. ## Choose your stack diff --git a/sites/platform/src/get-started/monitor-and-troubleshoot/log.md b/sites/platform/src/get-started/monitor-and-troubleshoot/log.md index 7960f05677..411c527e15 100644 --- a/sites/platform/src/get-started/monitor-and-troubleshoot/log.md +++ b/sites/platform/src/get-started/monitor-and-troubleshoot/log.md @@ -5,7 +5,7 @@ description: See what's happening inside your app. --- Once your app is up and running, you want to monitor it to make sure it stays that way. -Take advantage of the observability of apps running on Platform.sh to see everything that's happening. +Take advantage of the observability of apps running on {{< vendor/name >}} to see everything that's happening. ## Check activities @@ -57,7 +57,7 @@ For an interactive prompt with all available logs, run `platform log`. In addition to keeping track of events, you might want to see how your infrastructure responds to these events. For that, your project offers infrastructure metrics where you can see your CPU, RAM, and disk usage. -These metrics are available in the Platform.sh Console, +These metrics are available in the {{< vendor/name >}} Console, which is a web interface that offers similar options for interacting with your project as the CLI. Open the Console by running this command: diff --git a/sites/platform/src/get-started/monitor-and-troubleshoot/status.md b/sites/platform/src/get-started/monitor-and-troubleshoot/status.md index 72982b03c1..6bcde17d80 100644 --- a/sites/platform/src/get-started/monitor-and-troubleshoot/status.md +++ b/sites/platform/src/get-started/monitor-and-troubleshoot/status.md @@ -68,7 +68,7 @@ For now, focus on getting notified about activities. ## Get activity notifications Webhooks enable you to monitor events as they happen. -Platform.sh sends information about activities in your project to the URL you specify. +{{< vendor/name >}} sends information about activities in your project to the URL you specify. Say you want to get a notification any time your `main` environment gets new code or is redeployed. To see such a notification in action, follow these steps: @@ -97,8 +97,8 @@ You can also run the redeploy command for the `dev` environment and verify that ## What's next -Your Platform.sh project is now up and running and you can keep track of it! -That's a great start to working with Platform.sh. +Your {{< vendor/name >}} project is now up and running and you can keep track of it! +That's a great start to working with {{< vendor/name >}}. Now that you've mastered the basics, you can choose more advanced tasks to complete: @@ -109,4 +109,4 @@ Now that you've mastered the basics, you can choose more advanced tasks to compl - To maintain code in a third-party repository, integrate with [Bitbucket, GitHub, or GitLab](../../integrations/source/_index.md). - Read more on [health notifications](../../integrations/notifications.md). - See a reference on [all options available for activity notifications](../../integrations/activity/reference.md) or - use an [activity script](../../integrations/activity/_index.md) to manage activity responses in Platform.sh. + use an [activity script](../../integrations/activity/_index.md) to manage activity responses in {{< vendor/name >}}. diff --git a/sites/platform/src/guides/django/_index.md b/sites/platform/src/guides/django/_index.md index 8a59ce5071..f6df74f08b 100644 --- a/sites/platform/src/guides/django/_index.md +++ b/sites/platform/src/guides/django/_index.md @@ -3,17 +3,17 @@ title: "Django" weight: -200 sectionBefore: Python description: | - Everything you need to get started with [Django](https://www.djangoproject.com/), a Python framework for web development, on Platform.sh. + Everything you need to get started with [Django](https://www.djangoproject.com/), a Python framework for web development, on {{< vendor/name >}}. --- {{% description %}} Anything included in these guides applies to not only to Django, but also [Wagtail](https://wagtail.org/), the content management system built with Django. -See an example Django project in the official [Platform.sh Django template](https://github.com/platformsh-templates/django4), which you can use as a starting point for your own project. +See an example Django project in the official [{{< vendor/name >}} Django template](https://github.com/platformsh-templates/django4), which you can use as a starting point for your own project. If you already have a Django project ready to deploy, -see the template's [example Platform.sh files](https://github.com/platformsh-templates/django4/tree/master/.platform). +see the template's [example {{< vendor/name >}} files](https://github.com/platformsh-templates/django4/tree/master/.platform). These files let you [configure your app](../../create-apps/_index.md), [add services](../../add-services/_index.md), and [define routes](../../define-routes/_index.md). diff --git a/sites/platform/src/guides/django/deploy/_index.md b/sites/platform/src/guides/django/deploy/_index.md index ccab61f66b..5c1dbcd2d8 100644 --- a/sites/platform/src/guides/django/deploy/_index.md +++ b/sites/platform/src/guides/django/deploy/_index.md @@ -1,14 +1,14 @@ --- -title: Deploy Django on Platform.sh +title: Deploy Django on {{< vendor/name >}} sidebarTitle: Get started weight: -130 layout: single -description: See how to get started deploying Django on Platform.sh. +description: See how to get started deploying Django on {{< vendor/name >}}. --- Django is a web application framework written in Python with a built-in ORM (Object-Relational Mapper). -This guide provides instructions for deploying, and working with, Django on Platform.sh. +This guide provides instructions for deploying, and working with, Django on {{< vendor/name >}}. It includes examples for working with Django on all of the major package managers: pip, Pipenv, and Poetry. {{% guides/starting-point name="Django" templateRepo="django4" initExample=true %}} diff --git a/sites/platform/src/guides/django/deploy/configure.md b/sites/platform/src/guides/django/deploy/configure.md index cffbfe5121..cea02bf439 100644 --- a/sites/platform/src/guides/django/deploy/configure.md +++ b/sites/platform/src/guides/django/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Django for Platform.sh" +title: "Configure Django for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Django. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Django. --- {{% guides/config-desc name="Django" %}} diff --git a/sites/platform/src/guides/django/deploy/customize.md b/sites/platform/src/guides/django/deploy/customize.md index 5e15897420..d823b6f560 100644 --- a/sites/platform/src/guides/django/deploy/customize.md +++ b/sites/platform/src/guides/django/deploy/customize.md @@ -1,13 +1,13 @@ --- -title: "Customize Django for Platform.sh" +title: "Customize Django for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your Django site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your Django site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, -it's time to make your Django site itself ready to run on a Platform.sh environment. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, +it's time to make your Django site itself ready to run on a {{< vendor/name >}} environment. A number of additional steps are either required or recommended, depending on how much you want to optimize your site. ## Optional: Set up the Config Reader @@ -33,7 +33,7 @@ the most important of which are highlighted here to show where you could modify [`ALLOWED_HOSTS`](https://docs.djangoproject.com/en/4.1/ref/settings/#allowed-hosts) defines the host names that your Django site can serve. It's where you define `localhost` and also your site's primary domain. -On Platform.sh, every branch or pull request you create can become an active environment: +On {{< vendor/name >}}, every branch or pull request you create can become an active environment: a deployed site where you can test changes. The environment is given a URL that ends with `.platform.site`. To allow your site to serve these environment, add this suffix to `ALLOWED_HOSTS`. @@ -48,19 +48,19 @@ ALLOWED_HOSTS = [ ### Decoding variables -Platform.sh environment variables, which contain information on deployed environments, are often obscured. +{{< vendor/name >}} environment variables, which contain information on deployed environments, are often obscured. For example, `PLATFORM_RELATIONSHIPS`, which contains credentials to connect to services, is a base64-encoded JSON object. The example Django configuration file has a `decode` helper function to help with these variables. -Alternatively, you can use the [Platform.sh Config Reader](#optional-set-up-the-config-reader). +Alternatively, you can use the [{{< vendor/name >}} Config Reader](#optional-set-up-the-config-reader). ```py {location="settings.py"} ################################################################################# -# Platform.sh-specific configuration +# {{< vendor/name >}}h-specific configuration # Helper function for decoding base64-encoded JSON variables. def decode(variable): - """Decodes a Platform.sh environment variable. + """Decodes a {{< vendor/name >}} environment variable. Args: variable (string): Base64-encoded JSON (the content of an environment variable). @@ -78,7 +78,7 @@ def decode(variable): print('Error decoding JSON, code %d', json.decoder.JSONDecodeError) ``` -### Platform.sh overrides +### Handling overrides Once you have a [way to decode variables](#decoding-variables), you can use them to override settings based on the environment. @@ -90,13 +90,13 @@ a PostgreSQL database. # configured in .platform.app.yaml. PLATFORMSH_DB_RELATIONSHIP="database" -# Import some Platform.sh settings from the environment. -# The following block is only applied within Platform.sh environments -# That is, only when this Platform.sh variable is defined +# Import some {{< vendor/name >}} settings from the environment. +# The following block is only applied within {{< vendor/name >}} environments +# That is, only when this {{< vendor/name >}} variable is defined if (os.getenv('PLATFORM_APPLICATION_NAME') is not None): DEBUG = False - # Redefine the static root based on the Platform.sh directory + # Redefine the static root based on the {{< vendor/name >}} directory # See https://docs.djangoproject.com/en/4.1/ref/settings/#static-root if (os.getenv('PLATFORM_APP_DIR') is not None): STATIC_ROOT = os.path.join(os.getenv('PLATFORM_APP_DIR'), 'static') @@ -128,8 +128,8 @@ if (os.getenv('PLATFORM_APPLICATION_NAME') is not None): } ``` -As noted in comments in the example, services on Platform.sh (like PostgreSQL) aren't yet available during the build. -This it enables the environment-independent builds that make the Platform.sh inheritance model possible. +As noted in comments in the example, services on {{< vendor/name >}} (like PostgreSQL) aren't yet available during the build. +This it enables the environment-independent builds that make the {{< vendor/name >}} inheritance model possible. For this reason, when defining a service connection, you need to overwrite the settings during the deploy phase. You can determine the deploy phase using the `PLATFORM_ENVIRONMENT` variable, which is only available at deploy time. diff --git a/sites/platform/src/guides/django/deploy/deploy.md b/sites/platform/src/guides/django/deploy/deploy.md index 139d5d33f4..4d4664520c 100644 --- a/sites/platform/src/guides/django/deploy/deploy.md +++ b/sites/platform/src/guides/django/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Django" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/django/deploy/next-steps.md b/sites/platform/src/guides/django/deploy/next-steps.md index 66454a4ad5..d6c55ab0a6 100644 --- a/sites/platform/src/guides/django/deploy/next-steps.md +++ b/sites/platform/src/guides/django/deploy/next-steps.md @@ -8,7 +8,7 @@ description: | ## Local development -Once Django has been deployed on Platform.sh, you need to set up a local development environment to begin making revisions. +Once Django has been deployed on {{< vendor/name >}}, you need to set up a local development environment to begin making revisions. For more information, consult the [Django local development guides](../local/_index.md). ## Package management diff --git a/sites/platform/src/guides/django/local/_index.md b/sites/platform/src/guides/django/local/_index.md index 814aa7c384..04ae69b19e 100644 --- a/sites/platform/src/guides/django/local/_index.md +++ b/sites/platform/src/guides/django/local/_index.md @@ -2,18 +2,18 @@ title: Local development weight: -110 description: | - Sync Platform.sh with your local environments to start contributing. + Sync {{< vendor/name >}} with your local environments to start contributing. --- -A significant amount of work developing Django takes place locally rather than on an active Platform.sh environment. +A significant amount of work developing Django takes place locally rather than on an active {{< vendor/name >}} environment. You want to ensure that the process of local development is as close as possible to a deployed environment. You can achieve this through various approaches. Each of these examples: - Creates a local development environment for a Django site. -- Syncs data from the active Platform.sh environment where team review takes place. +- Syncs data from the active {{< vendor/name >}} environment where team review takes place. - Commits aspects of that local development method to the project so collaborators can replicate configuration to contribute. If you're already using Docker Compose, -consult the Community guide on [using Docker Compose with Django and Platform.sh](https://community.platform.sh/t/using-docker-compose-with-django/1205). +consult the Community guide on [using Docker Compose with Django and {{< vendor/name >}}](https://community.platform.sh/t/using-docker-compose-with-django/1205). diff --git a/sites/platform/src/guides/django/local/ddev.md b/sites/platform/src/guides/django/local/ddev.md index 98de899825..a8e3c57022 100644 --- a/sites/platform/src/guides/django/local/ddev.md +++ b/sites/platform/src/guides/django/local/ddev.md @@ -3,7 +3,7 @@ title: DDEV weight: -110 layout: single description: | - Set up an environment with Platform.sh's recommended local development tool, DDEV. + Set up an environment with {{< vendor/name >}}'s recommended local development tool, DDEV. sectionBefore: Integrated environments --- @@ -51,7 +51,7 @@ sectionBefore: Integrated environments 6. Update the DDEV PHP version. - Python support in DDEV and the Platform.sh integration is in active development. + Python support in DDEV and the {{< vendor/name >}} integration is in active development. At this time, the only officially supported runtime is PHP. With a few changes, the generated configuration can be modified to run local Django environments. @@ -78,7 +78,7 @@ title=Pip hooks: post-start: ... - # Platform.sh start command + # {{< vendor/name >}} start command - exec: python manage.py runserver 0.0.0.0:8000 ``` <---> @@ -89,7 +89,7 @@ title=Pipenv hooks: post-start: ... - # Platform.sh start command + # {{< vendor/name >}} start command - exec: pipenv run python manage.py runserver 0.0.0.0:8000 ``` <---> @@ -100,7 +100,7 @@ title=Poetry hooks: post-start: ... - # Platform.sh start command + # {{< vendor/name >}} start command - exec: poetry run python manage.py runserver 0.0.0.0:8000 ``` {{< /codetabs >}} @@ -177,7 +177,7 @@ hooks: 13. Pull data from the environment. Exit the currently running process (`CTRL+C`) - and then run the following command to retrieve data from the current Platform.sh environment: + and then run the following command to retrieve data from the current {{< vendor/name >}} environment: ```bash ddev pull platform @@ -189,7 +189,7 @@ hooks: ddev restart ``` - You now have a local development environment that's in sync with the `new-feature` environment on Platform.sh. + You now have a local development environment that's in sync with the `new-feature` environment on {{< vendor/name >}}. 15. When you finish your work, shut down DDEV. diff --git a/sites/platform/src/guides/django/local/tethered.md b/sites/platform/src/guides/django/local/tethered.md index b1559882c2..d2ce7ffce8 100644 --- a/sites/platform/src/guides/django/local/tethered.md +++ b/sites/platform/src/guides/django/local/tethered.md @@ -1,7 +1,7 @@ --- title: Tethered local weight: -90 -description: Connect a locally running Django server directly to active services on a Platform.sh environment. +description: Connect a locally running Django server directly to active services on a {{< vendor/name >}} environment. sectionBefore: Supported environments --- @@ -10,7 +10,7 @@ sectionBefore: Supported environments {{< /note >}} To test changes locally, you can connect your locally running Django server -to service containers on an active Platform.sh environment. +to service containers on an active {{< vendor/name >}} environment. {{% guides/local-requirements framework="Django" %}} @@ -18,16 +18,16 @@ to service containers on an active Platform.sh environment. If you followed the [Django deployment guide](../deploy/_index.md), you should have a Django configuration file with settings for [decoding variables](../deploy/customize.md#decoding-variables) -and also [overrides for Platform.sh](../deploy/customize.md#decoding-variables). +and also [overrides for {{< vendor/name >}}](../deploy/customize.md#decoding-variables). -You can use these settings to set up a tethered connection to services running on a Platform.sh environment. +You can use these settings to set up a tethered connection to services running on a {{< vendor/name >}} environment. The settings are used to mock the conditions of the environment locally. ## Create the tethered connection {{% tethered-dev/steps-start %}} -1. To ensure your `settings.py` file acts as if in a Platform.sh environment, +1. To ensure your `settings.py` file acts as if in a {{< vendor/name >}} environment, mock two variables present in active environments: ```bash diff --git a/sites/platform/src/guides/drupal9/_index.md b/sites/platform/src/guides/drupal9/_index.md index 6ed80c4c02..7e3ffed5b3 100644 --- a/sites/platform/src/guides/drupal9/_index.md +++ b/sites/platform/src/guides/drupal9/_index.md @@ -3,10 +3,10 @@ title: "Drupal" weight: -180 sectionBefore: PHP description: | - Everything you need to get started with Drupal on Platform.sh. + Everything you need to get started with Drupal on {{< vendor/name >}}. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- {{% description %}} diff --git a/sites/platform/src/guides/drupal9/deploy/_index.md b/sites/platform/src/guides/drupal9/deploy/_index.md index 0ef249c9ca..31a7a83532 100644 --- a/sites/platform/src/guides/drupal9/deploy/_index.md +++ b/sites/platform/src/guides/drupal9/deploy/_index.md @@ -1,16 +1,16 @@ --- -title: Deploy Drupal 9 on Platform.sh +title: Deploy Drupal 9 on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Drupal. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Drupal. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- -Drupal is a flexible and extensible PHP-based CMS framework. To deploy Drupal 9 on Platform.sh, the recommended way is to use Composer, the PHP package management suite. +Drupal is a flexible and extensible PHP-based CMS framework. To deploy Drupal 9 on {{< vendor/name >}}, the recommended way is to use Composer, the PHP package management suite. This guide assumes you are using the well-supported Composer flavor of Drupal 9. diff --git a/sites/platform/src/guides/drupal9/deploy/configure.md b/sites/platform/src/guides/drupal9/deploy/configure.md index 4c0f0595d3..444bc0d4b8 100644 --- a/sites/platform/src/guides/drupal9/deploy/configure.md +++ b/sites/platform/src/guides/drupal9/deploy/configure.md @@ -1,12 +1,12 @@ --- -title: "Configure Drupal 9 for Platform.sh" +title: "Configure Drupal 9 for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Drupal. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Drupal. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- {{% guides/config-desc name="Drupal 9" %}} diff --git a/sites/platform/src/guides/drupal9/deploy/customize.md b/sites/platform/src/guides/drupal9/deploy/customize.md index 877a8672f9..27aa4a54df 100644 --- a/sites/platform/src/guides/drupal9/deploy/customize.md +++ b/sites/platform/src/guides/drupal9/deploy/customize.md @@ -1,16 +1,16 @@ --- -title: "Customize Drupal 9 for Platform.sh" +title: "Customize Drupal 9 for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your Drupal site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your Drupal site to read from a {{< vendor/name >}} environment. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- -Now that your code contains all of the configuration to deploy on Platform.sh, -it's time to make your Drupal site itself ready to run on a Platform.sh environment. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, +it's time to make your Drupal site itself ready to run on a {{< vendor/name >}} environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. ## Install the Config Reader @@ -30,7 +30,7 @@ It contains configuration that's specific to your local development environment, such as a local development database. The `settings.platformsh.php` file contains glue code that configures Drupal -based on the information available in Platform.sh's environment variables. +based on the information available in {{< vendor/name >}}'s environment variables. That includes the database credentials, Redis caching, and file system paths. The file itself is a bit long, but reasonably self-explanatory. @@ -42,7 +42,7 @@ you would add configuration for those services to the `settings.platformsh.php` ## `.environment` -Platform.sh runs `source .environment` in the [app root](../../../create-apps/app-reference.md#root-directory) +{{< vendor/name >}} runs `source .environment` in the [app root](../../../create-apps/app-reference.md#root-directory) when a project starts, before cron commands are run, and when you log into an environment over SSH. That gives you a place to do extra environment variable setup before the app runs, including modifying the system `$PATH` and other shell level customizations. @@ -69,7 +69,7 @@ Drush requires a YAML file that declares what its URL is. That value varies depending on the branch you're on, so it can't be included in a static file. Instead, the `drush` directory includes a [short script](https://github.com/platformsh-templates/drupal9/blob/master/drush/platformsh_generate_drush_yml.php) that generates that file on each deploy, writing it to `.drush/drush.yml`. -That allows Drush to run successfully on Platform.sh, such as to run cron tasks. +That allows Drush to run successfully on {{< vendor/name >}}, such as to run cron tasks. The script contents aren't especially interesting. For the most part, you can download it from the template, diff --git a/sites/platform/src/guides/drupal9/deploy/deploy.md b/sites/platform/src/guides/drupal9/deploy/deploy.md index d7a26de28d..21b695f8f2 100644 --- a/sites/platform/src/guides/drupal9/deploy/deploy.md +++ b/sites/platform/src/guides/drupal9/deploy/deploy.md @@ -3,10 +3,10 @@ title: "Deploy Drupal 9" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- ## Deployment @@ -28,7 +28,7 @@ Drupal has a number of database tables that are useless when migrating and you're better off excluding their data. * If you're using a database cache backend then you can and should exclude all `cache_*` table data. - On Platform.sh we recommend using Redis anyway, + On {{< vendor/name >}} we recommend using Redis anyway, and the template described on the previous pages uses Redis automatically. * The `sessions` table's data can also be excluded. diff --git a/sites/platform/src/guides/drupal9/deploy/next-steps.md b/sites/platform/src/guides/drupal9/deploy/next-steps.md index 09af654cce..5df7a0296e 100644 --- a/sites/platform/src/guides/drupal9/deploy/next-steps.md +++ b/sites/platform/src/guides/drupal9/deploy/next-steps.md @@ -6,7 +6,7 @@ description: | Upgrading, adding modules, and further development of your site. banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- ## Adding modules and themes @@ -60,7 +60,7 @@ All updates should be done through composer to update the lock file, and then pu [Drush site aliases](https://www.drush.org/latest/site-aliases/) help you manage your development websites. -The Platform.sh CLI can generate Drush aliases for you automatically +The {{< vendor/name >}} CLI can generate Drush aliases for you automatically when you clone a project using the platform get {{< variable "PROJECT_ID" >}} command. To see the aliases that are created, run the following command: diff --git a/sites/platform/src/guides/drupal9/memcached.md b/sites/platform/src/guides/drupal9/memcached.md index 14ed348f03..962e992c70 100644 --- a/sites/platform/src/guides/drupal9/memcached.md +++ b/sites/platform/src/guides/drupal9/memcached.md @@ -6,7 +6,7 @@ description: | weight: -90 --- -Platform.sh recommends using Redis for caching with Drupal over Memcached, +{{< vendor/name >}} recommends using Redis for caching with Drupal over Memcached, as Redis offers better performance when dealing with larger values as Drupal tends to produce. But Memcached is also available if desired and is fully supported. diff --git a/sites/platform/src/guides/drupal9/multi-site.md b/sites/platform/src/guides/drupal9/multi-site.md index 3e04599fa2..e512531ff7 100644 --- a/sites/platform/src/guides/drupal9/multi-site.md +++ b/sites/platform/src/guides/drupal9/multi-site.md @@ -3,20 +3,20 @@ title: "Multiple Drupal sites in a single Project" sidebarTitle: "Multi-site" toc: false description: | - Platform.sh supports running [multiple applications](/bestpractices/oneormany.md) in the same project, and these can be two or more Drupal sites. + {{< vendor/name >}} supports running [multiple applications](/bestpractices/oneormany.md) in the same project, and these can be two or more Drupal sites. weight: -80 banner: title: A note on version - body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a Platform.sh [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. + body: While this guide focuses on Drupal 9, you can also refer to it when using Drupal 10 as differences in settings are minimal. Note that a {{< vendor/name >}} [Drupal 10 template](https://github.com/platformsh-templates/drupal10) is available. --- {{% description %}} But they would be separate Drupal instances: they have their assets separate and live their lives apart, and it would be much better for them not to share the same database (though they could). -## Multisite Drupal and Platform.sh +## Multisite Drupal -Platform.sh actively discourages running Drupal in "multisite" mode. Doing so eliminates many of the advantages Platform.sh offers, such as isolation and safe testing. +{{< vendor/name >}} actively discourages running Drupal in "multisite" mode. Doing so eliminates many of the advantages {{< vendor/name >}} offers, such as isolation and safe testing. Additionally, because of the dynamic nature of the domain names that are created for the different environments, the multisite configuration would be complex and fragile. We recommend running separate projects for separate Drupal sites, or using one of the various "single instance" options available such as [Domain Access](https://www.drupal.org/project/domain), [Organic Groups](https://www.drupal.org/project/og), or [Workbench Access](https://www.drupal.org/project/workbench_access). diff --git a/sites/platform/src/guides/drupal9/redis.md b/sites/platform/src/guides/drupal9/redis.md index af3329bb61..87e5b79225 100644 --- a/sites/platform/src/guides/drupal9/redis.md +++ b/sites/platform/src/guides/drupal9/redis.md @@ -13,14 +13,14 @@ or the [official Redis documentation](https://redis.io/docs/). Follow the instructions on this page to do one of the following: - Add and configure Redis for Drupal 9.x if you have deployed Drupal manually. -- Fine-tune your existing configuration if you have deployed Drupal 9 using a [Platform.sh template](../../development/templates.md). +- Fine-tune your existing configuration if you have deployed Drupal 9 using a [{{< vendor/name >}} template](../../development/templates.md). ## Before you begin You need: -- A [Drupal 9 version deployed on Platform.sh](../drupal9/deploy/_index.md) -- The [Platform.sh CLI](../../administration/cli/) +- A [Drupal 9 version deployed on {{< vendor/name >}}](../drupal9/deploy/_index.md) +- The [{{< vendor/name >}} CLI](../../administration/cli/) - [Composer](https://getcomposer.org/) - The [Config Reader library](../../guides/drupal9/deploy/customize.md#install-the-config-reader) @@ -34,7 +34,7 @@ This means that the Redis storage isn't persistent and that data can be lost when a container is moved, shut down or when the service hits its memory limit. -To solve this, Platform.sh recommends that you change the [service type](../../add-services/redis.md#service-types) +To solve this, {{< vendor/name >}} recommends that you change the [service type](../../add-services/redis.md#service-types) to [persistent Redis](../../add-services/redis.md#persistent-redis) (`redis-persistent`). {{< /note >}} diff --git a/sites/platform/src/guides/drupal9/simplesaml.md b/sites/platform/src/guides/drupal9/simplesaml.md index 254ca7a9c2..30a8e1b1d0 100644 --- a/sites/platform/src/guides/drupal9/simplesaml.md +++ b/sites/platform/src/guides/drupal9/simplesaml.md @@ -5,7 +5,7 @@ description: | weight: -60 banner: title: A note on versions - body: This page focuses on a Drupal 9 and SimpleSAML 1.19.x combination. Documentation for later SimpleSAML versions (2.0.x) has been delayed due to compatibility issues. If, as a Platform.sh user, you have successfully set up Drupal 9 or 10 with a SimpleSAML 2.0.x version, [we want to hear about it!](https://community.platform.sh/) + body: This page focuses on a Drupal 9 and SimpleSAML 1.19.x combination. Documentation for later SimpleSAML versions (2.0.x) has been delayed due to compatibility issues. If, as a {{< vendor/name >}} user, you have successfully set up Drupal 9 or 10 with a SimpleSAML 2.0.x version, [we want to hear about it!](https://community.platform.sh/) --- SimpleSAMLphp is a library for authenticating a PHP-based application against a SAML server, such as Shibboleth. @@ -88,7 +88,7 @@ Commit the whole `simplesamplphp` directory and `.platform.app.yaml` to Git. ## Configure SimpleSAML to use the database SimpleSAMLphp is able to store its data either on disk or in the Drupal database. -Platform.sh strongly recommends using the database. +{{< vendor/name >}} strongly recommends using the database. Open the file `simplesamlphp/config/config.php` that you created earlier. It contains a number of configuration properties that you can adjust as needed. @@ -104,7 +104,7 @@ In the interest of simplicity we recommend pasting the following code snippet at ```php {location="simplesamlphp/config/config.php"} }}will // be mapped to the /var/log/app.log file. $config['logging.handler'] = 'errorlog'; @@ -138,7 +138,7 @@ if (isset($_ENV['PLATFORM_RELATIONSHIPS'])) { } } -// Set the salt value from the Platform.sh entropy value, provided for this purpose. +// Set the salt value from the {{< vendor/name >}} entropy value, provided for this purpose. if (isset($_ENV['PLATFORM_PROJECT_ENTROPY'])) { $config['secretsalt'] = $_ENV['PLATFORM_PROJECT_ENTROPY']; } diff --git a/sites/platform/src/guides/drupal9/solr.md b/sites/platform/src/guides/drupal9/solr.md index 3af45a8354..b46c9f1984 100644 --- a/sites/platform/src/guides/drupal9/solr.md +++ b/sites/platform/src/guides/drupal9/solr.md @@ -77,7 +77,7 @@ And then commit the changes to `composer.json` and `composer.lock`. ### 4. Add auto-configuration code to `settings.platformsh.php` The configuration can be managed from `settings.platformsh.php` by adding the following code snippet. -It will override the environment-specific parts of the configuration object with the correct values to connect to the Platform.sh Solr instance. +It will override the environment-specific parts of the configuration object with the correct values to connect to the {{< vendor/name >}} Solr instance. {{< note >}} If you don't already have the [Config Reader library](../../development/variables/use-variables.md#access-variables-in-your-app) installed and referenced at the top of the file, you need to install it with `composer require platformsh/config-reader` and then add the following code before the block below: diff --git a/sites/platform/src/guides/gatsby/_index.md b/sites/platform/src/guides/gatsby/_index.md index d5cf5be1b4..ebfb6ce770 100644 --- a/sites/platform/src/guides/gatsby/_index.md +++ b/sites/platform/src/guides/gatsby/_index.md @@ -3,7 +3,7 @@ title: "Gatsby" weight: -90 sectionBefore: Javascript/Node.js description: | - Everything you need to get started with [Gatsby](https://www.gatsbyjs.com/), the open source framework based on React, on Platform.sh. + Everything you need to get started with [Gatsby](https://www.gatsbyjs.com/), the open source framework based on React, on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/gatsby/deploy/_index.md b/sites/platform/src/guides/gatsby/deploy/_index.md index db6718ee43..77a7deeb91 100644 --- a/sites/platform/src/guides/gatsby/deploy/_index.md +++ b/sites/platform/src/guides/gatsby/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Gatsby on Platform.sh +title: Deploy Gatsby on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Gatsby. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Gatsby. --- [Gatsby](https://www.gatsbyjs.com/) is an open source framework based on React that specializes in generating static websites from a variety of content sources. diff --git a/sites/platform/src/guides/gatsby/deploy/configure.md b/sites/platform/src/guides/gatsby/deploy/configure.md index af8ec637f2..bb4d25b4c4 100644 --- a/sites/platform/src/guides/gatsby/deploy/configure.md +++ b/sites/platform/src/guides/gatsby/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Gatsby for Platform.sh" +title: "Configure Gatsby for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Gatsby. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Gatsby. --- {{% guides/config-desc name="Gatsby" noService=true %}} @@ -14,7 +14,7 @@ In the template, `yarn` is run during the build hook to install all of Gatsby's - delete `yarn` from the build hook - update `yarn build` to `npm run build` in the build hook -- delete the `build.flavor` block, which tells Platform.sh to rely solely on the build hook to define the build process for your project when set to `none`. By default, Node.js containers run `npm install` prior to the build hook, so this block can be removed entirely from the configuration. +- delete the `build.flavor` block, which tells {{< vendor/name >}} to rely solely on the build hook to define the build process for your project when set to `none`. By default, Node.js containers run `npm install` prior to the build hook, so this block can be removed entirely from the configuration. - delete the `dependencies` block, which includes `yarn`, since it is no longer needed. All traffic is then directed to the `public` subdirectory once the deployment has completed via the `web.locations` section. diff --git a/sites/platform/src/guides/gatsby/deploy/deploy.md b/sites/platform/src/guides/gatsby/deploy/deploy.md index f61ffc0739..b0c14646c1 100644 --- a/sites/platform/src/guides/gatsby/deploy/deploy.md +++ b/sites/platform/src/guides/gatsby/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Gatsby" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- ## Deployment @@ -12,7 +12,7 @@ description: | ## Additional changes -A standard Gatsby site - either one created interactively through npm (`npm init gatsby`) or through a starter such as the [Blog starter](https://github.com/gatsbyjs/gatsby-starter-blog) used in the Platform.sh template - will generate a static site without the use of any external services. If this is your starting point you have all of the configuration necessary to deploy your project, but below are a few modifications that may help you develop your site more efficiently going forward. +A standard Gatsby site - either one created interactively through npm (`npm init gatsby`) or through a starter such as the [Blog starter](https://github.com/gatsbyjs/gatsby-starter-blog) used in the {{< vendor/name >}} template - will generate a static site without the use of any external services. If this is your starting point you have all of the configuration necessary to deploy your project, but below are a few modifications that may help you develop your site more efficiently going forward. ### Install the Config Reader diff --git a/sites/platform/src/guides/gatsby/deploy/next-steps.md b/sites/platform/src/guides/gatsby/deploy/next-steps.md index 0763c5384d..d0c2e56653 100644 --- a/sites/platform/src/guides/gatsby/deploy/next-steps.md +++ b/sites/platform/src/guides/gatsby/deploy/next-steps.md @@ -6,11 +6,11 @@ description: | A collection of resources for the further development of your Gatsby site. --- -Platform.sh supports [multi-app configuration](../../../create-apps/multi-app/_index.md) on projects - that is, including code for two separate sites that are deployed on their own containers within a single project cluster. +{{< vendor/name >}} supports [multi-app configuration](../../../create-apps/multi-app/_index.md) on projects - that is, including code for two separate sites that are deployed on their own containers within a single project cluster. These days, an increasingly common pattern is to decouple content resources from a frontend Gatsby site. Decoupled sites use Gatsby's source plugin ecosystem to pull external content resources into the build, where those resources (a headless CMS, for example) are typically located on a server elsewhere. -Platform.sh's multi-app configuration gets around this, placing both frontend and backend sites on the same server by keeping the code for both sites in the same repository. Gatsby would reside in a subdirectory alongside another that contains the code for the backend resource. For example, a Gatsby site pulling content from a Drupal site could be kept in a single repository that looks like the snippet below: +{{< vendor/name >}}'s multi-app configuration gets around this, placing both frontend and backend sites on the same server by keeping the code for both sites in the same repository. Gatsby would reside in a subdirectory alongside another that contains the code for the backend resource. For example, a Gatsby site pulling content from a Drupal site could be kept in a single repository that looks like the snippet below: ```bash . diff --git a/sites/platform/src/guides/gatsby/headless/_index.md b/sites/platform/src/guides/gatsby/headless/_index.md index 9fe71b46c2..0bd88b121a 100644 --- a/sites/platform/src/guides/gatsby/headless/_index.md +++ b/sites/platform/src/guides/gatsby/headless/_index.md @@ -2,7 +2,7 @@ title: "Gatsby multi-app projects" sidebarTitle: "Headless CMS" description: | - You can use Platform.sh's multi-app configuration to deploy Gatsby alongside a backend CMS, pulling content into Gatsby during builds. + You can use {{< vendor/name >}}'s multi-app configuration to deploy Gatsby alongside a backend CMS, pulling content into Gatsby during builds. weight: -100 toc: true --- @@ -13,7 +13,7 @@ A common pattern for Gatsby sites is to decouple services from the main site, pu The location of an external CMS is usually hard coded into Gatsby's configuration, so when you're developing your site every branch points to the same backend resource. Should the location of that resource change, you would need to commit the new URL to update the configuration. -The decoupled pattern can work differently on Platform.sh due to support for [multi-app configuration](../../../create-apps/multi-app/_index.md) on your projects. Consider the following project structure: +The decoupled pattern can work differently on {{< vendor/name >}} due to support for [multi-app configuration](../../../create-apps/multi-app/_index.md) on your projects. Consider the following project structure: ```bash . @@ -29,30 +29,30 @@ The decoupled pattern can work differently on Platform.sh due to support for [mu └── README.md ``` -Above is the repository structure for a Decoupled Drupal (Gatsby sourcing Drupal content) project on Platform.sh. Here, Gatsby and Drupal reside in their own subdirectories within the same repository. They are deployed to the same project from separate application containers, and from this cluster Gatsby can read data from Drupal internally. Their commit histories are tied together, such that each new pull request environment can test changes to either the frontend or backend freely from the same place. +Above is the repository structure for a Decoupled Drupal (Gatsby sourcing Drupal content) project on {{< vendor/name >}}. Here, Gatsby and Drupal reside in their own subdirectories within the same repository. They are deployed to the same project from separate application containers, and from this cluster Gatsby can read data from Drupal internally. Their commit histories are tied together, such that each new pull request environment can test changes to either the frontend or backend freely from the same place. -Drupal is just one example of a backend CMS that can be used with this pattern, and at the bottom of this page are a few additional guides for alternatives that work well on Platform.sh. +Drupal is just one example of a backend CMS that can be used with this pattern, and at the bottom of this page are a few additional guides for alternatives that work well on {{< vendor/name >}}. {{% guides/requirements %}} -## Signing up for Platform.sh +## Signing up -In each of the backend guides below, there is a "Deploy on Platform.sh" button that will not only deploy the guide's project for you, but also sign you up for a trial account. If you are planning on deploying a template and following along with these guides for greater context, feel free to move onto the next section. +In each of the backend guides below, there is a "Deploy on {{< vendor/name >}}" button that will not only deploy the guide's project for you, but also sign you up for a trial account. If you are planning on deploying a template and following along with these guides for greater context, feel free to move onto the next section. -If however you are planning on using the templates and guides to deploy your existing codebase to Platform.sh, -you first need to [register for a trial Platform.sh account](https://auth.api.platform.sh/register). +If however you are planning on using the templates and guides to deploy your existing codebase to {{< vendor/name >}}, +you first need to [register for a trial {{< vendor/name >}} account](https://auth.api.platform.sh/register). If you don't want to sign up initially with your e-mail address, you can sign up using an existing GitHub, Bitbucket, or Google account. -If you choose one of these options, you can set a password for your Platform.sh account later. +If you choose one of these options, you can set a password for your {{< vendor/name >}} account later. After creating an account, you are prompted to create your first project. Since you're providing your own code, use the "Blank project" option. You can give the project a title and choose a region closest to the visitors of your site. You also have the option to select more resources for your project. This is especially important with multi-application projects, so make sure to consult the [**Plan size**](#plan-size) note below for more details. ## Plan size -There are a few important points you need to keep in mind when deploying this pattern if you have already [deployed Gatsby by itself](/guides/gatsby/deploy/_index.md) on Platform.sh, which are relevant to each backend example. After following the steps below, you may find that Gatsby fails to bundle assets during its build on projects of the "Development" plan size. This is a factor of both the size and number of Gatsby's dependencies on the frontend, as well as the amount of data being pulled from the backend. +There are a few important points you need to keep in mind when deploying this pattern if you have already [deployed Gatsby by itself](/guides/gatsby/deploy/_index.md) on {{< vendor/name >}}, which are relevant to each backend example. After following the steps below, you may find that Gatsby fails to bundle assets during its build on projects of the "Development" plan size. This is a factor of both the size and number of Gatsby's dependencies on the frontend, as well as the amount of data being pulled from the backend. -Multi-application projects generally require more resources to run on Platform.sh, and so the trial's default `development` plan may not be enough to run your existing site. You are free to either proceed with a smaller plan to test or increase the resources at this point for the project. Otherwise, it may be best to initially deploy the templates listed in each backend guide to start out, and later modify that project to include your own code with more resources as you get used to developing on Platform.sh. +Multi-application projects generally require more resources to run on {{< vendor/name >}}, and so the trial's default `development` plan may not be enough to run your existing site. You are free to either proceed with a smaller plan to test or increase the resources at this point for the project. Otherwise, it may be best to initially deploy the templates listed in each backend guide to start out, and later modify that project to include your own code with more resources as you get used to developing on {{< vendor/name >}}. ## Headless backends -Platform.sh maintains a number of [multi-application templates](https://github.com/platformsh-templates/?q=gatsby&type=&language=) for Gatsby, that generally have very similar configuration changes on the Gatsby side. Below are a few of those written as short guides for different backend content management systems. +{{< vendor/name >}} maintains a number of [multi-application templates](https://github.com/platformsh-templates/?q=gatsby&type=&language=) for Gatsby, that generally have very similar configuration changes on the Gatsby side. Below are a few of those written as short guides for different backend content management systems. diff --git a/sites/platform/src/guides/gatsby/headless/drupal.md b/sites/platform/src/guides/gatsby/headless/drupal.md index b568e608a3..5ebac188ff 100644 --- a/sites/platform/src/guides/gatsby/headless/drupal.md +++ b/sites/platform/src/guides/gatsby/headless/drupal.md @@ -1,5 +1,5 @@ --- -title: "How to deploy Gatsby with Drupal (Decoupled Drupal) on Platform.sh" +title: "How to deploy Gatsby with Drupal (Decoupled Drupal) on {{< vendor/name >}}" sidebarTitle: "Drupal" description: | Drupal's JSON API module can be used as a data source for Gatsby via `gatsby-source-drupal`. @@ -7,7 +7,7 @@ description: | {{< guides/gatsby/headless-intro template="gatsby-drupal" name="Drupal" >}} -## Shared Platform.sh configuration +## Shared configuration {{% guides/gatsby/headless-project name="Drupal" %}} diff --git a/sites/platform/src/guides/gatsby/headless/strapi.md b/sites/platform/src/guides/gatsby/headless/strapi.md index 133b41e6f6..0ab46b4a5c 100644 --- a/sites/platform/src/guides/gatsby/headless/strapi.md +++ b/sites/platform/src/guides/gatsby/headless/strapi.md @@ -1,5 +1,5 @@ --- -title: "How to deploy Gatsby with Strapi on Platform.sh" +title: "How to deploy Gatsby with Strapi on {{< vendor/name >}}" sidebarTitle: "Strapi" description: | You can build out an API from scratch with Strapi, and then connect its data to a frontend Gatsby app with `gatsby-source-strapi`. @@ -7,7 +7,7 @@ description: | {{< guides/gatsby/headless-intro template="gatsby-strapi" name="Strapi" >}} -## Shared Platform.sh configuration +## Shared configuration {{% guides/gatsby/headless-project name="Strapi" %}} diff --git a/sites/platform/src/guides/gatsby/headless/wordpress.md b/sites/platform/src/guides/gatsby/headless/wordpress.md index 7bafd7125e..9451b1cad3 100644 --- a/sites/platform/src/guides/gatsby/headless/wordpress.md +++ b/sites/platform/src/guides/gatsby/headless/wordpress.md @@ -1,5 +1,5 @@ --- -title: "How to deploy Gatsby with WordPress on Platform.sh" +title: "How to deploy Gatsby with WordPress on {{< vendor/name >}}" sidebarTitle: "WordPress" description: | WordPress's built-in content API can quickly become a content source for Gatsby with `gatsby-source-wordpress`. @@ -8,7 +8,7 @@ description: | {{< guides/gatsby/headless-intro template="gatsby-wordpress" name="WordPress" >}} -## Shared Platform.sh configuration +## Shared configuration {{% guides/gatsby/headless-project name="WordPress" %}} diff --git a/sites/platform/src/guides/hibernate/_index.md b/sites/platform/src/guides/hibernate/_index.md index f2bf9f840c..e88e3cbe1c 100644 --- a/sites/platform/src/guides/hibernate/_index.md +++ b/sites/platform/src/guides/hibernate/_index.md @@ -2,7 +2,7 @@ title: Hibernate weight: -60 sectionBefore: Java -description: Everything you need to get started with Hibernate on Platform.sh. +description: Everything you need to get started with Hibernate on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/hibernate/deploy.md b/sites/platform/src/guides/hibernate/deploy.md index b342c09eaa..2fa3570b13 100644 --- a/sites/platform/src/guides/hibernate/deploy.md +++ b/sites/platform/src/guides/hibernate/deploy.md @@ -1,5 +1,5 @@ --- -title: Deploy Hibernate ORM on Platform.sh +title: Deploy Hibernate ORM on {{< vendor/name >}} sidebarTitle: Get started weight: 4 --- diff --git a/sites/platform/src/guides/ibexa/_index.md b/sites/platform/src/guides/ibexa/_index.md index 4073538203..ebdabe6823 100644 --- a/sites/platform/src/guides/ibexa/_index.md +++ b/sites/platform/src/guides/ibexa/_index.md @@ -1,7 +1,7 @@ --- title: "Ibexa DXP" weight: -160 -description: Everything you need to get started with Ibexa DXP on Platform.sh. +description: Everything you need to get started with Ibexa DXP on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/ibexa/deploy.md b/sites/platform/src/guides/ibexa/deploy.md index 4c2c73f7f7..e66a4b692a 100644 --- a/sites/platform/src/guides/ibexa/deploy.md +++ b/sites/platform/src/guides/ibexa/deploy.md @@ -1,17 +1,17 @@ --- -title: Deploy Ibexa DXP on Platform.sh +title: Deploy Ibexa DXP on {{< vendor/name >}} sidebarTitle: Get started weight: -10 -description: Learn how to use Ibexa DXP on Platform.sh. +description: Learn how to use Ibexa DXP on {{< vendor/name >}}. --- -Ibexa DXP is a Composer-based PHP CMS, and as such fits well with the Platform.sh model. +Ibexa DXP is a Composer-based PHP CMS, and as such fits well with the {{< vendor/name >}} model. As a Symfony-based application its setup is very similar to Symfony. -Ibexa DXP has come pre-configured for use with Platform.sh since its predecessor, eZ Platform 1.13. +Ibexa DXP has come pre-configured for use with {{< vendor/name >}} since its predecessor, eZ Platform 1.13. Version 2.5 and later is recommended. Those are the only versions that are supported. -Appropriate Platform.sh configuration files are included in the Ibexa DXP application itself, but may be modified to suit your particular site, if needed. +Appropriate {{< vendor/name >}} configuration files are included in the Ibexa DXP application itself, but may be modified to suit your particular site, if needed. ## Cache and sessions @@ -23,7 +23,7 @@ and the corresponding relationship in the `.platform.app.yaml` file. The bridge code that is provided with eZ Platform 1.13 and later automatically detects the additional Redis service and use it for session storage. On a {{% names/dedicated-gen-2 %}} instance, we strongly recommend using two separate Redis instances for Cache and Sessions. -The service and relationship names that ship with the default Platform.sh configuration in Ibexa DXP should be used as-is. +The service and relationship names that ship with the default {{< vendor/name >}} configuration in Ibexa DXP should be used as-is. To ensure the development environment works like Production, uncomment the `redissession` entry in the `.platform/services.yaml` file and the corresponding relationship in the `.platform.app.yaml` file. The bridge code that's provided with eZ Platform 1.13 and later automatically detects the additional Redis service and uses it for session storage. @@ -47,7 +47,7 @@ In particular, see: For local development on top of a Docker stack, the eZ community provides a tool called [eZ Launchpad](https://ezsystems.github.io/launchpad/) It improves developer experience and reduces complexity for common actions by simplifying your interactions with Docker containers. -eZ Launchpad is ready to work with Platform.sh. +eZ Launchpad is ready to work with {{< vendor/name >}}. It serves as a wrapper that allows you to run console commands from within the container without logging into it explicitly. For example to run `bin/console` `cache:clear` inside the PHP container do: @@ -86,9 +86,9 @@ Find more details on the [eZ Launchpad documentation](https://ezsystems.github.i Now, you have a working Ibexa DXP application with many services including Varnish, Solr, Redis, and more. -### Platform.sh integration +### Integration -To generate the key files for Platform.sh (`.platform.app.yaml` and `.platform`) run: +To generate the key files for {{< vendor/name >}} (`.platform.app.yaml` and `.platform`) run: ```bash ~/ez platformsh:setup @@ -98,7 +98,7 @@ eZ Launchpad generates the files for you and you are then totally free to fine t #### Solr specificity -Solr is fully functional with eZ Launchpad but it isn't enabled by default on Platform.sh. +Solr is fully functional with eZ Launchpad but it isn't enabled by default on {{< vendor/name >}}. You have to set it up manually following the [current documentation](https://github.com/ezsystems/ezplatform/blob/master/.platform/services.yaml#L37). Actions needed are: @@ -111,7 +111,7 @@ Actions needed are: #### Environment variables (optional) eZ Launchpad allows you to define environment variables in the `provisioning/dev/docker-compose.yml` file. -You may use that to set [variables](../../development/variables/_index.md) to match Platform.sh environments so that you can keep your environment behavior in sync. +You may use that to set [variables](../../development/variables/_index.md) to match {{< vendor/name >}} environments so that you can keep your environment behavior in sync. Such variables have to be set in the `engine` container. @@ -123,25 +123,25 @@ engine: - PLATFORM_RELATIONSHIPS=A_BASE64_ENCODED_VALUE ``` -### Local development with Platform.sh +### Local development with {{< vendor/name >}} Thanks to eZ Launchpad, you can work 100% locally: [untethered](../../development/local/untethered.md). You have the whole project working offline on machine. {{< note >}} -Platform.sh also provides smooth [tethered SSH tunnels](../../development/local/tethered.md). +{{< vendor/name >}} also provides smooth [tethered SSH tunnels](../../development/local/tethered.md). {{< /note >}} -Local services are provided by the Docker stack but there are minimum day-to-day tasks that you might need with Platform.sh. +Local services are provided by the Docker stack but there are minimum day-to-day tasks that you might need with {{< vendor/name >}}. The main ones are: * **Downstream database synchronization**: Getting it from the remote to the local. * **Downstream file storage synchronization**: Getting it from the remote to the local. -To help you with that, Platform.sh provides a CLI that you can [install](../../administration/cli/_index.md). +To help you with that, {{< vendor/name >}} provides a CLI that you can [install](../../administration/cli/_index.md). #### Database and storage synchronization diff --git a/sites/platform/src/guides/ibexa/fastly.md b/sites/platform/src/guides/ibexa/fastly.md index 6468b0bf0b..ae5770f4b7 100644 --- a/sites/platform/src/guides/ibexa/fastly.md +++ b/sites/platform/src/guides/ibexa/fastly.md @@ -10,7 +10,7 @@ description: | ## Remove Varnish configuration -In Ibexa DXP, Varnish is enabled by default when deploying on Platform.sh. +In Ibexa DXP, Varnish is enabled by default when deploying on {{< vendor/name >}} To use Fastly, Varnish must be disabled: - Remove environment variable `TRUSTED_PROXIES: "REMOTE_ADDR"` in [`.platform.app.yaml`](https://github.com/ezsystems/ezplatform/blob/master/.platform.app.yaml) @@ -30,9 +30,9 @@ To use Fastly, Varnish must be disabled: Ibexa DXP's documentation includes instructions on how to [configure Ibexa DXP for Fastly](https://doc.ibexa.co/en/latest/infrastructure_and_maintenance/cache/http_cache/reverse_proxy/#using-varnish-or-fastly). Follow the steps there to prepare Ibexa DXP for Fastly. -## Set credentials on Platform.sh +## Set credentials -The best way to provide the Fastly credentials and configuration to Ibexa DXP on Platform.sh is via environment variables. +The best way to provide the Fastly credentials and configuration to Ibexa DXP on {{< vendor/name >}} is via environment variables. That way private credentials are never stored in Git. Using the CLI, run the following commands to set the configuration on your production environment @@ -64,7 +64,7 @@ They handle varying cache by user context hash _(permissions)_ as well as several other needs by Ibexa DXP and it's underlying HttpCache system. -## Configure Fastly and Platform.sh +## Configure Fastly -See the alternate [Go-live process for Fastly](/domains/cdn/_index.md#client-authenticated-tls) on Platform.sh. +See the alternate [Go-live process for Fastly](/domains/cdn/_index.md#client-authenticated-tls) on {{< vendor/name >}}. This process is the same for any application. diff --git a/sites/platform/src/guides/jakarta/_index.md b/sites/platform/src/guides/jakarta/_index.md index d04cef4aa3..d7419e6ff3 100644 --- a/sites/platform/src/guides/jakarta/_index.md +++ b/sites/platform/src/guides/jakarta/_index.md @@ -1,7 +1,7 @@ --- title: Jakarta weight: -50 -description: Everything you need to get started with Jakarta on Platform.sh. +description: Everything you need to get started with Jakarta on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/jakarta/deploy.md b/sites/platform/src/guides/jakarta/deploy.md index 705674da2e..c7f95642c1 100644 --- a/sites/platform/src/guides/jakarta/deploy.md +++ b/sites/platform/src/guides/jakarta/deploy.md @@ -1,5 +1,5 @@ --- -title: Deploy Jakarta on Platform.sh +title: Deploy Jakarta on {{< vendor/name >}} sidebarTitle: Get started weight: 5 --- diff --git a/sites/platform/src/guides/laravel/_index.md b/sites/platform/src/guides/laravel/_index.md index d1f2a782ab..a88efa28dd 100644 --- a/sites/platform/src/guides/laravel/_index.md +++ b/sites/platform/src/guides/laravel/_index.md @@ -2,7 +2,7 @@ title: "Laravel" weight: -140 description: | - Everything you need to get started with [Laravel](https://laravel.com/) on Platform.sh. + Everything you need to get started with [Laravel](https://laravel.com/) on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/laravel/deploy/_index.md b/sites/platform/src/guides/laravel/deploy/_index.md index c60edff69c..93251258db 100644 --- a/sites/platform/src/guides/laravel/deploy/_index.md +++ b/sites/platform/src/guides/laravel/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Laravel on Platform.sh +title: Deploy Laravel on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Laravel. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Laravel. --- [Laravel](https://laravel.com) is an open-source PHP Framework. diff --git a/sites/platform/src/guides/laravel/deploy/bridge.md b/sites/platform/src/guides/laravel/deploy/bridge.md index 30aa0e4bc8..11fa42f580 100644 --- a/sites/platform/src/guides/laravel/deploy/bridge.md +++ b/sites/platform/src/guides/laravel/deploy/bridge.md @@ -2,14 +2,14 @@ title: "Laravel Bridge" sidebarTitle: "Laravel Bridge" weight: -100 -description: Connect your Laravel-based app to Platform.sh with Laravel Bridge. +description: Connect your Laravel-based app to {{< vendor/name >}} with Laravel Bridge. --- -Connect your Laravel-based app to Platform.sh with the `platformsh/laravel-bridge` library. +Connect your Laravel-based app to {{< vendor/name >}} with the `platformsh/laravel-bridge` library. Laravel 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 Laravel expects for common values. +{{< vendor/name >}} provides configuration information as environment variables in a different specific format. +This library handles mapping the {{< vendor/name >}} variables to the format Laravel expects for common values. ## Usage @@ -20,7 +20,7 @@ When Composer's autoload is included, this library is activated and the environm composer require platformsh/laravel-bridge ``` -Make sure to clear the cache on relevant Platform.sh environments afterwards. +Make sure to clear the cache on relevant {{< vendor/name >}} environments afterwards. ``` bash php artisan optimize:clear @@ -28,12 +28,12 @@ php artisan optimize:clear ## What is mapped -* If a Platform.sh relationship named `database` is defined, +* If a {{< vendor/name >}} relationship named `database` is defined, it is taken as an SQL database and mapped to the `DB_*` environment variables for Laravel. -* If a Platform.sh relationship named `rediscache` is defined, +* If a {{< vendor/name >}} relationship named `rediscache` is defined, it is mapped to the `REDIS_*` environment variables for Laravel. The `CACHE_DRIVER` variable is also set to `redis` to activate it automatically. -* If a Platform.sh relationship named `redissession` is defined, +* If a {{< vendor/name >}} relationship named `redissession` is defined, the `SESSION_DRIVER` is set to `redis` and the `REDIS_*` variables set based on that relationship. NOTE: This means you _*must*_ set 2 relationships to the same Redis service and endpoint, as Laravel reuses the same backend connection. @@ -41,13 +41,13 @@ php artisan optimize:clear which is provided for exactly this purpose. * The Laravel `APP_URL` variable is set based on the current route, when possible. * The `SESSION_SECURE_COOKIE` variable is set to `true` if it's not already defined. - A Platform.sh environment is by default encrypted-always, + A {{< vendor/name >}} environment is by default encrypted-always, so there's no reason to allow unencrypted cookies. - Overwrite this by setting the Platform.sh variable `env:SESSION_SECURE_COOKIE` to 0. + Overwrite this by setting the {{< vendor/name >}} variable `env:SESSION_SECURE_COOKIE` to 0. * The `MAIL_DRIVER`, `MAIL_HOST`, and `MAIL_PORT` variables are set - to support sending email through the Platform.sh mail gateway. + to support sending email through the {{< vendor/name >}} mail gateway. The `MAIL_ENCRYPTION` value is also set to `0` to disable TLS, - as it isn't needed or supported within Platform.sh's network. + as it isn't needed or supported within {{< vendor/name >}}'s network. Note that doing so is only supported on Laravel 6.0.4 and later. On earlier versions, you *must* manually modify `mail.php` and set `encryption` to `null`: @@ -59,7 +59,7 @@ php artisan optimize:clear Laravel provides reasonable defaults for many environment variables already and this library doesn't override those. -Customize them by setting a Platform.sh variable named `env:ENV_NAME`. +Customize them by setting a {{< vendor/name >}} variable named `env:ENV_NAME`. (Note the `env:` prefix.) The variables you are most likely to want to override are: @@ -68,6 +68,6 @@ The variables you are most likely to want to override are: * `env:APP_ENV`: Whether the app is in `production` or `development` mode. * `env:APP_DEBUG`: Set `true` to enable verbose error messages. -Now that your Laravel app is connected to Platform.sh, deploy it to see it in action. +Now that your Laravel app is connected to {{< vendor/name >}}, deploy it to see it in action. {{< guide-buttons next="Deploy" >}} diff --git a/sites/platform/src/guides/laravel/deploy/configure.md b/sites/platform/src/guides/laravel/deploy/configure.md index 42fd063e2b..9dede015a3 100644 --- a/sites/platform/src/guides/laravel/deploy/configure.md +++ b/sites/platform/src/guides/laravel/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Laravel for Platform.sh" +title: "Configure Laravel for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Laravel. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Laravel. --- {{% guides/config-desc name="Laravel" %}} @@ -16,4 +16,4 @@ description: | Now that you have Laravel configured, connect it with Laravel Bridge. -{{< guide-buttons next="Connect to Platform.sh" >}} +{{< guide-buttons next="Connect to {{< vendor/name >}}" >}} diff --git a/sites/platform/src/guides/laravel/deploy/deploy.md b/sites/platform/src/guides/laravel/deploy/deploy.md index c9ea889978..9cc9393cac 100644 --- a/sites/platform/src/guides/laravel/deploy/deploy.md +++ b/sites/platform/src/guides/laravel/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Laravel" sidebarTitle: "Deploy" weight: -80 description: | - Now that your Laravel app is ready, push it to Platform.sh and import your data. + Now that your Laravel app is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/laravel/deploy/octane.md b/sites/platform/src/guides/laravel/deploy/octane.md index 54ff8ece9a..2e4b06df52 100644 --- a/sites/platform/src/guides/laravel/deploy/octane.md +++ b/sites/platform/src/guides/laravel/deploy/octane.md @@ -21,7 +21,7 @@ Require Laravel Octane using Composer. composer require laravel/octane ``` -Then make sure to clear the cache on all relevant Platform.sh environments. +Then make sure to clear the cache on all relevant {{< vendor/name >}} environments. ``` bash php artisan optimize:clear diff --git a/sites/platform/src/guides/laravel/local-development/_index.md b/sites/platform/src/guides/laravel/local-development/_index.md index a8ffd752ae..b9f139e58e 100644 --- a/sites/platform/src/guides/laravel/local-development/_index.md +++ b/sites/platform/src/guides/laravel/local-development/_index.md @@ -2,15 +2,15 @@ title: Run a Laravel app on your local machine sidebarTitle: Local development weight: -80 -description: Run your Laravel app deployed on Platform.sh on your local machine. +description: Run your Laravel app deployed on {{< vendor/name >}} on your local machine. --- -Platform.sh provides support for locally running a Laravel app -that has been deployed on Platform.sh, including its services. -Once you've downloaded the code of the Laravel app you deployed on Platform.sh, -you can make changes to the project without pushing to Platform.sh each time to test them. +{{< vendor/name >}} provides support for locally running a Laravel app +that has been deployed on {{< vendor/name >}}, including its services. +Once you've downloaded the code of the Laravel app you deployed on {{< vendor/name >}}, +you can make changes to the project without pushing to {{< vendor/name >}} each time to test them. -You can build your app locally using the Platform.sh CLI, +You can build your app locally using the {{< vendor/name >}} CLI, even when the app functionality depends on a number of services. You can run your Laravel app locally with all of its services by following the steps for your chosen development platform: diff --git a/sites/platform/src/guides/micronaut/_index.md b/sites/platform/src/guides/micronaut/_index.md index 1b6ffa065b..ab6ce0e8ee 100644 --- a/sites/platform/src/guides/micronaut/_index.md +++ b/sites/platform/src/guides/micronaut/_index.md @@ -2,7 +2,7 @@ title: "Micronaut" weight: -40 description: | - Everything you need to get started with Micronaut on Platform.sh. + Everything you need to get started with Micronaut on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/micronaut/deploy/_index.md b/sites/platform/src/guides/micronaut/deploy/_index.md index 419c1a0249..7b2867dcb7 100644 --- a/sites/platform/src/guides/micronaut/deploy/_index.md +++ b/sites/platform/src/guides/micronaut/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Micronaut on Platform.sh +title: Deploy Micronaut on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Micronaut. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Micronaut. --- [Micronaut](https://micronaut.io/) is an open-source, JVM-based framework for building full-stack, modular, testable microservice and serverless applications. diff --git a/sites/platform/src/guides/micronaut/deploy/configure.md b/sites/platform/src/guides/micronaut/deploy/configure.md index 0f75378e34..8e51c798e8 100644 --- a/sites/platform/src/guides/micronaut/deploy/configure.md +++ b/sites/platform/src/guides/micronaut/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Micronaut for Platform.sh" +title: "Configure Micronaut for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Micronaut. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Micronaut. --- {{% guides/config-desc name="Micronaut" noService=true %}} @@ -16,7 +16,7 @@ Explaining the file line by line, notice the following settings: 3. `disk`: The disk space that the application needs in megabytes. 4. `hooks.build`: The command to package the application. 5. `web.commands`: The order to start the application, - where the port is overwritten using the `PORT` environment variable provided by Platform.sh to the application container. + where the port is overwritten using the `PORT` environment variable provided by {{< vendor/name >}} to the application container. {{< /guides/config-app >}} diff --git a/sites/platform/src/guides/micronaut/deploy/customize.md b/sites/platform/src/guides/micronaut/deploy/customize.md index 6668c37284..1d7b18a946 100644 --- a/sites/platform/src/guides/micronaut/deploy/customize.md +++ b/sites/platform/src/guides/micronaut/deploy/customize.md @@ -1,12 +1,12 @@ --- -title: "Customize Micronaut for Platform.sh" +title: "Customize Micronaut for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your Micronaut site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your Micronaut site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, it's time to make your Micronaut site itself ready to run on a Platform.sh environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, it's time to make your Micronaut site itself ready to run on a {{< vendor/name >}} environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. ## Install the Config Reader @@ -49,9 +49,9 @@ web: start: java -jar $JAVA_OPTS $CREDENTIAL target/file.jar ``` -On Platform.sh, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. Platform.sh runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. +On {{< vendor/name >}}, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. {{< vendor/name >}} runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. That gives you a place to do extra environment variable setup before the application runs, including modifying the system `$PATH` and other shell level customizations. -It allows us to define `JAVA_OPTS` when running on Platform.sh, but otherwise not be used during local development testing. +It allows us to define `JAVA_OPTS` when running on {{< vendor/name >}}, but otherwise not be used during local development testing. ```shell # .environment diff --git a/sites/platform/src/guides/micronaut/deploy/deploy.md b/sites/platform/src/guides/micronaut/deploy/deploy.md index d7c701c802..b08a8be02f 100644 --- a/sites/platform/src/guides/micronaut/deploy/deploy.md +++ b/sites/platform/src/guides/micronaut/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Micronaut" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/micronaut/deploy/next-steps.md b/sites/platform/src/guides/micronaut/deploy/next-steps.md index f05347eb57..9195616061 100644 --- a/sites/platform/src/guides/micronaut/deploy/next-steps.md +++ b/sites/platform/src/guides/micronaut/deploy/next-steps.md @@ -6,7 +6,7 @@ description: | Resources for further developing your site. --- -This guide has hopefully helped you deploy a new Micronaut site, or migrate an existing one, to Platform.sh. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the Platform.sh team maintains and adds to a number of Micronaut guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using JPA. +This guide has hopefully helped you deploy a new Micronaut site, or migrate an existing one, to {{< vendor/name >}}. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the {{< vendor/name >}} team maintains and adds to a number of Micronaut guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using JPA. Consult those guides below or in the sidebar for more information. diff --git a/sites/platform/src/guides/micronaut/elasticsearch.md b/sites/platform/src/guides/micronaut/elasticsearch.md index 2bfa50a70e..691f45d5ae 100644 --- a/sites/platform/src/guides/micronaut/elasticsearch.md +++ b/sites/platform/src/guides/micronaut/elasticsearch.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Micronaut on Platform.sh with Elasticsearch" +title: "How to Deploy Micronaut on {{< vendor/name >}} with Elasticsearch" sidebarTitle: "Elasticsearch" weight: -110 layout: single @@ -10,7 +10,7 @@ description: | Micronaut provides two ways of accessing Elasticsearch: via the lower level `RestClient` or via the `RestHighLevelClient`. To initialize Elasticsearch in your project's cluster so that it can be accessed by a Micronaut application, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Elasticsearch service @@ -27,7 +27,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Micronaut. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Micronaut. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export ES_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".essearch[0].host") diff --git a/sites/platform/src/guides/micronaut/jpa.md b/sites/platform/src/guides/micronaut/jpa.md index 23dd15a840..680f607ae9 100644 --- a/sites/platform/src/guides/micronaut/jpa.md +++ b/sites/platform/src/guides/micronaut/jpa.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Micronoaut on Platform.sh with JPA" +title: "How to Deploy Micronoaut on {{< vendor/name >}} with JPA" sidebarTitle: "JPA" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Micronoaut application with JPA. --- -To activate JPA and then have it accessed by the Micronoaut application already configured for Platform.sh, it is necessary to modify two files. +To activate JPA and then have it accessed by the Micronoaut application already configured for {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Micronoaut project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Micronoaut project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add a SQL database service @@ -27,7 +27,7 @@ To access the new service, set a `relationship` in your [app configuration](../. ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export JDBC_HOST=`echo $PLATFORM_RELATIONSHIPS|base64 -d|jq -r ".database[0].host"` diff --git a/sites/platform/src/guides/micronaut/micronaut-data.md b/sites/platform/src/guides/micronaut/micronaut-data.md index bb7edea46c..355c581f61 100644 --- a/sites/platform/src/guides/micronaut/micronaut-data.md +++ b/sites/platform/src/guides/micronaut/micronaut-data.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Micronaut on Platform.sh with Micronaut Data" +title: "How to Deploy Micronaut on {{< vendor/name >}} with Micronaut Data" sidebarTitle: "Micronaut Data" weight: -110 layout: single @@ -10,7 +10,7 @@ description: | [Micronaut Data](https://micronaut-projects.github.io/micronaut-data/latest/guide/) is a database access toolkit that uses Ahead of Time (AoT) compilation to pre-compute queries for repository interfaces that are then executed by a thin, lightweight runtime layer. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add a SQL database service @@ -27,7 +27,7 @@ To access the new service, set a `relationship` in your [app configuration](../. ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export JDBC_HOST=`echo $PLATFORM_RELATIONSHIPS|base64 -d|jq -r ".database[0].host"` diff --git a/sites/platform/src/guides/micronaut/mongodb.md b/sites/platform/src/guides/micronaut/mongodb.md index a5f0d69833..ee4c99481a 100644 --- a/sites/platform/src/guides/micronaut/mongodb.md +++ b/sites/platform/src/guides/micronaut/mongodb.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Micronaut on Platform.sh with MongoDB" +title: "How to Deploy Micronaut on {{< vendor/name >}} with MongoDB" sidebarTitle: "MongoDB" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Micronaut application with MongoDB. --- -To activate MongoDB and then have it accessed by the Micronaut application already in Platform.sh, it is necessary to modify two files. +To activate MongoDB and then have it accessed by the Micronaut application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a MongoDB service configuration to an existing Micronaut project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a MongoDB service configuration to an existing Micronaut project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the MongoDB service @@ -31,7 +31,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Micronaut. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export MONGO_PORT=`echo $PLATFORM_RELATIONSHIPS|base64 -d|json_pp|jq -r ".mongodb[0].port"` diff --git a/sites/platform/src/guides/micronaut/redis.md b/sites/platform/src/guides/micronaut/redis.md index 99183ecc84..a37104eeed 100644 --- a/sites/platform/src/guides/micronaut/redis.md +++ b/sites/platform/src/guides/micronaut/redis.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Micronaut on Platform.sh with Redis" +title: "How to Deploy Micronaut on {{< vendor/name >}} with Redis" sidebarTitle: "Redis" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Micronaut application with Redis. --- -To activate Redis and then have it accessed by the Micronaut application already in Platform.sh, it is necessary to modify two files. +To activate Redis and then have it accessed by the Micronaut application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Micronaut project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/micronaut/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Redis service @@ -27,7 +27,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Micronaut. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Micronaut. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export REDIS_HOST=$(echo $PLATFORM_RELATIONSHIPS|base64 --decode|jq -r ".redisdata[0].host") diff --git a/sites/platform/src/guides/nextjs/_index.md b/sites/platform/src/guides/nextjs/_index.md index ed4e1ea65a..fbf96bec42 100644 --- a/sites/platform/src/guides/nextjs/_index.md +++ b/sites/platform/src/guides/nextjs/_index.md @@ -2,7 +2,7 @@ title: "Next.js" weight: -80 description: | - Everything you need to get started with [Next.js](https://nextjs.org/), a React framework for building websites and web apps, on Platform.sh. + Everything you need to get started with [Next.js](https://nextjs.org/), a React framework for building websites and web apps, on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/nextjs/deploy.md b/sites/platform/src/guides/nextjs/deploy.md index 0713a1772d..b6f8714d49 100644 --- a/sites/platform/src/guides/nextjs/deploy.md +++ b/sites/platform/src/guides/nextjs/deploy.md @@ -1,5 +1,5 @@ --- -title: Deploy Next.js on Platform.sh +title: Deploy Next.js on {{< vendor/name >}} sidebarTitle: Get started description: Prepare to deploy Next.js. --- @@ -7,11 +7,11 @@ description: Prepare to deploy Next.js. [Next.js](https://nextjs.org/) is a React framework for building websites and web apps, with server-side rendering and static site generation. -See an example Next.js project in the official [Platform.sh Next.js template](https://github.com/platformsh-templates/nextjs). +See an example Next.js project in the official [{{< vendor/name >}} Next.js template](https://github.com/platformsh-templates/nextjs). You can use it as a starting point for your own project. If you already have a Next.js project ready to deploy, see the template's [example app configuration](https://github.com/platformsh-templates/nextjs/blob/master/.platform.app.yaml) -and other [example Platform.sh files](https://github.com/platformsh-templates/nextjs/tree/master/.platform). +and other [example {{< vendor/name >}} files](https://github.com/platformsh-templates/nextjs/tree/master/.platform). These files let you [configure your app](../../create-apps/_index.md), [add services](../../add-services/_index.md), and [define routes](../../define-routes/_index.md). diff --git a/sites/platform/src/guides/quarkus/_index.md b/sites/platform/src/guides/quarkus/_index.md index 9647abf76c..0420ffdf6c 100644 --- a/sites/platform/src/guides/quarkus/_index.md +++ b/sites/platform/src/guides/quarkus/_index.md @@ -2,7 +2,7 @@ title: "Quarkus" weight: -30 description: | - Everything you need to get started with Quarkus on Platform.sh. + Everything you need to get started with Quarkus on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/quarkus/deploy/_index.md b/sites/platform/src/guides/quarkus/deploy/_index.md index ce83218a4c..c03d6facdf 100644 --- a/sites/platform/src/guides/quarkus/deploy/_index.md +++ b/sites/platform/src/guides/quarkus/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Quarkus on Platform.sh +title: Deploy Quarkus on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Quarkus. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Quarkus. --- [Quarkus](https://quarkus.io/) is, in its own words, a cloud-native, (Linux) container-first framework for writing Java applications. diff --git a/sites/platform/src/guides/quarkus/deploy/configure.md b/sites/platform/src/guides/quarkus/deploy/configure.md index 0d323ef3d6..04ee032990 100644 --- a/sites/platform/src/guides/quarkus/deploy/configure.md +++ b/sites/platform/src/guides/quarkus/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Quarkus for Platform.sh" +title: "Configure Quarkus for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Quarkus. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Quarkus. --- {{% guides/config-desc name="Quarkus" noService=true %}} @@ -16,7 +16,7 @@ Explaining the file line by line, notice the following settings: 3. `disk`: The disk space that the application needs in megabytes. 4. `hooks.build`: The command to package the application 5. `web.commands`: The order to start the application, where the port is overwritten with `-Dquarkus.http.port=$PORT`, - using the `PORT` environment variable provided by Platform.sh to the application container. + using the `PORT` environment variable provided by {{< vendor/name >}} to the application container. {{< /guides/config-app >}} diff --git a/sites/platform/src/guides/quarkus/deploy/customize.md b/sites/platform/src/guides/quarkus/deploy/customize.md index ce40d6d2fe..fd6e002172 100644 --- a/sites/platform/src/guides/quarkus/deploy/customize.md +++ b/sites/platform/src/guides/quarkus/deploy/customize.md @@ -1,12 +1,12 @@ --- -title: "Customize Quarkus for Platform.sh" +title: "Customize Quarkus for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your Quarkus site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your Quarkus site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, it's time to make your Quarkus site itself ready to run on a Platform.sh environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, it's time to make your Quarkus site itself ready to run on a {{< vendor/name >}} environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. ## Install the Config Reader @@ -49,9 +49,9 @@ web: start: java -jar $JAVA_OPTS $CREDENTIAL -Dquarkus.http.port=$PORT target/file.jar ``` -On Platform.sh, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. Platform.sh runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. +On {{< vendor/name >}}, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. {{< vendor/name >}} runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. That gives you a place to do extra environment variable setup before the application runs, including modifying the system `$PATH` and other shell level customizations. -It allows us to define `JAVA_OPTS` when running on Platform.sh, but otherwise not be used during local development testing. +It allows us to define `JAVA_OPTS` when running on {{< vendor/name >}}, but otherwise not be used during local development testing. ```shell # .environment diff --git a/sites/platform/src/guides/quarkus/deploy/deploy.md b/sites/platform/src/guides/quarkus/deploy/deploy.md index fa48bd6304..c100b9d522 100644 --- a/sites/platform/src/guides/quarkus/deploy/deploy.md +++ b/sites/platform/src/guides/quarkus/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Quarkus" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/quarkus/deploy/next-steps.md b/sites/platform/src/guides/quarkus/deploy/next-steps.md index f394cff6a0..9924084b25 100644 --- a/sites/platform/src/guides/quarkus/deploy/next-steps.md +++ b/sites/platform/src/guides/quarkus/deploy/next-steps.md @@ -6,7 +6,7 @@ description: | Resources for further developing your site. --- -This guide has hopefully helped you deploy a new Quarkus site, or migrate an existing one, to Platform.sh. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the Platform.sh team maintains and adds to a number of Quarkus guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using Panache and JPA. +This guide has hopefully helped you deploy a new Quarkus site, or migrate an existing one, to {{< vendor/name >}}. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the {{< vendor/name >}} team maintains and adds to a number of Quarkus guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using Panache and JPA. Consult those guides below or in the sidebar for more information. diff --git a/sites/platform/src/guides/quarkus/elasticsearch.md b/sites/platform/src/guides/quarkus/elasticsearch.md index d5e33580bf..b4ec8841d1 100644 --- a/sites/platform/src/guides/quarkus/elasticsearch.md +++ b/sites/platform/src/guides/quarkus/elasticsearch.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Quarkus on Platform.sh with Elasticsearch" +title: "How to Deploy Quarkus on {{< vendor/name >}} with Elasticsearch" sidebarTitle: "Elasticsearch" weight: -110 layout: single @@ -10,7 +10,7 @@ description: | Quarkus provides two ways of accessing Elasticsearch: via the lower level `RestClient` or via the `RestHighLevelClient`. To initialize Elasticsearch in your project's cluster so that it can be accessed by a Quarkus application, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Elasticsearch service @@ -27,7 +27,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Quarkus. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Quarkus. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export ES_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".essearch[0].host") diff --git a/sites/platform/src/guides/quarkus/jpa.md b/sites/platform/src/guides/quarkus/jpa.md index a15d0c7a3b..421fd3bb51 100644 --- a/sites/platform/src/guides/quarkus/jpa.md +++ b/sites/platform/src/guides/quarkus/jpa.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Quarkus on Platform.sh with JPA" +title: "How to Deploy Quarkus on {{< vendor/name >}} with JPA" sidebarTitle: "JPA" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Quarkus application with JPA. --- -Hibernate ORM is a standard [JPA](https://jakarta.ee/specifications/persistence/) implementation. It offers you the full breadth of an Object Relational Mapper and it works well in Quarkus. To activate JPA and then have it accessed by the Quarkus application already configured for Platform.sh, it is necessary to modify two files. +Hibernate ORM is a standard [JPA](https://jakarta.ee/specifications/persistence/) implementation. It offers you the full breadth of an Object Relational Mapper and it works well in Quarkus. To activate JPA and then have it accessed by the Quarkus application already configured for {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add a SQL database service @@ -27,7 +27,7 @@ To access the new service, set a `relationship` in your [app configuration](../. ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".postgresdatabase[0].host") diff --git a/sites/platform/src/guides/quarkus/mongodb.md b/sites/platform/src/guides/quarkus/mongodb.md index 1adcca94b3..963bea9264 100644 --- a/sites/platform/src/guides/quarkus/mongodb.md +++ b/sites/platform/src/guides/quarkus/mongodb.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Quarkus on Platform.sh with MongoDB" +title: "How to Deploy Quarkus on {{< vendor/name >}} with MongoDB" sidebarTitle: "MongoDB" weight: -110 layout: single @@ -9,10 +9,10 @@ description: | MongoDB with Panache provides active record style entities (and repositories) like you have in [Hibernate ORM with Panache](https://quarkus.io/guides/hibernate-orm-panache). It focuses on helping you write your entities in Quarkus. -To activate MongoDB and then have it accessed by the Quarkus application already in Platform.sh, it is necessary to modify two files. +To activate MongoDB and then have it accessed by the Quarkus application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a MongoDB service configuration to an existing Quarkus project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a MongoDB service configuration to an existing Quarkus project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the MongoDB service @@ -33,7 +33,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export MONGO_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".mongodatabase[0].port") diff --git a/sites/platform/src/guides/quarkus/panache.md b/sites/platform/src/guides/quarkus/panache.md index e173699abd..9906148ff8 100644 --- a/sites/platform/src/guides/quarkus/panache.md +++ b/sites/platform/src/guides/quarkus/panache.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Quarkus on Platform.sh with Panache" +title: "How to Deploy Quarkus on {{< vendor/name >}} with Panache" sidebarTitle: "Panache" weight: -110 layout: single @@ -9,10 +9,10 @@ description: | Hibernate ORM is a JPA implementation and offers you the full breadth of an Object Relational Mapper. It makes complex mappings possible, but they can sometimes be difficult. Hibernate ORM with Panache focuses on helping you write your entities in Quarkus. -To activate Hibernate Panache and then have it accessed by the Quarkus application already in Platform.sh, it is necessary to modify two files. +To activate Hibernate Panache and then have it accessed by the Quarkus application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on Platform.sh. Please see the [deployment guide](./deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](./deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add a SQL database service @@ -29,7 +29,7 @@ To access the new service, set a `relationship` in your [app configuration](../. ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Quarkus. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".postgresdatabase[0].host") diff --git a/sites/platform/src/guides/quarkus/redis.md b/sites/platform/src/guides/quarkus/redis.md index 123cc69c87..f1b1c81121 100644 --- a/sites/platform/src/guides/quarkus/redis.md +++ b/sites/platform/src/guides/quarkus/redis.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Quarkus on Platform.sh with Redis" +title: "How to Deploy Quarkus on {{< vendor/name >}} with Redis" sidebarTitle: "Redis" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Quarkus application with Redis. --- -To activate Redis and then have it accessed by the Quarkus application already in Platform.sh, it is necessary to modify two files. +To activate Redis and then have it accessed by the Quarkus application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Quarkus project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/quarkus/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Redis service @@ -27,7 +27,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Quarkus. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Quarkus. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export REDIS_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".redisdata[0].host") diff --git a/sites/platform/src/guides/spring/_index.md b/sites/platform/src/guides/spring/_index.md index 23f326c967..a89cbefee1 100644 --- a/sites/platform/src/guides/spring/_index.md +++ b/sites/platform/src/guides/spring/_index.md @@ -2,7 +2,7 @@ title: "Spring" weight: -30 description: | - Everything you need to get started with Spring on Platform.sh. + Everything you need to get started with Spring on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/spring/deploy/_index.md b/sites/platform/src/guides/spring/deploy/_index.md index 8f6165bb35..522c771041 100644 --- a/sites/platform/src/guides/spring/deploy/_index.md +++ b/sites/platform/src/guides/spring/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Spring on Platform.sh +title: Deploy Spring on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Spring. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Spring. --- [Spring](https://start.spring.io/) is, in its own words, a cloud-native, (Linux) container-first framework for writing Java applications. diff --git a/sites/platform/src/guides/spring/deploy/configure.md b/sites/platform/src/guides/spring/deploy/configure.md index 505004f7d7..3e688db142 100644 --- a/sites/platform/src/guides/spring/deploy/configure.md +++ b/sites/platform/src/guides/spring/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Spring for Platform.sh" +title: "Configure Spring for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Spring. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Spring. --- {{% guides/config-desc name="Spring" noService=true %}} @@ -16,7 +16,7 @@ Explaining the file line by line, notice the following settings: 3. `disk`: The disk space that the application needs in megabytes. 4. `hooks.build`: The command to package the application. 5. `web.commands`: The order to start the application, where the port is overwritten with `--server.port=$PORT`, - using the `PORT` environment variable provided by Platform.sh to the application container. + using the `PORT` environment variable provided by {{< vendor/name >}} to the application container. {{< /guides/config-app >}} diff --git a/sites/platform/src/guides/spring/deploy/customize.md b/sites/platform/src/guides/spring/deploy/customize.md index 2da6b3158e..1279b11879 100644 --- a/sites/platform/src/guides/spring/deploy/customize.md +++ b/sites/platform/src/guides/spring/deploy/customize.md @@ -1,12 +1,12 @@ --- -title: "Customize Spring for Platform.sh" +title: "Customize Spring for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your Spring site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your Spring site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, it's time to make your Spring site itself ready to run on a Platform.sh environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, it's time to make your Spring site itself ready to run on a {{< vendor/name >}} environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. ## Install the Config Reader @@ -49,9 +49,9 @@ web: start: java -jar $JAVA_OPTS target/file.jar --server.port=$PORT ``` -On Platform.sh, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. Platform.sh runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. +On {{< vendor/name >}}, we can set the environment variable `JAVA_OPTS` by committing a `.environment` file to the repository's root. {{< vendor/name >}} runs `source .environment` in the application root when a project starts, and when logging into the environment over SSH. That gives you a place to do extra environment variable setup prior to the application running, including modifying the system `$PATH` and other shell level customizations. -It allows us to define `JAVA_OPTS` when running on Platform.sh, but otherwise not be used during local development testing. +It allows us to define `JAVA_OPTS` when running on {{< vendor/name >}}, but otherwise not be used during local development testing. ```shell # .environment diff --git a/sites/platform/src/guides/spring/deploy/deploy.md b/sites/platform/src/guides/spring/deploy/deploy.md index cc2d26b4d6..b5c2090c00 100644 --- a/sites/platform/src/guides/spring/deploy/deploy.md +++ b/sites/platform/src/guides/spring/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Spring" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/spring/deploy/next-steps.md b/sites/platform/src/guides/spring/deploy/next-steps.md index e09ecf972b..51548d6635 100644 --- a/sites/platform/src/guides/spring/deploy/next-steps.md +++ b/sites/platform/src/guides/spring/deploy/next-steps.md @@ -6,7 +6,7 @@ description: | Resources for further developing your site. --- -This guide has hopefully helped you deploy a new Spring site, or migrate an existing one, to Platform.sh. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the Platform.sh team maintains and adds to a number of Spring guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using Panache and JPA. +This guide has hopefully helped you deploy a new Spring site, or migrate an existing one, to {{< vendor/name >}}. It has made a few assumptions to provide the best information to do so, but is by no means a complete reference for your particular application. For this reason, the {{< vendor/name >}} team maintains and adds to a number of Spring guides that can help you add services like Elasticsearch and MongoDB to your application, or how to start using Panache and JPA. Consult those guides below or in the sidebar for more information. diff --git a/sites/platform/src/guides/spring/elasticsearch.md b/sites/platform/src/guides/spring/elasticsearch.md index 635c4833e2..f396351bc2 100644 --- a/sites/platform/src/guides/spring/elasticsearch.md +++ b/sites/platform/src/guides/spring/elasticsearch.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Spring on Platform.sh with Elasticsearch" +title: "How to Deploy Spring on {{< vendor/name >}} with Elasticsearch" sidebarTitle: "Elasticsearch" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Spring application with Elasticsearch. --- -To activate Elasticsearch and then have it accessed by the Spring application already in Platform.sh, it is necessary to modify two files. +To activate Elasticsearch and then have it accessed by the Spring application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Elasticsearch service @@ -27,7 +27,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Spring. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Elasticsearch, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Spring. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export ES_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".essearch[0].host") diff --git a/sites/platform/src/guides/spring/jpa.md b/sites/platform/src/guides/spring/jpa.md index 80efd0edc2..af1c163d65 100644 --- a/sites/platform/src/guides/spring/jpa.md +++ b/sites/platform/src/guides/spring/jpa.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Spring on Platform.sh with JPA" +title: "How to Deploy Spring on {{< vendor/name >}} with JPA" sidebarTitle: "JPA" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Spring application with JPA. --- -To activate JPA and then have it accessed by the Spring application already configured for Platform.sh, it is necessary to modify two files. +To activate JPA and then have it accessed by the Spring application already configured for {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add a SQL database service @@ -27,7 +27,7 @@ To access the new service, set a `relationship` in your [app configuration](../. ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Spring. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Spring. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export DB_PORT=`echo $PLATFORM_RELATIONSHIPS|base64 -d|jq -r ".postgresdatabase[0].port"` diff --git a/sites/platform/src/guides/spring/mongodb.md b/sites/platform/src/guides/spring/mongodb.md index 80ef49ecc5..d2b103a7c1 100644 --- a/sites/platform/src/guides/spring/mongodb.md +++ b/sites/platform/src/guides/spring/mongodb.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Spring on Platform.sh with MongoDB" +title: "How to Deploy Spring on {{< vendor/name >}} with MongoDB" sidebarTitle: "MongoDB" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Spring application with MongoDB. --- -To activate MongoDB and then have it accessed by the Spring application already in Platform.sh, it is necessary to modify two files. +To activate MongoDB and then have it accessed by the Spring application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a MongoDB service configuration to an existing Spring project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a MongoDB service configuration to an existing Spring project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the MongoDB service @@ -31,7 +31,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Spring. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for services are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to the database into it's own environment variables that can be used by Spring. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export SPRING_DATA_MONGODB_USERNAME=`echo $PLATFORM_RELATIONSHIPS|base64 -d|jq -r ".dbmongo[0].username"` diff --git a/sites/platform/src/guides/spring/redis.md b/sites/platform/src/guides/spring/redis.md index 3f4c1108e0..5bf5cb3442 100644 --- a/sites/platform/src/guides/spring/redis.md +++ b/sites/platform/src/guides/spring/redis.md @@ -1,5 +1,5 @@ --- -title: "How to Deploy Spring on Platform.sh with Redis" +title: "How to Deploy Spring on {{< vendor/name >}} with Redis" sidebarTitle: "Redis" weight: -110 layout: single @@ -7,10 +7,10 @@ description: | Configure a Spring application with Redis. --- -To activate Redis and then have it accessed by the Spring application already in Platform.sh, it is necessary to modify two files. +To activate Redis and then have it accessed by the Spring application already in {{< vendor/name >}}, it is necessary to modify two files. {{< note >}} -This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on Platform.sh. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. +This guide only covers the *addition* of a service configuration to an existing Spring project already configured to deploy on {{< vendor/name >}}. Please see the [deployment guide](/guides/spring/deploy/_index.md) for more detailed instructions for setting up app containers and initial projects. {{< /note >}} ## 1. Add the Redis service @@ -28,7 +28,7 @@ In your [app configuration](../../create-apps/app-reference.md), use the service ## 3. Export connection credentials to the environment -Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Spring. On Platform.sh, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: +Connection credentials for Redis, like any service, are exposed to the application container through the `PLATFORM_RELATIONSHIPS` environment variable from the deploy hook onward. Since this variable is a base64 encoded JSON object of all of your project's services, you'll likely want a clean way to extract the information specific to Elasticsearch into it's own environment variables that can be used by Spring. On {{< vendor/name >}}, custom environment variables can be defined programmatically in a `.environment` file using `jq` to do just that: ```text export SPRING_REDIS_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".redisdata[0].host") diff --git a/sites/platform/src/guides/strapi/_index.md b/sites/platform/src/guides/strapi/_index.md index 433d6c9562..6a239ab7ac 100644 --- a/sites/platform/src/guides/strapi/_index.md +++ b/sites/platform/src/guides/strapi/_index.md @@ -2,7 +2,7 @@ title: "Strapi" weight: -70 description: | - Everything you need to get started with [Strapi](https://www.strapi.io/), the open source headless CMS based on NodeJS, on Platform.sh. + Everything you need to get started with [Strapi](https://www.strapi.io/), the open source headless CMS based on NodeJS, on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/strapi/adding-frontends/_index.md b/sites/platform/src/guides/strapi/adding-frontends/_index.md index 96aec2eca1..ab8e36ac33 100644 --- a/sites/platform/src/guides/strapi/adding-frontends/_index.md +++ b/sites/platform/src/guides/strapi/adding-frontends/_index.md @@ -13,7 +13,7 @@ This helps with serving external data to a frontend at build time. Supported by Strapi's plugin ecosystem, data from Strapi (or headless) CMS can be served into a frontend application, with that frontend typically located on a server elsewhere. -Platform.sh provides a platform for this architectural pattern through a [multi-app configuration](../../../create-apps/multi-app/_index.md). +{{< vendor/name >}} provides a platform for this architectural pattern through a [multi-app configuration](../../../create-apps/multi-app/_index.md). Consider the following project structure: @@ -42,18 +42,18 @@ Gatsby is just one example of a frontend that can be used with this pattern. {{% guides/requirements %}} -## Signing up for Platform.sh +## Signing up -Each of the frontend guides below has a **Deploy on Platform.sh** button that deploys the guide's project for you +Each of the frontend guides below has a **Deploy on {{< vendor/name >}}** button that deploys the guide's project for you and also signs you up for a trial account. If you're planning on deploying a template and following along with these guides for greater context, feel free to move onto the next section. -If you're planning on using the templates and guides to deploy your existing codebase to Platform.sh, -you first need to [register for a trial Platform.sh account](https://auth.api.platform.sh/register). +If you're planning on using the templates and guides to deploy your existing codebase to {{< vendor/name >}}, +you first need to [register for a trial {{< vendor/name >}} account](https://auth.api.platform.sh/register). If you don't want to sign up initially with your e-mail address, you can sign up using an existing GitHub, Bitbucket, or Google account. -If you choose one of these options, you can set a password for your Platform.sh account later. +If you choose one of these options, you can set a password for your {{< vendor/name >}} account later. After creating an account, you're prompted to create your first project. Since you are providing your own code, use the **Blank project** option. @@ -63,18 +63,18 @@ This is especially important with multi-application projects, so for more detail ## Plan size -There are a few important points to keep in mind when deploying this pattern if you've already [deployed Gatsby by itself](../../gatsby/deploy/_index.md) on Platform.sh, which are relevant to each backend example. +There are a few important points to keep in mind when deploying this pattern if you've already [deployed Gatsby by itself](../../gatsby/deploy/_index.md) on {{< vendor/name >}}, which are relevant to each backend example. After following the steps below, you may find that Gatsby fails to bundle assets during its build if your plan size is Development. This is a factor of both the size and number of Gatsby's dependencies on the frontend, as well as the amount of data being pulled from the backend. -Multi-application projects generally require more resources to run on Platform.sh, and so the trial's default Development plan may not be enough to run your existing site. +Multi-application projects generally require more resources to run on {{< vendor/name >}}, and so the trial's default Development plan may not be enough to run your existing site. You are free to either proceed with a smaller plan to test or increase the resources at this point for the project. Otherwise, it may be best to initially deploy the templates listed in each backend guide to start out -and later modify that project to include your own code with more resources as you get used to developing on Platform.sh. +and later modify that project to include your own code with more resources as you get used to developing on {{< vendor/name >}}. ## Frontends for Strapi -Platform.sh maintains a number of [multi-application templates](https://github.com/platformsh-templates/?q=strapi&type=&language=) for Strapi that generally have very similar configuration changes on the Strapi side. +{{< vendor/name >}} maintains a number of [multi-application templates](https://github.com/platformsh-templates/?q=strapi&type=&language=) for Strapi that generally have very similar configuration changes on the Strapi side. Below are a few of those written as short guides for different frontends. diff --git a/sites/platform/src/guides/strapi/adding-frontends/gatsby.md b/sites/platform/src/guides/strapi/adding-frontends/gatsby.md index bc95166e49..56d0118d26 100644 --- a/sites/platform/src/guides/strapi/adding-frontends/gatsby.md +++ b/sites/platform/src/guides/strapi/adding-frontends/gatsby.md @@ -1,5 +1,5 @@ --- -title: "How to deploy Strapi with a Gatsby frontend on Platform.sh" +title: "How to deploy Strapi with a Gatsby frontend on {{< vendor/name >}}" sidebarTitle: "Gatsby" description: | You can build out an API from scratch with Strapi and then connect its data to a frontend Gatsby app with `gatsby-source-strapi`. @@ -7,7 +7,7 @@ description: | {{< guides/gatsby/headless-intro template="gatsby-strapi" name="Strapi" >}} -## Shared Platform.sh configuration +## Shared {{< vendor/name >}} configuration {{% guides/gatsby/headless-project name="Strapi" %}} diff --git a/sites/platform/src/guides/strapi/database-configuration/_index.md b/sites/platform/src/guides/strapi/database-configuration/_index.md index 67ee77c057..6ab3ba9bb1 100644 --- a/sites/platform/src/guides/strapi/database-configuration/_index.md +++ b/sites/platform/src/guides/strapi/database-configuration/_index.md @@ -1,9 +1,9 @@ --- -title: "Configuring Database Services for Strapi on Platform.sh" +title: "Configuring Database Services for Strapi on {{< vendor/name >}}" sidebarTitle: "Database Configuration" weight: -90 description: | - Configure a preferred database for your Strapi application on Platform.sh + Configure a preferred database for your Strapi application on {{< vendor/name >}} --- Strapi requires a database in order for it to run successfully. It currently has support for the following database types: diff --git a/sites/platform/src/guides/strapi/database-configuration/mongodb.md b/sites/platform/src/guides/strapi/database-configuration/mongodb.md index 5fe247818d..58d9015fea 100644 --- a/sites/platform/src/guides/strapi/database-configuration/mongodb.md +++ b/sites/platform/src/guides/strapi/database-configuration/mongodb.md @@ -1,14 +1,14 @@ --- -title: "Configure MongoDB for Strapi on Platform.sh" +title: "Configure MongoDB for Strapi on {{< vendor/name >}}" sidebarTitle: "MongoDB" weight: -70 description: | - Configure your strapi application to use a MongoDB database on Platform.sh (v3 only). + Configure your strapi application to use a MongoDB database on {{< vendor/name >}} (v3 only). --- Strapi can also be configured to use MongoDB as its default database, although due to compatibility issues this database type is only available in Strapi v3 and [not supported in Strapi v4](https://forum.strapi.io/t/mongodb-compatibility-delayed-on-v4/4549). -To use MongoDB with a Strapi v3 application on Platform.sh, follow these steps. +To use MongoDB with a Strapi v3 application on {{< vendor/name >}}, follow these steps. 1. Install the [Strapi mongoose connector](https://yarnpkg.com/package/strapi-connector-mongoose) @@ -50,11 +50,11 @@ To use MongoDB with a Strapi v3 application on Platform.sh, follow these steps. }; if (config.isValidPlatform() && !config.inBuild()) { - // Platform.sh database configuration. + // {{< vendor/name >}} database configuration. const credentials = config.credentials(dbRelationshipMongo); console.log( - `Using Platform.sh configuration with relationship ${dbRelationshipMongo}.` + `Using {{< vendor/name >}} configuration with relationship ${dbRelationshipMongo}.` ); settings = { @@ -74,12 +74,12 @@ To use MongoDB with a Strapi v3 application on Platform.sh, follow these steps. if (config.isValidPlatform()) { // Build hook configuration message. console.log( - "Using default configuration during Platform.sh build hook until relationships are available." + "Using default configuration during {{< vendor/name >}} build hook until relationships are available." ); } else { // Strapi default local configuration. console.log( - "Not in a Platform.sh Environment. Using default local sqlite configuration." + "Not in a {{< vendor/name >}} Environment. Using default local sqlite configuration." ); } } @@ -96,4 +96,4 @@ To use MongoDB with a Strapi v3 application on Platform.sh, follow these steps. }; ``` -This configuration instructs Platform.sh to deploy your Strapi v3 app with a MongoDB database. +This configuration instructs {{< vendor/name >}} to deploy your Strapi v3 app with a MongoDB database. diff --git a/sites/platform/src/guides/strapi/database-configuration/mysql.md b/sites/platform/src/guides/strapi/database-configuration/mysql.md index 8ad1e7d521..0b8f1b7e60 100644 --- a/sites/platform/src/guides/strapi/database-configuration/mysql.md +++ b/sites/platform/src/guides/strapi/database-configuration/mysql.md @@ -1,15 +1,15 @@ --- -title: "Configure MySQL for Strapi on Platform.sh" +title: "Configure MySQL for Strapi on {{< vendor/name >}}" sidebarTitle: "MySQL" weight: -80 description: | - Configure your Strapi application to use a MySQL database on Platform.sh. + Configure your Strapi application to use a MySQL database on {{< vendor/name >}}. --- Strapi can be configured to use MySQL as its default database. You can choose MySQL when installing your app by selecting custom and MySQL when asked for the installation type. Or you can just configure your existing Strapi application to use MySQL. -To configure a MySQL database for Strapi on Platform.sh, follow these steps. +To configure a MySQL database for Strapi on {{< vendor/name >}}, follow these steps. 1. Install the Node.js [MySQL driver](https://yarnpkg.com/package/mysql) @@ -59,11 +59,11 @@ To configure a MySQL database for Strapi on Platform.sh, follow these steps. }; if (config.isValidPlatform() && !config.inBuild()) { - // Platform.sh database configuration. + // {{< vendor/name >}} database configuration. try { const credentials = config.credentials(dbRelationship); console.log( - `Using Platform.sh configuration with relationship ${dbRelationship}.` + `Using {{< vendor/name >}} configuration with relationship ${dbRelationship}.` ); pool = { @@ -99,13 +99,13 @@ To configure a MySQL database for Strapi on Platform.sh, follow these steps. if (config.isValidPlatform()) { // Build hook configuration message. console.log( - "Using default configuration during Platform.sh build hook until relationships are available." + "Using default configuration during {{< vendor/name >}} build hook until relationships are available." ); } else { // Strapi default local configuration. console.log( - "Not in a Platform.sh Environment. Using default local sqlite configuration." + "Not in a {{< vendor/name >}} Environment. Using default local sqlite configuration." ); } } diff --git a/sites/platform/src/guides/strapi/database-configuration/postgresql.md b/sites/platform/src/guides/strapi/database-configuration/postgresql.md index 281d0dc843..ef1ed3289c 100644 --- a/sites/platform/src/guides/strapi/database-configuration/postgresql.md +++ b/sites/platform/src/guides/strapi/database-configuration/postgresql.md @@ -1,15 +1,15 @@ --- -title: "Configure PostgreSQL for Strapi on Platform.sh" +title: "Configure PostgreSQL for Strapi on {{< vendor/name >}}" sidebarTitle: "PostgreSQL" weight: -90 description: | - Configure your Strapi application to use a PostgreSQL database on Platform.sh. + Configure your Strapi application to use a PostgreSQL database on {{< vendor/name >}}. --- Strapi can be configured to use PostgreSQL as its default database. You can choose PostgreSQL when installing your app by selecting custom and PostgreSQL when asked for the installation type or you can just configure your existing Strapi application to use PostgreSQL. -To configure a PostgreSQL database for Strapi on Platform.sh, follow these steps. +To configure a PostgreSQL database for Strapi on {{< vendor/name >}}, follow these steps. 1. Install [PostgreSQL](https://www.postgresql.org/download/) on your machine and [pg](https://www.npmjs.com/package/pg) in your Strapi project. @@ -54,10 +54,10 @@ To configure a PostgreSQL database for Strapi on Platform.sh, follow these steps }; if (config.isValidPlatform() && !config.inBuild()) { - // Platform.sh database configuration. + // {{< vendor/name >}} database configuration. const credentials = config.credentials(dbRelationship); console.log( - `Using Platform.sh configuration with relationship ${dbRelationship}.` + `Using {{< vendor/name >}} configuration with relationship ${dbRelationship}.` ); let pool = { @@ -89,12 +89,12 @@ To configure a PostgreSQL database for Strapi on Platform.sh, follow these steps if (config.isValidPlatform()) { // Build hook configuration message. console.log( - "Using default configuration during Platform.sh build hook until relationships are available." + "Using default configuration during {{< vendor/name >}} build hook until relationships are available." ); } else { // Strapi default local configuration. console.log( - "Not in a Platform.sh Environment. Using default local sqlite configuration." + "Not in a {{< vendor/name >}} Environment. Using default local sqlite configuration." ); } } diff --git a/sites/platform/src/guides/strapi/database-configuration/sqlite.md b/sites/platform/src/guides/strapi/database-configuration/sqlite.md index 7c922ee0da..8e67902e94 100644 --- a/sites/platform/src/guides/strapi/database-configuration/sqlite.md +++ b/sites/platform/src/guides/strapi/database-configuration/sqlite.md @@ -1,9 +1,9 @@ --- -title: "Configure SQLite for Strapi on Platform.sh" +title: "Configure SQLite for Strapi on {{< vendor/name >}}" sidebarTitle: "SQLite" weight: -100 description: | - Configure your Strapi application to use a SQLite database on Platform.sh. + Configure your Strapi application to use a SQLite database on {{< vendor/name >}}. --- Strapi uses SQLite database by default when it's run on a local machine. @@ -48,10 +48,10 @@ Since Strapi uses SQLite by default, you don't need much configuration, just fol }; if (config.isValidPlatform() && !config.inBuild()) { - // Platform.sh database configuration. + // {{< vendor/name >}} database configuration. try { const credentials = config.credentials(dbRelationship); - console.log(`Using Platform.sh configuration with relationship ${dbRelationship}.`); + console.log(`Using {{< vendor/name >}} configuration with relationship ${dbRelationship}.`); pool = { min: 0, @@ -87,10 +87,10 @@ Since Strapi uses SQLite by default, you don't need much configuration, just fol } else { if (config.isValidPlatform()) { // Build hook configuration message. - console.log('Using default configuration during Platform.sh build hook until relationships are available.'); + console.log('Using default configuration during {{< vendor/name >}} build hook until relationships are available.'); } else { // Strapi default local configuration. - console.log('Not in a Platform.sh Environment. Using default local sqlite configuration.'); + console.log('Not in a {{< vendor/name >}} Environment. Using default local sqlite configuration.'); } } diff --git a/sites/platform/src/guides/strapi/deploy/_index.md b/sites/platform/src/guides/strapi/deploy/_index.md index d93dc2036b..2d798c1c80 100644 --- a/sites/platform/src/guides/strapi/deploy/_index.md +++ b/sites/platform/src/guides/strapi/deploy/_index.md @@ -1,10 +1,10 @@ --- -title: Deploy Strapi on Platform.sh +title: Deploy Strapi on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy Strapi. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy Strapi. --- [Strapi](https://strapi.io) is an open-source headless CMS for building fast and manageable APIs written in JavaScript. diff --git a/sites/platform/src/guides/strapi/deploy/configure.md b/sites/platform/src/guides/strapi/deploy/configure.md index 1284176bdc..db08812106 100644 --- a/sites/platform/src/guides/strapi/deploy/configure.md +++ b/sites/platform/src/guides/strapi/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure Strapi for Platform.sh" +title: "Configure Strapi for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for Strapi. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for Strapi. --- {{% guides/config-desc name="Strapi" %}} @@ -16,15 +16,15 @@ If you would rather use npm to manage your dependencies, you can: 1. Delete `yarn` from the build hook. 2. Replace `yarn build` in the build hook with `npm run build`. 3. Delete the `build.flavor` block. - When this is set to `none`, Platform.sh to rely solely on the build hook to define the build process. + When this is set to `none`, {{< vendor/name >}} to rely solely on the build hook to define the build process. By default, Node.js containers run `npm install` prior to the build hook, so this block can be removed entirely from the configuration. 4. Delete the `dependencies` block, which includes yarn. The relationships block is responsible for providing access to the data sources (services) that the Strapi application needs. -Since Platform.sh is read-only during build, mainly for security purposes, certain folders need to be mounted. -Platform.sh allows you to mount directories that need write access during the deploy phase with the `mounts` key. +Since {{< vendor/name >}} is read-only during build, mainly for security purposes, certain folders need to be mounted. +{{< vendor/name >}} allows you to mount directories that need write access during the deploy phase with the `mounts` key. In this case, the following folders are mounted for Strapi. - `.cache` file @@ -49,7 +49,7 @@ To use another service, replace `postgresql:12` in the example below with the na # The services of the project. # Each service listed is deployed -# to power your Platform.sh project. +# to power your {{< vendor/name >}} project. db: type: postgresql:12 diff --git a/sites/platform/src/guides/strapi/deploy/deploy.md b/sites/platform/src/guides/strapi/deploy/deploy.md index 0419642478..13a09654d1 100644 --- a/sites/platform/src/guides/strapi/deploy/deploy.md +++ b/sites/platform/src/guides/strapi/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy Strapi" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/strapi/local-development/_index.md b/sites/platform/src/guides/strapi/local-development/_index.md index 5a6ae7e0cc..a9d77e1dc4 100644 --- a/sites/platform/src/guides/strapi/local-development/_index.md +++ b/sites/platform/src/guides/strapi/local-development/_index.md @@ -1,12 +1,12 @@ --- -title: "Local development: Running Strapi on your local machine with Platform.sh" +title: "Local development: Running Strapi on your local machine with {{< vendor/name >}}" sidebarTitle: "Local development" weight: -80 description: | - Run your Strapi application deployed on Platform.sh on your local machine + Run your Strapi application deployed on {{< vendor/name >}} on your local machine --- -Platform.sh provides support for locally running a Strapi application that has been deployed on Platform.sh including its services. -This means that once you download the code of the Strapi project you deployed on Platform.sh, -you can make changes to the project without pushing to Platform.sh each time to test them. -You can build your app locally using the Platform.sh CLI, even when its functionality depends on a number of services. You can run your Strapi application locally with all of it’s services by following the steps for your Strapi version: +{{< vendor/name >}} provides support for locally running a Strapi application that has been deployed on {{< vendor/name >}} including its services. +This means that once you download the code of the Strapi project you deployed on {{< vendor/name >}}, +you can make changes to the project without pushing to {{< vendor/name >}} each time to test them. +You can build your app locally using the {{< vendor/name >}} CLI, even when its functionality depends on a number of services. You can run your Strapi application locally with all of it’s services by following the steps for your Strapi version: diff --git a/sites/platform/src/guides/strapi/local-development/local-development-v3.md b/sites/platform/src/guides/strapi/local-development/local-development-v3.md index f7bd4a7727..2513338ae7 100644 --- a/sites/platform/src/guides/strapi/local-development/local-development-v3.md +++ b/sites/platform/src/guides/strapi/local-development/local-development-v3.md @@ -30,10 +30,10 @@ let options = { }; if (config.isValidPlatform() && !config.inBuild()) { - // Platform.sh database configuration. + // {{< vendor/name >}} database configuration. const credentials = config.credentials(dbRelationship); console.log( - `Using Platform.sh configuration with relationship ${dbRelationship}.` + `Using {{< vendor/name >}} configuration with relationship ${dbRelationship}.` ); settings = { @@ -63,12 +63,12 @@ if (config.isValidPlatform() && !config.inBuild()) { if (config.isValidPlatform()) { // Build hook configuration message. console.log( - "Using default configuration during Platform.sh build hook until relationships are available." + "Using default configuration during {{< vendor/name >}} build hook until relationships are available." ); } else { // Strapi default local configuration. console.log( - "Not in a Platform.sh Environment. Using default local sqlite configuration." + "Not in a {{< vendor/name >}} Environment. Using default local sqlite configuration." ); } } diff --git a/sites/platform/src/guides/strapi/local-development/local-development-v4.md b/sites/platform/src/guides/strapi/local-development/local-development-v4.md index 7011e04a97..41be47a4d6 100644 --- a/sites/platform/src/guides/strapi/local-development/local-development-v4.md +++ b/sites/platform/src/guides/strapi/local-development/local-development-v4.md @@ -6,14 +6,14 @@ description: How to develop a Strapi v4 app locally. To run your Strapi v4 app locally with all of its services, follow these steps: -1. Download your deployed code by running the following command using the Platform.sh CLI: +1. Download your deployed code by running the following command using the {{< vendor/name >}} CLI: ```bash platform get {{< variable "PROJECT_ID" >}} ``` 2. Create a new branch. - Whenever you develop Platform.sh, you should develop in an isolated environment. + Whenever you develop {{< vendor/name >}}, you should develop in an isolated environment. This way you aren't opening SSH tunnels to your production environment. By creating a branch from your default environment, you create a new environment with copies of all production code and data. @@ -33,14 +33,14 @@ To run your Strapi v4 app locally with all of its services, follow these steps: const path = require("path"); let connection; let db_relationship = "postgresdatabase"; - // Helper function for decoding Platform.sh base64-encoded JSON variables. + // Helper function for decoding {{< vendor/name >}} base64-encoded JSON variables. function decode(value) { return JSON.parse(Buffer.from(value, "base64")); } if (!process.env.PLATFORM_RELATIONSHIPS) { if (process.env.PLATFORM_PROJECT) { console.log( - "In Platform.sh build hook. Using default SQLite configuration until services are available." + "In {{< vendor/name >}} build hook. Using default SQLite configuration until services are available." ); } else { console.log( @@ -64,7 +64,7 @@ To run your Strapi v4 app locally with all of its services, follow these steps: } else { if (process.env.PLATFORM_PROJECT) { console.log( - "In Platform.sh deploy hook. Using defined service configuration." + "In {{< vendor/name >}} deploy hook. Using defined service configuration." ); } else { console.log("Using tunnel for local development."); diff --git a/sites/platform/src/guides/symfony/_index.md b/sites/platform/src/guides/symfony/_index.md index e3b305e548..7a059323c0 100644 --- a/sites/platform/src/guides/symfony/_index.md +++ b/sites/platform/src/guides/symfony/_index.md @@ -2,7 +2,7 @@ title: "Symfony" weight: -150 description: | - Everything you need to get started with [Symfony](https://www.symfony.com/), a [PHP](../../development/templates.md#php) framework for web development, on Platform.sh. + Everything you need to get started with [Symfony](https://www.symfony.com/), a [PHP](../../development/templates.md#php) framework for web development, on {{< vendor/name >}}. --- {{% description %}} @@ -10,7 +10,7 @@ description: | [comment]: <> (If you already have a Symfony project ready to deploy,) -[comment]: <> (see the template's [example Platform.sh files](https://github.com/symfonycorp/platformsh-symfony-template/tree/6.2).) +[comment]: <> (see the template's [example {{< vendor/name >}} files](https://github.com/symfonycorp/platformsh-symfony-template/tree/6.2).) [comment]: <> (These files let you [configure your app](../../create-apps/_index.md),) diff --git a/sites/platform/src/guides/symfony/crons.md b/sites/platform/src/guides/symfony/crons.md index 1650fa2207..10f5f1d563 100644 --- a/sites/platform/src/guides/symfony/crons.md +++ b/sites/platform/src/guides/symfony/crons.md @@ -46,7 +46,7 @@ symfony var:create -y --level=project --name=env:MAILTO --value=sysadmin@example To ensure better reliability, `croncape` sends the emails using: - `project-id@cron.noreply.platformsh.site` as the sender address (`project-id+branch@cron.noreply.platformsh.site` for non-main environments) -- the provided [Platform.sh SMTP service](./environment-variables#emails), even if you define your own `MAILER_*` environment variables +- the provided [{{< vendor/name >}}SMTP service](./environment-variables#emails), even if you define your own `MAILER_*` environment variables To use a custom SMTP and/or custom sender address, follow these steps: diff --git a/sites/platform/src/guides/symfony/environment-variables.md b/sites/platform/src/guides/symfony/environment-variables.md index 18c092a9b5..d9c32d406e 100644 --- a/sites/platform/src/guides/symfony/environment-variables.md +++ b/sites/platform/src/guides/symfony/environment-variables.md @@ -5,7 +5,7 @@ description: | Learn about the environment variables added by the Symfony integration. --- -By default, Platform.sh exposes some [environment variables](/development/variables/use-variables#use-platformsh-provided-variables). +By default, {{< vendor/name >}} exposes some [environment variables](/development/variables/use-variables#use-provided-variables). If you're using the [Symfony integration](./integration), more [infrastructure environment variables](#symfony-environment-variables) related to Symfony are defined. @@ -22,7 +22,7 @@ and [service](https://github.com/symfony-cli/symfony-cli/blob/main/envs/envs.go# ## Symfony environment variables -Platform.sh exposes [environment variables](/development/variables/use-variables#use-platformsh-provided-variables) +{{< vendor/name >}} exposes [environment variables](/development/variables/use-variables#use-provided-variables) about the app and its infrastructure. The Symfony integration exposes more environment variables: @@ -35,7 +35,7 @@ The Symfony integration exposes more environment variables: You can manually override this value for a development environment by setting the `SYMFONY_DEBUG` environment variable to `1`, and remove it when done. -- `APP_SECRET` is set to the value of `PLATFORM_PROJECT_ENTROPY`, which is a random and unique value for all Platform.sh projects. +- `APP_SECRET` is set to the value of `PLATFORM_PROJECT_ENTROPY`, which is a random and unique value for all {{< vendor/name >}} projects. It overrides the value configured in the `.env` file of your app. - `MAILFROM` is set to a random value. diff --git a/sites/platform/src/guides/symfony/faq.md b/sites/platform/src/guides/symfony/faq.md index 6ff0f039a7..4e8cef4a41 100644 --- a/sites/platform/src/guides/symfony/faq.md +++ b/sites/platform/src/guides/symfony/faq.md @@ -2,7 +2,7 @@ title: "FAQ" weight: 200 description: | - Troubleshoot issue you might encounter using [Symfony](https://www.symfony.com/), a [PHP](/development/templates.md#php) framework on Platform.sh. + Troubleshoot issue you might encounter using [Symfony](https://www.symfony.com/), a [PHP](/development/templates.md#php) framework on {{< vendor/name >}}. --- ## How can I access my application logs? @@ -18,7 +18,7 @@ This includes language errors such as PHP errors, warnings, notices, as well as uncaught exceptions. The file also contains your application logs if you log on `stderr`. -Note that Platform.sh manages the `app` file for you. +Note that {{< vendor/name >}} manages the `app` file for you. This is to prevent disks from getting filled and using very fast local drives instead of slower network disks. Make sure your apps always output their logs to `stderr`. @@ -52,7 +52,7 @@ The *Oops! An Error Occurred* message comes from your app and is automatically g ![A 500 error page in production mode](/images/symfony/production-error-500.png "0.35") -If your app's working as expected locally but you see the previous error message on Platform.sh, +If your app's working as expected locally but you see the previous error message on {{< vendor/name >}}, it usually means you have a configuration error or a missing dependency. To fix this issue, search your application logs. @@ -84,11 +84,11 @@ As a result, when you run your project locally, the following welcome page is di ![The default Symfony welcome page in development mode](/images/symfony/new-symfony-welcome-page.png "0.45") -But when you run your project on Platform.sh, the following error is displayed instead: +But when you run your project on {{< vendor/name >}}, the following error is displayed instead: ![A 404 error page in production mode](/images/symfony/production-error-404.png "0.35") -This is because Platform.sh runs in production mode, leading Symfony to show a generic 404 error. +This is because {{< vendor/name >}} runs in production mode, leading Symfony to show a generic 404 error. To fix this issue, [create your first Symfony page](https://symfony.com/doc/current/page_creation.html). If you've already created a custom homepage, make sure you perform the following actions: diff --git a/sites/platform/src/guides/symfony/get-started.md b/sites/platform/src/guides/symfony/get-started.md index 9c514dec32..8508e8dcb9 100644 --- a/sites/platform/src/guides/symfony/get-started.md +++ b/sites/platform/src/guides/symfony/get-started.md @@ -3,26 +3,26 @@ title: Get Started weight: -255 layout: single description: | - See how to get started deploying Symfony on Platform.sh. + See how to get started deploying Symfony on {{< vendor/name >}}. --- [Symfony](https://symfony.com/) is a PHP framework that you can use to create web applications. -Platform.sh is the official Symfony PaaS. +{{< vendor/name >}} is the official Symfony PaaS. -This guide provides instructions for deploying, and working with, Symfony on Platform.sh. +This guide provides instructions for deploying, and working with, Symfony on {{< vendor/name >}}. {{% guides/requirements name="Symfony" %}} {{< note >}} -The Symfony CLI wraps the [Platform.sh CLI](/administration/cli/_index.md) with added features related to Symfony. +The Symfony CLI wraps the [{{< vendor/name >}} CLI](/administration/cli/_index.md) with added features related to Symfony. So when using Symfony, you can replace `platform ` by `symfony cloud:` in all of your commands. {{< /note >}} ## Create your Symfony app -To get familiar with Platform.sh, create a new Symfony project from scratch. +To get familiar with {{< vendor/name >}}, create a new Symfony project from scratch. The present tutorial uses the [Symfony Demo](https://symfony.com/doc/current/setup.html#the-symfony-demo-application) app as an example : ```bash @@ -31,14 +31,14 @@ cd {{< variable "PROJECT_NAME" >}} ``` The `--demo` flag pulls the [Symfony Demo skeleton](https://github.com/symfony/demo).
-The `--cloud` flag automatically generates the Platform.sh configuration files. +The `--cloud` flag automatically generates the {{< vendor/name >}} configuration files. {{< note >}} Alternatively, you can deploy an **existing Symfony project**. To do so, follow these steps: -1. To generate a sensible default Platform.sh configuration, +1. To generate a sensible default {{< vendor/name >}} configuration, run the following command from within the project's directory: ```bash @@ -51,19 +51,19 @@ To do so, follow these steps: ```bash git add .platform.app.yaml .platform/services.yaml .platform/routes.yaml php.ini - git commit -m "Add Platform.sh configuration" + git commit -m "Add {{< vendor/name >}} configuration" ``` {{< /note >}} -Platform.sh manages the entire infrastructure of your project, +{{< vendor/name >}} manages the entire infrastructure of your project, from code to services (such as databases, queues, or search engines), all the way to email sending, [cron jobs](./crons), and [workers](./workers). This infrastructure is described through configuration files stored alongside your code. -## Create the project on Platform.sh +## Create the project -To create the project on Platform.sh, run the following command from within the project's directory: +To create the project on {{< vendor/name >}}, run the following command from within the project's directory: ```bash symfony cloud:create --title PROJECT_TITLE --set-remote @@ -73,7 +73,7 @@ The `--set-remote` flag sets the new project as the remote for this repository. {{< note title="Tip" >}} -You can link any repository to an existing Platform.sh project using the following command: +You can link any repository to an existing {{< vendor/name >}} project using the following command: ```bash symfony project:set-remote {{< variable "PROJECT_ID" >}} @@ -91,18 +91,18 @@ symfony cloud:deploy {{< note title="Tip" >}} -During deployment, the logs from the Platform.sh API are displayed in your terminal so you can monitor progress. +During deployment, the logs from the {{< vendor/name >}} API are displayed in your terminal so you can monitor progress. To stop the display of the logs **without interrupting the deployment**, use `CTRL+C` in your terminal. To go back to displaying the logs, run `symfony cloud:activity:log`. {{< /note >}} -Congratulations, your first Symfony app has been deployed on Platform.sh! +Congratulations, your first Symfony app has been deployed on {{< vendor/name >}}! Now that your app is deployed in production mode, you can define a custom domain for your live website. -To do so, see how to [set up a custom domain on Platform.sh](/administration/web/configure-project.html#domains), +To do so, see how to [set up a custom domain on {{< vendor/name >}}](/administration/web/configure-project.html#domains), or run the following command: ```bash @@ -126,7 +126,7 @@ To make changes to your project, follow these steps: ``` This command creates a new local `feat-a` Git branch based on the main Git branch - and activates a related environment on Platform.sh. + and activates a related environment on {{< vendor/name >}}. The new environment inherits the data (service data and assets) of its parent environment (the production environment here). 2. Make changes to your project. @@ -138,7 +138,7 @@ To make changes to your project, follow these steps: {% block body %}
-

{{ 'title.homepage'|trans|raw }}

- +

Welcome to the Platform.sh Demo

+ +

Welcome to the {{< vendor/name >}} Demo

@@ -187,7 +187,7 @@ To make changes to your project, follow these steps: ## Use a third-party Git provider -When you choose to use a third-party Git hosting service, the Platform.sh Git +When you choose to use a third-party Git hosting service, the {{< vendor/name >}} Git repository becomes a read-only mirror of the third-party repository. All your changes take place in the third-party repository. @@ -202,7 +202,7 @@ Add an integration to your existing third-party repository: ### Symfony integration Learn more about the [Symfony integration](./integration), -a set of tools and auto-configurations that makes it easier to use Platform.sh for Symfony projects. +a set of tools and auto-configurations that makes it easier to use {{< vendor/name >}} for Symfony projects. ### Environment variables @@ -211,7 +211,7 @@ more [environment variables](./environment-variables) related to Symfony are def ### Local development -Once Symfony has been deployed on Platform.sh, +Once Symfony has been deployed on {{< vendor/name >}}, you might want to [set up a local development environment](./local). ### Symfony CLI tips diff --git a/sites/platform/src/guides/symfony/integration.md b/sites/platform/src/guides/symfony/integration.md index 0600fe9b3d..ea7413bac0 100644 --- a/sites/platform/src/guides/symfony/integration.md +++ b/sites/platform/src/guides/symfony/integration.md @@ -2,10 +2,10 @@ title: "Symfony Integration" weight: -130 description: | - Learn how to use the Symfony integration for a better Platform.sh experience. + Learn how to use the Symfony integration for a better {{< vendor/name >}} experience. --- -Symfony has a special integration with Platform.sh that makes it easier to use Platform.sh for Symfony projects. +Symfony has a special integration with {{< vendor/name >}} that makes it easier to use {{< vendor/name >}} for Symfony projects. **When using the Symfony integration, you are contributing financially to the Symfony project.** @@ -14,9 +14,9 @@ The Symfony integration is automatically enabled when: - You run the `symfony new` command with the `--cloud` option; - You run `symfony project:init` on an existing project to automatically - generate the Platform.sh configuration. + generate the {{< vendor/name >}} configuration. -If you already have a Platform.sh configuration without the Symfony +If you already have a {{< vendor/name >}} configuration without the Symfony integration, enable it by adding the following configuration: ```yaml {location=".platform.app.yaml"} @@ -45,7 +45,7 @@ services](./environment-variables#service-environment-variables). ## Tools -The **configurator** (`curl -fs https://get.symfony.com/cloud/configurator | bash`) is a script specially crafted for Platform.sh. +The **configurator** (`curl -fs https://get.symfony.com/cloud/configurator | bash`) is a script specially crafted for {{< vendor/name >}}. It ensures that projects are always using the latest version of the following tools: - [croncape](./crons#use-croncape) for cron feedback @@ -54,7 +54,7 @@ It ensures that projects are always using the latest version of the following to ## Hooks -The `hooks` section defines the scripts that Platform.sh runs at specific times of an application lifecycle: +The `hooks` section defines the scripts that {{< vendor/name >}} runs at specific times of an application lifecycle: - The [build hook](../../create-apps/hooks/hooks-comparison.md#build-hook) is run during the build process - The [deploy hook](../../create-apps/hooks/hooks-comparison.md#deploy-hook) is run during the deployment process @@ -88,7 +88,7 @@ To have your hooks fail on the first failed command, start your scripts with `se For more information, see [Hooks](../../../create-apps/hooks/hooks-comparison). To gain a better understanding of how hooks relate to each other when building and deploying an app, -see the [Platform.sh philosophy](../../overview/philosophy.md). +see the [{{< vendor/name >}} philosophy](../../overview/philosophy.md). {{< note title="Tip">}} @@ -108,7 +108,7 @@ hooks: ### symfony-build -**symfony-build** is the script that builds a Symfony app in an optimized way for Platform.sh. +**symfony-build** is the script that builds a Symfony app in an optimized way for {{< vendor/name >}}. Use it as the main build script in your `build` hook. **symfony-build** performs the following actions: @@ -159,9 +159,9 @@ It only works if you're using the [`symfony-build` script](#symfony-build) in yo ### php-ext-install You can use the **php-ext-install** script to compile and install PHP extensions -not provided out of the box by Platform.sh, +not provided out of the box by {{< vendor/name >}}, or when you need a specific version of an extension. -The script is written specifically for Platform.sh to ensure fast and reliable setup during the build step. +The script is written specifically for {{< vendor/name >}} to ensure fast and reliable setup during the build step. **php-ext-install** currently supports three ways of fetching sources: diff --git a/sites/platform/src/guides/symfony/local.md b/sites/platform/src/guides/symfony/local.md index 04e7e022be..495b3aeae7 100644 --- a/sites/platform/src/guides/symfony/local.md +++ b/sites/platform/src/guides/symfony/local.md @@ -2,11 +2,11 @@ title: Local development weight: -80 description: | - Sync Platform.sh with your local environments to start contributing. + Sync {{< vendor/name >}} with your local environments to start contributing. --- When you develop a Symfony project, a significant amount of work takes place -locally rather than on an active Platform.sh environment. You want to ensure +locally rather than on an active {{< vendor/name >}} environment. You want to ensure that the process of local development is as close as possible to a deployed environment. @@ -14,7 +14,7 @@ You can achieve this through various approaches. For example, you can use Symfony Server with tethered data To do so, when testing changes locally, you can connect your locally running -Symfony Server to service containers on an active Platform.sh environment. +Symfony Server to service containers on an active {{< vendor/name >}} environment. This methodology has several advantages: @@ -74,7 +74,7 @@ This starts the Symfony Server and opens the app in your local browser. export PLATFORM_RELATIONSHIPS="$(symfony tunnel:info --encode)" ``` -3. To expose Platform.sh services to your Symfony app, run the following +3. To expose {{< vendor/name >}} services to your Symfony app, run the following command: ```bash @@ -82,9 +82,9 @@ This starts the Symfony Server and opens the app in your local browser. ``` This automatically configures your local Symfony app to use all your - remote Platform.sh services (remote database, remote Redis component, etc.). + remote {{< vendor/name >}} services (remote database, remote Redis component, etc.). - To check that you're now using remote data and components from Platform.sh, + To check that you're now using remote data and components from {{< vendor/name >}}, reload your local app within your browser. 4. When you've finished your work, diff --git a/sites/platform/src/guides/symfony/workers.md b/sites/platform/src/guides/symfony/workers.md index 7380e852d9..c2ff244fc2 100644 --- a/sites/platform/src/guides/symfony/workers.md +++ b/sites/platform/src/guides/symfony/workers.md @@ -19,9 +19,9 @@ workers: ``` Note that the `symfony` binary is available when you use the [Symfony -integration](./integration) in your Platform.sh app configuration. +integration](./integration) in your {{< vendor/name >}} app configuration. -On Platform.sh, worker containers run the exact same code as the web container. +On {{< vendor/name >}}, worker containers run the exact same code as the web container. The container image is built only once and deployed multiple times in its own container alongside the web container. The *build* hook and dependencies might not vary but, as these containers are independent, they can be customized the same way using common properties. diff --git a/sites/platform/src/guides/typo3/_index.md b/sites/platform/src/guides/typo3/_index.md index dc9a740ff5..b7b544cb3f 100644 --- a/sites/platform/src/guides/typo3/_index.md +++ b/sites/platform/src/guides/typo3/_index.md @@ -2,7 +2,7 @@ title: "TYPO3" weight: -110 description: | - Everything you need to get started with TYPO3 on Platform.sh. + Everything you need to get started with TYPO3 on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/typo3/deploy/_index.md b/sites/platform/src/guides/typo3/deploy/_index.md index d7ef8b4db6..9670570f38 100644 --- a/sites/platform/src/guides/typo3/deploy/_index.md +++ b/sites/platform/src/guides/typo3/deploy/_index.md @@ -1,13 +1,13 @@ --- -title: Deploy TYPO3 on Platform.sh +title: Deploy TYPO3 on {{< vendor/name >}} sidebarTitle: "Get started" weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy TYPO3. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy TYPO3. --- -TYPO3 is an Open Source Enterprise PHP-based CMS framework. The recommended way to deploy TYPO3 on Platform.sh is by using Composer, the PHP package management suite. +TYPO3 is an Open Source Enterprise PHP-based CMS framework. The recommended way to deploy TYPO3 on {{< vendor/name >}} is by using Composer, the PHP package management suite. This guide assumes you are using the well-supported Composer flavor of TYPO3. diff --git a/sites/platform/src/guides/typo3/deploy/configure.md b/sites/platform/src/guides/typo3/deploy/configure.md index 9e81a56133..f3341b7f55 100644 --- a/sites/platform/src/guides/typo3/deploy/configure.md +++ b/sites/platform/src/guides/typo3/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure TYPO3 for Platform.sh" +title: "Configure TYPO3 for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for TYPO3. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for TYPO3. --- {{% guides/config-desc name="TYPO3" %}} diff --git a/sites/platform/src/guides/typo3/deploy/customize.md b/sites/platform/src/guides/typo3/deploy/customize.md index 806103faa3..89926ce671 100644 --- a/sites/platform/src/guides/typo3/deploy/customize.md +++ b/sites/platform/src/guides/typo3/deploy/customize.md @@ -1,13 +1,13 @@ --- -title: "Customize TYPO3 for Platform.sh" +title: "Customize TYPO3 for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your TYPO3 site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your TYPO3 site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, -it’s time to make your TYPO3 site itself ready to run on a Platform.sh environment. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, +it’s time to make your TYPO3 site itself ready to run on a {{< vendor/name >}} environment. There are a number of additional steps that are either required or recommended, depending on how well you want to optimize your site. @@ -53,7 +53,7 @@ php vendor/bin/typo3 extension:activate pxa_lpeh ## TYPO3 CMS's `web-dir` -Platform.sh recommends serving TYPO3 from its default subdirectory `public`. +{{< vendor/name >}} recommends serving TYPO3 from its default subdirectory `public`. `public` can be seen already throughout your `.platform.app.yaml` file in `web.locations.root`, `mounts` and within your `build` and `deploy` hooks. You need to assign `public` to the `cms.web-dir` attribute in your `composer.json` file, @@ -73,13 +73,13 @@ You can also add the definition to your existing `baseVariant` attribute for pro You define this environment variable in the next section, but its purpose is to retrieve the root domain -(since you haven't yet registered a domain name on the Platform.sh project, +(since you haven't yet registered a domain name on the {{< vendor/name >}} project, this is a hashed placeholder domain generated from the environment) from the environment variable `PLATFORM_ROUTES`. {{< note >}} -The above `base` configuration only includes the production case (running on Platform.sh) +The above `base` configuration only includes the production case (running on {{< vendor/name >}}) or at least exporting a `PLATFORM_ROUTES_MAIN` environment variable to match during local development. Alternatively, you can place the above definition within a `baseVariant` definition for the production environment alongside another development environment `condition` for local. @@ -98,11 +98,11 @@ baseVariants: ## Environment -Finally, you can start using the Platform.sh Configuration Reader library +Finally, you can start using the {{< vendor/name >}} Configuration Reader library to starting reading from the environment from within your application. In a `public/typo3conf/PlatformshConfiguration.php` file, you can use the library to: -- Verify the deployment is occurring on a Platform.sh project (`if (!$platformConfig->isValidPlatform())`) +- Verify the deployment is occurring on a {{< vendor/name >}} project (`if (!$platformConfig->isValidPlatform())`) - Verify that it's not running during build, when services aren't yet available (`if ($platformConfig->inBuild())`) - Set the `PLATFORM_ROUTES_MAIN` environment variable used in `config/sites/main/config.yaml`) @@ -114,7 +114,7 @@ In a `public/typo3conf/PlatformshConfiguration.php` file, you can use the librar {{< readFile file="static/files/fetch/config-examples-platform/typo3" highlight="php" >}} -Then include the `require_once()` function within your `public/typo3conf/AdditionalConfiguration.php` file to load the Platform.sh-specific configuration into the site if present. +Then include the `require_once()` function within your `public/typo3conf/AdditionalConfiguration.php` file to load the {{< vendor/name >}}-specific configuration into the site if present. ```php }} environments and local development. * - * Platform.sh-specific configuration should be added to PlatformshConfiguration.php. + * {{< vendor/name >}}-specific configuration should be added to PlatformshConfiguration.php. * Environment-specific configuration should be added to LocalConfiguration.php as normal. */ -// Include the Platform.sh-specific configuration. -// This file will no-op on its own if not on Platform.sh. +// Include the {{< vendor/name >}}-specific configuration. +// This file will no-op on its own if not on {{< vendor/name >}}. $platformshFile = __DIR__ . '/PlatformshConfiguration.php'; if (file_exists($platformshFile)) { require_once($platformshFile); diff --git a/sites/platform/src/guides/typo3/deploy/deploy.md b/sites/platform/src/guides/typo3/deploy/deploy.md index d618bc485f..5f03c9e458 100644 --- a/sites/platform/src/guides/typo3/deploy/deploy.md +++ b/sites/platform/src/guides/typo3/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy TYPO3" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} @@ -33,7 +33,7 @@ If you're migrating an existing site, you can move on to the next step. php vendor/bin/typo3cms install:setup \ --install-steps-config=src/SetupDatabase.yaml \ --site-setup-type=no \ - --site-name="TYPO3 on Platform.sh" \ + --site-name="TYPO3 on {{< vendor/name >}}" \ --admin-user-name=admin \ --admin-password=password \ --skip-extension-setup \ diff --git a/sites/platform/src/guides/wordpress/_index.md b/sites/platform/src/guides/wordpress/_index.md index fcab700d64..72b7ac5cc9 100644 --- a/sites/platform/src/guides/wordpress/_index.md +++ b/sites/platform/src/guides/wordpress/_index.md @@ -2,7 +2,7 @@ title: "WordPress" weight: -100 description: | - Everything you need to get started with WordPress on Platform.sh. + Everything you need to get started with WordPress on {{< vendor/name >}}. --- {{% description %}} diff --git a/sites/platform/src/guides/wordpress/composer/_index.md b/sites/platform/src/guides/wordpress/composer/_index.md index 328e9564fb..da3cd6f75f 100644 --- a/sites/platform/src/guides/wordpress/composer/_index.md +++ b/sites/platform/src/guides/wordpress/composer/_index.md @@ -4,19 +4,19 @@ weight: -100 layout: single sidebarTitle: "Why use Composer?" description: | - This guide will give you a greater understanding for why Platform.sh recommends using Composer to manage WordPress. + This guide will give you a greater understanding for why{{< vendor/name >}} recommends using Composer to manage WordPress. --- -Using Composer isn't traditionally the norm for WordPress development, but it is strongly recommended when deploying on Platform.sh. This guide is intended to provide an overview of why using Composer - including adding modules and themes locally as packages, as well as updating WordPress itself - is recommended. +Using Composer isn't traditionally the norm for WordPress development, but it is strongly recommended when deploying on {{< vendor/name >}}. This guide is intended to provide an overview of why using Composer - including adding modules and themes locally as packages, as well as updating WordPress itself - is recommended. ## Why use Composer -Like any other application, your WordPress site is most secure when you can ensure repeatable builds and committable updates for both your code and its dependencies. This is a priority at Platform.sh, and that's why you can control your infrastructure in the same way. Your infrastructure is committed through a set of configuration files that specify which version of PHP and MariaDB you want to use, because that's the best way to ensure that your project remains reproducible when developing new features. +Like any other application, your WordPress site is most secure when you can ensure repeatable builds and committable updates for both your code and its dependencies. This is a priority at {{< vendor/name >}}, and that's why you can control your infrastructure in the same way. Your infrastructure is committed through a set of configuration files that specify which version of PHP and MariaDB you want to use, because that's the best way to ensure that your project remains reproducible when developing new features. WordPress core, as well as its themes and plugins, should ideally work the same way, but very often this isn't the case. WordPress's administration panel provides one-click buttons to update all of these components when they're out of date, or otherwise expects write access to the file system to make configuration changes at runtime. Developing this way has its consequences, however. -First off, you aren't always going to have write access to the file system at runtime (which is the case for Platform.sh), so depending on this mechanism for updates and configuration changes is entirely restricted for many hosting solutions. On the other hand, if you *do* have write access at runtime where you're hosting currently, installing a new module or theme presents a nontrivial security risk when the source is unknown. +First off, you aren't always going to have write access to the file system at runtime (which is the case for {{< vendor/name >}}), so depending on this mechanism for updates and configuration changes is entirely restricted for many hosting solutions. On the other hand, if you *do* have write access at runtime where you're hosting currently, installing a new module or theme presents a nontrivial security risk when the source is unknown. But, perhaps most importantly, updating WordPress at runtime decouples the state of your site from the code in your repository. A colleague working on a new feature on their local clone of the project could very well be a full major version behind the live site, introducing bugs with unknown (and more importantly, untested) consequences completely as a result of this workflow. @@ -42,13 +42,13 @@ or add the [cache-control](https://wordpress.org/plugins/cache-control-by-cachol composer require wpackagist-plugin/cache-control ``` -These commands will add the packages to your `composer.json` file, and then lock the exact version to `composer.lock`. Just push those updates to your project on Platform.sh, and enable them through the administration panel as you would normally. +These commands will add the packages to your `composer.json` file, and then lock the exact version to `composer.lock`. Just push those updates to your project on {{< vendor/name >}}h, and enable them through the administration panel as you would normally. {{< note >}} -Typically, Composer dependencies install to a `vendor` directory in the project root, but themes and plugins need to install to `wp-content` instead. There is an `installer-paths` attribute that is added to `composer.json` to accomplish this, which is explained in more detail in the [How to Deploy WordPress on Platform.sh](/guides/wordpress/deploy/_index.md) guide (which uses Composer from the start), as well as the [How to update your WordPress site to use Composer](/guides/wordpress/composer/migrate.md) guide. +Typically, Composer dependencies install to a `vendor` directory in the project root, but themes and plugins need to install to `wp-content` instead. There is an `installer-paths` attribute that is added to `composer.json` to accomplish this, which is explained in more detail in the [How to Deploy WordPress on {{< vendor/name >}}](/guides/wordpress/deploy/_index.md) guide (which uses Composer from the start), as well as the [How to update your WordPress site to use Composer](/guides/wordpress/composer/migrate.md) guide. {{< /note >}} -For more information, see the following Platform.sh community post: [How to install custom/private WordPress plugins and themes with Composer](https://community.platform.sh/t/how-to-install-custom-private-wordpress-plugins-and-themes-with-composer/622). +For more information, see the following {{< vendor/name >}} community post: [How to install custom/private WordPress plugins and themes with Composer](https://community.platform.sh/t/how-to-install-custom-private-wordpress-plugins-and-themes-with-composer/622). ### Installing WordPress core with Composer @@ -67,13 +67,13 @@ Now that WordPress core, your themes and your plugins have been added as depende composer update ``` -This command will update everything in your project locally, after which you can push to Platform.sh on a new environment. After you are satisfied with the changes merge into your production site. +This command will update everything in your project locally, after which you can push to {{< vendor/name >}} on a new environment. After you are satisfied with the changes merge into your production site. ## Resources -Platform.sh has written several guides for WordPress alongside the Composer recommendation: +{{< vendor/name >}} has written several guides for WordPress alongside the Composer recommendation: -- [How to Deploy WordPress on Platform.sh](/guides/wordpress/deploy/_index.md): From here, you can create a Composer-based version of WordPress from scratch and deploy to Platform.sh. -- [How to update your WordPress site to use Composer](/guides/wordpress/composer/migrate.md): This guide will take you through the steps of updating your fully committed *vanilla* WordPress repository into one that uses Composer and deploy it to Platform.sh. +- [How to Deploy WordPress on {{< vendor/name >}}](/guides/wordpress/deploy/_index.md): From here, you can create a Composer-based version of WordPress from scratch and deploy to {{< vendor/name >}}. +- [How to update your WordPress site to use Composer](/guides/wordpress/composer/migrate.md): This guide will take you through the steps of updating your fully committed *vanilla* WordPress repository into one that uses Composer and deploy it to {{< vendor/name >}}. - [Redis](/guides/wordpress/redis.md): This guide will show you how to add a Redis container to your configuration and add it to your deployed WordPress site. -- [How to Deploy WordPress without Composer on Platform.sh](/guides/wordpress/vanilla/_index.md): If you do not want to switch to using Composer and you are willing to work around some of Platform.sh runtime constraints, this guide will show you how to deploy a fully committed *vanilla* WordPress site to Platform.sh +- [How to Deploy WordPress without Composer on {{< vendor/name >}}](/guides/wordpress/vanilla/_index.md): If you do not want to switch to using Composer and you are willing to work around some of {{< vendor/name >}} runtime constraints, this guide will show you how to deploy a fully committed *vanilla* WordPress site to {{< vendor/name >}} diff --git a/sites/platform/src/guides/wordpress/composer/migrate.md b/sites/platform/src/guides/wordpress/composer/migrate.md index b5c029541f..dac96680f4 100644 --- a/sites/platform/src/guides/wordpress/composer/migrate.md +++ b/sites/platform/src/guides/wordpress/composer/migrate.md @@ -3,7 +3,7 @@ title: "Upgrade your WordPress site to use Composer" sidebarTitle: Upgrade to use Composer weight: 2 description: | - Learn how to use WordPress with Composer on Platform.sh. + Learn how to use WordPress with Composer on {{< vendor/name >}}. --- Composer helps you declare, manage, and install all the dependencies needed to run your project. @@ -17,8 +17,8 @@ You also don't need to manage any of these elements as Git submodules. To update your WordPress site to use Composer, check that: - You already have a [vanilla version of WordPress installed locally](../vanilla/_index.md). -- Your project has been set up for deployment on Platform.sh. - If you don't have Platform.sh configuration files in your repository, +- Your project has been set up for deployment on {{< vendor/name >}}. + If you don't have {{< vendor/name >}} configuration files in your repository, [deploy WordPress without Composer](../vanilla/_index.md) before upgrading to a Composer-based site. - You have [downloaded and installed Composer](https://getcomposer.org/download/). @@ -28,7 +28,7 @@ To install WordPress with Composer, complete the following steps: 1. Switch to a new Git branch. - To safely make changes to your repository and Platform.sh environment, run the following command: + To safely make changes to your repository and {{< vendor/name >}} environment, run the following command: ```bash $ git checkout -b composer @@ -66,7 +66,7 @@ To install WordPress with Composer, complete the following steps: ``` Then, at the end of your existing `.gitignore` file, - add the content of Platform.sh’s [template `.gitignore` file](https://github.com/platformsh-templates/wordpress-composer/blob/master/.gitignore). + add the content of {{< vendor/name >}}’s [template `.gitignore` file](https://github.com/platformsh-templates/wordpress-composer/blob/master/.gitignore). This adds the `wordpress` subdirectory to the resulting `.gitignore` file. This way, after Composer reinstalls WordPress, the `wordpress` subdirectory is ignored in commits. @@ -191,13 +191,13 @@ To do so, complete the following steps: Each dependency is now installed. -## 3. Deploy to Platform.sh +## 3. Deploy to {{< vendor/name >}} -Switching to a Composer-based installation doesn't require any modifications to the Platform.sh configuration files +Switching to a Composer-based installation doesn't require any modifications to the {{< vendor/name >}} configuration files created when [you deployed your vanilla version](../vanilla/_index.md). Make sure that your project contains those three files. You can then commit all your changes -and deploy your new Composer-based WordPress site to Platform.sh: +and deploy your new Composer-based WordPress site to {{< vendor/name >}}: ```bash git add . && git commit -m "Composerify plugins and themes." diff --git a/sites/platform/src/guides/wordpress/deploy/_index.md b/sites/platform/src/guides/wordpress/deploy/_index.md index 056d23e8c5..760440cd8a 100644 --- a/sites/platform/src/guides/wordpress/deploy/_index.md +++ b/sites/platform/src/guides/wordpress/deploy/_index.md @@ -1,24 +1,24 @@ --- -title: Deploy WordPress on Platform.sh +title: Deploy WordPress on {{< vendor/name >}} sidebarTitle: Get started weight: -110 layout: single description: | - Create a Platform.sh account, download a few tools, and prepare to deploy WordPress using Composer. + Create a {{< vendor/name >}} account, download a few tools, and prepare to deploy WordPress using Composer. --- -WordPress is a popular Content Management System written in PHP. The recommended way to deploy WordPress on Platform.sh is by using Composer, the PHP package management suite. The most popular and supported way to do so is with the [John Bloch](https://github.com/johnpbloch/wordpress) Composer fork script. This guide assumes from the beginning that you're migrating a Composer-flavored WordPress repository. +WordPress is a popular Content Management System written in PHP. The recommended way to deploy WordPress on {{< vendor/name >}} is by using Composer, the PHP package management suite. The most popular and supported way to do so is with the [John Bloch](https://github.com/johnpbloch/wordpress) Composer fork script. This guide assumes from the beginning that you're migrating a Composer-flavored WordPress repository. {{< note >}} -With some caveats, it's possible to deploy WordPress to Platform.sh without using Composer, [though not recommended](/guides/wordpress/composer/_index.md). You can consult the ["WordPress without Composer on Platform.sh"](/guides/wordpress/vanilla/_index.md) guide to set that up, but do consider [upgrading to use Composer](/guides/wordpress/composer/migrate.md). +With some caveats, it's possible to deploy WordPress to {{< vendor/name >}} without using Composer, [though not recommended](/guides/wordpress/composer/_index.md). You can consult the ["WordPress without Composer on {{< vendor/name >}}"](/guides/wordpress/vanilla/_index.md) guide to set that up, but do consider [upgrading to use Composer](/guides/wordpress/composer/migrate.md). {{< /note >}} {{% guides/starting-point name="WordPress" templateRepo="wordpress-composer" composerLink="https://github.com/johnpbloch/wordpress" initExample=true %}} {{< note >}} -All of the examples in this deployment guide use the [`wordpress-composer`](https://github.com/platformsh-templates/wordpress-composer) template maintained by the Platform.sh team. That template is built using the [John Bloch Composer fork](https://github.com/johnpbloch/wordpress) of WordPress, which is meant to facilitate managing WordPress with Composer, but the template comes with its own assumptions. One is that WordPress core is downloaded by default into a `wordpress` subdirectory when installed, but other teams would rather specify another subdirectory along with many more assumptions. +All of the examples in this deployment guide use the [`wordpress-composer`](https://github.com/platformsh-templates/wordpress-composer) template maintained by the {{< vendor/name >}} team. That template is built using the [John Bloch Composer fork](https://github.com/johnpbloch/wordpress) of WordPress, which is meant to facilitate managing WordPress with Composer, but the template comes with its own assumptions. One is that WordPress core is downloaded by default into a `wordpress` subdirectory when installed, but other teams would rather specify another subdirectory along with many more assumptions. -An alternative approach is shown in Platform.sh's [Bedrock template](https://github.com/platformsh-templates/wordpress-bedrock), which installs core into `web/wp`, exports environment customization to a separate `config/environments` directory, and largely depends on setting environment variables to configure the database. Your are free to follow that template as an example with this guide, though there are slight differences. For its ease of use, the Bedrock approach is often used as a substitute starting point in some of the other WordPress guides in this documentation. +An alternative approach is shown in {{< vendor/name >}}'s [Bedrock template](https://github.com/platformsh-templates/wordpress-bedrock), which installs core into `web/wp`, exports environment customization to a separate `config/environments` directory, and largely depends on setting environment variables to configure the database. Your are free to follow that template as an example with this guide, though there are slight differences. For its ease of use, the Bedrock approach is often used as a substitute starting point in some of the other WordPress guides in this documentation. {{< /note >}} {{% guides/requirements %}} diff --git a/sites/platform/src/guides/wordpress/deploy/configure.md b/sites/platform/src/guides/wordpress/deploy/configure.md index 268642f9f5..961c6961f5 100644 --- a/sites/platform/src/guides/wordpress/deploy/configure.md +++ b/sites/platform/src/guides/wordpress/deploy/configure.md @@ -1,9 +1,9 @@ --- -title: "Configure WordPress for Platform.sh" +title: "Configure WordPress for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for WordPress. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for WordPress. --- {{% guides/config-desc name="WordPress" %}} diff --git a/sites/platform/src/guides/wordpress/deploy/customize.md b/sites/platform/src/guides/wordpress/deploy/customize.md index dcb607dd5a..139533045d 100644 --- a/sites/platform/src/guides/wordpress/deploy/customize.md +++ b/sites/platform/src/guides/wordpress/deploy/customize.md @@ -1,12 +1,12 @@ --- -title: "Customize WordPress for Platform.sh" +title: "Customize WordPress for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your WordPress site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your WordPress site to read from a {{< vendor/name >}} environment. --- -Now that your code contains all of the configuration to deploy on Platform.sh, it’s time to make your WordPress site itself ready to run on a Platform.sh environment. +Now that your code contains all of the configuration to deploy on {{< vendor/name >}}, it’s time to make your WordPress site itself ready to run on a {{< vendor/name >}} environment. ## Install the Config Reader @@ -18,7 +18,7 @@ With the Configuration Reader library installed, add or update a `wp-config.php` - Retrieve connection credentials for MariaDB through the `database` relationship to configure the WordPress database. This will set up the database automatically and avoid you having to set the connection yourself during the installer. - Use the project's [routes](../../../define-routes/_index.md) to set `WP_HOME` and `WP_SITEURL` settings. -- Set all of WordPress's security and authentication keys to the Platform.sh-provided `PLATFORM_PROJECT_ENTROPY` - a hashed variable specific to your repository consistent across environments. +- Set all of WordPress's security and authentication keys to the {{< vendor/name >}}-provided `PLATFORM_PROJECT_ENTROPY` - a hashed variable specific to your repository consistent across environments. Many other WordPress settings are pre-defined in this file for you, so consult the inline comments for more information. @@ -26,7 +26,7 @@ Many other WordPress settings are pre-defined in this file for you, so consult t ## Setting up Composer -Through this guide you will set up your WordPress repository to install everything during it's build using Composer. That includes themes, plugins, and even WordPress Core itself. Any new plugins you want to use or migrate from your existing application can be committed as dependencies using Composer, but there are a few changes we need to make to the `composer.json` file to prepare it for the final Platform.sh environment. +Through this guide you will set up your WordPress repository to install everything during it's build using Composer. That includes themes, plugins, and even WordPress Core itself. Any new plugins you want to use or migrate from your existing application can be committed as dependencies using Composer, but there are a few changes we need to make to the `composer.json` file to prepare it for the final {{< vendor/name >}} environment. First, the John Bloch script has a default `wordpress` installation directory, so the `composer.json` file needs to know that all new themes and plugins have a destination within that subdirectory. diff --git a/sites/platform/src/guides/wordpress/deploy/deploy.md b/sites/platform/src/guides/wordpress/deploy/deploy.md index b3b1f21b8c..4978d1dfd0 100644 --- a/sites/platform/src/guides/wordpress/deploy/deploy.md +++ b/sites/platform/src/guides/wordpress/deploy/deploy.md @@ -3,7 +3,7 @@ title: "Deploy WordPress" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/wordpress/deploy/next-steps.md b/sites/platform/src/guides/wordpress/deploy/next-steps.md index 633ac0014a..f815664fd0 100644 --- a/sites/platform/src/guides/wordpress/deploy/next-steps.md +++ b/sites/platform/src/guides/wordpress/deploy/next-steps.md @@ -38,13 +38,13 @@ $ composer require wpackagist-theme/neve ``` This updates your `composer.json` and `composer.lock` files. -Once you push the change to Platform.sh, the package is downloaded during the WordPress build. +Once you push the change to {{< vendor/name >}}, the package is downloaded during the WordPress build. All that's left is to sign in to the administration dashboard on your deployed site and enable plugins and themes from the Plugins and Appearance settings, respectively. ## Set up a WooCommerce site -Platform.sh maintains a [WooCommerce template](https://github.com/platformsh-templates/wordpress-woocommerce) +{{< vendor/name >}} maintains a [WooCommerce template](https://github.com/platformsh-templates/wordpress-woocommerce) that you can deploy quickly from the button in its README, but using Composer you can quickly install WooCommerce yourself: @@ -85,14 +85,14 @@ you can use them in your project by defining local `repositories` for them in yo In the snippet above, other packages can still be downloaded from WPPackagist, but now two custom `path` repositories have been defined from `/custom/[themes|plugins]` locally. Adding packages from these sources then only requires `composer require author/custom_plugin` -to ensure that the plugin at `/custom/plugin/author/custom_plugin` is installed by Platform.sh when WordPress is built. +to ensure that the plugin at `/custom/plugin/author/custom_plugin` is installed by {{< vendor/name >}} when WordPress is built. ## Updating WordPress, plugins, and themes Your WordPress site is fully managed by Composer, which means so are updates to WordPress core itself. Run `composer update` periodically to get new versions of WordPress core, as well as any plugins or themes your have installed. -Commit the resulting changes to your `composer.lock` file and push again to Platform.sh +Commit the resulting changes to your `composer.lock` file and push again to {{< vendor/name >}}. The [Composer documentation](https://getcomposer.org/doc/) has more information on options to update individual modules or perform other tasks. diff --git a/sites/platform/src/guides/wordpress/redis.md b/sites/platform/src/guides/wordpress/redis.md index 05db450f55..ad2c452b8f 100644 --- a/sites/platform/src/guides/wordpress/redis.md +++ b/sites/platform/src/guides/wordpress/redis.md @@ -6,7 +6,7 @@ description: | Configure Redis for your WordPress site. --- -There are a number of Redis plugins for WordPress, only some of which are compatible with Platform.sh. +There are a number of Redis plugins for WordPress, only some of which are compatible with {{< vendor/name >}}. We've tested and recommend [WP Redis](https://wordpress.org/plugins/wp-redis/) and [Redis Object Cache](https://wordpress.org/plugins/redis-cache/), both of which require a minimal amount of configuration. @@ -35,7 +35,7 @@ relationships: redis: "rediscache:redis" ``` -The key (left side) is the name that's exposed to the application in the [`PLATFORM_RELATIONSHIPS` variable](../../development/variables/use-variables.md#use-platformsh-provided-variables). +The key (left side) is the name that's exposed to the application in the [`PLATFORM_RELATIONSHIPS` variable](../../development/variables/use-variables.md#use-provided-variables). The value (right side) is the name of the service you specified in step 1 (`rediscache`) and the endpoint (`redis`). If you named the service something different in step 1, change `rediscache` to that. diff --git a/sites/platform/src/guides/wordpress/vanilla/_index.md b/sites/platform/src/guides/wordpress/vanilla/_index.md index e30bc8fd26..832592056c 100644 --- a/sites/platform/src/guides/wordpress/vanilla/_index.md +++ b/sites/platform/src/guides/wordpress/vanilla/_index.md @@ -1,13 +1,13 @@ --- -title: "How to Deploy WordPress without Composer on Platform.sh" +title: "How to Deploy WordPress without Composer on {{< vendor/name >}}" weight: -90 layout: single sidebarTitle: "Deploy without Composer" description: | - Migrate your existing vanilla WordPress site to Platform.sh. + Migrate your existing vanilla WordPress site to {{< vendor/name >}}. --- -WordPress is a popular Content Management System written in PHP. The recommended way to deploy WordPress on Platform.sh is by using [Composer](/guides/wordpress/deploy/_index.md), the PHP package management suite. This guide will take you through the steps of setting up "vanilla" WordPress - that is, WordPress not managed through Composer, but rather by either fully committing WordPress, themes, and plugins or defining them with submodules - on Platform.sh. It should be noted that this approach comes with certain limitations based on the way Platform.sh works, and for this reason is [not recommended](/guides/wordpress/composer/_index.md). Instead, consider using the ["Upgrade to use Composer"](/guides/wordpress/composer/migrate.md) guide to modify your project into one that uses Composer. +WordPress is a popular Content Management System written in PHP. The recommended way to deploy WordPress on {{< vendor/name >}} is by using [Composer](/guides/wordpress/deploy/_index.md), the PHP package management suite. This guide will take you through the steps of setting up "vanilla" WordPress - that is, WordPress not managed through Composer, but rather by either fully committing WordPress, themes, and plugins or defining them with submodules - on {{< vendor/name >}}. It should be noted that this approach comes with certain limitations based on the way {{< vendor/name >}} works, and for this reason is [not recommended](/guides/wordpress/composer/_index.md). Instead, consider using the ["Upgrade to use Composer"](/guides/wordpress/composer/migrate.md) guide to modify your project into one that uses Composer. {{% guides/starting-point name="WordPress" templateRepo="wordpress-vanilla" initExample=true %}} diff --git a/sites/platform/src/guides/wordpress/vanilla/configure.md b/sites/platform/src/guides/wordpress/vanilla/configure.md index 6d3534ba9c..2d86c1c5b3 100644 --- a/sites/platform/src/guides/wordpress/vanilla/configure.md +++ b/sites/platform/src/guides/wordpress/vanilla/configure.md @@ -1,16 +1,16 @@ --- -title: "Configure WordPress for Platform.sh" +title: "Configure WordPress for {{< vendor/name >}}" sidebarTitle: "Configure" weight: -100 description: | - Review the basics of what makes up a Platform.sh project, including its three principle configuration files and how to define them for WordPress. + Review the basics of what makes up a {{< vendor/name >}} project, including its three principle configuration files and how to define them for WordPress. --- {{% guides/config-desc name="WordPress" %}} {{% guides/config-app template="wordpress-vanilla" %}} -There are a few things to notice in this file specific to running non-Composer variants of WordPress on Platform.sh. Defined in the `dependencies` block, all of the packages needed to run the WordPress CLI in both the application container and via SSH are installed in the first stages of the build process using Composer. Also, the `web.locations` block will expose `wordpress/index.php` under the primary route. +There are a few things to notice in this file specific to running non-Composer variants of WordPress on {{< vendor/name >}}. Defined in the `dependencies` block, all of the packages needed to run the WordPress CLI in both the application container and via SSH are installed in the first stages of the build process using Composer. Also, the `web.locations` block will expose `wordpress/index.php` under the primary route. {{< /guides/config-app >}} diff --git a/sites/platform/src/guides/wordpress/vanilla/customize.md b/sites/platform/src/guides/wordpress/vanilla/customize.md index a8ebf475a0..8da0f51cd5 100644 --- a/sites/platform/src/guides/wordpress/vanilla/customize.md +++ b/sites/platform/src/guides/wordpress/vanilla/customize.md @@ -1,12 +1,12 @@ --- -title: "Customize WordPress for Platform.sh" +title: "Customize WordPress for {{< vendor/name >}}" sidebarTitle: "Customize" weight: -90 description: | - Add some helpful dependencies, and modify your WordPress site to read from a Platform.sh environment. + Add some helpful dependencies, and modify your WordPress site to read from a {{< vendor/name >}} environment. --- -Deploying WordPress without Composer on Platform.sh isn't recommended, +Deploying WordPress without Composer on {{< vendor/name >}} isn't recommended, but should you wish to do so there are a few additional modifications you need to make to your repository. ## Place WordPress core into a subdirectory @@ -22,19 +22,19 @@ It also makes defining WordPress as a submodule possible if you choose to do so. Place all code for WordPress core into a subdirectory called `wordpress`, including your `wp-config.php` file. {{< note >}} -You can name the WordPress core subdirectory whatever you would like - the most common being `wp`, `web`, and `wordpress`. `wordpress` has been chosen for Platform.sh templates and guides because it is often the default install location for [composer-flavored versions of WordPress](/guides/wordpress/deploy/_index.md), and naming it `wordpress` now in your project will make [migrating to use Composer](/guides/wordpress/composer/migrate.md) later on straightforward. If naming the directory something other than `wordpress`, make sure to update the `web.locations["/"].root` attribute to match in your `.platform.app.yaml file`, as well as any other `root` attribute there. +You can name the WordPress core subdirectory whatever you would like - the most common being `wp`, `web`, and `wordpress`. `wordpress` has been chosen for {{< vendor/name >}} templates and guides because it is often the default install location for [composer-flavored versions of WordPress](/guides/wordpress/deploy/_index.md), and naming it `wordpress` now in your project will make [migrating to use Composer](/guides/wordpress/composer/migrate.md) later on straightforward. If naming the directory something other than `wordpress`, make sure to update the `web.locations["/"].root` attribute to match in your `.platform.app.yaml file`, as well as any other `root` attribute there. {{< /note >}} ### Core, themes, and plugins can also be submodules -Platform.sh validates and retrieves submodules in the first stages of its build process, +{{< vendor/name >}} validates and retrieves submodules in the first stages of its build process, so it's possible to manage your code entirely this way. This modifies the update steps from what's listed below, so visit the [Git submodules](/development/submodules.md) documentation for more information. ## `.environment` -Platform.sh provides multiple *environments* for your projects, that can be customized (with different values for staging and development), but that inherit features from the production environment. One clear case where this can be useful is environment variables. Each environment on Platform.sh comes with a set of [pre-defined variables](../../../development/variables/use-variables.md#use-platformsh-provided-variables) that provide information about the branch you are working on, the application's configuration, and the credentials to connect to each service defined in `services.yaml`. +{{< vendor/name >}} provides multiple *environments* for your projects, that can be customized (with different values for staging and development), but that inherit features from the production environment. One clear case where this can be useful is environment variables. Each environment on {{< vendor/name >}} comes with a set of [pre-defined variables](../../../development/variables/use-variables.md#use-provided-variables) that provide information about the branch you are working on, the application's configuration, and the credentials to connect to each service defined in `services.yaml`. Service credentials reside in a base64 encoded JSON object variable called `PLATFORM_RELATIONSHIPS`, which you can use to define your database connection to the MariaDB container. @@ -61,11 +61,11 @@ fi ``` As you can see above, you can define a number of environment-specific or project-wide variable settings in this file -that are applied when deployed on Platform.sh but not locally. +that are applied when deployed on {{< vendor/name >}} but not locally. ## `wp-config.php` -Now that your database credentials have been cleaned up and `WP_HOME` defined, you can pull these values into `wp-config.php` to configure WordPress for deployment on a Platform.sh environment. +Now that your database credentials have been cleaned up and `WP_HOME` defined, you can pull these values into `wp-config.php` to configure WordPress for deployment on a {{< vendor/name >}} environment. Below is the `wp-config.php` file from the [WordPress template](https://github.com/platformsh-templates/wordpress-vanilla) using the variables defined in the previous section. Many other WordPress settings are pre-defined in this file for you, so consult the inline comments for more information. diff --git a/sites/platform/src/guides/wordpress/vanilla/deploy.md b/sites/platform/src/guides/wordpress/vanilla/deploy.md index 793bb58fd1..3b7072a12a 100644 --- a/sites/platform/src/guides/wordpress/vanilla/deploy.md +++ b/sites/platform/src/guides/wordpress/vanilla/deploy.md @@ -3,7 +3,7 @@ title: "Deploy WordPress" sidebarTitle: "Deploy" weight: -80 description: | - Now that your site is ready, push it to Platform.sh and import your data. + Now that your site is ready, push it to {{< vendor/name >}} and import your data. --- {{% guides/deployment %}} diff --git a/sites/platform/src/guides/wordpress/vanilla/next-steps.md b/sites/platform/src/guides/wordpress/vanilla/next-steps.md index 80de9bea6d..65b2e479a9 100644 --- a/sites/platform/src/guides/wordpress/vanilla/next-steps.md +++ b/sites/platform/src/guides/wordpress/vanilla/next-steps.md @@ -8,14 +8,14 @@ description: | ## Updating WordPress, plugins, and themes -There is an important caveat to keep in mind when maintaining WordPress on Platform.sh, +There is an important caveat to keep in mind when maintaining WordPress on {{< vendor/name >}}, namely that after the build process has completed your site is left with a read-only file system. This makes updating WordPress core, themes, and plugins not possible at runtime through the administration panel like you may be used to. Keeping WordPress up-to-date in environments like this is the primary reason that [managing WordPress with Composer](/guides/wordpress/composer/_index.md) is recommended. -Keeping a vanilla WordPress up-to-date on Platform.sh requires you to clone the repository locally +Keeping a vanilla WordPress up-to-date on {{< vendor/name >}} requires you to clone the repository locally and subsequently remove and re-download WordPress core, themes, and plugins to their updated version. -Perform this on a new branch, and push to Platform.sh to test the updates before merging. +Perform this on a new branch, and push to {{< vendor/name >}} to test the updates before merging. If you choose to keep themes, plugins, and core defined as submodules in your project, consult the [submodule documentation](/development/submodules.md) and `git pull` for the latest version. diff --git a/sites/platform/src/increase-observability/_index.md b/sites/platform/src/increase-observability/_index.md index 3d55d83d8a..d433e62503 100644 --- a/sites/platform/src/increase-observability/_index.md +++ b/sites/platform/src/increase-observability/_index.md @@ -1,5 +1,5 @@ --- title: Increase observability weight: -75 -description: See how to increase observability for your Platform.sh projects. +description: See how to increase observability for your {{< vendor/name >}} projects. --- diff --git a/sites/platform/src/increase-observability/integrate-observability/_index.md b/sites/platform/src/increase-observability/integrate-observability/_index.md index 2f58f6a5a3..9f5d129c78 100644 --- a/sites/platform/src/increase-observability/integrate-observability/_index.md +++ b/sites/platform/src/increase-observability/integrate-observability/_index.md @@ -4,13 +4,13 @@ weight: 10 description: Find an observability service to optimize your code. --- -As the **official Platform.sh observability service**, +As the **official {{< vendor/name >}} observability service**, [Blackfire](https://www.blackfire.io/) allows you to best optimize your code. From development to testing, staging, and production, Blackfire offers a unique blend of monitoring and profiling features. -Blackfire works integrally with the Platform.sh workflow, +Blackfire works integrally with the {{< vendor/name >}} workflow, offering a smooth user experience. -Platform.sh also supports third-party services such as New Relic and Tideways. +{{< vendor/name >}} also supports third-party services such as New Relic and Tideways. Note that these third-party services have their own associated cost, are language-specific, and may not be available for all languages. \ No newline at end of file diff --git a/sites/platform/src/increase-observability/integrate-observability/blackfire.md b/sites/platform/src/increase-observability/integrate-observability/blackfire.md index 767ffb12ff..414ca3ec54 100644 --- a/sites/platform/src/increase-observability/integrate-observability/blackfire.md +++ b/sites/platform/src/increase-observability/integrate-observability/blackfire.md @@ -3,10 +3,10 @@ title: "Blackfire" sidebarTitle: Blackfire weight: 1 sectionBefore: In-house observability tool -description: Blackfire is the official Platform.sh observability service for monitoring and profiling your PHP and Python apps. +description: Blackfire is the official {{< vendor/name >}} observability service for monitoring and profiling your PHP and Python apps. --- -As the **official Platform.sh observability service**, +As the **official {{< vendor/name >}} observability service**, [Blackfire](https://www.blackfire.io/) helps you improve the performance of your apps at each stage of their lifecycle. With Blackfire's unique Application Performance Monitoring (APM) and Profiling features, you can achieve the following goals: @@ -17,7 +17,7 @@ you can achieve the following goals: {{< youtube bS4dzuzkir0 >}} -Blackfire is installed natively on Platform.sh and [works integrally with the Platform.sh workflow](https://www.youtube.com/watch?v=Bq-LFjgD6L0). +Blackfire is installed natively on {{< vendor/name >}} and [works integrally with the {{< vendor/name >}} workflow](https://www.youtube.com/watch?v=Bq-LFjgD6L0). This results in an effortless setup process and smooth user experience. {{< note >}} @@ -35,18 +35,18 @@ All customers can also subscribe to Blackfire separately. If you're using a plan with the [Observability Suite](https://platform.sh/features/observability-suite/), the [Blackfire automated integration](#automated-integration) is enabled on your environments by default. Note that as an Observability Suite user, you can only access your Blackfire environments -after you've been granted access to the related Platform.sh project. -Therefore, to access your Blackfire environments, make sure you log in using your Platform.sh account. +after you've been granted access to the related {{< vendor/name >}} project. +Therefore, to access your Blackfire environments, make sure you log in using your {{< vendor/name >}} account. If you have a {{% names/dedicated-gen-3 %}} cluster or Grid environments without the Observability suite, you need to enable the integration yourself. To do so, follow these steps: -1. Create a [Blackfire account](https://blackfire.io/signup?target=/login), preferably using your Platform.sh login. +1. Create a [Blackfire account](https://blackfire.io/signup?target=/login), preferably using your {{< vendor/name >}} login. 2. In your Blackfire account, create an organization. If you subscribed to Blackfire independently, your organization is automatically activated. - If you subscribed to Blackfire through Platform.sh, - [ask **Platform.sh** Support](https://console.platform.sh/-/users/~/tickets/open) to activate your organization. + If you subscribed to Blackfire through {{< vendor/name >}}, + [ask **{{< vendor/name >}}** Support](https://console.platform.sh/-/users/~/tickets/open) to activate your organization. 3. In your organization, create an environment. 4. In your environment, click **Settings/Environment Credentials**. 5. Retrieve your Blackfire server ID and server token. @@ -62,11 +62,11 @@ to let Blackfire profile the code running on your servers. To install Blackfire on your {{% names/dedicated-gen-2 %}} environments: -1. Create a [Blackfire account](https://blackfire.io/signup?target=/login), preferably using your Platform.sh login. +1. Create a [Blackfire account](https://blackfire.io/signup?target=/login), preferably using your {{< vendor/name >}} login. 2. In your Blackfire account, create an organization. If you subscribed to Blackfire independently, your organization is automatically activated. - If you subscribed to Blackfire through Platform.sh, - [ask **Platform.sh** Support](https://console.platform.sh/-/users/~/tickets/open) to activate your organization. + If you subscribed to Blackfire through {{< vendor/name >}}, + [ask **{{< vendor/name >}}** Support](https://console.platform.sh/-/users/~/tickets/open) to activate your organization. 3. In your organization, create an environment. 4. In your environment, click **Settings/Environment Credentials**. 5. Retrieve your Blackfire server ID and server token. @@ -90,12 +90,12 @@ On this Blackfire environment, you have access to [all the features provided by This includes monitoring, profiling, alerting, and build-related features. When a Blackfire environment is created based on a Grid environment, -user access settings are replicated from the Platform.sh Console to Blackfire. +user access settings are replicated from the {{< vendor/name >}} Console to Blackfire. This includes all [access levels](https://blackfire.io/docs/up-and-running/access-management). To access the Blackfire environment, each project user needs a Blackfire account. When a project user doesn't already have a Blackfire account, -a new one is automatically created using the user's Platform.sh credentials. +a new one is automatically created using the user's {{< vendor/name >}} credentials. You might have Blackfire variables already set on your project. In this case, the existing variables override the settings of the automated integration. @@ -160,7 +160,7 @@ see the [Blackfire documentation](https://blackfire.io/docs/profiling-cookbooks/ ## Test the performance of each new deployment -Blackfire's native integration with Platform.sh enables you to test your app's performance +Blackfire's native integration with {{< vendor/name >}} enables you to test your app's performance every time you deploy a branch in production, staging, or development. Follow these steps: diff --git a/sites/platform/src/increase-observability/integrate-observability/new-relic/_index.md b/sites/platform/src/increase-observability/integrate-observability/new-relic/_index.md index 1cc08edd11..dddb9e643e 100644 --- a/sites/platform/src/increase-observability/integrate-observability/new-relic/_index.md +++ b/sites/platform/src/increase-observability/integrate-observability/new-relic/_index.md @@ -3,7 +3,7 @@ title: "New Relic" weight: 2 sectionBefore: Third-party observability tools description: | - Platform.sh supports [New Relic application performance monitoring](https://newrelic.com/products/application-monitoring). + {{< vendor/name >}} supports [New Relic application performance monitoring](https://newrelic.com/products/application-monitoring). layout: single --- diff --git a/sites/platform/src/increase-observability/integrate-observability/new-relic/php.md b/sites/platform/src/increase-observability/integrate-observability/new-relic/php.md index bab2292edc..80ee2aa059 100644 --- a/sites/platform/src/increase-observability/integrate-observability/new-relic/php.md +++ b/sites/platform/src/increase-observability/integrate-observability/new-relic/php.md @@ -36,7 +36,7 @@ runtime: - newrelic ``` -Push the changes to your Platform.sh environment to enable New Relic as follows: +Push the changes to your {{< vendor/name >}} environment to enable New Relic as follows: ```bash git add .platform.app.yaml diff --git a/sites/platform/src/increase-observability/integrate-observability/tideways.md b/sites/platform/src/increase-observability/integrate-observability/tideways.md index 8fe297b951..6096e66314 100644 --- a/sites/platform/src/increase-observability/integrate-observability/tideways.md +++ b/sites/platform/src/increase-observability/integrate-observability/tideways.md @@ -1,13 +1,13 @@ --- title: "Tideways" description: | - Platform.sh supports [Tideways APM](https://tideways.com/) for PHP. This functionality is only available on PHP 7.0 and later. + {{< vendor/name >}} supports [Tideways APM](https://tideways.com/) for PHP. This functionality is only available on PHP 7.0 and later. --- {{% description %}} {{< note >}} -The upstream now maintains two versions for Tideways, and both plugins are available on Platform.sh: +The upstream now maintains two versions for Tideways, and both plugins are available on {{< vendor/name >}}: * [Tideways_XHProf](https://github.com/tideways/php-xhprof-extension): The open source version and so no licensing is required (On the downside, less integration services are available). You can use it in combination with [XHProf UI](https://github.com/phacility/xhprof). * [tideways](https://tideways.com): The bundle proprietary full version of the product and plugins, which the rest of the guide is mostly aimed to cover. {{< /note >}} @@ -38,7 +38,7 @@ runtime: Enabling the extension also activates the Tideways background process. -Push the changes to your Platform.sh environment to enable Tideways as follows: +Push the changes to your {{< vendor/name >}} environment to enable Tideways as follows: ```bash git add .platform.app.yaml @@ -51,8 +51,8 @@ Give it a few hours to a day to get a decent set of data before checking your Ti ## Deployment Integration -Tideways integrates with Platform.sh deployment hooks and provides performance comparisons -before and after deployments were released. You can find the Platform.sh CLI command to register +Tideways integrates with {{< vendor/name >}} deployment hooks and provides performance comparisons +before and after deployments were released. You can find the {{< vendor/name >}} CLI command to register this hook for your application in Tideways "Application Settings" screen under the section "Exports & Integrations". Here is an example: diff --git a/sites/platform/src/increase-observability/logs/forward-fastly-logs.md b/sites/platform/src/increase-observability/logs/forward-fastly-logs.md index 096f93d2fc..ceeeacef84 100644 --- a/sites/platform/src/increase-observability/logs/forward-fastly-logs.md +++ b/sites/platform/src/increase-observability/logs/forward-fastly-logs.md @@ -13,7 +13,7 @@ and therefore improve your site's overall performance. To enable log forwarding on your Fastly CDN, follow these directions: -- If you've subscribed to [Fastly through Platform.sh](../../domains/cdn/managed-fastly.md), +- If you've subscribed to [Fastly through {{< vendor/name >}}](../../domains/cdn/managed-fastly.md), [contact Support](https://console.platform.sh/-/users/~/tickets/open). - If you've subscribed to Fastly independently, diff --git a/sites/platform/src/increase-observability/logs/forward-logs.md b/sites/platform/src/increase-observability/logs/forward-logs.md index 975e367908..f416a23975 100644 --- a/sites/platform/src/increase-observability/logs/forward-logs.md +++ b/sites/platform/src/increase-observability/logs/forward-logs.md @@ -1,6 +1,6 @@ --- -title: Forward Platform.sh and Blackfire logs -description: Send your Platform.sh and Blackfire logs to a third-party service for further analysis. +title: Forward {{< vendor/name >}} and Blackfire logs +description: Send your {{< vendor/name >}} and Blackfire logs to a third-party service for further analysis. weight: 10 banner: type: observability-suite @@ -10,7 +10,7 @@ You might use a service to analyze logs from various parts of your fleet. You might want to consolidate all your logs in one place that everyone has access to without needing to grant them access to each project individually. -In such cases, forward your logs from Platform.sh and Blackfire to a third-party service. +In such cases, forward your logs from {{< vendor/name >}} and Blackfire to a third-party service. You can use a [service with an integration](#use-a-log-forwarding-integration) or any service that supports a [syslog endpoint](#forward-to-a-syslog-endpoint) or [HTTP endpoint](#forward-to-an-http-endpoint). @@ -41,7 +41,7 @@ Integrations exist for the following third-party services to enable log forwardi #### Using the CLI -To enable log forwarding for a specific project using the [Platform.sh CLI](../../administration/cli/_index.md), +To enable log forwarding for a specific project using the [{{< vendor/name >}} CLI](../../administration/cli/_index.md), follow the steps for your selected service. {{< codetabs >}} @@ -120,7 +120,7 @@ follow these steps: Syslog is a standard protocol for transferring log messages. Many third-party services offer endpoints for ingesting syslog events. -You can forward your Platform.sh and Blackfire logs to any of those endpoints. +You can forward your {{< vendor/name >}} and Blackfire logs to any of those endpoints. {{< codetabs >}} +++ @@ -156,7 +156,7 @@ To start forwarding logs, once you've added the service [trigger a redeploy](../ title=In the Console +++ -To enable log forwarding to a syslog endpoint for a specific project using the [Platform.sh CLI](../../administration/cli/_index.md), +To enable log forwarding to a syslog endpoint for a specific project using the [{{< vendor/name >}} CLI](../../administration/cli/_index.md), follow these steps: 1. Navigate to your project. @@ -176,7 +176,7 @@ follow these steps: Some third-party services, such as [Elasticsearch](../../add-services/elasticsearch.md) and [OpenSearch](../../add-services/opensearch.md), support ingesting log messages through an HTTP endpoint. -You can use HTTP forwarding to forward Platform.sh and Blackfire logs to such third-party services. +You can use HTTP forwarding to forward {{< vendor/name >}}and Blackfire logs to such third-party services. HTTP forwarding makes a `POST` HTTP request with an `application/json` body while forwarding the log messages to the endpoint. diff --git a/sites/platform/src/increase-observability/metrics/_index.md b/sites/platform/src/increase-observability/metrics/_index.md index 6a7227d1a8..a3ee924a2b 100644 --- a/sites/platform/src/increase-observability/metrics/_index.md +++ b/sites/platform/src/increase-observability/metrics/_index.md @@ -4,7 +4,7 @@ weight: 5 description: See all of the live infrastructure metrics available to give you an overview of resource usage. --- -Platform.sh projects are accompanied by live infrastructure metrics that provide an overview of resource usage for environments. +{{< vendor/name >}} projects are accompanied by live infrastructure metrics that provide an overview of resource usage for environments. Within the Console, metrics can be found for an environment under **Metrics**. diff --git a/sites/platform/src/increase-observability/metrics/dedicated.md b/sites/platform/src/increase-observability/metrics/dedicated.md index 212181b83f..0d8faa17cf 100644 --- a/sites/platform/src/increase-observability/metrics/dedicated.md +++ b/sites/platform/src/increase-observability/metrics/dedicated.md @@ -35,13 +35,8 @@ ssh 3.ent-abcde3clusterID-production-qwerty8@ssh.us-4.platform.sh You get output similar to the following: ```bash - ___ _      _    __                    _ -| _ \ |__ _| |_ / _|___ _ _ _ __    __| |_ -|  _/ / _` |  _|  _/ _ \ '_| '  \ _(_-< ' \ -|_| |_\__,_|\__|_| \___/_| |_|_|_(_)__/_||_| - - Welcome to Platform.sh. + Welcome to {{< vendor/name >}}. This is environment production-qwerty8 of project abcde3clusterID. diff --git a/sites/platform/src/integrations/activity/_index.md b/sites/platform/src/integrations/activity/_index.md index 7a3115fe64..258502b29b 100644 --- a/sites/platform/src/integrations/activity/_index.md +++ b/sites/platform/src/integrations/activity/_index.md @@ -2,12 +2,12 @@ title: "Activity scripts" weight: -5 description: | - Platform.sh supports custom scripts that can fire in response to any activity. These scripts allow you to take arbitrary actions in response to actions in your project, such as when it deploys, when a new branch is created, etc. + {{< vendor/name >}} supports custom scripts that can fire in response to any activity. These scripts allow you to take arbitrary actions in response to actions in your project, such as when it deploys, when a new branch is created, etc. --- {{% description %}} -Check out examples from other users on the Platform.sh [Community site](https://community.platform.sh/c/activity-scripts/10). +Check out examples from other users on the {{< vendor/name >}}[Community site](https://community.platform.sh/c/activity-scripts/10). ## Installing @@ -15,7 +15,7 @@ Activity scripts are configured as integrations. That means they're at the *project level*, not at the level of an individual environment. While you can store the scripts in your Git repository for access, they have no effect there. -To install a new activity script, use the [Platform.sh CLI](/administration/cli/_index.md). +To install a new activity script, use the [{{< vendor/name >}} CLI](/administration/cli/_index.md). ```bash platform integration:add --type script --file ./my_script.js diff --git a/sites/platform/src/integrations/activity/discord.md b/sites/platform/src/integrations/activity/discord.md index d3ddd2ea04..90224cdd38 100644 --- a/sites/platform/src/integrations/activity/discord.md +++ b/sites/platform/src/integrations/activity/discord.md @@ -27,7 +27,7 @@ For more on the message format, see the [Discord webhook API reference](https:// * Sends a message to Discord. * * To control what events trigger it, use the --events switch in - * the Platform.sh CLI. + * the {{< vendor/name >}} CLI. * * @param {string} title * The title of the message block to send. diff --git a/sites/platform/src/integrations/activity/reference.md b/sites/platform/src/integrations/activity/reference.md index f54bf53b30..5726718a07 100644 --- a/sites/platform/src/integrations/activity/reference.md +++ b/sites/platform/src/integrations/activity/reference.md @@ -218,7 +218,7 @@ Its content varies based on the activity type. #### `user` payload -Contains information about the Platform.sh user that triggered the activity. +Contains information about the {{< vendor/name >}} user that triggered the activity. | Name | Description | |------|-------------| @@ -381,7 +381,7 @@ The following example shows the full activity response to a cron job: "id": "admin", "created_at": "2022-12-13T16:06:08.066085+00:00", "updated_at": null, - "display_name": "Platform.sh Bot" + "display_name": "{{< vendor/name >}} Bot" }, "project": { "id": "abcdefgh1234567", @@ -460,8 +460,8 @@ The following example shows the full activity response to a cron job: }, "cron": "saybye" }, - "description": "Platform.sh Bot ran cron saybye", - "text": "Platform.sh Bot ran cron **saybye**", + "description": "{{< vendor/name >}} Bot ran cron saybye", + "text": "{{< vendor/name >}} Bot ran cron **saybye**", "expires_at": "2023-01-12T16:06:08.081293+00:00" } ``` @@ -731,7 +731,7 @@ The following example shows the full activity response to a Git push: } } }, - "product_name": "Platform.sh", + "product_name": "{{< vendor/name >}}", "product_code": "platformsh", "variables_prefix": "PLATFORM_", "bot_email": "bot@platform.sh", diff --git a/sites/platform/src/integrations/activity/slack.md b/sites/platform/src/integrations/activity/slack.md index 2f85f44d09..d1cc54a352 100644 --- a/sites/platform/src/integrations/activity/slack.md +++ b/sites/platform/src/integrations/activity/slack.md @@ -27,7 +27,7 @@ For formatting more complex messages, see the [Slack messaging documentation](ht * Sends a color-coded formatted message to Slack. * * To control what events trigger it, use the --events switch in - * the Platform.sh CLI. + * the {{< vendor/name >}} CLI. * * @param {string} title * The title of the message block to send. diff --git a/sites/platform/src/integrations/notifications.md b/sites/platform/src/integrations/notifications.md index e8b8333f87..1e30cac0b4 100644 --- a/sites/platform/src/integrations/notifications.md +++ b/sites/platform/src/integrations/notifications.md @@ -2,7 +2,7 @@ title: "Health notifications" weight: -1 description: | - Platform.sh can notify you when various events happen on your project, in any environment. At this time the only notification provided is a low disk space warning, but others may be added in the future. + {{< vendor/name >}} can notify you when various events happen on your project, in any environment. At this time the only notification provided is a low disk space warning, but others may be added in the future. --- {{% description %}} @@ -12,13 +12,13 @@ To add or modify an integration for a project, you need to be a [project admin]( ## Default low-disk email notifications When you create a new project, -Platform.sh creates a default [low-disk email notification](#low-disk-warning) for all [project admins](../administration/users.md#project-roles). +{{< vendor/name >}} creates a default [low-disk email notification](#low-disk-warning) for all [project admins](../administration/users.md#project-roles). ## Available notifications ### Low-disk warning -Platform.sh monitors disk space usage on all applications and services in your cluster. +{{< vendor/name >}} monitors disk space usage on all applications and services in your cluster. * When available disk space drops below 20% or 4 GB, whichever is smaller, a warning notification is generated. * When available disk space drops below 10% or 2 GB, whichever is smaller, a critical notification is generated. @@ -28,7 +28,7 @@ Notifications are generated every 5 minutes, so there may be a brief delay betwe ## Configuring notifications -Health notifications can be set up via the [Platform.sh CLI](/administration/cli/_index.md), through a number of different channels. +Health notifications can be set up via the [{{< vendor/name >}} CLI](/administration/cli/_index.md), through a number of different channels. ### Email notifications @@ -68,7 +68,7 @@ platform integration:add --type health.email --recipients them@example.com --rec You must specify one or more `recipients`, each as its own switch. -The default `from-address` points to the "Platform.sh Bot". +The default `from-address` points to the "{{< vendor/name >}} Bot". You can also configure a custom `--from-address`. The `--from-address` is whatever address you want the email to appear to be from. It is completely fine to use the same email address for both `from-address` and `recipients`. Note that depending on the configuration of the recipient mail server (including SPF and DKIM DNS entries) when using a custom `from-address`, the email can be marked as spam or lost. @@ -78,7 +78,7 @@ A notification can trigger a message to be sent to a Slack bot. First, create a new custom "[bot user](https://api.slack.com/bot-users)" for your Slack group and configure the channels you wish it to live in. Note the API token is the "Bot User OAuth Access Token" provided by Slack. -Then register that Slack bot with Platform.sh using a `health.slack` integration: +Then register that Slack bot with {{< vendor/name >}} using a `health.slack` integration: ```bash platform integration:add --type health.slack --token YOUR_API_TOKEN --channel '#channelname' diff --git a/sites/platform/src/integrations/overview.md b/sites/platform/src/integrations/overview.md index ad54e47bba..f2de5c8ef2 100644 --- a/sites/platform/src/integrations/overview.md +++ b/sites/platform/src/integrations/overview.md @@ -4,15 +4,15 @@ title: "External Integrations" weight: -10 layout: single description: | - Platform.sh can be integrated with external services. + {{< vendor/name >}} can be integrated with external services. --- {{% description %}} -Platform.sh supports native integrations with multiple services, first and foremost Git hosting services such as GitHub, GitLab, or Bitbucket. -You can continue to use those tools for your development workflow, and have Platform.sh environments created automatically for your pull requests and branches. +{{< vendor/name >}} supports native integrations with multiple services, first and foremost Git hosting services such as GitHub, GitLab, or Bitbucket. +You can continue to use those tools for your development workflow, and have {{< vendor/name >}} environments created automatically for your pull requests and branches. -You can also add native integrations with performance monitoring tools. Platform.sh recommends [Blackfire](../increase-observability/integrate-observability//blackfire.md), which is part of the standard Platform.sh Observability Suite. +You can also add native integrations with performance monitoring tools. {{< vendor/name >}} recommends [Blackfire](../increase-observability/integrate-observability//blackfire.md), which is part of the standard {{< vendor/name >}} Observability Suite. Be aware that only a project administrator (someone with `admin` level access to the project) can add or remove integrations. See [User administration](/administration/users.md) for more details. @@ -59,7 +59,7 @@ To do so, follow these steps: ## Debug integrations -When integrations run, they trigger "activities." Activities are actions that happen on Platform.sh, and they get logged. +When integrations run, they trigger "activities." Activities are actions that happen on {{< vendor/name >}}, and they get logged. Usually these are triggered nearly instantaneously on the webhook endpoint. These activities may be delayed due to the external services having latency. @@ -88,7 +88,7 @@ follow these steps: You get output similar to the following: ```bash - Activities on the project Platform.sh | Docs (6b2eocegfkwwg), integration c4opi5tjv3yfd (github): + Activities on the project {{< vendor/name >}} | Docs (6b2eocegfkwwg), integration c4opi5tjv3yfd (github): +---------------+---------------------------+-------------------------------------------------------------+----------+---------+ | ID | Created | Description | State | Result | +---------------+---------------------------+-------------------------------------------------------------+----------+---------+ diff --git a/sites/platform/src/integrations/source/_index.md b/sites/platform/src/integrations/source/_index.md index f9d344f2c5..b9268b119f 100644 --- a/sites/platform/src/integrations/source/_index.md +++ b/sites/platform/src/integrations/source/_index.md @@ -1,12 +1,12 @@ --- title: Source integrations weight: -4 -description: See how to maintain your code in a third-party repository that's linked to your Platform.sh project. +description: See how to maintain your code in a third-party repository that's linked to your {{< vendor/name >}} project. --- -You might want to keep your code in a third-party repository that's linked to your Platform.sh project. -This means you keep all your workflows where you want and use Platform.sh for deploying. +You might want to keep your code in a third-party repository that's linked to your {{< vendor/name >}} project. +This means you keep all your workflows where you want and use {{< vendor/name >}} for deploying. -Your Platform.sh project becomes a mirror of your code repository elsewhere. -This means you shouldn't push code directly to Platform.sh. +Your {{< vendor/name >}} project becomes a mirror of your code repository elsewhere. +This means you shouldn't push code directly to {{< vendor/name >}}. Any changes you push directly get overwritten by the integration when changes happen in the third-party repository. diff --git a/sites/platform/src/integrations/source/bitbucket.md b/sites/platform/src/integrations/source/bitbucket.md index 409576e27d..e429c533d6 100644 --- a/sites/platform/src/integrations/source/bitbucket.md +++ b/sites/platform/src/integrations/source/bitbucket.md @@ -1,7 +1,7 @@ --- title: Integrate with Bitbucket sidebarTitle: Bitbucket -description: See how to manage your Platform.sh environments directly from your Bitbucket repository. +description: See how to manage your {{< vendor/name >}} environments directly from your Bitbucket repository. --- {{% source-integration/intro source="Bitbucket" %}} @@ -15,7 +15,7 @@ or a self-hosted [Bitbucket Server](https://confluence.atlassian.com/bitbucketse ### 1. Create an OAuth consumer -To integrate your Platform.sh project with an existing Bitbucket Cloud repository, +To integrate your {{< vendor/name >}} project with an existing Bitbucket Cloud repository, [create an OAuth consumer](https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/): ![A screenshot of how to setup the Bitbucket OAuth consumer](/images/integrations/bitbucket/bitbucket-oauth-consumer.svg "0.35") @@ -42,7 +42,7 @@ Copy the **Key** and **Secret** for your consumer. ### 1. Generate a token -To integrate your Platform.sh project with a repository on a Bitbucket Server instance, +To integrate your {{< vendor/name >}} project with a repository on a Bitbucket Server instance, you first need to create an access token associated with your account. [Generate a token](https://confluence.atlassian.com/display/BitbucketServer/HTTP+access+tokens). diff --git a/sites/platform/src/integrations/source/github.md b/sites/platform/src/integrations/source/github.md index 7d50451135..8a54bf4e8d 100644 --- a/sites/platform/src/integrations/source/github.md +++ b/sites/platform/src/integrations/source/github.md @@ -1,7 +1,7 @@ --- title: Integrate with GitHub sidebarTitle: GitHub -description: See how to manage your Platform.sh environments directly from your GitHub repository. +description: See how to manage your {{< vendor/name >}} environments directly from your GitHub repository. --- {{% source-integration/intro source="GitHub" %}} @@ -9,7 +9,7 @@ description: See how to manage your Platform.sh environments directly from your ## 1. Generate a token -To integrate your Platform.sh project with an existing GitHub repository, +To integrate your {{< vendor/name >}} project with an existing GitHub repository, you need to [generate a new token](https://github.com/settings/tokens/new). You can generate a classic personal access token, or a [fine-grained personal access token](https://github.blog/changelog/2022-10-18-introducing-fine-grained-personal-access-tokens/) diff --git a/sites/platform/src/integrations/source/gitlab.md b/sites/platform/src/integrations/source/gitlab.md index 8cde8199f4..ad958ac959 100644 --- a/sites/platform/src/integrations/source/gitlab.md +++ b/sites/platform/src/integrations/source/gitlab.md @@ -1,7 +1,7 @@ --- title: Integrate with GitLab sidebarTitle: GitLab -description: See how to manage your Platform.sh environments directly from your GitLab repository. +description: See how to manage your {{< vendor/name >}} environments directly from your GitLab repository. --- {{% source-integration/intro source="GitLab" %}} @@ -9,7 +9,7 @@ description: See how to manage your Platform.sh environments directly from your ## 1. Generate a token -To integrate your Platform.sh project with an existing GitLab repository, +To integrate your {{< vendor/name >}} project with an existing GitLab repository, generate a [project access token](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#create-a-project-access-token). Ensure the token has the following scopes: diff --git a/sites/platform/src/integrations/source/troubleshoot.md b/sites/platform/src/integrations/source/troubleshoot.md index 90a25d9e5f..b8b8f13021 100644 --- a/sites/platform/src/integrations/source/troubleshoot.md +++ b/sites/platform/src/integrations/source/troubleshoot.md @@ -5,7 +5,7 @@ description: Learn how to troubleshoot access rights for integrated repositories toc: false --- -If you [add a user](/administration/users.md#add-a-user-to-a-project) to a Platform.sh project, +If you [add a user](/administration/users.md#add-a-user-to-a-project) to a {{< vendor/name >}} project, but you haven’t added them to the remote repository on GitHub, GitLab, or Bitbucket, they can't clone the project locally. diff --git a/sites/platform/src/languages/dotnet.md b/sites/platform/src/languages/dotnet.md index 2082e6d33a..10d091a365 100644 --- a/sites/platform/src/languages/dotnet.md +++ b/sites/platform/src/languages/dotnet.md @@ -1,7 +1,7 @@ --- title: "C#/.NET Core" description: | - Platform.sh supports deploying .NET applications by allowing developers to define a build process and pass its variables to the .NET Core build environment. + {{< vendor/name >}} supports deploying .NET applications by allowing developers to define a build process and pass its variables to the .NET Core build environment. --- {{% description %}} @@ -31,7 +31,7 @@ hooks: where `PLATFORM_OUTPUT_DIR` is the output directory for compiled languages available at build time. Typically, .NET Core builds start a collection of build servers, which are helpful for repeated builds. -On Platform.sh, however, if this process isn't disabled, +On {{< vendor/name >}}, however, if this process isn't disabled, the build process doesn't finish until the idle timeout is reached. As a result, you should include `-p` toggles that disable the Razor compiler for dynamic CSHTML pages (`UseRazorBuildServer`) diff --git a/sites/platform/src/languages/elixir.md b/sites/platform/src/languages/elixir.md index c20617766b..39df7436ae 100644 --- a/sites/platform/src/languages/elixir.md +++ b/sites/platform/src/languages/elixir.md @@ -1,6 +1,6 @@ --- title: "Elixir" -description: Platform.sh supports building and deploying applications written in Elixir. There is no default flavor for the build phase, but you can define it explicitly in your build hook. Platform.sh Elixir images support both committed dependencies and download-on-demand. The underlying Erlang version is 22.0.7. +description: "{{< vendor/name >}} supports building and deploying applications written in Elixir. There is no default flavor for the build phase, but you can define it explicitly in your build hook. {{< vendor/name >}} Elixir images support both committed dependencies and download-on-demand. The underlying Erlang version is 22.0.7." --- {{% description %}} @@ -15,9 +15,9 @@ description: Platform.sh supports building and deploying applications written in {{% language-specification type="elixir" display_name="Elixir" %}} -## Platform.sh variables +## Built-in variables -Platform.sh exposes relationships and other configuration as [environment variables](../development/variables/_index.md). +{{< vendor/name >}} exposes relationships and other configuration as [environment variables](../development/variables/_index.md). Most notably, it allows a program to determine at runtime what HTTP port it should listen on and what the credentials are to access [other services](../add-services/_index.md). @@ -43,7 +43,7 @@ variables: MIX_ENV: 'prod' ``` -The `SECRET_KEY_BASE` variable is generated automatically based on the [`PLATFORM_PROJECT_ENTROPY` variable](../development/variables/use-variables.md#use-platformsh-provided-variables). +The `SECRET_KEY_BASE` variable is generated automatically based on the [`PLATFORM_PROJECT_ENTROPY` variable](../development/variables/use-variables.md#use-provided-variables). You can change it. Include in your build hook the steps to retrieve a local Hex and `rebar`, and then run `mix do deps.get, deps.compile, compile` on your application to build a binary. @@ -89,7 +89,7 @@ Note that there is still an Nginx proxy server sitting in front of your applicat ## Dependencies -The recommended way to handle Elixir dependencies on Platform.sh is using Hex. +The recommended way to handle Elixir dependencies on {{< vendor/name >}} is using Hex. You can commit a `mix.exs` file in your repository and the system downloads the dependencies in your `deps` section using the build hook above. ```elixir diff --git a/sites/platform/src/languages/go.md b/sites/platform/src/languages/go.md index 1a957987c1..ad60d4814b 100644 --- a/sites/platform/src/languages/go.md +++ b/sites/platform/src/languages/go.md @@ -1,6 +1,6 @@ --- title: "Go" -description: Platform.sh supports building and deploying applications written in Go using Go modules. They're compiled during the Build hook phase, and support both committed dependencies and download-on-demand. +description: "{{< vendor/name >}} supports building and deploying applications written in Go using Go modules. They're compiled during the Build hook phase, and support both committed dependencies and download-on-demand." --- {{% description %}} @@ -21,7 +21,7 @@ description: Platform.sh supports building and deploying applications written in ## Go modules -The recommended way to handle Go dependencies on Platform.sh is using Go module support in Go 1.11 and later. That allows the build process to use `go build` directly without any extra steps, and you can specify an output executable file of your choice. (See the examples below.) +The recommended way to handle Go dependencies on {{< vendor/name >}} is using Go module support in Go 1.11 and later. That allows the build process to use `go build` directly without any extra steps, and you can specify an output executable file of your choice. (See the examples below.) ## Building and running the application @@ -139,7 +139,7 @@ func main() { p, err := psh.NewPlatformInfo() if err != nil { - panic("Not in a Platform.sh Environment.") + panic("Not in a {{< vendor/name >}} Environment.") } http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) { diff --git a/sites/platform/src/languages/java/_index.md b/sites/platform/src/languages/java/_index.md index 832df0af53..12041a2fea 100644 --- a/sites/platform/src/languages/java/_index.md +++ b/sites/platform/src/languages/java/_index.md @@ -1,6 +1,6 @@ --- title: "Java" -description: Java is a general-purpose programming language, and one of the most popular in the world today. Platform.sh supports Java runtimes that can be used with build management tools such as Gradle, Maven, and Ant. +description: Java is a general-purpose programming language, and one of the most popular in the world today. {{< vendor/name >}} supports Java runtimes that can be used with build management tools such as Gradle, Maven, and Ant. layout: single --- @@ -23,7 +23,7 @@ To save space and reduce potential vulnerabilities, they don't contain GUI class ## Support build automation -Platform.sh supports the most common project management tools in the Java ecosystem, including: +{{< vendor/name >}} supports the most common project management tools in the Java ecosystem, including: * [Gradle](https://gradle.org/) * [Maven](https://maven.apache.org/) @@ -53,7 +53,7 @@ hooks: ## Other JVM languages -It’s worth remembering that the JVM by its specification [doesn't read Java code](https://docs.oracle.com/javase/specs/jvms/se8/html/index.html), but bytecode. So within the JVM, it’s possible to [run several languages](https://en.wikipedia.org/wiki/List_of_JVM_languages). Platform.sh supports several of them, such as Kotlin, Groovy, and Scala, so long as that language works with any build automation that Platform.sh supports. +It’s worth remembering that the JVM by its specification [doesn't read Java code](https://docs.oracle.com/javase/specs/jvms/se8/html/index.html), but bytecode. So within the JVM, it’s possible to [run several languages](https://en.wikipedia.org/wiki/List_of_JVM_languages). {{< vendor/name >}}supports several of them, such as Kotlin, Groovy, and Scala, so long as that language works with any build automation that {{< vendor/name >}} supports. | Article | Link | | ------------------------------------------------------------ | ------------------------------------------------------------ | diff --git a/sites/platform/src/languages/java/frameworks.md b/sites/platform/src/languages/java/frameworks.md index d11749c797..2eae55b83a 100644 --- a/sites/platform/src/languages/java/frameworks.md +++ b/sites/platform/src/languages/java/frameworks.md @@ -60,7 +60,7 @@ sidebarTitle: "Frameworks" ## Spring -The [Spring Framework](https://spring.io/projects/spring-framework) provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. Platform.sh is flexible, and allows you to use Spring Framework in several flavors such as [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html) and [Spring Boot](https://spring.io/projects/spring-boot). +The [Spring Framework](https://spring.io/projects/spring-framework) provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform. {{< vendor/name >}} is flexible, and allows you to use Spring Framework in several flavors such as [Spring MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html) and [Spring Boot](https://spring.io/projects/spring-boot). * [Spring Best Practices](../../guides/spring/_index.md) diff --git a/sites/platform/src/languages/java/migration.md b/sites/platform/src/languages/java/migration.md index 8bf1fc457e..4148057722 100644 --- a/sites/platform/src/languages/java/migration.md +++ b/sites/platform/src/languages/java/migration.md @@ -1,15 +1,15 @@ --- -title: "Moving a Java application to Platform.sh" +title: "Moving a Java application to {{< vendor/name >}}" weight: 2 -sidebarTitle: "Moving to Platform.sh" +sidebarTitle: "Moving to {{< vendor/name >}}" --- -It is common to have a Java application that you want to migrate to Platform.sh. -Platform.sh supports several styles of Java application, such as monolith, microservices, stateful, and stateless. +It is common to have a Java application that you want to migrate to {{< vendor/name >}}. +{{< vendor/name >}} supports several styles of Java application, such as monolith, microservices, stateful, and stateless. ## Minimum Requirement -To run a Java application at Platform.sh you need: +To run a Java application at {{< vendor/name >}} you need: * [A supported Java version](/languages/java/_index.md#supported-versions) * [A build management tool](/languages/java/_index.md#support-build-automation) @@ -21,7 +21,7 @@ To run a Java application at Platform.sh you need: * [GitHub](/integrations/source/github.md) * [BitBucket](/integrations/source/bitbucket.md) * [GitLab](/integrations/source/gitlab.md) - * The default Git repository provided by Platform.sh + * The default Git repository provided by {{< vendor/name >}} {{< note >}} A container application can't be bigger than **8 GB** of memory. @@ -30,7 +30,7 @@ For more details, see [tuning](./tuning.md). ## Monolith/Single Application -To start a Java application, you need to understand the [Platform.sh structure](../../overview/structure.md). +To start a Java application, you need to understand the [{{< vendor/name >}} structure](../../overview/structure.md). At minimum, you need to configure your [application](../../create-apps/_index.md). You can also have two [YAML files](../../overview/yaml/_index.md) if you need: @@ -90,7 +90,7 @@ You have the option to use several languages in microservices. If you're using J * [Gradle Multi-project](https://guides.gradle.org/creating-multi-project-builds/) * [Git submodules](/development/submodules.md) -[Platform.sh supports multiple applications](../../create-apps/multi-app/_index.md) and there are two options: +[{{< vendor/name >}} supports multiple applications](../../create-apps/multi-app/_index.md) and there are two options: * One application YAML file to each application * Aggregate all applications in a single file with an `applications.yaml` file @@ -108,9 +108,9 @@ As a single application, in the multi-app, you have the option to set load balan {{< /note >}} -## Access to services included at Platform.sh +## Access to managed services -[Platform.sh has services managed by Platform.sh itself such as database, cache and search engine](/add-services/_index.md). However, you can use a database or any services such as a transition process, just be aware of the [firewall](../../create-apps/app-reference.md#firewall). +[{{< vendor/name >}} has services managed by {{< vendor/name >}} itself such as database, cache and search engine](/add-services/_index.md). However, you can use a database or any services such as a transition process, just be aware of the [firewall](../../create-apps/app-reference.md#firewall). When applications need to access a service, it is important to include the [Relationships key](../../create-apps/app-reference.md#relationships), because. by default an application may not talk to any other container within a project it includes others projects as a microservices architecture. @@ -123,10 +123,10 @@ The most common mechanisms are listed below. If you are using a framework that follows the [Twelve-Factor App](https://12factor.net/) methodology, particularly the [third point](https://12factor.net/config), you can configure the application directly from environment variables. Examples of such frameworks include Spring, Eclipse MicroProfile Config, Quarkus, and Micronauts. -The services information is available in the [**PLATFORM_RELATIONSHIPS** environment variable](../../development/variables/use-variables.md#use-platformsh-provided-variables). +The services information is available in the [**PLATFORM_RELATIONSHIPS** environment variable](../../development/variables/use-variables.md#use-provided-variables). This variable is a base64-encoded JSON object with keys of the relationship name and values of arrays of relationship endpoint definitions. -Platform.sh supports the [`jq` tool](https://stedolan.github.io/jq/), which allows to extract information from this JSON. +{{< vendor/name >}} supports the [`jq` tool](https://stedolan.github.io/jq/), which allows to extract information from this JSON. ```shell export DB_HOST=`echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host"` @@ -173,7 +173,7 @@ web: ### Using Java Config Reader If your framework doesn't support configuration via environment variables, use the [Config Reader](../../development/variables/use-variables.md#access-variables-in-your-app). -This library provides a streamlined way to interact with a Platform.sh environment. It offers utility methods to access routes and relationships more cleanly than reading the raw environment variables yourself. [See the maven dependency](https://mvnrepository.com/artifact/sh.platform/config). +This library provides a streamlined way to interact with a {{< vendor/name >}} environment. It offers utility methods to access routes and relationships more cleanly than reading the raw environment variables yourself. [See the maven dependency](https://mvnrepository.com/artifact/sh.platform/config). ```java import Config; diff --git a/sites/platform/src/languages/java/tuning.md b/sites/platform/src/languages/java/tuning.md index 89a735bf4f..6130320fcb 100644 --- a/sites/platform/src/languages/java/tuning.md +++ b/sites/platform/src/languages/java/tuning.md @@ -4,7 +4,7 @@ weight: 2 sidebarTitle: "Tuning" --- -There are a number of settings that can be adjusted for each application to optimize its performance on Platform.sh. +There are a number of settings that can be adjusted for each application to optimize its performance on {{< vendor/name >}}. ## Memory limits @@ -15,7 +15,7 @@ To extract the container-scaled value on the command line, use `$(jq .info.limit You should also set the `ExitOnOutOfMemoryError`. When you enable this option, the JVM exits on the first occurrence of an out-of-memory error. -Platform.sh will restart the application automatically. +{{< vendor/name >}} will restart the application automatically. These are the recommended parameters for running a Java application. Thus, the command to use to start a Java application is: @@ -27,7 +27,7 @@ java -jar -Xmx$(jq .info.limits.memory /run/config.json)m -XX:+ExitOnOutOfMemory When migrating the application to a cloud environment, it is often essential to analyze the Garbage Collector's log and behavior. For this, there are two options: -* Placing the log into the Platform.sh `/var/log/app.log` file (which captures `STDOUT`). +* Placing the log into the {{< vendor/name >}} `/var/log/app.log` file (which captures `STDOUT`). * Creating a log file specifically for the GC. To use the `STDOUT` log, you can add the parameter `-XX: + PrintGCDetails`, E.g.: @@ -78,7 +78,7 @@ java -jar -Xmx$(jq .info.limits.memory /run/config.json)m -XX:+ExitOnOutOfMemory Ideally, all applications should run the latest LTS release of the JVM at least. That is currently Java 11. -Java 11 has a number of performance improvements, particularly on container-based environments such as Platform.sh. +Java 11 has a number of performance improvements, particularly on container-based environments such as {{< vendor/name >}}. However, in many cases, this isn't possible. If you are still running on Java 8 there are two additional considerations. @@ -96,5 +96,5 @@ java -jar -Xmx$(jq .info.limits.memory /run/config.json)m -XX:+UseG1GC -XX:+UseS ## References -* [How to Migrate my Java application to Platform.sh](https://community.platform.sh/t/how-to-migrate-my-java-application-to-platfrom-sh/529) +* [How to Migrate my Java application to {{< vendor/name >}}](https://community.platform.sh/t/how-to-migrate-my-java-application-to-platfrom-sh/529) * [Introduction to Garbage Collection Tuning](https://docs.oracle.com/en/java/javase/14/gctuning/introduction-garbage-collection-tuning.html#GUID-326EB4CF-8C8C-4267-8355-21AB04F0D304) diff --git a/sites/platform/src/languages/lisp.md b/sites/platform/src/languages/lisp.md index 73e9b32bcb..0d14b3f501 100644 --- a/sites/platform/src/languages/lisp.md +++ b/sites/platform/src/languages/lisp.md @@ -1,6 +1,6 @@ --- title: "Lisp" -description: Platform.sh supports building and deploying applications written in Lisp using Common Lisp (the SBCL version) with ASDF and Quick Lisp support. They're compiled during the Build phase, and support both committed dependencies and download-on-demand. +description: "{{< vendor/name >}} supports building and deploying applications written in Lisp using Common Lisp (the SBCL version) with ASDF and Quick Lisp support. They're compiled during the Build phase, and support both committed dependencies and download-on-demand." --- {{% description %}} @@ -17,11 +17,11 @@ description: Platform.sh supports building and deploying applications written in ## Assumptions -Platform.sh is making assumptions about your application to provide a more streamlined experience. These assumptions are the following: +{{< vendor/name >}} is making assumptions about your application to provide a more streamlined experience. These assumptions are the following: - Your `.asd` file is named like your system name. For example `example.asd` has `(defsystem example ...)`. -Platform.sh will then run `(asdf:make :example)` on your system to build a binary. +{{< vendor/name >}} will then run `(asdf:make :example)` on your system to build a binary. If you don't want these assumptions, you can disable this behavior by specifying in your `.platform.app.yaml`: @@ -32,7 +32,7 @@ build: ## Dependencies -The recommended way to handle Lisp dependencies on Platform.sh is using ASDF. Commit a `.asd` file in your repository and the system will automatically download the dependencies using QuickLisp. +The recommended way to handle Lisp dependencies on {{< vendor/name >}} is using ASDF. Commit a `.asd` file in your repository and the system will automatically download the dependencies using QuickLisp. ## QuickLisp options @@ -57,9 +57,9 @@ runtime: ``` -## Platform.sh variables +## Built-in variables -Platform.sh exposes relationships and other configuration as [environment variables](../development/variables/_index.md). +{{< vendor/name >}} exposes relationships and other configuration as [environment variables](../development/variables/_index.md). To get the `PORT` environment variable (the port on which your web application is supposed to listen): ```lisp @@ -147,7 +147,7 @@ Then in your program you could access the PostgreSQL instance as follows: ## Example The following is a basic example of a Hunchentoot-based web app -(you can find the corresponding `.asd` and Platform.sh `.yaml` files in the [template](#project-templates)): +(you can find the corresponding `.asd` and {{< vendor/name >}} `.yaml` files in the [template](#project-templates)): ```lisp (defpackage #:example @@ -168,7 +168,7 @@ The following is a basic example of a Hunchentoot-based web app ``` Notice how it gets the `PORT` from the environment and how it sleeps at the end, -as `(start acceptor)` immediately yields and Platform.sh requires apps to run in the foreground. +as `(start acceptor)` immediately yields and {{< vendor/name >}} requires apps to run in the foreground. ## Project templates diff --git a/sites/platform/src/languages/nodejs/_index.md b/sites/platform/src/languages/nodejs/_index.md index 354597f5b0..70f0e576d3 100644 --- a/sites/platform/src/languages/nodejs/_index.md +++ b/sites/platform/src/languages/nodejs/_index.md @@ -1,11 +1,11 @@ --- title: "JavaScript/Node.js" -description: Get started creating JavaScript apps with Node.js on Platform.sh. +description: Get started creating JavaScript apps with Node.js on {{< vendor/name >}}. layout: single --- Node.js is a popular asynchronous JavaScript runtime. -Deploy scalable Node.js apps of all sizes on Platform.sh. +Deploy scalable Node.js apps of all sizes on {{< vendor/name >}}. You can also develop a microservice architecture mixing JavaScript and other apps with [multi-app projects](../../create-apps/multi-app/_index.md). ## Supported versions @@ -28,7 +28,7 @@ To use a specific version in a container with a different language, [use a versi ## Usage example -To use JavaScript with Node.js on Platform.sh, configure your [app configuration](../../create-apps/_index.md) +To use JavaScript with Node.js on {{< vendor/name >}}, configure your [app configuration](../../create-apps/_index.md) (a complete example is included at the end). ### 1. Specify the version @@ -80,7 +80,7 @@ The following example uses the [`platformsh-config` helper](#configuration-reade // Load the http module to create an http server. const http = require('http'); -// Load the Platform.sh configuration +// Load the {{< vendor/name >}} configuration const config = require('platformsh-config').config(); const server = http.createServer(function (request, response) { @@ -88,7 +88,7 @@ const server = http.createServer(function (request, response) { response.end("Hello world!"); }); -// Listen on the port from the Platform.sh configuration +// Listen on the port from the {{< vendor/name >}} configuration server.listen(config.port); ``` @@ -119,7 +119,7 @@ web: ## Dependencies -By default, Platform.sh assumes you're using npm as a package manager. +By default, {{< vendor/name >}} assumes you're using npm as a package manager. If your code has a `package.json`, the following command is run as part of the default [build flavor](../../create-apps/app-reference.md#build): ```bash diff --git a/sites/platform/src/languages/nodejs/debug.md b/sites/platform/src/languages/nodejs/debug.md index be73fb7915..5b3841e42b 100644 --- a/sites/platform/src/languages/nodejs/debug.md +++ b/sites/platform/src/languages/nodejs/debug.md @@ -7,7 +7,7 @@ Effectively debugging web apps takes effort, especially when an HTTP request goes through multiple layers before reaching your web app. Follow the steps below to debug a specific app. -You can choose to debug in an environment deployed to Platform.sh +You can choose to debug in an environment deployed to {{< vendor/name >}} or with your app running locally but connected to deployed services. In either case, make sure to debug in a non-production environment. diff --git a/sites/platform/src/languages/nodejs/node-version.md b/sites/platform/src/languages/nodejs/node-version.md index 16bbbd2126..0ec3e1215d 100644 --- a/sites/platform/src/languages/nodejs/node-version.md +++ b/sites/platform/src/languages/nodejs/node-version.md @@ -1,14 +1,14 @@ --- title: "Manage Node.js versions" weight: 1 -description: See how to manage different Node.js versions in your Platform.sh containers." +description: See how to manage different Node.js versions in your {{< vendor/name >}} containers." --- -Each Platform.sh container image includes a specific language in a specific version. +Each {{< vendor/name >}}container image includes a specific language in a specific version. A set of dependencies is also provided based on that language version. This ensures that your application container is as small and efficient as possible. -Therefore, by default, when you use a Platform.sh container image, +Therefore, by default, when you use a {{< vendor/name >}} container image, you use the Node.js version that's included in that image, if any. If you want to use a different Node.js version, use a version manager to install it yourself. diff --git a/sites/platform/src/languages/php/_index.md b/sites/platform/src/languages/php/_index.md index 27373d11d8..929d823445 100644 --- a/sites/platform/src/languages/php/_index.md +++ b/sites/platform/src/languages/php/_index.md @@ -1,6 +1,6 @@ --- title: "PHP" -description: Deploy PHP apps on Platform.sh. +description: Deploy PHP apps on {{< vendor/name >}}. layout: single --- @@ -24,7 +24,7 @@ Note that from PHP versions 7.1 to 8.1, the images support the Zend Thread Safe ## Usage example -Configure your app to use PHP on Platform.sh. +Configure your app to use PHP on {{< vendor/name >}}. ### 1. Specify the version @@ -375,7 +375,7 @@ memory_limit=-1 ### Disable functions for security A common recommendation for securing PHP installations is disabling built-in functions frequently used in remote attacks. -By default, Platform.sh doesn't disable any functions. +By default, {{< vendor/name >}} doesn't disable any functions. If you're sure a function isn't needed in your app, you can disable it. diff --git a/sites/platform/src/languages/php/composer-auth.md b/sites/platform/src/languages/php/composer-auth.md index 1813d38b17..a4810f163d 100644 --- a/sites/platform/src/languages/php/composer-auth.md +++ b/sites/platform/src/languages/php/composer-auth.md @@ -12,9 +12,9 @@ follow the instructions on this page. ## Before you begin You need: -- A Platform.sh project using [PHP](../php/_index.md) and Composer +- A {{< vendor/name >}} project using [PHP](../php/_index.md) and Composer - Credentials to access a private third-party Composer repository -- The [Platform.sh CLI](../../administration/cli/_index.md) +- The [{{< vendor/name >}} CLI](../../administration/cli/_index.md) ## 1. Declare a private Composer repository diff --git a/sites/platform/src/languages/php/extensions.md b/sites/platform/src/languages/php/extensions.md index bef2b6847e..63211fb2ec 100644 --- a/sites/platform/src/languages/php/extensions.md +++ b/sites/platform/src/languages/php/extensions.md @@ -1,11 +1,11 @@ --- title: "Extensions" weight: 1 -description: See what PHP extensions are available with each PHP version on Platform.sh. +description: See what PHP extensions are available with each PHP version on {{< vendor/name >}}. --- PHP has a number of [extensions](https://pecl.php.net/) developed by members of the community. -Some of them are available for Platform.sh containers. +Some of them are available for {{< vendor/name >}} containers. {{< note >}} diff --git a/sites/platform/src/languages/php/fpm.md b/sites/platform/src/languages/php/fpm.md index 667226cb90..0ce6e495bc 100644 --- a/sites/platform/src/languages/php/fpm.md +++ b/sites/platform/src/languages/php/fpm.md @@ -8,7 +8,7 @@ PHP-FPM helps improve your app's performance by maintaining pools of workers that can process PHP requests. This is particularly useful when your app needs to handle a high number of simultaneous requests. -By default, Platform.sh automatically sets a maximum number of PHP-FPM workers for your app. +By default, {{< vendor/name >}} automatically sets a maximum number of PHP-FPM workers for your app. This number is calculated based on three parameters: - The container memory: the amount of memory you can allot for PHP processing depending on [app size](../../create-apps/app-reference.md#sizes). @@ -23,7 +23,7 @@ Also, the minimum number of PHP-FPM workers is 2. {{< note >}} -To ensure that Platform.sh doesn't add more workers than the CPU can handle, +To ensure that {{< vendor/name >}} doesn't add more workers than the CPU can handle, a CPU limit applies as soon as the number of set workers equals or exceeds 25. This limit is calculated as follows: `number of vCPU cores * 5`. @@ -39,7 +39,7 @@ To adjust the maximum number of PHP-FPM workers depending on your app's needs, f You need: - An up-and-running web app in PHP, complete with [PHP-FPM](https://www.php.net/manual/en/install.fpm.php) -- The [Platform.sh CLI](../../administration/cli/_index.md) +- The [{{< vendor/name >}} CLI](../../administration/cli/_index.md) Note that the memory settings mentioned on this page are different from the [`memory_limit` PHP setting](./_index.md). The `memory_limit` setting is the maximum amount of memory a single PHP process can use @@ -82,14 +82,14 @@ Setting a lower request memory presents a risk of allowing more concurrent reque This can result in memory swapping and latencies. For further help in estimating the optimal request memory for your app, -use the [log analyzer tool for Platform.sh](https://github.com/pixelant/platformsh-analytics) +use the [log analyzer tool for {{< vendor/name >}}](https://github.com/pixelant/platformsh-analytics) by [Pixelant](https://www.pixelant.net/). This tool offers a better visualization of access logs. It also provides additional insights into the operation of your app. These can help you further optimize your configuration and provide guidance on when to increase your plan size. Note that this tool is maintained by a third party, -not by Platform.sh. +not by {{< vendor/name >}}. ## 2. Adjust the maximum number of PHP-FPM workers diff --git a/sites/platform/src/languages/php/redis.md b/sites/platform/src/languages/php/redis.md index 31b2840ee0..aa2d5eb028 100644 --- a/sites/platform/src/languages/php/redis.md +++ b/sites/platform/src/languages/php/redis.md @@ -4,12 +4,12 @@ sidebarTitle: Custom Redis weight: 7 --- -[Redis](../../add-services/redis.md) is a popular structured key-value service, supported by Platform.sh. +[Redis](../../add-services/redis.md) is a popular structured key-value service, supported by {{< vendor/name >}}. It's frequently used for caching. ## Install PhpRedis -The [PhpRedis](https://github.com/phpredis/phpredis) extension is available on Platform.sh's PHP container images. +The [PhpRedis](https://github.com/phpredis/phpredis) extension is available on {{< vendor/name >}}'s PHP container images. The extension has been known to break its API between versions when removing deprecated functionality. The version available on each application image is the latest available at the time that PHP version was built, which if your app is sensitive to PhpRedis versions may not be ideal. diff --git a/sites/platform/src/languages/php/swoole.md b/sites/platform/src/languages/php/swoole.md index 4a5edeefd1..ef68a084d7 100644 --- a/sites/platform/src/languages/php/swoole.md +++ b/sites/platform/src/languages/php/swoole.md @@ -16,7 +16,7 @@ Swoole requires PHP 7.3+. The Swoole installation script is compatible up to PHP 8.0. {{< /note >}} -Check the documentation related to [Laravel Octane on Platform.sh](../../guides/laravel/deploy/octane.md). +Check the documentation related to [Laravel Octane on {{< vendor/name >}}](../../guides/laravel/deploy/octane.md). {{% swoole %}} diff --git a/sites/platform/src/languages/php/troubleshoot.md b/sites/platform/src/languages/php/troubleshoot.md index 01cff4f614..48a6bb4ee2 100644 --- a/sites/platform/src/languages/php/troubleshoot.md +++ b/sites/platform/src/languages/php/troubleshoot.md @@ -16,13 +16,13 @@ WARNING: [pool web] server reached max_children setting (2), consider raising it ``` This means some requests have to wait until another finishes. -Platform.sh sets the number of workers based on the available memory of your container +{{< vendor/name >}} sets the number of workers based on the available memory of your container and the estimated average memory size of each process. You have two ways to increase the number of workers: - Adjust the [worker sizing hints](./fpm.md) for your project. -- Upgrade your Platform.sh plan to get more computing resources. +- Upgrade your {{< vendor/name >}} plan to get more computing resources. ## Execution timeout @@ -56,7 +56,7 @@ Otherwise, you may check if the following options are applicable: - Find the most visited pages and see if they can be cached and/or put behind a CDN. Refer to [how caching works](../../define-routes/cache.md). -- Upgrade your Platform.sh plan to get more computing resources. +- Upgrade your {{< vendor/name >}} plan to get more computing resources. ## Troubleshoot a crashed PHP process @@ -85,7 +85,7 @@ To solve this issue, try the following approaches: - Check if the memory usage of your app is as expected and try to optimize it. - Use [sizing hints](./fpm.md) to reduce the amount of PHP workers, which reduces the memory footprint. -- Upgrade your Platform.sh plan to get more computing resources. +- Upgrade your {{< vendor/name >}} plan to get more computing resources. ## Restart PHP processes stuck during a build or deployment diff --git a/sites/platform/src/languages/php/tuning.md b/sites/platform/src/languages/php/tuning.md index f6572556e5..12c3f99b21 100644 --- a/sites/platform/src/languages/php/tuning.md +++ b/sites/platform/src/languages/php/tuning.md @@ -4,7 +4,7 @@ weight: 3 --- Once your app is up and running it still needs to be kept fast. -Platform.sh offers a wide degree of flexibility in how PHP behaves, +{{< vendor/name >}} offers a wide degree of flexibility in how PHP behaves, but that does mean you may need to take a few steps to ensure your site is running optimally. The following recommendations are guidelines only. @@ -199,7 +199,7 @@ To force a restart of PHP-FPM: To optimize your app, consider using a [profiler](../../increase-observability/integrate-observability/_index.md). A profiler helps determine what slow spots can be found and addressed and helps improve performance. -The web agency [Pixelant](https://www.pixelant.net/) has released a [log analyzer tool for Platform.sh](https://github.com/pixelant/platformsh-analytics) +The web agency [Pixelant](https://www.pixelant.net/) has released a [log analyzer tool for {{< vendor/name >}}](https://github.com/pixelant/platformsh-analytics) that offers visualization of access logs to determine how much memory requests are using on average. It also offers additional insights into the operation of your site and can suggest places to further optimize your configuration or when it's time to increase your plan size. -Note that this tool is maintained by a third party, not by Platform.sh. +Note that this tool is maintained by a third party, not by {{< vendor/name >}}. diff --git a/sites/platform/src/languages/php/xdebug.md b/sites/platform/src/languages/php/xdebug.md index fc322a3f56..f89ccf515e 100644 --- a/sites/platform/src/languages/php/xdebug.md +++ b/sites/platform/src/languages/php/xdebug.md @@ -7,7 +7,7 @@ sidebarTitle: "Xdebug" [Xdebug](https://xdebug.org/) is a real-time debugger extension for PHP. While usually used for local development, it can also be helpful for debugging aberrant behavior on the server. -As configured on Platform.sh, it avoids any runtime overhead for non-debug requests, even in production, and only allows connections via SSH tunnels to avoid any security issues. +As configured on {{< vendor/name >}}, it avoids any runtime overhead for non-debug requests, even in production, and only allows connections via SSH tunnels to avoid any security issues. Note that Xdebug runs only on your app containers. So you can't use it for [worker containers](../../create-apps/workers.md). @@ -23,7 +23,7 @@ The following table shows the PHP versions where Xdebug is available on Grid env You also need: -- The Platform.sh [CLI](../../administration/cli/_index.md) +- The {{< vendor/name >}} [CLI](../../administration/cli/_index.md) - A Xdebug-compatible IDE installed on your machine. For setup instructions, consult your IDE's Xdebug documentation, such as that for [PHPStorm](https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html). @@ -41,7 +41,7 @@ runtime: {{< variable "YOUR_KEY" >}} can be any arbitrary alphanumeric string. -When that key is defined, Platform.sh starts a second PHP-FPM process on the container that's identically configured but also has Xdebug enabled. +When that key is defined, {{< vendor/name >}} starts a second PHP-FPM process on the container that's identically configured but also has Xdebug enabled. Only incoming requests that have an Xdebug cookie or query parameter set are forwarded to the debug PHP-FPM process. All other requests are directed to the normal PHP-FPM process and thus have no performance impact. @@ -101,8 +101,8 @@ The common steps for setup usually include: 1. Configuring the Xdebug debug port and making sure it's set to the expected value (`9003` as default or the value you chose with `--port` when opening the tunnel). 2. Making sure that external connections are allowed. -3. Adding a new server for your Platform.sh environment. - The Host should be the hostname of the environment on Platform.sh you are debugging. +3. Adding a new server for your {{< vendor/name >}} environment. + The Host should be the hostname of the environment on {{< vendor/name >}} you are debugging. The Port should always be `443` and the Debugger set to `Xdebug`. 4. Ensuring path mappings is enabled. This lets you define what remote paths on the server correspond to what path on your local machine. diff --git a/sites/platform/src/languages/python/_index.md b/sites/platform/src/languages/python/_index.md index e4f78ebb79..6d653180b6 100644 --- a/sites/platform/src/languages/python/_index.md +++ b/sites/platform/src/languages/python/_index.md @@ -1,10 +1,10 @@ --- title: "Python" -description: Get started creating Python apps on Platform.sh. +description: Get started creating Python apps on {{< vendor/name >}}. --- Python is a general purpose scripting language often used in web development. -You can deploy Python apps on Platform.sh using a server or a project such as [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/). +You can deploy Python apps on {{< vendor/name >}} using a server or a project such as [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/). ## Supported versions @@ -28,7 +28,7 @@ You are strongly recommended to upgrade to a supported version. ### Run your own server You can define any server to handle requests. -Once you have it configured, add the following configuration to get it running on Platform.sh: +Once you have it configured, add the following configuration to get it running on {{< vendor/name >}}: 1. Specify one of the [supported versions](#supported-versions): @@ -107,7 +107,7 @@ Follow these steps to get your server started. def application(env, start_response): start_response('200 OK', [('Content-Type', 'text/html')]) - return [b"Hello world from Platform.sh"] + return [b"Hello world from {{< vendor/name >}}"] ``` ## Package management @@ -228,7 +228,7 @@ see how to [sanitize databases](../../development/sanitize-db/_index.md). ## Frameworks -All major Python web frameworks can be deployed on Platform.sh. +All major Python web frameworks can be deployed on {{< vendor/name >}}. See dedicated guides for deploying and working with them: - [Django](../../guides/django/_index.md) diff --git a/sites/platform/src/languages/python/dependencies.md b/sites/platform/src/languages/python/dependencies.md index c56c38d782..9dafa1a97e 100644 --- a/sites/platform/src/languages/python/dependencies.md +++ b/sites/platform/src/languages/python/dependencies.md @@ -25,7 +25,7 @@ commit a `requirements.txt` file with all of the dependencies needed for your ap Then install the packages in your [`build` hook](../../create-apps/hooks/_index.md), such as by running the following command: `pip install -r requirements.txt`. -The following sections present ideas to keep in mind to ensure repeatable deployments on Platform.sh. +The following sections present ideas to keep in mind to ensure repeatable deployments on {{< vendor/name >}}. ### pip version @@ -77,7 +77,7 @@ hooks: You can write `requirements.txt` files in various ways. You can specify anything from the latest major to a specific patch version in a [requirement specifier](https://pip.pypa.io/en/stable/reference/requirement-specifiers/). Use `pip freeze` before committing your requirements to pin specific package versions. -This ensures repeatable builds on Platform.sh with the same packages. +This ensures repeatable builds on {{< vendor/name >}} with the same packages. ## Pipenv @@ -142,7 +142,7 @@ It allows you to declare the libraries your project depends on and manages them Poetry offers a lock file to ensure repeatable installs and can build your project for distribution. It also creates and manages virtual environments to keep project work isolated from the rest of your system. -To set up Poetry on Platform.sh, follow these steps: +To set up Poetry on {{< vendor/name >}}, follow these steps: 1. Configure your virtual environment by setting two variables in your [app configuration](../../create-apps/_index.md). @@ -250,5 +250,5 @@ hooks: Some frameworks and tools recommend using Anaconda or Miniconda to manage packages in Python. The following Community resources can help get you started with them: -- [Running and installing Anaconda/Miniconda on Platform.sh](https://community.platform.sh/t/how-to-run-an-anaconda-miniconda-python-stack-on-platform-sh/230) -- [Running R Shiny using Miniconda on Platform.sh](https://community.platform.sh/t/how-to-run-r-shiny-on-platform-sh/231) +- [Running and installing Anaconda/Miniconda on {{< vendor/name >}}](https://community.platform.sh/t/how-to-run-an-anaconda-miniconda-python-stack-on-platform-sh/230) +- [Running R Shiny using Miniconda on {{< vendor/name >}}](https://community.platform.sh/t/how-to-run-r-shiny-on-platform-sh/231) diff --git a/sites/platform/src/languages/python/python-version.md b/sites/platform/src/languages/python/python-version.md index 6942da6cba..c73d2a6254 100644 --- a/sites/platform/src/languages/python/python-version.md +++ b/sites/platform/src/languages/python/python-version.md @@ -2,7 +2,7 @@ title: Manage Python versions in non-Python containers sidebarTitle: Python in non-Python containers weight: 0 -description: See how to manage different Python versions in your Platform.sh containers. +description: See how to manage different Python versions in your {{< vendor/name >}} containers. --- You may need to use a specific version of Python that isn't available in an app container for a different language. diff --git a/sites/platform/src/languages/python/server.md b/sites/platform/src/languages/python/server.md index 69aed5e2c6..0f22a00336 100644 --- a/sites/platform/src/languages/python/server.md +++ b/sites/platform/src/languages/python/server.md @@ -4,7 +4,7 @@ weight: -90 description: See how to start your apps as you wish with ASGI and WSGI servers. --- -The Python ecosystem offers a number of web servers that can be used to deploy to Platform.sh. +The Python ecosystem offers a number of web servers that can be used to deploy to {{< vendor/name >}}. The following examples deploy a Django project named `myapp`. They assume a `myapp/wsgi.py` or `myapp/asgi.py` file with a callable `application`. Adjust the examples to fit your framework and app. diff --git a/sites/platform/src/languages/ruby.md b/sites/platform/src/languages/ruby.md index bdf923b175..ac8bef13dc 100644 --- a/sites/platform/src/languages/ruby.md +++ b/sites/platform/src/languages/ruby.md @@ -1,7 +1,7 @@ --- title: "Ruby" description: | - Platform.sh supports deploying any Ruby application. Your application can use any Ruby application server such as Unicorn or Puma and deploying a Rails or a Sinatra app is very straight forward. + {{< vendor/name >}} supports deploying any Ruby application. Your application can use any Ruby application server such as Unicorn or Puma and deploying a Rails or a Sinatra app is very straight forward. --- {{% description %}} @@ -34,7 +34,7 @@ A complete example is included at the end of this section. Rails runs by default on a development environment. You can change the Rails/Bundler via those environment variables, - some of which are defaults on Platform.sh. + some of which are defaults on {{< vendor/name >}}. ```yaml variables: @@ -55,7 +55,7 @@ A complete example is included at the end of this section. RAILS_TMP: '/tmp' ``` - The `SECRET_KEY_BASE` variable is generated automatically based on the [`PLATFORM_PROJECT_ENTROPY` variable](../development/variables/use-variables.md#use-platformsh-provided-variables). + The `SECRET_KEY_BASE` variable is generated automatically based on the [`PLATFORM_PROJECT_ENTROPY` variable](../development/variables/use-variables.md#use-provided-variables). You can change it. 3. Build your application with the build hook. @@ -81,7 +81,7 @@ A complete example is included at the end of this section. gem install --no-document bundler -v $BUNDLER_VERSION echo "Installing gems" - # We copy the bundle directory to the Platform.sh cache directory for + # We copy the bundle directory to the {{< vendor/name >}} cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. [ -d "$PLATFORM_CACHE_DIR/bundle" ] && \ @@ -94,7 +94,7 @@ A complete example is included at the end of this section. # precompile assets echo "Precompiling assets" - # We copy the webpacker directory to the Platform.sh cache directory for + # We copy the webpacker directory to the {{< vendor/name >}} cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. mkdir -p "$PLATFORM_CACHE_DIR/webpacker" @@ -235,7 +235,7 @@ hooks: gem install --no-document bundler -v $BUNDLER_VERSION echo "Installing gems" - # We copy the bundle directory to the Platform.sh cache directory for + # We copy the bundle directory to the {{< vendor/name >}} cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. [ -d "$PLATFORM_CACHE_DIR/bundle" ] && \ @@ -248,7 +248,7 @@ hooks: # precompile assets echo "Precompiling assets" - # We copy the webpacker directory to the Platform.sh cache directory for + # We copy the webpacker directory to the {{< vendor/name >}} cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. mkdir -p "$PLATFORM_CACHE_DIR/webpacker" diff --git a/sites/platform/src/languages/rust.md b/sites/platform/src/languages/rust.md index 46977decf7..66749b21b7 100644 --- a/sites/platform/src/languages/rust.md +++ b/sites/platform/src/languages/rust.md @@ -7,7 +7,7 @@ banner: To share your feedback so we can improve it, add a comment to the [Rust feature card](https://next.platform.sh/c/221-rust). --- -Platform.sh supports building and deploying applications written in Rust. +{{< vendor/name >}} supports building and deploying applications written in Rust. ## Supported versions @@ -19,7 +19,7 @@ Platform.sh supports building and deploying applications written in Rust. ## Dependencies -The recommended way to handle Rust dependencies on Platform.sh is using Cargo. +The recommended way to handle Rust dependencies on {{< vendor/name >}} is using Cargo. Commit a `Cargo.toml` and a `Cargo.lock` file in your repository so the system automatically downloads dependencies using Cargo. @@ -66,9 +66,9 @@ web: Note that there is still an Nginx proxy server sitting in front of your application. If desired, certain paths may be served directly by Nginx without hitting your application (for static files, primarily) or you may route all requests to the Rust app unconditionally, as in the example above. -## Platform.sh variables +## Built-in variables -Platform.sh exposes relationships and other configuration as [environment variables](../development/variables/_index.md). +{{< vendor/name >}} exposes relationships and other configuration as [environment variables](../development/variables/_index.md). To get the `PORT` environment variable (the port on which your app is supposed to listen), use the following snippet: @@ -92,7 +92,7 @@ use the following snippet: ## Complete example -Here is a basic hello world app to illustrate how you can use Rust with Platform.sh. +Here is a basic hello world app to illustrate how you can use Rust with {{< vendor/name >}}. It builds from a `hello.rs` file to serve a static `index.html`. Follow these steps: diff --git a/sites/platform/src/other/glossary.md b/sites/platform/src/other/glossary.md index 13da242713..7e00fa4c43 100644 --- a/sites/platform/src/other/glossary.md +++ b/sites/platform/src/other/glossary.md @@ -92,7 +92,7 @@ These differences aren't present with [{{% names/dedicated-gen-3 %}} projects](. Older versions of languages and services eventually reach the end of their lives. This means they stop getting security and other updates and may have security vulnerabilities. -When that happens, the versions in Platform.sh are deprecated. +When that happens, the versions in {{< vendor/name >}} are deprecated. This means you can still use them in your project, but they aren't fully secure. It's also possible they'll stop working at some point. @@ -106,7 +106,7 @@ Drush is a command-line shell and scripting interface for Drupal. Drush site aliases allow you to define short names that let you run Drush commands on specific local or remote Drupal installations. -The Platform.sh CLI configures Drush aliases for you on your local environment +The {{< vendor/name >}} CLI configures Drush aliases for you on your local environment (via `platform get` or `platform drush-aliases`). You can also configure them manually. @@ -164,7 +164,7 @@ When you merge an environment, three things happen: A Platform as a Service is an end-to-end hosting solution that includes workflow tools, APIs, and other functionality above and beyond basic hosting. -The best example is Platform.sh (although we're a little biased). +The best example is {{< vendor/name >}}(although we're a little biased). ## Production plan diff --git a/sites/platform/src/overview/_index.md b/sites/platform/src/overview/_index.md index 5b6fb574d0..9fedb58a27 100644 --- a/sites/platform/src/overview/_index.md +++ b/sites/platform/src/overview/_index.md @@ -1,5 +1,5 @@ --- title: "The big picture" weight: -220 -description: "If you're new to Platform.sh, we recommend starting with Structure and Build & Deploy, which will get you started on the right track to use Platform.sh most effectively." +description: "If you're new to {{< vendor/name >}}, we recommend starting with Structure and Build & Deploy, which will get you started on the right track to use {{< vendor/name >}} most effectively." --- diff --git a/sites/platform/src/overview/build-deploy.md b/sites/platform/src/overview/build-deploy.md index f2bceb631c..fcc43228d4 100644 --- a/sites/platform/src/overview/build-deploy.md +++ b/sites/platform/src/overview/build-deploy.md @@ -1,7 +1,7 @@ --- title: Build and deploy weight: 3 -description: See how applications get built and deployed with Platform.sh. +description: "See how applications get built and deployed with {{< vendor/name >}}." --- Each time you push a change to your app through Git or activate an [environment](../environments/_index.md), @@ -87,12 +87,12 @@ After the deploy process is over, any commands in your `post_deploy` hook are ru ## Deployment philosophy -Platform.sh values consistency over availability, acknowledging that it's nearly impossible to have both. +{{< vendor/name >}} values consistency over availability, acknowledging that it's nearly impossible to have both. During a deployment, the [deploy hook](../create-apps/hooks/hooks-comparison.md#deploy-hook) may make database changes that are incompatible with the previous code version. Having both old and new code running in parallel on different servers could therefore result in data loss. -Platform.sh believes that a minute of planned downtime for authenticated users is preferable to a risk of race conditions +{{< vendor/name >}} believes that a minute of planned downtime for authenticated users is preferable to a risk of race conditions resulting in data corruption, especially with a CDN continuing to serve anonymous traffic uninterrupted. That brief downtime applies only to the environment changes are being pushed to. diff --git a/sites/platform/src/overview/get-support.md b/sites/platform/src/overview/get-support.md index 8cd45b9f2d..1b9f022c67 100644 --- a/sites/platform/src/overview/get-support.md +++ b/sites/platform/src/overview/get-support.md @@ -3,7 +3,7 @@ title: " Get support" weight: 4 toc: false description: | - Find out how to get help if you're experiencing issues with Platform.sh. + Find out how to get help if you're experiencing issues with {{< vendor/name >}}. --- {{% description %}} @@ -11,7 +11,7 @@ description: | ## Create a support ticket If you're experiencing issues related to -the proper functioning of the Platform.sh infrastructure, application container software, or build processes; +the proper functioning of the {{< vendor/name >}} infrastructure, application container software, or build processes; have found possible bugs; or have general questions, open a support ticket: @@ -34,15 +34,15 @@ join other customers and engineers in the [public Slack channel](https://chat.pl ## Community -The [Platform.sh Community site](https://community.platform.sh/) has how-to guides with suggestions -on how to get the most out of Platform.sh. +The [{{< vendor/name >}} Community site](https://community.platform.sh/) has how-to guides with suggestions +on how to get the most out of {{< vendor/name >}}. ## Contact Sales -If you have questions about pricing or need help figuring out if Platform.sh is the right solution for your team, +If you have questions about pricing or need help figuring out if {{< vendor/name >}} is the right solution for your team, get in touch with [Sales](https://platform.sh/contact/). ## Delete your account -To permanently delete your Platform.sh account, +To permanently delete your {{< vendor/name >}} account, [contact Support](https://console.platform.sh/-/users/~/tickets/open). diff --git a/sites/platform/src/overview/philosophy.md b/sites/platform/src/overview/philosophy.md index 36e6ece80a..0c87813c70 100644 --- a/sites/platform/src/overview/philosophy.md +++ b/sites/platform/src/overview/philosophy.md @@ -1,14 +1,14 @@ --- title: Philosophy weight: 1 -description: Gain insight into the philosophy of Platform.sh. +description: Gain insight into the philosophy of {{< vendor/name >}}. --- -Platform.sh aims at reducing configuration and making developers more productive. +{{< vendor/name >}} aims at reducing configuration and making developers more productive. It abstracts your project infrastructure and manages it for you, so you never have to configure services like a web server, a MySQL database, or a Redis cache from scratch again. -Platform.sh is built on one main idea — your server infrastructure is part of your app, +{{< vendor/name >}} is built on one main idea — your server infrastructure is part of your app, so it should be version controlled along with your app. Every branch you push to your Git repository can come with bug fixes, @@ -21,15 +21,15 @@ This allows you to preview exactly what your site would look like if you merged ## The basics -On Platform.sh, a **project** is linked to a Git repository and is composed of one or more **apps**. -An app is a directory in your Git repository with a specific Platform.sh configuration +On {{< vendor/name >}}, a **project** is linked to a Git repository and is composed of one or more **apps**. +An app is a directory in your Git repository with a specific {{< vendor/name >}} configuration and dedicated HTTP endpoints (via the `.platform.app.yaml` file). Projects are deployed in **environments**. An environment is a standalone copy of your live app which can be used for testing, Q&A, implementing new features, fixing bugs, and so on. -Every project you deploy on Platform.sh is built as a *virtual cluster* containing a series of containers. +Every project you deploy on {{< vendor/name >}} is built as a *virtual cluster* containing a series of containers. The main branch of your Git repository is always deployed as a production cluster. Any other branch can be deployed as a staging or development cluster. @@ -48,7 +48,7 @@ all configured by files stored alongside your code: ## The workflow -Every time you deploy a branch to Platform.sh, the code is *built* and then *deployed* on a new cluster. +Every time you deploy a branch to {{< vendor/name >}}, the code is *built* and then *deployed* on a new cluster. The [**build** process](../overview/build-deploy.md#build-steps) looks through the configuration files in your repository and assembles the necessary containers. @@ -81,17 +81,17 @@ That filesystem is the final build artifact. ### How your app is deployed Before starting the [deployment](../overview/build-deploy.md#deploy-steps) of your app, -Platform.sh pauses all incoming requests and holds them to avoid downtime. +{{< vendor/name >}} pauses all incoming requests and holds them to avoid downtime. Then, the current containers are stopped and the new ones are started. -Platform.sh then opens networking connections between the various containers, +{{< vendor/name >}} then opens networking connections between the various containers, as specified in the configuration files. The connection information for each service is available as [environment variables](../guides/symfony/environment-variables.md). Similar to the build step, you can define a [deploy hook](../create-apps/hooks/hooks-comparison.md#deploy-hook) to prepare your app. Your app has complete access to all services, but the filesystem where your code lives is now read-only. -Finally, Platform.sh opens the floodgates and lets incoming requests through your newly deployed app. +Finally, {{< vendor/name >}} opens the floodgates and lets incoming requests through your newly deployed app. ### Add a post-deploy hook @@ -106,10 +106,10 @@ During a redeploy, the `post-deploy` hook is the only hook that is run. ## Get support -If you're facing an issue with Platform.sh, +If you're facing an issue with {{< vendor/name >}}, submit a [Support ticket](https://console.platform.sh/-/users/~/tickets/open). ## What's next? -To get a feeling of what working with Platform.sh entails, +To get a feeling of what working with {{< vendor/name >}} entails, see the [Get Started](../get-started/_index.md) tutorial. \ No newline at end of file diff --git a/sites/platform/src/overview/structure.md b/sites/platform/src/overview/structure.md index 6a1e5aed22..d9ed0399d7 100644 --- a/sites/platform/src/overview/structure.md +++ b/sites/platform/src/overview/structure.md @@ -1,7 +1,7 @@ --- title: Structure weight: 2 -description: Learn about how your Platform.sh environments are structured and which files control that structure. +description: "Learn about how your {{< vendor/name >}} environments are structured and which files control that structure." --- {{< note >}} @@ -14,7 +14,7 @@ For {{% names/dedicated-gen-2 %}} projects, read about how [{{% names/dedicated- {{< /note >}} -Each environment you deploy on Platform.sh is built as a set of containers. +Each environment you deploy on {{< vendor/name >}} is built as a set of containers. Each container is an isolated instance with specific resources. Each environment has 2 to 4 types of containers: diff --git a/sites/platform/src/overview/yaml/_index.md b/sites/platform/src/overview/yaml/_index.md index 0fec96adac..ca5b8437be 100644 --- a/sites/platform/src/overview/yaml/_index.md +++ b/sites/platform/src/overview/yaml/_index.md @@ -1,11 +1,11 @@ --- title: YAML weight: 1 -description: An overview of YAML and its use at Platform.sh. +description: "An overview of YAML and its use at {{< vendor/name >}}." --- [YAML](https://en.wikipedia.org/wiki/YAML) is a human-readable format for data serialization across languages. -This means it's a good fit for human-edited configuration files, like those at Platform.sh. +This means it's a good fit for human-edited configuration files, like those at {{< vendor/name >}}. You can control nearly all aspects of your project's build and deploy pipeline with YAML files. -Learn what YAML is or, if you're already familiar, what custom tags Platform.sh offers. +Learn what YAML is or, if you're already familiar, what custom tags {{< vendor/name >}} offers. diff --git a/sites/platform/src/overview/yaml/platform-yaml-tags.md b/sites/platform/src/overview/yaml/platform-yaml-tags.md index 3a2e618b3d..7c6e58d748 100644 --- a/sites/platform/src/overview/yaml/platform-yaml-tags.md +++ b/sites/platform/src/overview/yaml/platform-yaml-tags.md @@ -1,13 +1,13 @@ --- -title: Platform.sh YAML tags +title: "{{< vendor/name >}} YAML tags" weight: 0 -description: A description of custom YAML tags available for Platform.sh files. +description: "A description of custom YAML tags available for {{< vendor/name >}} files." --- In addition to the [basic functions you should be familiar with](./what-is-yaml.md), YAML allows for special tags. -Platform.sh accepts certain custom tags to facilitate working with configuration files. +{{< vendor/name >}} accepts certain custom tags to facilitate working with configuration files. -These tags work with Platform.sh configuration files, but may not elsewhere. +These tags work with {{< vendor/name >}} configuration files, but may not elsewhere. ## Include @@ -126,4 +126,4 @@ mysearch: The `!archive` tag means that the value for `conf_dir` isn't the string `solr/conf` but the entire `solr/conf` directory. This directory is in the `.platform` directory, since that's where the `services.yaml` file is. -The `solr/conf` directory is then copied into the Platform.sh management system to use with the service. +The `solr/conf` directory is then copied into the {{< vendor/name >}} management system to use with the service. diff --git a/sites/platform/src/overview/yaml/what-is-yaml.md b/sites/platform/src/overview/yaml/what-is-yaml.md index f8d4b8247a..4a37a14edc 100644 --- a/sites/platform/src/overview/yaml/what-is-yaml.md +++ b/sites/platform/src/overview/yaml/what-is-yaml.md @@ -164,6 +164,6 @@ Note that you need to place an alias with `<<:` at the same level as the other k ## What's next -- See what Platform.sh makes possible with [custom tags](./platform-yaml-tags.md). +- See what {{< vendor/name >}} makes possible with [custom tags](./platform-yaml-tags.md). - Read everything that's possible with YAML in the [YAML specification](https://yaml.org/spec/1.2.2/). - See a [YAML file that explains YAML syntax](https://learnxinyminutes.com/docs/yaml/). diff --git a/sites/platform/src/projects/_index.md b/sites/platform/src/projects/_index.md index 7bab699b7f..feee4db2c3 100644 --- a/sites/platform/src/projects/_index.md +++ b/sites/platform/src/projects/_index.md @@ -1,9 +1,9 @@ --- title: Manage projects weight: -75 -description: Learn about projects on Platform.sh are and how to configure them. +description: "Learn about projects on {{< vendor/name >}} are and how to configure them." toc: false --- -See how to manage projects within Platform.sh. +See how to manage projects within {{< vendor/name >}}. To create a project, see how to [get started](../get-started/_index.md). diff --git a/sites/platform/src/projects/delete-project.md b/sites/platform/src/projects/delete-project.md index 87377e540f..8909e61ad7 100644 --- a/sites/platform/src/projects/delete-project.md +++ b/sites/platform/src/projects/delete-project.md @@ -5,7 +5,7 @@ description: See how to delete projects you no longer need. To delete a project, you must be an organization owner or have the [manage plans permission](../administration/users.md#organization-permissions). -To delete a Platform.sh project, including all data, code, and active environments: +To delete a {{< vendor/name >}} project, including all data, code, and active environments: {{< codetabs >}} diff --git a/sites/platform/src/projects/region-migration.md b/sites/platform/src/projects/region-migration.md index 5948923184..ed48ac6813 100644 --- a/sites/platform/src/projects/region-migration.md +++ b/sites/platform/src/projects/region-migration.md @@ -4,7 +4,7 @@ sidebarTitle: Change regions description: See how to change the region your project is in and why you might want to do so. --- -To host your project data, Platform.sh offers several [regions](../development/regions.md). +To host your project data, {{< vendor/name >}} offers several [regions](../development/regions.md). You specify a region when you create a project. You can also change the project's region after it's created. @@ -14,7 +14,7 @@ You can also change the project's region after it's created. - Different data centers are located in different geographic areas. You may want your site close to your users for improved performance. - You may want to move to a region with a lower [environmental impact](../development/regions.md#environmental-impact). -- Some regions are running older versions of the Platform.sh orchestration system that offers fewer features. +- Some regions are running older versions of the {{< vendor/name >}} orchestration system that offers fewer features. If you are on one of those legacy regions, you can migrate to one of the newer regions. ## 1. Plan the migration @@ -140,10 +140,10 @@ Once the new project is running and the DNS has fully propagated, delete the old ## Alternative process -Although not directly supported by Platform.sh, +Although not directly supported by {{< vendor/name >}}, an agency named [Contextual Code](https://www.contextualcode.com/) has built a bash migration script. This script automates most common configurations. If your site is a typical single app with a single SQL database, the script should take care of most of the process for you. -See more at the [Platform.sh Project Migration repository](https://gitlab.com/contextualcode/platformsh-migration). +See more at the [{{< vendor/name >}} Project Migration repository](https://gitlab.com/contextualcode/platformsh-migration). diff --git a/sites/platform/src/security/_index.md b/sites/platform/src/security/_index.md index 8b4441a6ec..4a6c7149fc 100644 --- a/sites/platform/src/security/_index.md +++ b/sites/platform/src/security/_index.md @@ -2,12 +2,12 @@ title: "Security and compliance" weight: -50 description: | - Learn how Platform.sh ensures your data is handled with appropriate care and according to industry standards. + Learn how {{< vendor/name >}} ensures your data is handled with appropriate care and according to industry standards. banner: title: Note body: Your main source of information about the security, privacy, - and compliance of the Platform.sh products and services, - is now the Platform.sh [Trust Center](https://platform.sh/trust-center/). + and compliance of the {{< vendor/name >}} products and services, + is now the {{< vendor/name >}} [Trust Center](https://platform.sh/trust-center/). keywords: - pen-test - penetration test diff --git a/sites/platform/src/security/data-retention.md b/sites/platform/src/security/data-retention.md index 76305b30e0..c4eb78f4f7 100644 --- a/sites/platform/src/security/data-retention.md +++ b/sites/platform/src/security/data-retention.md @@ -1,20 +1,20 @@ --- title: Data retention description: | - Platform.sh logs and stores various types of data as a normal part of its business. This information is only retained as needed to perform relevant business functions. Retention periods vary depending on the type of data stored. If a legal obligation, law enforcement request, or ongoing business need so requires, data may be retained after the original purpose for which it was collected ceases to exist. + {{< vendor/name >}} logs and stores various types of data as a normal part of its business. This information is only retained as needed to perform relevant business functions. Retention periods vary depending on the type of data stored. If a legal obligation, law enforcement request, or ongoing business need so requires, data may be retained after the original purpose for which it was collected ceases to exist. --- {{% description %}} ## Account information -Information relating to customer accounts (login information, billing information, etc.) is retained for as long as the account is active with Platform.sh. +Information relating to customer accounts (login information, billing information, etc.) is retained for as long as the account is active with{{< vendor/name >}}. Customers may request that their account be deleted and all related data be purged by filing a support ticket. ## System logs -System level access and security logs are maintained by Platform.sh for diagnostic purposes. +System level access and security logs are maintained by {{< vendor/name >}} for diagnostic purposes. These logs aren't customer-accessible. These logs are retained for at least 6 months and at most 2 years depending upon legal and standards compliance required for each system. @@ -95,12 +95,12 @@ See more about [backups of {{% names/dedicated-gen-2 %}} environments](../dedica ## Tombstone backups -When a project is deleted, Platform.sh takes a final backup of active environments, as well as the Git repository holding user code. -This final backup is to allow Platform.sh to recover a recently deleted project in case of accident. +When a project is deleted, {{< vendor/name >}} takes a final backup of active environments, as well as the Git repository holding user code. +This final backup is to allow {{< vendor/name >}} to recover a recently deleted project in case of accident. These "tombstone" backups are retained for between 7 days and 6 months depending upon legal and standards compliance required for each system. ## Analytics -Platform.sh uses Google Analytics on various web pages, and so Google Analytics stores collected data for a period of time. +{{< vendor/name >}} uses Google Analytics on various web pages, and so Google Analytics stores collected data for a period of time. We have configured our Google Analytics account to store data for 14 months from the time you last accessed our site, which is the minimum Google allows. diff --git a/sites/platform/src/security/web-application-firewall/_index.md b/sites/platform/src/security/web-application-firewall/_index.md index 76e6d8595e..476aa8f1d8 100644 --- a/sites/platform/src/security/web-application-firewall/_index.md +++ b/sites/platform/src/security/web-application-firewall/_index.md @@ -1,10 +1,10 @@ --- title: Web Application Firewall (WAF) -description: Find out which WAF options Platform.sh offers to help protect your site. +description: "Find out which WAF options {{< vendor/name >}} offers to help protect your site." banner: type: tiered-feature --- To protect your app from common security threats, Platform. sh provides its own Web Application Firewall (WAF). -You can also subscribe to the Fastly Next-Gen WAF through Platform.sh. \ No newline at end of file +You can also subscribe to the Fastly Next-Gen WAF through {{< vendor/name >}}. \ No newline at end of file diff --git a/sites/platform/src/security/web-application-firewall/fastly-waf.md b/sites/platform/src/security/web-application-firewall/fastly-waf.md index bc5a0bfc3d..3157f8b687 100644 --- a/sites/platform/src/security/web-application-firewall/fastly-waf.md +++ b/sites/platform/src/security/web-application-firewall/fastly-waf.md @@ -1,21 +1,21 @@ --- title: Fastly Next-Gen WAF -description: Find out about the offers you can choose from to subscribe to the Fastly Next-Gen Web Application Firewall (WAF) through Platform.sh. +description: "Find out about the offers you can choose from to subscribe to the Fastly Next-Gen Web Application Firewall (WAF) through {{< vendor/name >}}." weight: 2 banner: type: tiered-feature --- -On top of the [Platform.sh Web Application Firewall (WAF)](./waf.md) included in Enterprise and Elite plans, +On top of the [{{< vendor/name >}} Web Application Firewall (WAF)](./waf.md) included in Enterprise and Elite plans, you can subscribe to the Fastly Next-Gen WAF to further protect your app from security threats. ## Available offers -If you want to subscribe to the Fastly Next-Gen WAF through Platform.sh, +If you want to subscribe to the Fastly Next-Gen WAF through {{< vendor/name >}}, you can choose from three offers: -- If you subscribe to the **Basic** or **Managed** offer, your WAF is fully managed by Platform.sh. -- If you subscribe to the **Advanced** offer, after your WAF is installed by Platform.sh, +- If you subscribe to the **Basic** or **Managed** offer, your WAF is fully managed by {{< vendor/name >}}. +- If you subscribe to the **Advanced** offer, after your WAF is installed by {{< vendor/name >}}, you have access to more features that you manage yourself. To view a list of all the features included in each offer, see the following table. @@ -23,7 +23,7 @@ To view a list of all the features included in each offer, see the following tab {{< note theme="info" >}} Links to the official [Fastly Next-Gen WAF documentation](https://docs.fastly.com/products/fastly-next-gen-waf) are provided for reference only. -The offers described on this page have been designed specifically for Platform.sh customers. +The offers described on this page have been designed specifically for {{< vendor/name >}} customers. Included features may present limitations compared to those advertised by Fastly to their direct customers. {{< /note >}} @@ -39,5 +39,5 @@ Included features may present limitations compared to those advertised by Fastly | [Custom signals](https://docs.fastly.com/signalsciences/using-signal-sciences/signals/working-with-custom-signals/) | No | No | Yes | | [Standard API & ATO signals](https://docs.fastly.com/signalsciences/using-signal-sciences/rules/working-with-templated-rules/) | No | No | Yes | -To subscribe to a Fastly Next-Gen WAF offer through Platform.sh, +To subscribe to a Fastly Next-Gen WAF offer through {{< vendor/name >}}, [contact Sales](https://platform.sh/contact/). \ No newline at end of file diff --git a/sites/platform/src/security/web-application-firewall/waf.md b/sites/platform/src/security/web-application-firewall/waf.md index 7803115a08..186a4aa575 100644 --- a/sites/platform/src/security/web-application-firewall/waf.md +++ b/sites/platform/src/security/web-application-firewall/waf.md @@ -1,15 +1,15 @@ --- -title: Platform.sh WAF +title: "{{< vendor/name >}} WAF" description: Learn how the WAF included in Enterprise and Elite plans can help protect your site from distributed denial of service (DDoS) attacks. weight: 1 banner: type: tiered-feature --- -Enterprise and Elite projects on Platform.sh come with a web application firewall (WAF) at no additional cost. +Enterprise and Elite projects on {{< vendor/name >}} come with a web application firewall (WAF) at no additional cost. This WAF monitors requests to your app and blocks suspicious ones. -All traffic to Platform.sh endpoints is also filtered +All traffic to {{< vendor/name >}} endpoints is also filtered using a system that takes into account traffic patterns and abuse scores. ## CRLF injection prevention @@ -80,7 +80,7 @@ the WAF implements additional rules to enforce the HTTP protocol. [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) defines the generic syntax for URIs. When the WAF detects a URI with incorrect syntax, the incoming connection is terminated. -The request is then reconstructed on the internal Platform.sh network, +The request is then reconstructed on the internal {{< vendor/name >}} network, enforcing the valid format in transit. ### File upload limit @@ -123,12 +123,12 @@ This rule helps protect apps from [request smuggling](#request-smuggling). The WAF detects and blocks requests featuring both headers and forces requests to use [chunked transfer encoding](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) -only on the internal Platform.sh network. +only on the internal {{< vendor/name >}} network. #### Missing or empty `host` headers As [routes are mapped](../../define-routes/_index.md) based on host names, -the Platform.sh WAF blocks requests with an empty or absent `host` header. +the {{< vendor/name >}} WAF blocks requests with an empty or absent `host` header. #### Other restricted HTTP headers @@ -140,5 +140,5 @@ Slowloris DDoS attacks use partial HTTP requests to open connections between a s These connections are then kept open for as long as possible to overwhelm the web server. While Apache web servers are vulnerable to Slowloris attacks, Nginx servers aren't. -Since Platform.sh router services use Nginx processes, +Since {{< vendor/name >}} router services use Nginx processes, your projects are protected against such attacks. \ No newline at end of file diff --git a/sites/platform/src/tutorials/dependency-updates.md b/sites/platform/src/tutorials/dependency-updates.md index c950a83d68..cfecae8fd1 100644 --- a/sites/platform/src/tutorials/dependency-updates.md +++ b/sites/platform/src/tutorials/dependency-updates.md @@ -8,14 +8,14 @@ tier: - Enterprise --- -Platform.sh allows you to update your dependencies through [source operations](../create-apps/source-operations.md). +{{< vendor/name >}} allows you to update your dependencies through [source operations](../create-apps/source-operations.md). ## Before you start You need: -- The [Platform.sh CLI](../administration/cli/_index.md) -- An [API token](../administration/cli/api-tokens.md#2-create-a-platformsh-api-token) +- The [{{< vendor/name >}} CLI](../administration/cli/_index.md) +- An [API token](../administration/cli/api-tokens.md#2-create-an-api-token) ## 1. Define a source operation to update your dependencies @@ -133,8 +133,8 @@ you can automate it using a cron job. Note that it’s best not to run source operations on your production environment, but rather on a dedicated environment where you can test changes. -Make sure you have the [Platform.sh CLI](../administration/cli/_index.md) installed -and [an API token](../administration/cli/api-tokens.md#2-create-a-platformsh-api-token) +Make sure you have the [{{< vendor/name >}} CLI](../administration/cli/_index.md) installed +and [an API token](../administration/cli/api-tokens.md#2-create-an-api-token) so you can run a cron job in your app container. 1. Set your API token as a top-level environment variable: @@ -181,10 +181,10 @@ Make sure you carefully check your [user access on this project](../administrati hooks: build: | set -e - echo "Installing Platform.sh CLI" + echo "Installing {{< vendor/name >}} CLI" curl -fsSL https://raw.githubusercontent.com/platformsh/cli/main/installer.sh | bash - echo "Testing Platform.sh CLI" + echo "Testing {{< vendor/name >}} CLI" platform ``` @@ -235,7 +235,7 @@ To do so, follow these steps: * Sends a color-coded formatted message to Slack. * * To control what events trigger it, use the --events switch in - * the Platform.sh CLI. + * the {{< vendor/name >}} CLI. * * Replace SLACK_URL in the following script with your Slack webhook URL. * Get one here: https://api.slack.com/messaging/webhooks @@ -271,7 +271,7 @@ To do so, follow these steps: sendSlackMessage(activity.text, activity.log); ``` -4. Run the following [Platform.sh CLI](../administration/cli/_index.md) command: +4. Run the following [{{< vendor/name >}} CLI](../administration/cli/_index.md) command: ```bash platform integration:add --type script --file ./my_script.js --events=environment.source-operation @@ -294,7 +294,7 @@ This script receives the same payload as an activity script and responds to the but can be hosted on your own server and in your own language. To configure the integration between your webhook and your source operation, -run the following [Platform.sh CLI](../administration/cli/_index.md) command: +run the following [{{< vendor/name >}} CLI](../administration/cli/_index.md) command: ```bash platform integration:add --type=webhook --url=URL_TO_RECEIVE_JSON --events=environment.source-operation diff --git a/sites/platform/src/tutorials/exporting.md b/sites/platform/src/tutorials/exporting.md index 37b7509acc..e377603f0c 100644 --- a/sites/platform/src/tutorials/exporting.md +++ b/sites/platform/src/tutorials/exporting.md @@ -3,7 +3,7 @@ title: "Exporting data" description: See how to export your code, files and service data. --- -As a Platform.sh user, your code and data belong to you. +As a {{< vendor/name >}} user, your code and data belong to you. At any time, you can download your site's data for local development, to back up your data, or to change provider. ## Before you begin @@ -11,9 +11,9 @@ At any time, you can download your site's data for local development, to back up You need: - [Git](https://git-scm.com/downloads) -- A Platform.sh account +- A {{< vendor/name >}} account - Code in your project -- Optional: the [Platform.sh CLI](../administration/cli/_index.md) +- Optional: the [{{< vendor/name >}} CLI](../administration/cli/_index.md) ## 1. Download your app's code @@ -86,7 +86,7 @@ Environment variables can have different prefixes: - Variables beginning with `env:` are exposed [as Unix environment variables](../development/variables/_index.md#top-level-environment-variables). - Variables beginning with `php:` are interpreted [as `php.ini` directives](../development/variables/_index.md#php-specific-variables). -All other variables are [part of `$PLATFORM_VARIABLES`](../development/variables/use-variables.md#use-platformsh-provided-variables). +All other variables are [part of `$PLATFORM_VARIABLES`](../development/variables/use-variables.md#use-provided-variables). To back up your environment variables: @@ -128,6 +128,6 @@ Use the CLI to retrieve these values. ## What's next -- Migrate data from elsewhere [into Platform.sh](./migrating.md). +- Migrate data from elsewhere [into {{< vendor/name >}}](./migrating.md). - Migrate to [another region](../projects/region-migration.md). - To use data from an environment locally, export your data and set up your [local development environment](../development/local/_index.md). diff --git a/sites/platform/src/tutorials/migrating.md b/sites/platform/src/tutorials/migrating.md index eabb27f2ba..ed8615f311 100644 --- a/sites/platform/src/tutorials/migrating.md +++ b/sites/platform/src/tutorials/migrating.md @@ -1,11 +1,11 @@ --- -title: Migrating to Platform.sh -description: See how to migrate your app to Platform.sh so it's ready to be deployed. +title: Migrating to {{< vendor/name >}} +description: See how to migrate your app to {{< vendor/name >}} so it's ready to be deployed. keywords: - "set remote" --- -If you already have an app running somewhere else, you want to migrate it to Platform.sh and deploy it. +If you already have an app running somewhere else, you want to migrate it to {{< vendor/name >}} and deploy it. To do so, follow these steps. ## Before you begin @@ -14,8 +14,8 @@ You need: - An app that works and is ready to be built - Code in Git -- A Platform.sh account -- if you don't already have one, [start a trial](https://auth.api.platform.sh/register?trial_type=general) -- Optional: the [Platform.sh CLI](../administration/cli/_index.md) +- A {{< vendor/name >}} account -- if you don't already have one, [start a trial](https://auth.api.platform.sh/register?trial_type=general) +- Optional: the [{{< vendor/name >}} CLI](../administration/cli/_index.md) ## 1. Export from previous system @@ -23,7 +23,7 @@ Start by exporting everything you might need from your current app. This includes data in databases, files on a file system, and for some apps, such as Drupal, configuration that you need to export from the system into files. -## 2. Create a Platform.sh project +## 2. Create a project {{< codetabs >}} +++ @@ -52,7 +52,7 @@ which you can then upgrade. {{< /codetabs >}} -## 3. Add Platform.sh configuration +## 3. Add configuration The exact configuration you want depends on your app. You likely want to configure three areas: @@ -68,9 +68,9 @@ When you've added your configuration, make sure to commit it to Git. ## 4. Push your code -The way to push your code to Platform.sh depends on +The way to push your code to {{< vendor/name >}} depends on whether you're hosting your code with a third-party service using a [source integration](../integrations/source/_index.md). -If you aren't, your repository is hosted in Platform.sh +If you aren't, your repository is hosted in {{< vendor/name >}} and you can use the CLI or just Git itself. {{< codetabs >}} @@ -84,13 +84,13 @@ title=Using the CLI platform projects ``` -2. Add Platform.sh as a remote repository by running the following command: +2. Add {{< vendor/name >}} as a remote repository by running the following command: ```bash platform project:set-remote {{< variable "PROJECT_ID" >}} ``` -3. Push to the Platform.sh repository by running the following command: +3. Push to the {{< vendor/name >}} repository by running the following command: ```bash git push -u platform {{< variable "DEFAULT_BRANCH_NAME" >}} @@ -131,13 +131,13 @@ title=Using Git abcdefgh1234567@git.eu.platform.sh:abcdefgh1234567.git ``` -5. Add Platform.sh as a remote repository by running the following command: +5. Add {{< vendor/name >}} as a remote repository by running the following command: ```bash git remote add platform {{< variable "REPOSITORY_LOCATION" >}} ``` -6. Push to the Platform.sh repository by running the following command: +6. Push to the {{< vendor/name >}} repository by running the following command: ```bash git push -u platform {{< variable "DEFAULT_BRANCH_NAME" >}} diff --git a/sites/platform/src/tutorials/restrict-service-access.md b/sites/platform/src/tutorials/restrict-service-access.md index c3cebf92c5..88e1b24308 100644 --- a/sites/platform/src/tutorials/restrict-service-access.md +++ b/sites/platform/src/tutorials/restrict-service-access.md @@ -5,7 +5,7 @@ description: Learn how to restrict access to a service using a worker and additi weight: 2 --- -Platform.sh allows you to restrict access to a service. +{{< vendor/name >}} allows you to restrict access to a service. In this tutorial, learn how to grant your Data team `read-only` access to your production database. diff --git a/sites/platform/src/tutorials/third-party.md b/sites/platform/src/tutorials/third-party.md index cff3aa186c..0c2cc9f906 100644 --- a/sites/platform/src/tutorials/third-party.md +++ b/sites/platform/src/tutorials/third-party.md @@ -1,8 +1,8 @@ --- -title: "Platform.sh Third-Party Resources" +title: "{{< vendor/name >}} Third-Party Resources" sidebarTitle: "Third-party resources" description: | - This is a Big List of known third party resources for Platform.sh. These resources aren't vetted by Platform.sh, but may be useful for people working with the platform. + This is a Big List of known third party resources for {{< vendor/name >}}. These resources aren't vetted by {{< vendor/name >}}, but may be useful for people working with the platform. --- {{% description %}} @@ -10,39 +10,39 @@ description: | ## Blogs -- "[The future of the PHP PaaS is here: Our journey to Platform.sh](https://platform.sh/2016/06/future-php-paas/)", by Marcus Hausammann -- An [introduction to Platform.sh](https://www.sitepoint.com/first-look-platform-sh-development-deployment-saas/) from Chris Ward +- "[The future of the PHP PaaS is here: Our journey to {{< vendor/name >}}](https://platform.sh/2016/06/future-php-paas/)", by Marcus Hausammann +- An [introduction to {{< vendor/name >}}](https://www.sitepoint.com/first-look-platform-sh-development-deployment-saas/) from Chris Ward ## Guides ### Getting started & workflow -- [Set up your Mac for Platform.sh using MAMP](https://github.com/owntheweb/platform-quick-starter) by [@owntheweb](https://github.com/owntheweb) -- How Platform.sh can [simplify your contribution workflow on GitHub](https://medium.com/akeneo-labs/how-platform-sh-can-simplify-your-contribution-workflow-on-github-6e2a557a1bcc) by Mickaël Andrieu from Akeneo -- All the stuff you need for a [pro-dev-flow using platform.sh](https://github.com/thinktandem/platform-workflow-demo) as your deploy target again by https://www.thinktandem.io +- [Set up your Mac for {{< vendor/name >}} using MAMP](https://github.com/owntheweb/platform-quick-starter) by [@owntheweb](https://github.com/owntheweb) +- How {{< vendor/name >}} can [simplify your contribution workflow on GitHub](https://medium.com/akeneo-labs/how-platform-sh-can-simplify-your-contribution-workflow-on-github-6e2a557a1bcc) by Mickaël Andrieu from Akeneo +- All the stuff you need for a [pro-dev-flow using {{< vendor/name >}}](https://github.com/thinktandem/platform-workflow-demo) as your deploy target again by https://www.thinktandem.io -### Working with Platform.sh +### Development - How to [connect to your MySQL database](https://www.thinktandem.io/blog/2017/03/03/connecting-to-a-remote-platform-sh-database) using Sequel Pro - How to [set up XDebug](https://ghosty.co.uk/2015/09/debugging-on-platform-sh/) -- Official [Sylius](https://docs.sylius.com/en/latest/cookbook/deployment/platform-sh.html) documentation on deploying to Platform.sh -- How to install [Apache Tika on Platform.sh](https://thinktandem.io/blog/2017/11/10/apache-tika-on-platform-sh/) +- Official [Sylius](https://docs.sylius.com/en/latest/cookbook/deployment/platform-sh.html) documentation on deploying to {{< vendor/name >}} +- How to install [Apache Tika on {{< vendor/name >}}](https://thinktandem.io/blog/2017/11/10/apache-tika-on-platform-sh/) - How to [store complete logs at AWS S3](https://gitlab.com/contextualcode/platformsh-store-logs-at-s3) by [Contextual Code](https://www.contextualcode.com/) -- [Automated SSL Certificates Export on Platform.sh](https://www.contextualcode.com/Blog/Automated-SSL-Certificates-Export-on-Platform.sh) by [Contextual Code](https://www.contextualcode.com/) -- A Platform.sh [region migration tool](https://gitlab.com/contextualcode/platformsh-migration) by [Contextual Code](https://www.contextualcode.com/) +- [Automated SSL Certificates Export on {{< vendor/name >}}](https://www.contextualcode.com/Blog/Automated-SSL-Certificates-Export-on-Platform.sh) by [Contextual Code](https://www.contextualcode.com/) +- A {{< vendor/name >}} [region migration tool](https://gitlab.com/contextualcode/platformsh-migration) by [Contextual Code](https://www.contextualcode.com/) ### Drupal -- [Modifying distribution make files for Platform.sh](https://www.nickvahalik.com/blog/modifying-distribution-makefiles-within-your-own-project-makefile-platformsh) -- Syslogging isn't supported on Platform.sh, instead, you can [Log using Monolog](https://gist.github.com/janstoeckler/7f251bf10fedbfb7f752b61ee5d2ef5e) to keep log files out of the database (and/or use whatever processors & handlers you want) +- [Modifying distribution make files for {{< vendor/name >}}](https://www.nickvahalik.com/blog/modifying-distribution-makefiles-within-your-own-project-makefile-platformsh) +- Syslogging isn't supported on {{< vendor/name >}}, instead, you can [Log using Monolog](https://gist.github.com/janstoeckler/7f251bf10fedbfb7f752b61ee5d2ef5e) to keep log files out of the database (and/or use whatever processors & handlers you want) ### Sylius -- The [Sylius documentation](https://docs.sylius.com/en/1.12/cookbook/deployment/platform-sh.html) has a solid set of instructions for setting up Sylius with Platform.sh. +- The [Sylius documentation](https://docs.sylius.com/en/1.12/cookbook/deployment/platform-sh.html) has a solid set of instructions for setting up Sylius with {{< vendor/name >}}. ## Examples -Platform.sh lists maintained examples on its Github page, with some cross-referencing from https://docs.platform.sh. Examples listed below could work fine, or may be out-of-date or unmaintained. Use at your own risk. +{{< vendor/name >}} lists maintained examples on its Github page, with some cross-referencing from https://docs.platform.sh. Examples listed below could work fine, or may be out-of-date or unmaintained. Use at your own risk. ### NodeJS @@ -88,27 +88,27 @@ Framework | Credit ## Integrations -- [Integrate GitLab with Platform.sh using Gitlab-CI](https://github.com/axelerant/pushtoplatformsh), by [@Axelerant](https://github.com/axelerant) -- [Running Behat tests from CircleCI to a Platform.sh environment](https://glamanate.com/blog/running-behat-tests-circleci-platformsh-environment), by [Matt Glaman](https://github.com/mglaman) -- Platform.sh's original (unsupported) scripts for **GitLab** https://gist.github.com/pjcdawkins/0b3f7a6da963c129030961f0947746c4. Platform.sh now supports Gitlab natively. -- An adapter from platform.sh webhook to **slack** incoming webhook that can be hosted on a platform.sh app https://github.com/hanoii/platformsh2slack +- [Integrate GitLab with {{< vendor/name >}} using Gitlab-CI](https://github.com/axelerant/pushtoplatformsh), by [@Axelerant](https://github.com/axelerant) +- [Running Behat tests from CircleCI to a {{< vendor/name >}} environment](https://glamanate.com/blog/running-behat-tests-circleci-platformsh-environment), by [Matt Glaman](https://github.com/mglaman) +- {{< vendor/name >}}'s original (unsupported) scripts for **GitLab** https://gist.github.com/pjcdawkins/0b3f7a6da963c129030961f0947746c4. {{< vendor/name >}} now supports Gitlab natively. +- An adapter from {{< vendor/name >}} webhook to **slack** incoming webhook that can be hosted on a {{< vendor/name >}} app https://github.com/hanoii/platformsh2slack - How to [call the NewRelic API on deploy](https://github.com/platformsh/platformsh-docs/pull/536#issuecomment-295578188) (by @christopher-hopper) -- A helper utility for running browser based tests on CircleCI against a Platform.sh environment. https://github.com/xendk/dais +- A helper utility for running browser based tests on CircleCI against a {{< vendor/name >}} environment. https://github.com/xendk/dais ## Tools & development - A small tool from Hanoii https://github.com/hanoii/drocal - Script to **sync a Drupal site** from Production to Local https://github.com/pjcdawkins/platformsh-sync -- Matt Pope's [Platform.sh automated mysql and files backup script](https://bitbucket.org/snippets/kaypro4/gnB4E) +- Matt Pope's [{{< vendor/name >}} automated mysql and files backup script](https://bitbucket.org/snippets/kaypro4/gnB4E) ### Development environments -- [**Beetbox**](https://beetbox.readthedocs.io/en/stable/), a pre-provisioned L*MP stack for Drupal and other frameworks, with Platform.sh CLI integration -- A **Docker** image with the Platform.sh CLI on it https://github.com/maxc0d3r/docker-platformshcli -- Some tips on using Platform.sh with **DrupalVM** https://github.com/geerlingguy/drupal-vm/issues/984 -- [**Vagrant with Ansible**](https://github.com/mglaman/platformsh-vagrant)for Platform.sh, opinionated towards Drupal, by @mglaman. +- [**Beetbox**](https://beetbox.readthedocs.io/en/stable/), a pre-provisioned L*MP stack for Drupal and other frameworks, with {{< vendor/name >}} CLI integration +- A **Docker** image with the {{< vendor/name >}} CLI on it https://github.com/maxc0d3r/docker-platformshcli +- Some tips on using {{< vendor/name >}} with **DrupalVM** https://github.com/geerlingguy/drupal-vm/issues/984 +- [**Vagrant with Ansible**](https://github.com/mglaman/platformsh-vagrant)for {{< vendor/name >}}, opinionated towards Drupal, by @mglaman. ### Ansible -- [Playbook for setting up Vagrant and VirtualBox](https://github.com/DurableDrupal/ansible-vm-platformsh) for use with a Platform.sh project -- PixelArt's [Platform.sh CLI role](https://galaxy.ansible.com/pixelart/platformsh-cli/) +- [Playbook for setting up Vagrant and VirtualBox](https://github.com/DurableDrupal/ansible-vm-platformsh) for use with a {{< vendor/name >}} project +- PixelArt's [{{< vendor/name >}} CLI role](https://galaxy.ansible.com/pixelart/platformsh-cli/) diff --git a/themes/psh-docs/layouts/_default/baseof.html b/themes/psh-docs/layouts/_default/baseof.html index 127bc23137..9566795373 100644 --- a/themes/psh-docs/layouts/_default/baseof.html +++ b/themes/psh-docs/layouts/_default/baseof.html @@ -3,7 +3,7 @@ {{ partial "head/head" . }} - {{ $currentPage := printf "https://docs.platform.sh%s" ( .Page.RelPermalink ) }} + {{ $currentPage := printf "%s%s" ( .Site.BaseURL ) ( .Page.RelPermalink ) }} diff --git a/themes/psh-docs/layouts/partials/feedback/form.html b/themes/psh-docs/layouts/partials/feedback/form.html index 1ec07974b2..015927b295 100644 --- a/themes/psh-docs/layouts/partials/feedback/form.html +++ b/themes/psh-docs/layouts/partials/feedback/form.html @@ -44,7 +44,7 @@

Is this page helpful?

"https://github.com/platformsh/platformsh-docs/issues/new?template=improvements.yml&where_on_docs_platform_sh_should_be_changed=" + currentUrl + "&title=%F0%9F%90%9B%20Issue%20on%20the%20page%20" + - document.title.replace(" · Platform.sh Documentation", ""), + document.title.replace({{ printf " · %s Documentation" .Site.Params.vendor.name }}, ""), handleClick(event) { const title = event.target.getAttribute("title"); diff --git a/themes/psh-docs/layouts/partials/header/actions.html b/themes/psh-docs/layouts/partials/header/actions.html index f9cc365f2e..6257986064 100644 --- a/themes/psh-docs/layouts/partials/header/actions.html +++ b/themes/psh-docs/layouts/partials/header/actions.html @@ -1,6 +1,6 @@ - + diff --git a/themes/psh-docs/layouts/shortcodes/databases-passwords.md b/themes/psh-docs/layouts/shortcodes/databases-passwords.md index e491dfce49..d440edd220 100644 --- a/themes/psh-docs/layouts/shortcodes/databases-passwords.md +++ b/themes/psh-docs/layouts/shortcodes/databases-passwords.md @@ -13,7 +13,7 @@ Note that you can't customize these automatically generated passwords. After your custom endpoints are exposed as relationships in your [app configuration](../../create-apps/_index.md), you can retrieve the password for each endpoint -through the `PLATFORM_RELATIONSHIPS` [environment variable](../../development/variables/use-variables.md#use-platformsh-provided-variables). +through the `PLATFORM_RELATIONSHIPS` [environment variable](../../development/variables/use-variables.md#use-provided-variables). You can access the `PLATFORM_RELATIONSHIPS` environment variable directly [in your app or through the configuration reader](../../development/variables/use-variables.md#access-variables-in-your-app). The password value changes automatically over time, to avoid downtime its value has to be read dynamically by your app. Globally speaking, having passwords hard-coded into your codebase can cause security issues and should be avoided. diff --git a/themes/psh-docs/layouts/shortcodes/ddev/connect.md b/themes/psh-docs/layouts/shortcodes/ddev/connect.md index c1d1e33242..3f3ad9cfff 100644 --- a/themes/psh-docs/layouts/shortcodes/ddev/connect.md +++ b/themes/psh-docs/layouts/shortcodes/ddev/connect.md @@ -1,4 +1,4 @@ -The best way to connect your local DDEV to your Platform.sh project is through the [Platform.sh DDEV add-on](https://github.com/ddev/ddev-platformsh). +The best way to connect your local DDEV to your {{ .Site.Params.vendor.name }} project is through the [{{ .Site.Params.vendor.name }} DDEV add-on](https://github.com/ddev/ddev-platformsh). To add it, run the following command: ```bash @@ -7,4 +7,4 @@ ddev get ddev/ddev-platformsh Answer the interactive prompts with your project ID and the name of the environment to pull data from. -With the add-on, you can now run `ddev platform ` from your computer without needing to install the Platform.sh CLI. +With the add-on, you can now run `ddev platform ` from your computer without needing to install the {{ .Site.Params.vendor.name }} CLI. diff --git a/themes/psh-docs/layouts/shortcodes/ddev/definition.md b/themes/psh-docs/layouts/shortcodes/ddev/definition.md index 88481cc5eb..c01e906c28 100644 --- a/themes/psh-docs/layouts/shortcodes/ddev/definition.md +++ b/themes/psh-docs/layouts/shortcodes/ddev/definition.md @@ -1,4 +1,4 @@ [DDEV](https://ddev.readthedocs.io/en/stable/) is an open-source tool for local development environments. It allows you to use Docker in your workflows while maintaining a GitOps workflow. You get fully containerized environments to run everything locally -without having to install tools (including the Platform.sh CLI, PHP, and Composer) on your machine. \ No newline at end of file +without having to install tools (including the {{ .Site.Params.vendor.name }} CLI, PHP, and Composer) on your machine. \ No newline at end of file diff --git a/themes/psh-docs/layouts/shortcodes/ddev/token.md b/themes/psh-docs/layouts/shortcodes/ddev/token.md index 6559045d0e..d0fd668d1e 100644 --- a/themes/psh-docs/layouts/shortcodes/ddev/token.md +++ b/themes/psh-docs/layouts/shortcodes/ddev/token.md @@ -1,6 +1,6 @@ -To connect DDEV with your Platform.sh account, use a Platform.sh API token. +To connect DDEV with your {{ .Site.Params.vendor.name }} account, use a {{ .Site.Params.vendor.name }} API token. -First [create an API token](/administration/cli/api-tokens.md#2-create-a-platformsh-api-token) in the Console. +First [create an API token](/administration/cli/api-tokens.md#2-create-an-api-token) in the Console. Then add the token to your DDEV configuration. You can do so globally (easiest for most people): diff --git a/themes/psh-docs/layouts/shortcodes/get-started/connect-service.md b/themes/psh-docs/layouts/shortcodes/get-started/connect-service.md index 2ad4056c3a..fafa93bbd3 100644 --- a/themes/psh-docs/layouts/shortcodes/get-started/connect-service.md +++ b/themes/psh-docs/layouts/shortcodes/get-started/connect-service.md @@ -4,7 +4,7 @@ Now connect the database to your app.
-First, add the Platform.sh Config Reader library to make the connection easier. +First, add the {{ .Site.Params.vendor.name }} Config Reader library to make the connection easier.
diff --git a/themes/psh-docs/layouts/shortcodes/get-started/service-needed.md b/themes/psh-docs/layouts/shortcodes/get-started/service-needed.md index 07fca96573..b232a42380 100644 --- a/themes/psh-docs/layouts/shortcodes/get-started/service-needed.md +++ b/themes/psh-docs/layouts/shortcodes/get-started/service-needed.md @@ -11,4 +11,4 @@ Your app is built and served at the returned URL, but it doesn't yet have all th You could [define more complicated routes](/define-routes.html), but the default is enough for basic apps. -Now branch your environment to see how data works in Platform.sh and then add services. +Now branch your environment to see how data works in {{ .Site.Params.vendor.name }} and then add services. diff --git a/themes/psh-docs/layouts/shortcodes/guides/config-desc.md b/themes/psh-docs/layouts/shortcodes/guides/config-desc.md index 28d55f2122..f2b52db136 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/config-desc.md +++ b/themes/psh-docs/layouts/shortcodes/guides/config-desc.md @@ -1,5 +1,5 @@ {{ $name := .Get "name" }} -You now have a *project* running on Platform.sh. +You now have a *project* running on {{ .Site.Params.vendor.name }} . In many ways, a project is just a collection of tools around a Git repository. Just like a Git repository, a project has branches, called *environments*. Each environment can then be activated. @@ -24,7 +24,7 @@ You can configure these containers in three ways, each corresponding to a [YAML Start by creating empty versions of each of these files in your repository: ```bash -# Create empty Platform.sh configuration files +# Create empty {{ .Site.Params.vendor.name }} configuration files touch .platform.app.yaml && mkdir -p .platform && touch .platform/routes.yaml{{ if not (.Get "noService") }} && touch .platform/services.yaml{{ end }} ``` @@ -47,7 +47,7 @@ dependencies. ```bash symfony project:init -git add . && git commit -m "Add Platform.sh configuration files" +git add . && git commit -m "Add {{ .Site.Params.vendor.name }} configuration files" ``` {{ end }} diff --git a/themes/psh-docs/layouts/shortcodes/guides/data-migration.md b/themes/psh-docs/layouts/shortcodes/guides/data-migration.md index a68fd8de1c..d0b77bdb3c 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/data-migration.md +++ b/themes/psh-docs/layouts/shortcodes/guides/data-migration.md @@ -2,7 +2,7 @@ {{ $isSymfony := .Get "Symfony" }} ## Migrate your data -If you are moving an existing site to Platform.sh, then in addition to code you also need to migrate your data. +If you are moving an existing site to {{ .Site.Params.vendor.name }}, then in addition to code you also need to migrate your data. That means your database and your files. ### Import the database @@ -15,7 +15,7 @@ such as using the {{ .Inner | .Page.RenderString }} -Next, import the database into your Platform.sh site by running the following command: +Next, import the database into your {{ .Site.Params.vendor.name }} site by running the following command: {{ if $isSymfony }} ```bash @@ -60,7 +60,7 @@ platform mount:upload --mount src/main/resources/files/public --source ./files/p This uses an SSH tunnel and rsync to upload your files as efficiently as possible. Note that rsync is picky about its trailing slashes, so be sure to include those. -You've now added your files and database to your Platform.sh environment. +You've now added your files and database to your {{ .Site.Params.vendor.name }} environment. When you make a new branch environment off of it, all of your data is fully cloned to that new environment so you can test with your complete dataset without impacting production. diff --git a/themes/psh-docs/layouts/shortcodes/guides/deployment.md b/themes/psh-docs/layouts/shortcodes/guides/deployment.md index 2b4626bdba..acda1b4071 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/deployment.md +++ b/themes/psh-docs/layouts/shortcodes/guides/deployment.md @@ -3,9 +3,9 @@ {{ if $isSymfony }} {{ $cliCommand = "symfony cloud:" }} {{ end }} -Now you have your configuration for deployment and your app set up to run on Platform.sh. +Now you have your configuration for deployment and your app set up to run on {{ .Site.Params.vendor.name }}. Make sure all your code is committed to Git -and run `{{ if $isSymfony }}symfony cloud:deploy{{ else }}git push{{ end }}` to your Platform.sh environment. +and run `{{ if $isSymfony }}symfony cloud:deploy{{ else }}git push{{ end }}` to your {{ .Site.Params.vendor.name }} environment. Your code is built, producing a read-only image that's deployed to a running cluster of containers. If you aren't using a source integration, the log of the process is returned in your terminal. diff --git a/themes/psh-docs/layouts/shortcodes/guides/django/local-assumptions.md b/themes/psh-docs/layouts/shortcodes/guides/django/local-assumptions.md index 06a0afc177..1a4525246e 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/django/local-assumptions.md +++ b/themes/psh-docs/layouts/shortcodes/guides/django/local-assumptions.md @@ -6,6 +6,6 @@ It's assumed you want to run a built-in lightweight development server with `man To match a production web server (such as Gunicorn or Daphne), [modify those commands accordingly](../../../languages/python/server.md). -It's generally assumed that Platform.sh is the primary remote for the project. +It's generally assumed that {{ .Site.Params.vendor.name }} is the primary remote for the project. If you use a source integration, the steps are identical in most cases. When they differ, the alternative is noted. diff --git a/themes/psh-docs/layouts/shortcodes/guides/django/local-sanitize-example.md b/themes/psh-docs/layouts/shortcodes/guides/django/local-sanitize-example.md index 5efa851c24..0e3f964373 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/django/local-sanitize-example.md +++ b/themes/psh-docs/layouts/shortcodes/guides/django/local-sanitize-example.md @@ -19,5 +19,5 @@ You can customize your deployments to include a script that sanitizes the data w 4. Merge the change into production. - Once the script is merged into production, every non-production environment created on Platform.sh + Once the script is merged into production, every non-production environment created on {{ .Site.Params.vendor.name }} and all local environments contain sanitized data free of your users' personally identifiable information (PII). diff --git a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-backend.md b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-backend.md index 04b72e719c..67904b1346 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-backend.md +++ b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-backend.md @@ -3,7 +3,7 @@ {{ if eq $name "Drupal" }} {{ $template = "Drupal9"}} {{ end }} -The multi-app template has a single modification to Platform.sh's [standard {{ $name }} template](https://github.com/platformsh-templates/{{ anchorize ( $template ) }}): +The multi-app template has a single modification to {{ .Site.Params.vendor.name }}'s [standard {{ $name }} template](https://github.com/platformsh-templates/{{ anchorize ( $template ) }}): the `name` attribute in {{ $name }}'s `.platform.app.yaml` has been updated to `{{ anchorize ( $name )}}`. This value is used to define the [relationship between Gatsby and {{ $name }}](#gatsby) and in the [routes configuration](#platformroutesyaml). diff --git a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-gatsby.md b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-gatsby.md index 158e24fca0..372f7da019 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-gatsby.md +++ b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-gatsby.md @@ -13,7 +13,7 @@ In particular, notice: - `post_deploy` - Platform.sh containers reside in separate build containers at build time, + {{ .Site.Params.vendor.name }} containers reside in separate build containers at build time, before their images are moved to the final app container at deploy time. These build containers are isolated and so Gatsby can't access {{ .Get "name" }} during the build hook, where you would normally run the [`gatsby build` command](https://github.com/platformsh-templates/gatsby/blob/master/.platform.app.yaml#L21). @@ -31,7 +31,7 @@ In particular, notice: {{ .Inner | .Page.RenderString }} -This is facilitated by Platform.sh's [Config Reader library](https://github.com/platformsh/config-reader-nodejs). +This is facilitated by {{ .Site.Params.vendor.name }}'s [Config Reader library](https://github.com/platformsh/config-reader-nodejs). So be sure to install this to the Gatsby dependencies first when replicating. When used, Gatsby pulls the information to communicate with the {{ .Get "name" }} container *on the current branch*. diff --git a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-intro.html b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-intro.html index 8eaa451e39..bfd8bf1107 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-intro.html +++ b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-intro.html @@ -1,7 +1,7 @@ -

Platform.sh maintains a template that you can quickly deploy, and then use this guide as a reference for the Platform.sh specific changes that have been made to Gatsby and {{ .Get "name" }} to make it work. Click the button below to sign up for a free trial account and deploy the project.

+

{{ .Site.Params.vendor.name }} maintains a template that you can quickly deploy, and then use this guide as a reference for the {{ .Site.Params.vendor.name }} specific changes that have been made to Gatsby and {{ .Get "name" }} to make it work. Click the button below to sign up for a free trial account and deploy the project.

- Deploy on Platform.sh + Deploy on {{ .Site.Params.vendor.name }}

diff --git a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-routes.md b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-routes.md index 038e3706ae..db8dcd21f8 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-routes.md +++ b/themes/psh-docs/layouts/shortcodes/guides/gatsby/headless-routes.md @@ -1,4 +1,4 @@ -This [`routes.yaml`](/define-routes.html) file defines how requests are handled by Platform.sh. +This [`routes.yaml`](/define-routes.html) file defines how requests are handled by {{ .Site.Params.vendor.name }}. The following example shows Gatsby being served from the primary domain and {{ .Get "name" }} being accessible from the `backend` subdomain. diff --git a/themes/psh-docs/layouts/shortcodes/guides/initialize.html b/themes/psh-docs/layouts/shortcodes/guides/initialize.html index abab02a878..6fedf19513 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/initialize.html +++ b/themes/psh-docs/layouts/shortcodes/guides/initialize.html @@ -3,7 +3,7 @@ {{ if $isSymfony }} {{ $cliCommand = "symfony" }} {{ end }} -

You can start with a basic code base or push a pre-existing project to Platform.sh.

+

You can start with a basic code base or push a pre-existing project to {{ .Site.Params.vendor.name }}.

  1. @@ -25,12 +25,12 @@

    If your code isn't in a Git repository, initialize it by running git init.

    {{ .Inner | .Page.RenderString }}
  2. -

    Connect your Platform.sh project with Git. - You can use Platform.sh as your Git repository or connect to a third-party provider: +

    Connect your {{ .Site.Params.vendor.name }} project with Git. + You can use {{ .Site.Params.vendor.name }} as your Git repository or connect to a third-party provider: GitHub, GitLab, or BitBucket.

    -{{ $titleName := "Platform.sh" }} +{{ $titleName := .Site.Params.vendor.name }} {{ if $isSymfony }} {{ $titleName = "the Symfony CLI" }} {{ end }} @@ -39,7 +39,7 @@ title=Using ` $titleName ` +++ -Add a Git remote for the Platform.sh project you just created +Add a Git remote for the {{ .Site.Params.vendor.name }} project you just created by running the following command from your repository: 
    ` $cliCommand ` project:set-remote {{< variable "PROJECT_ID" >}}
    @@ -52,7 +52,7 @@ +++ When you choose to use a third-party Git hosting service -the Platform.sh Git repository becomes a read-only mirror of the third-party repository. +the {{ .Site.Params.vendor.name }} Git repository becomes a read-only mirror of the third-party repository. All your changes take place in the third-party repository. Add an integration to your existing third party repository. @@ -65,11 +65,11 @@ Accept the default options or modify to fit your needs. -All of your existing branches are automatically synchronized to Platform.sh. +All of your existing branches are automatically synchronized to {{ .Site.Params.vendor.name }}. You get a deploy failure message because you haven't provided configuration files yet. You add them in the next step. -If you're integrating a repository to Platform.sh that contains a number of open pull requests, +If you're integrating a repository to {{ .Site.Params.vendor.name }} that contains a number of open pull requests, don't use the default integration options. Projects are limited to three\* development environments (active and deployed branches or pull requests) and you would need to deactivate them individually to test this guide's migration changes. @@ -88,4 +88,4 @@
-

Now you have a local Git repository, a Platform.sh project, and a way to push code to that project. Next you can configure your project to work with Platform.sh.

+

Now you have a local Git repository, a {{ .Site.Params.vendor.name }} project, and a way to push code to that project. Next you can configure your project to work with {{ .Site.Params.vendor.name }}.

diff --git a/themes/psh-docs/layouts/shortcodes/guides/lando.md b/themes/psh-docs/layouts/shortcodes/guides/lando.md index 7c817f6698..0ee6846727 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/lando.md +++ b/themes/psh-docs/layouts/shortcodes/guides/lando.md @@ -1,22 +1,22 @@ [Lando](https://github.com/lando/lando) is a local development tool. -Lando can read your Platform.sh configuration files for WordPress +Lando can read your {{ .Site.Params.vendor.name }} configuration files for WordPress and produce an approximately equivalent configuration using Docker -See a guide on [using Lando with Platform.sh](/development/local/lando.html). +See a guide on [using Lando with {{ .Site.Params.vendor.name }}](/development/local/lando.html). Templates come configured for use already with a base [Landofile](https://docs.lando.dev/config/lando.html), as in the following example. -It can be helpful getting started with Lando without the need to have a project on Platform.sh. -This file sets up good defaults for Lando and Platform.sh-configured codebases, +It can be helpful getting started with Lando without the need to have a project on {{ .Site.Params.vendor.name }}. +This file sets up good defaults for Lando and {{ .Site.Params.vendor.name }}-configured codebases, most notably through the `recipe` attribute. {{ $file := printf "static/files/fetch/lando/%s" (.Get "repo" ) }} {{ highlight ( readFile $file ) "yaml" ""}} This Landofile is also where you can configure access to tools -that would normally be available within a Platform.sh app container (such as the WordPress CLI) +that would normally be available within a {{ .Site.Params.vendor.name }} app container (such as the WordPress CLI) and that you also want to access locally. -You can replicate this file or follow the guide on [using Lando with Platform.sh](/development/local/lando.html). +You can replicate this file or follow the guide on [using Lando with {{ .Site.Params.vendor.name }}](/development/local/lando.html). Once you have completed the configuration, you can start your local environment by running: ```bash diff --git a/themes/psh-docs/layouts/shortcodes/guides/link-philosophy.md b/themes/psh-docs/layouts/shortcodes/guides/link-philosophy.md index 2cf7d70efb..124422573c 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/link-philosophy.md +++ b/themes/psh-docs/layouts/shortcodes/guides/link-philosophy.md @@ -1,2 +1,2 @@ -If you're new to Platform.sh, you might want to check out the [philosophy of Platform.sh](overview/philosophy.md) +If you're new to {{ .Site.Params.vendor.name }}, you might want to check out the [philosophy of {{ .Site.Params.vendor.name }}](overview/philosophy.md) to get started on the best possible footing. \ No newline at end of file diff --git a/themes/psh-docs/layouts/shortcodes/guides/local-requirements.md b/themes/psh-docs/layouts/shortcodes/guides/local-requirements.md index 042a99b33f..08c1e2bfff 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/local-requirements.md +++ b/themes/psh-docs/layouts/shortcodes/guides/local-requirements.md @@ -3,7 +3,7 @@ You need: -- A local copy of the repository for a {{ with .Get "framework" }}[{{ . }}](../deploy/_index.md) {{ end }} project running on Platform.sh. +- A local copy of the repository for a {{ with .Get "framework" }}[{{ . }}](../deploy/_index.md) {{ end }} project running on {{ .Site.Params.vendor.name }}. {{ if not $isSymfony }} To get one, run platform get {{ `{{< variable "PROJECT_ID" >}}` | .Page.RenderString }}. @@ -11,4 +11,4 @@ You need: {{ if not $isSymfony }}Alternatively, you can clone{{ else }}You can clone{{ end }} an integrated source repository and set the remote branch. To do so, run {{ if $isSymfony }}symfony cloud:{{ else }}platform {{ end }}project:set-remote {{ `{{< variable "PROJECT_ID" >}}` | .Page.RenderString }}. -- The {{ if $isSymfony }}[Symfony CLI](https://symfony.com/download){{ else }}[Platform.sh CLI](/administration/cli/_index.md){{ end }} +- The {{ if $isSymfony }}[Symfony CLI](https://symfony.com/download){{ else }}[{{ .Site.Params.vendor.name }} CLI](/administration/cli/_index.md){{ end }} diff --git a/themes/psh-docs/layouts/shortcodes/guides/requirements.md b/themes/psh-docs/layouts/shortcodes/guides/requirements.md index 0dc3b3088c..11f72af049 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/requirements.md +++ b/themes/psh-docs/layouts/shortcodes/guides/requirements.md @@ -7,11 +7,11 @@ You need: Git is the primary tool to manage everything your app needs to run. Push commits to deploy changes and control configuration through YAML files. These files describe your infrastructure, making it transparent and version-controlled. -- A Platform.sh account. +- A {{ .Site.Params.vendor.name }} account. If you don't already have one, [register for a trial account](https://auth.api.platform.sh/register). You can sign up with an email address or an existing GitHub, Bitbucket, or Google account. - If you choose one of these accounts, you can set a password for your Platform.sh account later. -- {{ if $isSymfony }}The [Symfony CLI](https://symfony.com/download){{ else }}Optional: the [Platform.sh CLI](/administration/cli/_index.md){{ end }}. + If you choose one of these accounts, you can set a password for your {{ .Site.Params.vendor.name }} account later. +- {{ if $isSymfony }}The [Symfony CLI](https://symfony.com/download){{ else }}Optional: the [{{ .Site.Params.vendor.name }} CLI](/administration/cli/_index.md){{ end }}. This lets you interact with your project from the command line. You can also do most things through the [Web Console](/administration/web/_index.md), but this guide focuses on using the CLI. diff --git a/themes/psh-docs/layouts/shortcodes/guides/starting-point.md b/themes/psh-docs/layouts/shortcodes/guides/starting-point.md index bdeb9836b3..9cdfa1e59a 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/starting-point.md +++ b/themes/psh-docs/layouts/shortcodes/guides/starting-point.md @@ -16,10 +16,10 @@ {{ $templateUrl = print `https://raw.githubusercontent.com/symfonycorp/platformsh-symfony-template-metadata/main/` ( .Get "template" ) `.yaml` }} {{ end }} -To get {{ $name }} running on Platform.sh, you have two potential starting places: +To get {{ $name }} running on {{ .Site.Params.vendor.name }}, you have two potential starting places: - You already have a {{ $site }} site you are trying to deploy. - Go through this guide to make the recommended changes to your repository to prepare it for Platform.sh. + Go through this guide to make the recommended changes to your repository to prepare it for {{ .Site.Params.vendor.name }}. - You have no code at this point. @@ -35,7 +35,7 @@ To get {{ $name }} running on Platform.sh, you have two potential starting place

- Deploy on Platform.sh + Deploy on {{ .Site.Params.vendor.name }}

diff --git a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-assumptions.md b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-assumptions.md index a2b33fd103..2c824666c7 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-assumptions.md +++ b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-assumptions.md @@ -5,7 +5,7 @@ This example makes a few assumptions, which you may need to adjust for your own circumstances. -It assumes that you've already [deployed a Symfony project on Platform.sh](../getting-started/_index.md) +It assumes that you've already [deployed a Symfony project on {{ .Site.Params.vendor.name }}](../getting-started/_index.md) that has production data in a [PostgreSQL database]({{ $postgresqlGuide }}) and use [Redis component]({{ $redisGuide }}). It's assumed that your project has the following service definitions: @@ -30,5 +30,5 @@ relationships: rediscache: "cache:redis" ``` -Finally, this example mostly assumes that a Platform.sh is the primary remote for the project. +Finally, this example mostly assumes that a {{ .Site.Params.vendor.name }} is the primary remote for the project. When using source integrations, the steps will be identical in most cases and addressed otherwise. diff --git a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-end.md b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-end.md index 990fba8581..e03dfaf900 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-end.md +++ b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-end.md @@ -64,5 +64,5 @@ You can customize your deployments to include a script that sanitizes the data w symfony merge sanitize-non-prod ``` -Once the script is merged into production, every non-production environment created on Platform.sh +Once the script is merged into production, every non-production environment created on {{ .Site.Params.vendor.name }} and all local environments contain sanitized data free of your users' personally identifiable information (PII). diff --git a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-start.md b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-start.md index 58bf4bf47e..af3d5edc0f 100644 --- a/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-start.md +++ b/themes/psh-docs/layouts/shortcodes/guides/symfony/local-next-steps-start.md @@ -4,7 +4,7 @@ {{ end }} ## Next steps -You can now use your local environment to develop changes for review on Platform.sh environments. +You can now use your local environment to develop changes for review on {{ .Site.Params.vendor.name }} environments. The following examples show how you can take advantage of that. ### Onboard collaborators @@ -18,7 +18,7 @@ You can merge this change into production. symfony branch local-config ``` -2. Create an executable script to set up a local environment for a new Platform.sh environment. +2. Create an executable script to set up a local environment for a new {{ .Site.Params.vendor.name }} environment. ```bash touch init-local.sh && chmod +x init-local.sh diff --git a/themes/psh-docs/layouts/shortcodes/local-dev/lando-plugin-note.md b/themes/psh-docs/layouts/shortcodes/local-dev/lando-plugin-note.md index e0dbaaf7f5..23a811a1b0 100644 --- a/themes/psh-docs/layouts/shortcodes/local-dev/lando-plugin-note.md +++ b/themes/psh-docs/layouts/shortcodes/local-dev/lando-plugin-note.md @@ -1,7 +1,7 @@ -Lando used to support Platform.sh PHP projects out of the box through a plugin. +Lando used to support {{ .Site.Params.vendor.name }} PHP projects out of the box through a plugin. However, this plugin is now deprecated. It's still available, but it's no longer receiving updates and isn't guaranteed to work. -For a seamless experience, switch to [DDEV](./ddev.md), which is the recommended tool for local development with Platform.sh. -The integration with DDEV is maintained by Platform.sh to ensure it works smoothly. -Note that a Platform.sh migration guide from Lando to DDEV will be released soon. \ No newline at end of file +For a seamless experience, switch to [DDEV](./ddev.md), which is the recommended tool for local development with {{ .Site.Params.vendor.name }}. +The integration with DDEV is maintained by {{ .Site.Params.vendor.name }} to ensure it works smoothly. +Note that a {{ .Site.Params.vendor.name }} migration guide from Lando to DDEV will be released soon. \ No newline at end of file diff --git a/themes/psh-docs/layouts/shortcodes/local-dev/next-steps-start.md b/themes/psh-docs/layouts/shortcodes/local-dev/next-steps-start.md index 2b59a03f67..3b4e760e20 100644 --- a/themes/psh-docs/layouts/shortcodes/local-dev/next-steps-start.md +++ b/themes/psh-docs/layouts/shortcodes/local-dev/next-steps-start.md @@ -4,7 +4,7 @@ {{ end }} ## Next steps -You can now use your local environment to develop changes for review on Platform.sh environments. +You can now use your local environment to develop changes for review on {{ .Site.Params.vendor.name }} environments. The following examples show how you can take advantage of that. ### Onboard collaborators @@ -15,7 +15,7 @@ You can merge this change into production. 1. Create a new environment called `local-config`. -1. To set up a local environment for a new Platform.sh environment, create an executable script. +1. To set up a local environment for a new {{ .Site.Params.vendor.name }} environment, create an executable script. ```bash touch init-local.sh && chmod +x init-local.sh diff --git a/themes/psh-docs/layouts/shortcodes/onboarding-table.html b/themes/psh-docs/layouts/shortcodes/onboarding-table.html index c7bace1d94..2e0a4d22e4 100644 --- a/themes/psh-docs/layouts/shortcodes/onboarding-table.html +++ b/themes/psh-docs/layouts/shortcodes/onboarding-table.html @@ -37,7 +37,7 @@

The customer has access to all the resources necessary to develop, migrate, and test the project on the - Platform.sh infrastructure - development, staging, and production. If necessary, developers may request an + {{ .Site.Params.vendor.name }} infrastructure - development, staging, and production. If necessary, developers may request an additional training session (held by the Solutions Engineer) to discuss the development workflow and best practices in detail.

Once the application is live on your staging environment, a staging CDN distribution will be created so that diff --git a/themes/psh-docs/layouts/shortcodes/premium-features/add-on.html b/themes/psh-docs/layouts/shortcodes/premium-features/add-on.html index 3348025714..d1b6120896 100644 --- a/themes/psh-docs/layouts/shortcodes/premium-features/add-on.html +++ b/themes/psh-docs/layouts/shortcodes/premium-features/add-on.html @@ -1,5 +1,5 @@ {{ $feature := .Get "feature" }} -{{ $content := print $feature ` isn't included in any Platform.sh plan. +{{ $content := print $feature ` isn't included in any {{ .Site.Params.vendor.name }} plan. You need to add it separately at an additional cost. To add ` $feature `, [contact Sales](https://platform.sh/contact/).`}} diff --git a/themes/psh-docs/layouts/shortcodes/python-sockets.md b/themes/psh-docs/layouts/shortcodes/python-sockets.md index 6307b4c3da..af6e20bf55 100644 --- a/themes/psh-docs/layouts/shortcodes/python-sockets.md +++ b/themes/psh-docs/layouts/shortcodes/python-sockets.md @@ -1,5 +1,5 @@ {{ $server := .Get "server" }} -To deploy with {{ $server }} on Platform.sh, +To deploy with {{ $server }} on {{ .Site.Params.vendor.name }} , use one of the following examples to update your [app configuration](../../create-apps/_index.md). The examples vary based on both your package manager (Pip, Pipenv, or Poetry) diff --git a/themes/psh-docs/layouts/shortcodes/relationship-ref-intro.md b/themes/psh-docs/layouts/shortcodes/relationship-ref-intro.md index 548ffcc5f4..9b93946f66 100644 --- a/themes/psh-docs/layouts/shortcodes/relationship-ref-intro.md +++ b/themes/psh-docs/layouts/shortcodes/relationship-ref-intro.md @@ -1,4 +1,4 @@ ## Relationship reference -Example information available through the [`PLATFORM_RELATIONSHIPS` environment variable](/development/variables/use-variables.md#use-platformsh-provided-variables) +Example information available through the [`PLATFORM_RELATIONSHIPS` environment variable](/development/variables/use-variables.md#use-provided-variables) or by running `platform relationships`. diff --git a/themes/psh-docs/layouts/shortcodes/repolist.html b/themes/psh-docs/layouts/shortcodes/repolist.html index a458f26826..55c02e56ce 100644 --- a/themes/psh-docs/layouts/shortcodes/repolist.html +++ b/themes/psh-docs/layouts/shortcodes/repolist.html @@ -51,7 +51,7 @@

Features:

View the repository on GitHub.

diff --git a/themes/psh-docs/layouts/shortcodes/source-integration/enable-integration.html b/themes/psh-docs/layouts/shortcodes/source-integration/enable-integration.html index e3ac935087..4a2f94b048 100644 --- a/themes/psh-docs/layouts/shortcodes/source-integration/enable-integration.html +++ b/themes/psh-docs/layouts/shortcodes/source-integration/enable-integration.html @@ -109,7 +109,7 @@ {{ end }} {{ $CLIc := print ` -- PLATFORM_SH_PROJECT_ID is the ID of your Platform.sh project. +- PLATFORM_SH_PROJECT_ID is the ID of your {{ .Site.Params.vendor.name }} project. - OWNER/REPOSITORY is the name of the repository in ` $source `. ` $accessFlagsExplanation ` ` $baseUrlExpanation ` @@ -185,7 +185,7 @@ | CLI flag | Default | Description | | -------- | ------- | ----------- | | fetch-branches | true | Whether to track all branches and create inactive environments from them. | -| prune-branches | true | Whether to delete branches from Platform.sh that don't exist in the ` $source ` repository. Automatically disabled when fetching branches is disabled. | +| prune-branches | true | Whether to delete branches from {{ .Site.Params.vendor.name }} that don't exist in the ` $source ` repository. Automatically disabled when fetching branches is disabled. | | build-` $pull `-requests | true | Whether to track all ` $pull ` requests and create active environments from them, which builds the ` $pull ` request. | ` $draftOption ` ` $cloneOption $extraOption }} {{ $OptionsTable | markdownify }} diff --git a/themes/psh-docs/layouts/shortcodes/source-integration/environment-status.md b/themes/psh-docs/layouts/shortcodes/source-integration/environment-status.md index af1183c73e..4790a5ee92 100644 --- a/themes/psh-docs/layouts/shortcodes/source-integration/environment-status.md +++ b/themes/psh-docs/layouts/shortcodes/source-integration/environment-status.md @@ -6,9 +6,9 @@ ## Environment parent and status When a **branch** is created in {{ $source }}, -an environment is created in Platform.sh with the default branch as its parent. +an environment is created in {{ .Site.Params.vendor.name }} with the default branch as its parent. It starts as an [inactive environment](/other/glossary.html#inactive-environment) with no data or services. When a **{{ $pull }} request** is opened in {{ $source }}, -an environment is created in Platform.sh with the {{ $pull }} request's target branch as its parent. +an environment is created in {{ .Site.Params.vendor.name }} with the {{ $pull }} request's target branch as its parent. It starts as an [active environment](/other/glossary.html#active-environment) with a copy of its parent's data. diff --git a/themes/psh-docs/layouts/shortcodes/source-integration/intro.md b/themes/psh-docs/layouts/shortcodes/source-integration/intro.md index 3c659a5b75..605a07e351 100644 --- a/themes/psh-docs/layouts/shortcodes/source-integration/intro.md +++ b/themes/psh-docs/layouts/shortcodes/source-integration/intro.md @@ -3,12 +3,12 @@ {{ if eq $source "GitLab" }} {{ $pull = "merge" }} {{ end }} -If you have code in a {{ $source }} repository, you might want to connect it to a Platform.sh project. +If you have code in a {{ $source }} repository, you might want to connect it to a {{ .Site.Params.vendor.name }} project. This means you can keep your {{ $source }} workflows and treat the {{ $source }} repository as the source of truth for your code. -Your Platform.sh project becomes a mirror of your {{ $source }} repository. -This means you shouldn't push code directly to Platform.sh. +Your {{ .Site.Params.vendor.name }} project becomes a mirror of your {{ $source }} repository. +This means you shouldn't push code directly to {{ .Site.Params.vendor.name }}. Any changes you push directly get overwritten by the integration when changes happen in the {{ $source }} repository. When you set up an integration with {{ $source }}, diff --git a/themes/psh-docs/layouts/shortcodes/source-integration/source-of-truth.html b/themes/psh-docs/layouts/shortcodes/source-integration/source-of-truth.html index 69511bbf9d..ea4d215fc8 100644 --- a/themes/psh-docs/layouts/shortcodes/source-integration/source-of-truth.html +++ b/themes/psh-docs/layouts/shortcodes/source-integration/source-of-truth.html @@ -1,7 +1,7 @@ {{ $source := .Get "source" }}

When you add an integration, your {{ $source }} repository is considered to be the source of truth for the project. -Your Platform.sh project is only a mirror of that repository and you should only push commits to {{ $source }}. -Any changes you push to Platform.sh get overwritten by the integration when changes happen in your {{ $source }} repository.

+Your {{ .Site.Params.vendor.name }} project is only a mirror of that repository and you should only push commits to {{ $source }}. +Any changes you push to {{ .Site.Params.vendor.name }} get overwritten by the integration when changes happen in your {{ $source }} repository.

To clone your code, follow these steps:

diff --git a/themes/psh-docs/layouts/shortcodes/source-integration/validate.md b/themes/psh-docs/layouts/shortcodes/source-integration/validate.md index ede19791aa..4e767bded6 100644 --- a/themes/psh-docs/layouts/shortcodes/source-integration/validate.md +++ b/themes/psh-docs/layouts/shortcodes/source-integration/validate.md @@ -34,4 +34,4 @@ you need to have {{ $reqdPerms }} [user permissions]({{ $permsLink }}). You can now start pushing code, creating new branches, and opening {{ if eq $source "GitLab" }}merge{{ else }}pull{{ end }} requests directly in your {{ $source }} repository. -Your Platform.sh environments are automatically created and updated. +Your {{ .Site.Params.vendor.name }} environments are automatically created and updated. diff --git a/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli-database.md b/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli-database.md index 93cbf8a9f9..963c0bf828 100644 --- a/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli-database.md +++ b/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli-database.md @@ -1,5 +1,5 @@ {{ $cliCommand := "platform " }} -{{ $cliName := "Platform.sh CLI" }} +{{ $cliName := ".Site.Params.vendor.name CLI" }} {{ if eq ( .Get "framework" ) "Symfony" }} {{ $cliCommand = "symfony cloud:" }} {{ $cliName = "Symfony CLI" }} diff --git a/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli.md b/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli.md index 24b96b6922..86469743c2 100644 --- a/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli.md +++ b/themes/psh-docs/layouts/shortcodes/tips-and-tricks/cli.md @@ -1,5 +1,5 @@ {{ $cliCommand := "platform " }} -{{ $cliName := "Platform.sh CLI" }} +{{ $cliName := ".Site.Params.vendor.name CLI" }} {{ if eq ( .Get "framework" ) "Symfony" }} {{ $cliCommand = "symfony cloud:" }} {{ $cliName = "Symfony CLI" }} diff --git a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2020/abuse.html b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2020/abuse.html index ddad6d3058..3bec51d16f 100644 --- a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2020/abuse.html +++ b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2020/abuse.html @@ -32,7 +32,7 @@ 1 day - Content moderation engaged at Platform.sh's own initiative + Content moderation engaged at {{ .Site.Params.vendor.name }}'s own initiative 1 0 Abuse of services diff --git a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2021/abuse.html b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2021/abuse.html index 799d8427ff..dbefe57736 100644 --- a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2021/abuse.html +++ b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2021/abuse.html @@ -32,7 +32,7 @@ 2.8 days - Content moderation engaged at Platform.sh's own initiative + Content moderation engaged at {{ .Site.Params.vendor.name }}'s own initiative 0 0 n/a diff --git a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2022/abuse.html b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2022/abuse.html index 223d1d39b0..75b759fcf3 100644 --- a/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2022/abuse.html +++ b/themes/psh-docs/layouts/shortcodes/tranparency-reports/tables/2022/abuse.html @@ -32,7 +32,7 @@ 1.8 days - Content moderation engaged at Platform.sh's own initiative + Content moderation engaged at {{ .Site.Params.vendor.name }}'s own initiative 0 0 n/a diff --git a/themes/psh-docs/layouts/shortcodes/vendor/url.html b/themes/psh-docs/layouts/shortcodes/vendor/url.html new file mode 100644 index 0000000000..2d6af1e9f2 --- /dev/null +++ b/themes/psh-docs/layouts/shortcodes/vendor/url.html @@ -0,0 +1 @@ +{{ .Get 1 }} \ No newline at end of file