Dropbox powered website builder

This post is being written retroactively. I wanted to make sure I marked the point at which I switched over from my old blogging system to this Dropbox powered one. Yup.

This service, available (currently) as Dropsite, was developed using their APIs to parse Markdown files into blog posts.

When you visit Dropsite, you get prompted to connect your Dropbox account, and are then given the sole option of choosing a subdomain to setup a "site" on. From there, a directory is created within your /Dropbox/Apps/DropsiteApp/{subdomain}/.

From there, you simply create files of the following format:

[Title]
Dropbox powered website builder

[Slug]
dropbox-powered-website-builder

[Published]
March 8th, 2012 10:00PM EDT

[Post]
..post..

After your post is done, simply connect to Dropsite, and hit the sync button. Boom!

Stack

Time for the technical :)
This project is running on a LAMP stack, and using the following open source libraries:

• TurtlePHP
• PHP-Email
• PHP-MySQL
• PHP-Pagination
• PHP-Query
• PHP-SecureSessions
• php-markdown
• postmark-php
• Dropbox
• JS-Ghost

Setup/Flow

There is one database which contains 3 tables. These tables are:

• accounts Records Dropbox accounts
• posts Records posts to a site
• sites Records sites for a specific account (one Dropbox account can have multiple sites)

The 4th table notifications was added to enable add-on functionality which emails visitors upon a new post being added.

You can see that it's a pretty basic database setup. I won't go into the columns themselves, but the table definitions are quite basic as well.

When a site record is created through the Dropsite administration panel, an API call is made to Dropbox to create a new folder with the site's desired subdomain.

This then triggers a Dropbox folder to be created for the authenticated user.

After this point, each time the sync action is triggered through the administration panel for a site, an API call is made which parses a specific-site folder, looking for files that have been changed (the markdown files I demonstrated above).

These files are then checked against the posts table to see if they are new posts, or updates to existing posts. The appropriate CRUD operation is performed, and well, that's about it.

There is a lot of work that gets done with the Dropbox API, naturally, and response handling when certain unexpected behaviour is discovered (eg. Dropbox Mime Types).

Updates

Hindsight being 20-20, there are quite a few things I would do differently, and will when I find the time.

At the time of development, the delta API method was not available. This method is really efficient when it comes to checking which files should be read (as in, which ones have changed since a previous sync call). I would use this method rather than my current flow, which checks each file's revision stamp to see if it's been changed.

Additionally, I would decouple a post's title, slug and published timestamp from the post file itself. Rather, I would create a master *.table file, which would act/serve as a traditional RDBMS table which defined post titles, slugs, published timestamps, and add flexibility for post drafts.

They would require a primary key (the first column in the flat-file) of a post file's filename/path.

Finally, I would have templates and the theme (stylesheets) itself pushed to the users Dropbox in order to give them full customization of the markup surrounding their post, as well as the theme.