So, you’ve decided to get Grav and build a site with it. Congratulations! Building with Grav gives you the power and flexibility you need to realize your site but you need to develop that site first. Using an efficient development strategy will allow you to build your site faster and hassle-free. You might even have fun while doing it!

When you look at how easy it is to set Grav up and get it running on a remote server, it can be very tempting to just do development there, especially given the fact that there are no databases to migrate over, and everything is file-based. However, don't be tempted by this approach! In this blog post I'll endeavor to explain why...

Development on Remote vs. Local Servers

Having a local development server is an essential tool every web developer should employ. No matter the level of complexity of your site, during the development phase you will want to be able to have an environment that you have complete control over, can easily monitor, and make changes to.

On a local server, you can make changes quickly, control its resources, easily monitor logs, make system-level configuration changes, and set up as many testing environments you need. You will also be able to quickly respond and reset services n the event that something goes awry, and also test against scenarios that you may not be able to easily recreate in the remote environment. Throughout the life-cycle of your site, having a local sever also means you can test upgrades, work on new content, and implement redesigns, all without having to worry about affecting your live site.

Remote servers (especially budget-friendly ones) can be very limiting. You will find yourself having to spend a lot more time and effort working around the restrictions of your remote server compared to working locally, and then uploading the finished product in-one-go when it is release-ready.

If you are developing on a live server, you are essentially walking a tightrope without a net, where anything that goes wrong will appear on your live site. In general you want to limit your interaction on your live site as much as possible. Any changes, even seemingly harmless ones, have the potential of taking your site offline and making it unavailable. You really want to avoid this outcome at all costs.

The preferred approach is to develop your site locally, and when you get to a stable state, push your site to your live production environment.

Source Control Systems

Even if you are a lone developer, utilizing a source control system such as GIT can be a huge benefit. It allows you to commit incremental development progress and then be able to track your progress and even rollback problematic code or updates. Grav, being entirely file-based, is eminently suited to being used in source control environment. Your entire Grav site can be pushed into a source control repository giving you complete control and version history over every file. This approach also allows you to push a known release or tested state to your production or live server.

If you work with multiple developers, source control is a must. It becomes imperative for all developers to be able to synchronize changes between themselves and ultimately be confident that the resulting code is stable and production-ready.

We will go over using GitHub effectively with Grav in an upcoming blog post. We intend to cover how best to make use of GitHub to simplify the process of developing locally and utilizing GitHub to manage pushing your Grav site to production in a controlled manner.

Local Development Server Solutions

By now you should be thoroughly convinced why you should be developing your site locally, and never directly on your live site. Whether you are working on a Mac, Windows, or Linux-based PC, you can easily set up a development environment that gives you the ability to have a fully functional test server at your disposal, no matter where you are.

You don’t have to make this server accessible from the Internet. You can restrict access to localhost, making your system the only one that can access the server. If your working in a team environment, you may need to look at making your site accessible via the internet, but this is an advanced setup, and we won't cover that today.

Both OS X and Windows, as well as most Linux Distros, have some form of server software either included or easily available.

If you are running OS X, we detailed a basic Apache setup in previous blog posts ( Part 2 ). Windows’ primary native server software solution is IIS, though there are many other software options and stacks available. This is probably more for a power-user and there are some much simpler approaches that are installable via simple one-click installers:

• MAMP and MAMP Pro - (Mac/Windows) Here is a post explaining how some members of our team use MAMP for development.
• XAMPP - (Windows)
• EasyPHP - (Windows)

Once installed and running you effectively have all the tools you need to develop your Grav site locally. Check out the Grav System Requirements page for more information. Please follow the Grav Installation and the Basic Tutorial to get started and get your Grav site up and running.

How to Migrate Your Development Site to a Remote Live Server

Once development and testing is complete, migrating Grav from your development server to your live site is easy as F--T--P. You basically just need to copy your root Grav directory to the directory on the live server you wish to have your site located on using SFTP or FTP.

There are other approaches that are even better than manually copying files over to your production site. You can pre-configure a synchronization process with many tools including FTP clients and dedicated file-syncing applications. This will allow you to more reliably copy over local files to your remote server. Most of the applications available are smart enough to detect changes, so they only copy over what is needed making them fast and efficient.

An even better approach is to use a source control system and either manually pull a stable version from your site, or setup a GitHub webhook that will automatically tell your server to pull the latest version from the repository. The benefits of this approach are pretty obvious, and the upcoming blog post will make it even clearer.

After your files have been updated, you will want to clear the Grav cache so that you are starting from a clean slate, free of any URL assignments and other cached information specific to your development environment. This can be done by deleting all of the files in the cache/ directory, or by using Grav CLI.

Environment Configuration

There are several advanced features that you can take advantage of when developing with a split local/remote development strategy. First you should take advantage of Grav's Environment Configuration settings. These allow you to configure your local environment differently from your live site. A good example of this is enabled the debugger locally only. Another common use it disable asset pipelining locally to ease development and debugging, but enable it on your live site to increase performance.