Ready to get started with WordPress VIP? Contact us
Showing page 7 of 16
The vip import validate-sql VIP-CLI command scans the format of a SQL database file for errors and potential incompatibilities with VIP Platform databases. The scan does not validate if the SQL will execute successfully after import.
VIP recommends setting up a local development environment with the VIP Local Development Environment feature built into VIP-CLI. The steps outlined here are a separate and alternative method for setting up a local environment for applications such as Chassis or @wordpress/env.
Remove a user’s access to an organization’s VIP Dashboard and their ability to interact with an organization’s applications.
Edit a user’s access permissions by updating the Org roles or App roles assigned to them. A user’s Org role and App role define the permissions they have to interact with an organization’s applications.
Invite new users to have access to an organization’s VIP Dashboard, and assign Org roles and App roles to them that will define the permissions they have to interact with an organization’s applications.
Debugging against a remote environment, such as a VIP Platform environment, can be limiting and challenging. For this reason, it is recommended to debug Node.js application issues on a local development environment. Make an effort to reproduce issues locally, and to keep the local development environment in close synchronization with remote environments.
The VIP Platform supports and strongly encourages the use of the HTTP Strict-Transport-Security response header (HSTS). This header informs browsers that a site should only be accessed using HTTPS , and that any future attempts to access the site using HTTP will automatically be converted to HTTPS.
Media files associated with a WordPress environment can be viewed and downloaded in the application view of the VIP Dashboard.
Environments with Default Deployment enabled are configured to track a specific branch of an application’s wpcomvip GitHub repository. For example, new production environments are set up to track a branch named production by default. Pushing any changes to this branch (via a push, merge, or rebase) triggers an automatic deployment to the production environment.
Testing a reverse proxy‘s configurations should be done with a site’s convenience domain URL in preparation for a site launch. When the proxy testing is complete, and the site is ready to launch, the final production domain (e.g. https://www.example.com) should replace the convenience domain in the configurations.