We decided to pick up Git for the Vanilla & Garden projects after discussions we had with people from many other companies while we were in TechStars 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? Check with:

git remote -v

If not, add the remote branch and fetch the latest changes with:

git remote add -f <username> git://github.com/<username>/Garden.git

Note: “Garden” is the name of our project on github. Obviously, you would need to substitute that for your project name.

2. Do you already have a local copy of their repo? Check with:

git branch -a

If not, create it and check it out with:

git checkout -b <username>/master

If you do already have a local copy of their repo, fetch the latest changes:

git fetch <username>

3. Get their changes into your personal working branch:

git checkout master
git cherry-pick <hash of user's specific changes that they requested you to pull>

That’s it. I can’t believe it took me so long to figure that out!

It is long overdue that I post an update to the Garden & Vanilla 2 development. First: if you find that I’ve not been posting on my blog, you can take it as a good sign meaning that I’m busy doing other things.

Myself and a great friend of mine (Todd Burry) have been working full-time on the project for the last four weeks.

Next week we will be moving our current issue tracker over to GitHub and simultaneously releasing the Garden and Vanilla 2 code there. The code is still under heavy development and is absolutely not ready for production use. However, it does work and we need your help getting it finished.

Although Vanilla 1 is an open source project, I have always been the bottleneck that keeps it from really taking off. I refuse to let this happen with Garden and Vanilla 2. So, we will be doing our best to allow everyone in the 10,000-strong Lussumo community to help us out this time around, and the release of the code on GitHub is just the first of many steps in this direction.

Following the GitHub move, I will be contacting the authors of the most popular plugins for Vanilla 1 and helping them to get their plugins ported to Vanilla 2 so they can be fully functional and compatible for the Vanilla 2 release. If, for some reason, the authors are uninterested in porting their plugins to Vanilla 2, I will be making announcements here to find anyone out there who is interested in picking up where the previous authors left off, so keep your eyes peeled. If you have a new plugin idea that you want implemented for Vanilla 2 and you want a hand with getting Garden, Vanilla 2, and understanding how things are done: feel free to contact me here on this blog, via twitter @navvywavvy, or directly via email at mark [at] lussumodotcom.

The future starts here!

I’m in the process of adding some methods to the database object to help in writing chained queries for Garden. One of the annoying problems I’ve run into is that the words “or” and “and” are reserved and won’t work as method names. So, for example, imagine I wanted to write the following chained query:

$Database
     ->Select('FieldName')
     ->From('TableName')
     ->Where('FieldName', 'value')
     ->Or()
     ->Where('FieldName', 'othervalue')
     ->And()
     ->Where('FieldName', 'Yet Another Value')
     ->Get();

I realize that this query really doesn’t make much sense, but that’s beside the point. The “or” and the “and” methods can’t exist in PHP, so what should I use instead?

I’ve played with things like AndOp and OrOp, implying that they are operators. I’ve tried going for shorter versions like Nd and R, but those are just stupid and don’t make much sense. I’ve also considered having OrWhere and AndWhere methods, but that would mean adding a whole bunch of methods like that (think: OrWhere, AndWhere, OrLike, AndLike, OrWhereIn, AndWhereIn, etc).

I’m looking for community input here. What would you prefer to type?

Update
Jon posted a walk-through of how all of these logos came to life. Check it out!

The Vanilla 2 Public Beta is online now. Please read this entire post before clicking away, as it contains important information about questions you will surely have after getting there.

Development Status

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”. The installation you are about to see is a copy of the community forum from about 3pm on April 3rd, 2009. All of your whispers from that database have been transformed into conversations. Also note that as bugs are encountered and fixed, it may be necessary for us to roll the database back to the April 3rd date. So, don’t be surprised if your discussions, comments, replies, conversations, messages, status updates, profile changes, etc get wiped out.

Reporting Bugs

We’ve set up a trac issue tracker at issues.gardenframework.com. If you discover a bug, please register there and then search for it before submitting it.

Not For Download

This is a public beta. You do not get to download and install Vanilla 2. You just get to use our installation.

Without any further ado, I give you Vanilla 2.

It’s that time, once again, when I can’t figure out how to do something with CSS and I need your help. I’ve created a full description of the problem and examples of solutions I’ve tried.

The long and short of it is that I have a control that writes messages to the screen. I am currently using an unordered list to render these messages, but I want to format them at the top & center of the screen. I want each message to be on it’s own line, and I want all of the messages to be encapsulated by a solid rectangular background. I want the solid rectangular background to be only as wide as it needs to be in order to encapsulate the widest message.

