Presslabs development guidelines
Developing on the Presslabs platform is no different than developing a regular WordPress website with a few caveats required by software development good practices on distributed systems. We consider software version control to be the central point of good software development. For this reason, we use the Presslabs-provided Git repository as the source of truth when it comes to a website’s code.
In order to access a website’s code you can use SFTP. The access credentials can be retrieved from the Access menu in the Presslabs Dashboard. Your website code can be changed from the
/current folder. The
/history folder contains the list of changes to your site grouped by date and time.
The recommended way to change the code is by using Git. In order to access it, you need to first configure your Git access keys. Afterwards, you can clone the repository using the provided URL in the Access menu form the Presslabs Dashboard.
Presslabs allows database modification and querying only through the WordPress API. This is because our systems are tailored for WordPress code and not general PHP applications. This allows us to do proper database replication and availability. Although it’s possible to create tables, we strongly encourage you to use the containers that WordPress has to offer, namely custom post types, custom taxonomies, and metadata for storing your data.
Feature development and deploying
From the WordPress perspective, it’s recommended to develop features as separate plugins and ONLY keep things related to formatting and displaying content inside of the theme. From the git perspective, it’s recommended that you keep each feature as a separate branch.
There are many articles around the web about git workflows, but there is one we'd like to mention. The summary is that you should have branches for each feature, and after you ended testing you merge that branch with master.
From Presslabs’s perspective, pushing to a site’s git master branch means deploying it to live.
You can debug and look for errors using the error log console in the Development section of the Presslabs Dashboard. Fatal errors give you a
request_id which you can look up in the error log. Also, the PHP function
error_log logs directly to the console.
Development life cycle
Each site hosted by Presslabs has a git repository associated with it. As we said earlier, this is the source of truth when it comes to a website’s code. Each repository comes with a Vagrant file for local development. You can follow these steps to setup the Vagrant environment corresponding to your site. This way, you can develop and test locally, and, when you are satisfied, merge the code with the
master branch and push it to live.
Like we said earlier, pushing to a site’s git master branch means deploying it to live, and each site comes with its own git repository. We will use this to our advantage to create the well known development pipeline:
local - staging - production. In order to do this, you need two Presslabs sites, one for production (
site) and one for staging (
dev-site) while following these steps (replace
dev-site with the corresponding ID's from your Presslabs account):
1. Clone the site
git clone -o prod email@example.com:site.git cd site
git remote add stage firstname.lastname@example.org:dev-site.git git fetch stage
3. Push master by default to stage
git config branch.master.remote stage
4. Create the feature branch
git checkout -b feature-name
Now you can develop the new feature locally and test it on the Vagrant setup described earlier.
5. Merge the feature branch into
master and push it to staging when ready
git checkout master git merge feature-name git push stage
Now you can test your changes on the staging site (
dev-site) that is identical with the production site from the environment point of view (caching, security restrictions etc.).
6. Push the changes to live when ready
git push prod
Following this guideline, you can always push where you want to by using
git push prod and
git push stage.
Also, if you update plugins directly on production, you can always create a local
production branch with
git checkout -b production prod/master and merge it with your local master. This way you can merge remote changes from production or stage with local ones.