Ready to get started with WordPress VIP? Contact us
Showing page 9 of 18
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).
Media files associated with a WordPress environment can be viewed and downloaded in the application view of the VIP Dashboard.
XML-RPC allows requests formatted in XML to be sent between WordPress and other systems. The XML-RPC endpoint is enabled on new WordPress sites by default since the release of WordPress version 3.5. The XML-RPC endpoint is extremely useful, but is also a common attack vector for WordPress sites. Security reviews for WordPress sites often recommend disabling the XML-RPC endpoint entirely.
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.