I’ve been able to accomplish this with a table, but that’s just semantically wrong.

Please check out the examples and let me know how you would solve this problem.

Update

Evdawg posted a solution that works cross-browser! I’ve updated the examples with his working version.

Update 2

Inky posted another kickass center-float solution that also works cross-browser. I’ve added that one to the examples as well.

Today I spent the day at TechStars for “TechStars for a Day”. It was a very overwhelming day and I met a lot of interesting people. I came out of the day with a number of realizations about things that I’ve been doing “wrong”, and improvements that I need to make in my approach.

1. Private Beta == Bad
This notion that I’ve had of letting just the core community members in to test a closed beta of Garden & Vanilla 2 is simply a bad idea. After all, why limit the user-base when I know that *all* of you have fantastic ideas? So, the first beta that goes online will be open to anyone to register and use. I want everyone to get a taste ASAP.

2. Delivering on Promises
I’ve been explaining the softare for literally months without giving any of you any real immediate interaction. I need to pick up the pace and get something out there for you guys to play with SOON. I don’t have a specific date for you, but my hope is that we’re talking about weeks, not months.

3. Listening to You
Obviously I have my ideas of what I would like to see the software do. But ultimately it will be you, the users, who judge the software as something you will want to use – or not. So, after you’ve had a chance to use it, I will be paying a lot of attention to your feedback. What do you like? What don’t you like? What is missing? What have I overlooked? etc.

4. Open the Source
I still believe that it is important to have a real focus on where the software is going. But I think I’ve been confusing that need with “letting go of control”. The way that changes were implemented with Vanilla 1 were far too constricted. I’ve been speaking in private chat with a bunch of the Vanilla 1 developers about this, and while I won’t be allowing *everyone* to commit changes to the core, I will be accepting bugfixes and change suggestions from the community and allowing other Vanilla 1 developers to review and decide on which ones should be a part of the core. Some Vanilla 1 developers are already looking into ways we can facilitate this process, and I’ll be relinquishing a lot of control to them right away.

With all of these things in mind, my primary goal for the software in the immediate future is to get a beta online right away. I’m trusting that everyone is aware that the design isn’t going to be as polished as the final product will be. My focus will be on completing core features and not focusing so much on design. Design can be polished later.

The bottom line comes down to a quote I heard today: Getting all of your ducks in a row is important, but it is more important that you do something with the ducks. That is now the focus.

On another note, feel free to follow me on twitter if you want to stay on top of all things Lussumo. I don’t *always* stay on topic (I might post what some people have called “zen food tweets”), but I don’t spam, and anything new that comes up with the software will be posted there first.

Thanks to everyone for all of their help & advice!

TODO

There are a lot of little things left to do as far as programming goes. Lots of debugging, a bit of commenting, and most of the design. I am going to leave most of the debugging to when the beta goes online and all of you have a chance to play with it. The commenting is really what I’m focusing on right now, as I am writing a parser to go through all of the code and pull out comments – it will serve as the primary documentation of the objects in the framework. The design has been handed off to two close friends who have a lot of experience in that area. I am waiting to hear back from them, but they both have jobs and lives as well, and can only do so much so fast. I have no idea when they will deliver anything to me. It could be hours, it could be weeks.

A Successful Launch

Above all else, I need to make sure that Vanilla 2 gets the launch it deserves. A big part of ensuring it’s success is setting realistic expectations for myself. I’ve come to fully understand that I can’t do this job all by myself (furthermore, I don’t want to do it by myself). I’ve been reaching out to various people in the community for help in different areas. A big thank you to everyone for their enthusiasm and assistance!

Things to Come

A few months ago, when I really came to terms with the need for help, I started reaching out to everyone in the community around me both in my home city, and in various communities on the internet. I got a lot of advice from people in all lines of business, and eventually I was connected with David Cohen at TechStars. Techstars is a company that specializes in getting startup businesses off the ground by giving chosen businesses an instant network of mentors and contacts in the tech industry.

Since our initial contact, I’ve spoken with a number of people from Techstars, including some who have been through program in previous years, and I’ve applied to be in the 2009 program. I’ve since been invited to go down to Boulder, CO where they are based for a meet-and-greet called “TechStars for a Day”, which takes place on March 3rd. I’ve accepted, and I am looking forward to meeting everyone involved and getting a good grasp of what the program might actually be like.

Partnership

