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.
Find out more about Git-driven development, development – stage – production environments basics and benefits of dev sites on our blog.
Feature Development and Deploying
From the WordPress perspective, it’s recommended to develop features as separate plugins and to keep ONLY the things which are related to formatting and displaying content inside 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 in particular. Briefly, you should have branches for each feature, and after you ended testing you merge that branch with master.
You can debug and look for errors using the error log console in the Logs section of our 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.
For debugging purposes, we recommend the following plugins:
- Query Monitor - monitors any queries that your pages generate, load times and resources;
- Rewrite Rules Inspector - for inspecting your rewrite rules
- What The File - adds an option to your toolbar showing you which files and template parts are used to display the page you’re currently viewing
- Crontrol - allows you to create new cron jobs, as well as edit, delete and immediately run any cron events.
Since social media sites are today’s go-to channels for sharing content, make sure you check out our tips and tricks for using the Facebook Debugger.
- Toplytics - displays the most visited posts as a widget, using data from Google Analytics. Check also Google Analytics in WordPress—Your 2.0 Guide
- File Manager - allows you to easily manage your media files and folders
- Wordfence - firewall and malware scanner
- Activity Log - monitor and track your site activity.
Regarding image optimizations plugins, check our blog articles: WordPress Image Optimization Plugins that Actually Work and Hottest WordPress Image Optimization Services Compared.
We also debate the Pros and Cons of Comment Systems for WordPress Sites.
Make sure you also check out our list of banned plugins, detailing the reasons we do not allow them on our platform.
Development Life Cycle
Each site hosted by Presslabs has a git repository associated with it.
In addition, we offer free development sites, in order to simplify the process of developing new features for our customers. Your development site can be set up in two ways:
- the production and development site are located on separate repositories
- the production and development site are located on the same repository, but on different branches.
You can ask our Support team to set your development site the way you prefer it.
Depending on your chosen development site setup, there are two recommended development life cycles. Both underline that you should firstly make changes on a local environment, or on your development instance, but only after proper testing, and then push them to the live site.
In this way, you ensure that if something happens, it will happen to the dev site and not the live one.
Case 1: The production and the development sites are on separate repositories
Each repository comes with a Vagrant file for local development. You can follow these steps to set up 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 the live site.
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 IDs from your Presslabs account):
Clone the site
git clone -o prod firstname.lastname@example.org:username/site.git cd site
git remote add stage email@example.com:username/dev-site.git git fetch stage
Push master by default to stage
git config branch.master.remote stage
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 above.
Merge the feature branch into
masterand 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), which is identical with the production site from the environment point of view (caching, security restrictions etc.).
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.
Case 2: The production and development site are on the same repository, but on different branches
This development site setup means that you can have 2 branches on the same repository: master (which is connected to the live site) and develop (connected to the development site).
Step 1: Switch to develop branch
Clone your code locally:
git clone https://git.presslabs.net/username/site.git cd site
Switch to the develop branch:
git checkout develop
Ensure you have all the changes from the repo:
git pull origin develop
Step 2: Do the code changes that you want to do and test them on the local environment. When everything is ready and working as expected on the local environment, you can push these changes to the development site.
Here’s how to do it:
Check out the changes that have been made
You can ignore from this list the
wordpress folder, as that is only used for your local setup.
You can also ensure you’re on the
develop branch, so you won’t send the changes directly into production:
Prepare all changes from the entire
wp-content folder to be sent to the development site
git add -A wp-content/
-A means that you’ll also add the files that need to be removed ( e.g. in case you have deleted some files that are not needed). In case you want to send for testing only one file, then you should only add that file. For example:
git add wp-content/themes/yourthemename/style.css
Now that the modified files are added, you need to commit them:
git commit -m "Here's the commit message"
In the commit message, it’s good to say what you have changed, in order to have an easy way to revert, if needed.
The final step is to get the changes pushed
git push origin develop
After this command is executed, you can check how everything looks on the dev site:
Step 3. If everything is OK on the dev site, then you can push the changes in production:
First, switch to the master branch:
git checkout master
Then, ensure you have all the changes:
git pull origin master
Merge the changes from develop into master:
git merge develop
Then, push all the changes to the production site:
git push origin master