Pagebuild

Pagebuild was in development for about two years. We used an agile project-management method, developing new features in iterations as we went. A lot of the functionality was the result of building something and then discovering a usability issue that required us to rethink that particular feature. The iterative method allowed us the flexibility to chop and change things as required.

In order to provide an incredibly simple site-editing interface, it was clear from the beginning that the bulk of the work on the front-end would involve using JavaScript to implement the desired UX. We used jQuery, jQuery UI, and a series of jQuery plugins.

FRONT-END

Editing
It was very important for us that the editor was truly WYSIWYG. It wasn't enough that a heading was a heading and bolded text was bold. We needed headings to be styled exactly the same, whether the user was editing a content area or viewing it. As a result, we threw out the idea of using IFrame-based WYSIWYG editors such as CKEditor or TinyMCE.

Another requirement was that users should be able to freely drag and drop images from our Media Manager into the content area. It wasn't possible to do this with an IFrame-based editor. After much back and forth, we settled on Twoism's reviser as the base for the WYSIWYG editor. I say base because we made extensive Pagebuild-specific changes to get it to work just so. The result was that we were able to provide a true WYSIWYG editing experience that is completely tailored to the Pagebuild Way.

One of the coolest features of Pagebuild's editor is the ability to drag images from the Media Manager toolbar and drop them into the content area at a position that makes sense visually. Unlike other drag-and-drop solutions in web WYSIWYGs, Pagebuild won't allow you to drop an image in the middle of a sentence. Using the jQuery UI module's sortable plugin, we are able to force the image to be moved around the content area and dropped in sensible drop zones.

Blocks and regions
Of course, it's not enough for users to be able to edit the main content area. We leverage Drupal's regions and blocks to allow the user to create unique and flexible page layouts.

When editing a page, regions can be shown or hidden, and blocks can be added to regions. This all happens via Ajax. Creating/editing/deleting blocks happens on the page itself, to prevent interrupting the editing experience. As a bonus, existing blocks can be dragged from one region to another.

Themes
We provide a number of free themes for customers to choose from. All Pagebuild themes are Zen sub-themes. On top of being a great base for our themes, Zen enabled our JavaScript to work, as we required all DOM classes and IDs to be consistent across themes.

When a user selects a theme from the Switch theme toolbar, we simply set that theme to be the default for all users, and make sure the block visibility remains the same.

BACK-END

Whereas Pagebuild's front-end largely consists of JavaScript backed up by Drupal modules, the back-end uses Aegir and custom Drupal modules.

Provisioning
From a customer's perspective, the Pagebuild adventure begins with sign-up. Here, we capture the customer's details, process the payment and provision the site.

We use Aegir to provision new sites automatically when the customer has finished signing up. Aegir, being as wonderful as it is, makes this incredibly simple. All you need to do is create a node of type site, and it will be added to Aegir's task queue.

After sign-up, the customer is automatically logged in and presented with the Pagebuild Dashboard. Once the site has been provisioned (which usually happens within 5 seconds), they can log into it and start editing right away.

In order to implement a single sign-on, the back-end acts as an OpenID provider. Our custom Drupal install profile adds an entry into the authmap table, allowing customers to log into their site without having to reenter their login details.

The custom Drupal install profile on the front-end communicates with the back-end database to set up themes, roles, filters, Pathauto and ImageCache settings, amongst other things.

Once customers have signed up, they can add new sites to their subscription with a simple single-page form.

Domain settings
When customers first sign up, they are asked to enter a subdomain for their website. Initially, the site is provisioned as example.pagebuild.net. Once the site is provisioned, though, customers can use any domain of their choosing for their site. Again, Aegir makes this very simple. When customers submit the form, we check that the domain they have specified points to our IP address. This prevents the site from being unreachable if the A record doesn't match. Once we've checked that the A record points to the correct IP address, we create a migrate task in Aegir, which renames the site.

Thanks, Aegir!

Theme editor
Customers are able to choose from a set of free themes, or they can make their own theme.

Using one of our themes as a starting point, users can alter every aspect of the design from their browsers. They can then save their theme with a new name, effectively forking it from the pre-built theme we provided. Both Drupal Gardens and the Sweaver module use this concept; however, both of those implementations allow so much freedom that they could confuse a non-technical user. We have made it harder to do silly things to your theme by restricting what HTML elements you can actually modify. While this limits the power of the theme editor, on the whole it results in a better theme when a novice uses the system.

Custom themes
While we provide free themes for customers to use on their sites, we also allow them to purchase a customized design. This is not automated, and involves the customer talking with a designer to get a result.

To greatly simplify the process of creating Pagebuild themes, we implemented a simple templating language that allows designers to write minimal HTML and as much CSS as they require to get the look right. Each theme only requires a single theme template.

Using the Token module, we then replace the Pagebuild theme tags with the Zen markup required, to make sure the theme works with the Pagebuild editor.

Designers upload the template file, a CSS file and whatever images are required. A complete Zen sub-theme is automatically generated and copied into sites/all/themes, ready for use.

Permissions on individual theme nodes ensure the theme is available only to the customer who purchased it.

Custom themes are currently only available to designers with whom we have an existing relationship. In the future, we plan to open this feature up to more designers. We will eventually open the feature to customers themselves.

Subscriptions
Initially, we tried using Ubercart, uc_recurring and various payment modules for the checkout and subscription payments. This added an unnecessary layer of complexity to the system: the Ubercart product wasn't meshing well with the existing Aegir and Pagebuild node types. Eventually we replaced the whole thing with a simpler, custom-built payment and subscription module.

The uc_hosting module to integrate Aegir and Ubercart looked promising, but we needed to move quickly. Rolling our own system allowed us to do that. Another benefit of making our own payment system: it's tightly integrated with the rest of the Pagebuild system, letting us avoid having to work around the assumptions inherent in Ubercart, uc_recurring and the payment modules.

Challenges

Internet Explorer
During the first half of development, we aimed to support IE7+ for page editing. After considerable effort, we decided to ditch native IE support, and instead create a simple UX for the customer to install Google Chrome Frame. We are really pushing the limit of WebKit and Gecko browsers when it comes to building WYSIWYGs, and we decided that a superior experience was preferable to a lowest-common-denominator one. The UX we provide for customers to install GCF is as simple as possible, and we doubt it will deter customers. Of course, GCF is only required for customers when editing their site. We support IE6+ as well as the proper browsers when viewing Pagebuild sites.

Content editable
Instead of using an IFrame-based WYSIWYG editor, we decided to use a feature of some browsers called content editable. While we believe this provides a superior editing experience, the cost is in the fact that it is not uniformly supported across all browsers. Worse, some implementations are particularly bad. For example, to fix a bug caused by Firefox's implementation of document.execCommand, we were forced to build a debug binary of Firefox and step through the rendering code in GNU Debugger.

Outcome
Despite the additional effort involved in rolling our own WYSIWYG editor, we are very happy with the experience we've managed to produce. To see Pagebuild in action, sign up for a free trial, or visit some of the live sites built with Pagebuild:

Intrinsic Interiors
Learn Microsoft Excel
Barbara Mordini