I’ve known for a long time that having a partner would have sped up every aspect of getting Vanilla 2 off the ground. When I first started reaching out to the community for help and advice a number of months ago, I found that almost everyone I spoke to (investors, business owners, everyone at techstars, etc) went a step further to say that having a business partner (or partners) isn’t just a nice-to-have, but really is a must-have if you want to be successful. There is simply too much work for one person to do all by him/herself, and your chances for success increase immeasurably with partners.

When I began to think seriously about what I would look for in a business partner, there were three criteria that were absolutely necessary: commitment, knowledge, and trust. The first two: commitment to the project, and knowledge (either in programming, finance, or marketing) are pretty easy to find. I can look at any of the big names (I’m not going to name names) from the Lussumo community and they fall into that category. But the third requirement, trust, is a lot harder to find. Trust can only be gained over time interacting with someone. This really limited me down to friends and colleagues that I know and/or work with in-real-life. The list was short, so I started contacting those people to see if they had any interest in joining me for this journey.

At the time of this writing, one of my oldest friends and work colleagues is weighing out his options, but it looks like he is going to come on board and help me get this thing off the ground. He is a programmer (he actually used to be my boss when I first started programming many many years ago), and will bring a great deal of knowledge to the table in many areas beyond just the code. That being said, I am still open to considering other people from other skill sets (finance & marketing, preferrably) who might be interested in speaking about the road ahead for getting Garden & Vanilla 2 off the ground and into the world of making money. So, consider this an open call to anyone interested to drop me an email and see where it takes us (mark at lussumo dot com).

Next

The coming weeks will be hectic as I forge ahead with new work contracts, head out to Boulder to meet everyone at TechStars, and frantically try to get the remaining work done on the framework and Vanilla 2 in whatever spare time is left over. I was hoping that there would be a beta online already for people to play with, but it just doesn’t seem to be in the cards yet. All I can say is that I’m doing the best I can with the limited amount of time that I’ve got, and I’m sure the same goes for all of those people out there who are jumping in and helping with various other parts of the launch (you know who you are).

Keep your syndication compilers pointed at this blog and I’ll post anything new as it comes to me!

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.

Vanilla comes with a bunch of different modules as well, like:

BookmarkModule: contains a sidebar-sized list of discussions that the user has bookmarked.
CategoriesModule: contains a sidebar-sized list of categories, with the currently-viewed category highlighted.

There are actually a lot more modules than that, but I don’t want to give too much away about the new functionality in Vanilla.

How Modules Work

As previously stated, modules really only have one purpose, and that is to return a string which can then be added to an asset container and placed in the page. All modules are extended from the base Module class, which is an implementation of the IModule interface. The interface is quite simple:

interface IModule {

   /// <summary>
   /// Class constructor, requires the object that is constructing the module.
   /// </summary>
   /// <param name="Sender" type="object">
   /// The controller that is building the module.
   /// </summary>
   public function __construct($Sender);

   /// <summary>
   /// Returns the name of the asset where this component should be rendered.
   /// </summary>
   public function AssetTarget();

   /// <summary>
   /// Returns the xhtml for this module as a fully parsed and rendered string.
   /// </summary>
   public function FetchView();

   /// <summary>
   /// Returns the location of the view for this module in the filesystem.
   /// </summary>
   /// <param name="View" type="string" required="false" default="The name of the module">
   /// The name of the view to search for. If not provided, the name of the module (minus "module") will be used.
   /// </summary>
   /// <param name="ApplicationFolder" type="string" required="false" default="The application folder of the controller that built this module">
   /// The application folder that the view should be found within. If not provided, the application folder of the controller that constructed this module will be used.
   /// </summary>
   public function FetchViewLocation($View = '', $ApplicationFolder = '');

   /// <summary>
   /// Returns the name of the module.
   /// </summary>
   public function Name();

   /// <summary>
   /// Returns the module as a string to be rendered to the screen.
   /// </summary>
   public function ToString();
}

Modules can be added to the page in a number of different ways, but the easiest way is to use the base controller class’ AddModule method. Modules do not even need to be instantiated before being added with this method. If the name of a module is provided, the method will handle creating an instance of the module class and calling it’s ToString() method in order to get the module’s xhtml and add it to the appropriate asset container (as defined by IModule::AssetTarget()). The Controller::AddModule() method also gives you some extra control by allowing you to override the default asset target of the module. That method is defined as:

