To get the big picture of how Presslabs services work, take a visual journey to our platform infrastructure: Presslabs Specifications.
Site access on Presslabs
You can’t do much development if you can’t access your site’s files, right? This page contains all the details you need to know to access your site, from wp-admin access to accessing your site’s code, database and media files.
Accessing your site’s code is now easier than ever thanks to our new web app based on Gitea. With an interface resembling GitHub Desktop, you can now easily edit your site’s files, directly from your browser.
Of course, for rigorous development needs or complex bug fixing issues, Git remains the go-to method for accessing your site’s code. This is why, besides the old way of cloning your site locally, using the SSH protocol which requires further SSH keys configuration), we have also implemented clone URLs via HTTPS. Now you can simply clone your site and authenticate using your Presslabs dashboard credentials. It’s that simple.
This page also contains details about giving access to collaborators to your site. You can give access to a developer to all the sites in your account, by adding his public key to the SSH Keys section of the Presslabs dashboard, or to a single site, by adding him as a collaborator in the Collaborators section.
You can read more about site access by visiting our dedicated page.
Configure SSH Keys
Although cloning your site using HTTPS seems easier and doesn’t require extra configuration, if you do a lot of git clone/pull/push operations on a daily basis it can become quite a nuisance to manually enter your credentials each time. By using the SSH protocol you can clone your site locally without having to supply your username and password each time. For this, however, you need to set up your SSH keys. You need to generate a pair of SSH keys, and then enter your public key into the Presslabs dashboard.
Take a look at all the necessary steps for configuring your SSH keys on Linux, macOS and Windows.
DNS Records Examples
DNS records seem confusing for most users and words such as “A record”, “CNAME” or “SPF” can seem rather difficult to grasp. To make it easier for you, we have previously written an article that explains the basics of DNS records and also updated the description of the zone management section from our dashboard. You will no longer be confused about what are your nameservers and what to do with them after checking our resources.
This page presents DNS records from another perspective, showing you simple examples of how to configure various DNS records on the Presslabs dashboard, how to set up an email with your own domain, even how to add records to prevent email spamming.
Don’t let DNS frighten you anymore, check out our DNS records examples.
We have put together some common guidelines regarding both WordPress and Git, as well as updated development specifications related to our platform. We tackle various topics, such as feature development and deploying, debugging, recommended plugins and proper plugin and theme installation.
Since installing and updating plugins are the most common cause for crashing your site, we provide free development sites to test plugins, new features and any other changes in a safe mode.
Make sure you are familiar with our development guidelines for a proper development workflow.
Development Life Cycle
We highly encourage you to make changes using the well-known development pipeline local - staging - production and we have detailed the necessary steps for setting up such a workflow.
Local development means setting up a local development environment (we’re offering Vagrant as a default tool) on your personal computer to make the changes. The staging part implies pushing your changes on your development site to test the changes and the compatibility with different elements. The last step is to push the changes to the production site, aka the site you are presenting to your users.
Learn more about how to set up a local-staging-production workflow.
We’re offering Vagrant as a default tool for local testing, and each site hosted by Presslabs comes with a Vagrant file. Vagrant is a tool that replicates a production environment to your local computer for development purposes.
The necessary steps to configure a local environment are easy to follow, considering your site already has a Vagrant file configured, so all you have to do is to install Vagrant and VirtualBox and run some simple commands.
Vagrant is simple, straightforward and just works on any platform: Mac, Windows and Linux. Regarding using Vagrant on Windows, we recommend you to install Git for Windows, which provides a BASH emulation where you can run all the necessary commands lines, just like you would do it on Linux or Mac.
Check out how easy it is to set up a local environment with Vagrant.
For many years we’ve been in a love-hate relationship with SFTP, and we even had to create our own Git-based file system called Gitfs to make it work. We discontinued using it this year and replaced it with Gitea, a Github alike platform you will get to love. Managing your source code is now easier than ever, as you can access Gitea on the go, either on tablet or mobile at every moment, directly in your browser.
Our Gitea-based Presslabs dashboard, which we simply refer to as Gitea, offers easy to manage repositories through a visual, user-friendly interface. You can visualize commits, edit your code, make issues and pull requests and many more.
We have detailed how to log in and how to make basic operations such as editing, creating or deleting a file. Want to add something quickly to your robots.txt file? Now you can do it yourself in just a few seconds, just check our Gitea Development page above.
Find out how easy it is to find your way around Gitea.
If a few years ago Git-driven development was only used by tech-savvy developers, now more and more managed WordPress hosting companies come with Git integration, as it allows you to version control your code. With Git, you know exactly who brought changes to your code and when, and you can also go back to previous versions in no time.
Once we discontinued using SFTP, we started creating a series of tutorials, to help our customers learn the basics of Git development on our platform and leave the old SFTP behind.
There are a lot of different ways to use Git. Besides accessing your site’s code directly in Gitea, you can use the original command line or one of the many graphical user interfaces designed to help a Git user.
Manage your code with a Git client:
Manage your code from the command line:
You might find yourself wondering why to bother learning Git command lines or even install a Git GUI, as long as you can manage the code in Gitea? Well, if you are a publisher and you only need to make small code updates, like adding new ads in your ads.txt file, you don’t. A developer, on the other hand, needs to be able to get the code on his local computer, to properly work on it.
It is actually easier to manage your source code’s files and changes locally. For example, if you want to move some files to another directory, it is much easier to move the files using your operating system’s file manager than changing their path one by one in Gitea. It allows you to have a cleaner and more comprehensive Git history. Let’s take an example. You want to change the path to some images you have on your site and you have 10 files to edit. If you do this in Gitea, it will create 10 commits, each saying «Changed the image path». Whereas if you do this locally, you can incorporate all this changes into a single commit «Changed the image path», thus keeping your Git history much cleaner and easier to track.
Another important reason is that there are certain operations that cannot be performed in Gitea, the most important one being reverting a commit. This is a very important operation, especially if you want to revert a commit that put your site down, for example. For this, you need to use Git command lines or a Git Client, such as Fork or Github Desktop, which offer such possibilities.
If you can’t decide whether to use Git command lines or Git GUIs, use whichever works best for you. The command line is the only place you can run all Git commands and offers you more control, but a graphical interface may offer you a better visualization of your Git history. Also, who’s stopping you from using both? Nonetheless, we created a set of tutorials for both Git command lines and two Git GUIs: Fork and Github Desktop.
Follow the tutorials to learn more; you’ll feel better.