Up in the title of this post are some of the most requested features for Forge. We gave some consideration about the best way to approach implementing these and this post is intended to introduce the early stages of our process and thinking.
So, what you may not know about Forge is that there is a node.js server and some scripts that handle how your site gets served - the caching of pages and assets, urls etc. There's some smarts in there, but also some limitations, up until now.
Over the last few weeks we've set about giving this proxy server some love and attention in order to achieve the new features and providing an extensible platform that can do a whole lot more.
Much like with Hammer, we first expose advanced functionality through a simpler, albeit more "technical" interface. That way we can see what is most commonly used, most broadly and globally required for users of all technical levels - and then we expose that functionality through a simple and elegant UI in the app. This is to protect the simplicity of our products.
So, now we're starting with the technical interface, in the form of a configuration file, called:
By including this file in the root of your Forge site directory, you can access the features. Let's take a closer look at how this works, and the features that are available to you.
File Format and Structure
Our config file allows to specify how site requests will be handled. The general structure of a file is:
[Condition#1] [args] [Rule#1] [args] [Rule#2] [args] [Rule#3] [args] [Condition#1] [args] [Rule#1] [args]
So far these conditions are supported:
- Location <exact path or express-like wildcards>
Additionally, any plugin can define it's own rules or conditions (more on that to follow).
The example of a config file:
Example Use Cases
You would probably need .forgerc file on your site if you want to reuse pages across different URLs or you want better looking links. This can be achieved with Redirect/Rewrite rules. E.g.:
Location /our-team Rewrite /our-team.html
We imagine you'd want to give a link to your site with terms and conditions. You're too busy at the moment to design specific page, so instead just redirect users to a Google Doc (replace it with your own page, the link will remain the same!).
Location /terms Redirect https://docs.google.com/document/d/1_n1_oiyk0b3x7i69n-iAh4f0UmFbvA 302
You don't even need a page, you can write a quick text placeholder directly in the config file:
Location /terms Respond "Oops! Not ready yet, stay tuned." 200
Use NotFound condition if you want to display custom 404 page (Forge already supports 404.html out of box, but say you need another name).
NotFound Rewrite /my-custom-404.html
This condition is also useful if you have a single-page application with pushState routing. In order to make your app work when it refreshes, you need to respond with index.html on any unknown request.
NotFound Rewrite /index.html
I love it when time and consideration is given to make something extensible, with a suitably straightforward API and structure. We've tried to do that with this Forge Server feature.
All of the above features are written as Plugins. And you can write them too, because we plan to open source the Forge Server, just like we do with our Hammer Compiler and Anvil app.
Basically a Plugin is a module in ./plugins directory of the Forge Server project. Each plugin is responsible for registering it's own rules or conditions (in future, extra conditions are not yet implemented).
The example of a plugin with one rule definition:
Thanks to our lead developer on this, Alexey, and the Forge customers in the Slack Team room for help in developing this feature, if you would like to join the conversation, jump in - we're waiting for you. We'd especially like to hear what other plugins could be useful and for you to have a go at writing plugins yourselves.
We're currently testing the first release of this feature internally and plan to release it in the next week or so.