Open Source Forum Scripts Published Vanilla 2 Public Beta

The Vanilla 2 Public Beta is online now on open source community forum. Please read this entire post before clicking away, as it contains important information about questions you will surely have after getting there. I wasn’t sure if I should call this an alpha or a beta. There are a number of core features that are not yet in the version of Vanilla you are about to see. The most glaringly obvious of these is a search page. In the end I chose beta simply because it rolled off the tongue. Regardless, rest assured that the application is not yet feature-complete.

Feature Suggestions

I know that many of you will have feature suggestions after playing with the application. Please use the Vanilla category at the community forum as a place for your suggestions. Also, please remember (a) that the application is not yet feature-complete, and (b) to be nice when making suggestions, and (c) if your suggestion is not implemented, Vanilla 2 is a pluggable system (and more easily pluggable that Vanilla 1 was), so your feature ideas can easily come after Vanilla 2 is finalized.

Whispers & Data Loss

There are no whispers in Vanilla 2. Instead there are “conversations”.

Garden & Vanilla 2 on Open Source Software Forum

Things you need to know before downloading it from :

1. Garden & Vanilla 2 are currently beta products that contain bugs and incomplete features.
2. Garden & Vanilla 2 should not currently be placed on production servers.
3. There is a first draft of documentation available at
4. You can not currently upgrade your Vanilla 1 database to Vanilla 2 with the code at GitHub (you’ll be able to soon).
5. If you start to use this code, be prepared to erase your Garden/Vanilla database a few times before the codebase is final. Data WILL be lost.

Many have asked will Vanilla be compatible with open-source casino software, but no. Our software purpose is mostly for responding and data services. So, if you wish to play slots games, do not have an expectation from Vanilla, instead, go to platform and knock yourself out with free playing.

About GitHub

We are absolute newbies to GitHub. We’ve heard fantastical and amazing things about it, and we can’t wait to start working with all of you on patches, fixes, merges, branches, and all that awesome stuff. Please be patient with us as we learn the subtle nuances of GitHub.

Contributor’s Agreements

We’ve been speaking with a number of lawyers and leaders in the open source world since we got to TechStars.

How to Handle a Pull Request from Mark O’Sullivan Online

We decided to pick up Git for the Vanilla & Garden projects after discussions we had with people from many other companies while we were part of open source discussion forum software this past summer. Git is still a bit of an enigma to me, and I’ve been receiving pull requests from people for a while, and I’ve failed to successfully get their changes into my code – instead opting to just manually apply their changes with my own IDE. That is, of course, a total waste of my time and contrary to the entire purpose of us adopting Git. So, today I finally sat down and dug my way through to figure out how to handle a pull request.

After a few hours of frustration, it finally makes sense. Here’s the long and short of it: Define the user’s remote repo, get a local copy of their work, go into the branch you want to pull their changes into, and cherry pick their commit into your branch.

Here are the actual commands I used to accomplish this for a number of different pull requests today:

Step 1. Do you already have their repo set up as a remote branch on your dev machine?

Garden Preview Part I

Almost two years ago I started thinking about rewriting the Lussumo Framework, the framework upon which Vanilla is built. After a year of heavy contemplation, I finally started development on the new version, which I have come to call “Garden”.

My concept for the Garden framework is not to be competition for the likes of The Zend Framework, CakePHP, or even CodeIgniter (to name a few of the other great PHP frameworks), but something both a little less and a little more. My idea was to create a framework that didn’t solve everyproblem, but just most of the common problems we face when developing simple web applications. I wanted to build a framework that had user and permission management built right in. I wanted to build a framework with which you could easily create new applications and throw them alongside any others – and all users, roles, permissions, preferences, plugins, and themes could play nice together. can safely say that I have accomplished that task.

Recently I had an active member of the Lussumo Community contact me and ask if his plugins for Vanilla 1 would work with Vanilla 2. It was hard to give him the answer that, no, none of the (over 400) plugins for Vanilla 1 would work with Vanilla 2.

Garden Preview Part XI: Structure

Most open source software forum have database setup scripts that are simply a set of SQL instructions that you can inject directly into your database (typically mysql) to get going. Vanilla 1 was no exception to this rule. The benefit of this approach is that you can quickly and easily get your app up and running. The downside to this approach is that when it is time to upgrade the application to a newer version, you have to write extremely convoluted scripts to figure out what application version the user currently user has, or write scripts to examine database table structure to see what fields need to be removed, or what fields need to be added. Hell, it’s even difficult to understand what I just wrote, let alone the code that would go along with it.

The Database Structure Class

Garden does not have any SQL install or update scripts. Instead, every application in garden has a structure.php file which can be used by either the Garden installer, or by the application management screen when enabling that application. The structure.php file contains a set of instructions on how to build the structure of the database. This file uses the DatabaseStructure class to define the structure of the database.

Garden Preview Part III: Anatomy of a Request

mod_rewrite was an afterthought in Vanilla 1. As a result, have always felt that the mod_rewrite mappings were sloppy and really just didn’t make much sense. In Garden, the way pages are accessed is completely different, and definitely deserves explaining. Let’s start by looking at a typical url request in Garden without mod_rewrite enabled:


Let’s look closer at each part of the request:

http://localhost/garden/default.php: On my development server, I’ve created a folder called garden, and placed all of the garden files I discussed in last week’s preview in it. As you can see, the default.php file that handles all requests is sitting within that folder’s root.

/garden: The next part of the url is the application that is being requested. In this case, we are requesting the “garden” application within the garden framework’s application folder.

/settings: The next part of the url is the controller that is being requested within the garden application. In this example, we are requesting a controller called “Settings”.

/configure: the final part of the url in this example is the method within the “Settings” controller that we are calling. In this example, we are calling $SettingsController->Configure();.

I could take the same request and add information to the end, like this:


Garden Preview XV: Modules

Views are used to define the main content of a page (ie. a list of discussions, a user profile, etc), but what about all of the other supplementary elements on a page? How does Garden handle adding buttons, menus, and all of the sundry elements that make any page complete? Modules.

Modules are extremely simple classes that have one purpose: return a string. That string can really be anything you want, but typically it will be a string of xhtml that is to be added to any of the asset containers defined in the master view.

Garden comes with a number of predefined modules, such as:

HeadModule: Allows the addition of tags to the head of the document, like link (css) tags, script tags, meta tags, etc.
MenuModule: Used to build a hierarchical menu that can then be manipulated to do a number of different tasks. For example, it is used for the main menu of Garden that includes hover-driven dropdown items, and it also is used for the main settings page as a sidebar menu.
EditInPlaceModule: Can be added to any page in the sidebars, header, or footer and allows administrators to put anything they want into that page by editing the content block in-place.