/// <summary>
/// Adds the specified module to the specified asset target. If no asset
/// target is defined, it will use the asset target defined by the module's
/// AssetTarget method.
/// </summary>
/// <param name="Modules" type="mixed">
/// An instance of a module or the name of a module to add to the page.
/// </param>
public function AddModule($Module, $AssetTarget = '') {}

Some modules might be as simple as returning a static string of xhtml (like a “New Discussion” button for the sidebar in Vanilla, for example), and others might need a lot more information or have a number of different methods which allow developers to manipulate them before returning their xhtml (like the MenuModule, which allows you to add different menu options based on a myriad of criteria, like permissions, session state, etc). So, in some cases you may want to instantiate a module and then fire an event so plugin authors can manipulate it before rendering, and in other cases you may just want to call the controller’s AddModule method with the module name as a parameter.

Any module you create can do anything you want, and you can add as many different properties and methods to it as you like to suit your purposes. As long as it is extended from the Module class and contains the methods defined in the IModule interface, it will function properly.

Theme-ing Modules

Of course it may be necessary for theme authors to edit the xhtml of a module. Depending on the complexity of the xhtml returned by their module, module authors have the choice of creating a view and placing it in their application’s view folder (in a “modules” directory), or not using a view file at all, and just returning the xhtml directly from the ToString method of their module. For example, here is the list of modules and their related views in Vanilla 2 (I’ve blurred the names of some modules in order to keep some of the new features in Vanilla 2 secret):

In the above image, the two short-blurred modules do not have associated views, but all of the other modules do.

Organizing Modules

Okay, so we’ve now got a way to add just about anything, anywhere, on any screen we want. How can we organize those modules on the page? For example, if I’m adding a bunch of different modules to the sidebar of the discussion page in Vanilla, how can I make sure that, for example, the “Start a New Discussion” button is at the top of that sidebar? Obviously, I could make sure that I add that module to the page *first* when I am coding the application, but what if you don’t want that button to be at the top of the sidebar in *your* installation?

I’ve created a modules.php file in the conf folder that handles organizing the order that modules appear in their various asset containers on specific pages. It is a simple associative array that appears as:

$Modules['ModuleSortContainerName']['AssetContainerName'] = 'ModuleName';

Every Controller class has a “ModuleSortContainer” property. This property allows a controller (or collection of controllers) to represent the same “container” for modules. For example, the main settings page for Garden allows you to see all of the various configuration options that are available: Application management, role management, user management, etc. Vanilla also has it’s own settings pages which appear in the sidebar menu on the garden settings pages (and vice versa). To the end user, it appears as though they are always in a “Settings” area whether they are looking at one of the garden settings pages (/garden/settings/applications, for example) or one of the vanilla settings pages (/vanilla/settings/categories, for example). So, both Garden’s settings controller and Vanilla’s settings controller use the same ModuleSortContainer name.

The AssetContainerName is really just the name of the asset that the module has been added to.

So, for example, if I want to sort the modules that appear in the panel of the discussions page in Vanilla, here is how they would appear in my conf/modules.php file:

// Discussions Panel Order
$Modules['Discussions']['Panel'][] = 'NewDiscussionModule';
$Modules['Discussions']['Panel'][] = 'CategoriesModule';
$Modules['Discussions']['Panel'][] = 'BookmarkedModule';
$Modules['Discussions']['Panel'][] = 'ThisModuleDoesntExist';

So, in order for this code to work, I would have had to define my DiscussionController’s ModuleSortContainer property as: “Discussions”. I did this in my DiscussionController’s class constructor.

With this code in place, it doesn’t matter what order the modules were actually added to the page programmatically. Furthermore, it doesn’t matter if the list contains a module that doesn’t exist (like the “ThisModuleDoesntExist” item in the list). If a module doesn’t exist, it will simply be ignored. So, this can be handy for making sure that modules which were added via plugins can be ordered regardless of whether the plugin is enabled or not.

Conclusion

My goal is to eventually have a page in the Garden settings area where you can drag & drop your modules to order them on the various pages they appear. I don’t think I will get that far for launch, but you never know. It will definitely come later if it doesn’t make it into the launch code.

Furthermore, I’d like it to go so far as allowing administrators to grab modules from a toolbox and drag/drop them to different pages so they can do things like: add an editinplace module to the header of a page and throw a banner ad in there, or add a “WhosOnline” module to their main homepage, etc.

One final note: I briefly considered calling them “controls”, but I didn’t want people to confuse them with controls from Vanilla 1, as they are different beasts entirely. In the end, “module” was the first word that came to mind.