
Our first product pending release released! is the Webiva content management system, a CMS that we have used internally and with clients for the past three years, and which we are gearing up for a large-scale public release. This is a system that has been developed from the ground up for use by web development companies to create custom designed, professional websites that look and operate exactly the way that you want them to.
Webiva has been extensively internally tested over the past 3 years - we and our partners have used it to build over 80 different websites, ranging from simple brochure websites to full-featured e-commerce and social networking sites. We've "eaten our own dogfood" and have adjusted and tweaked whenever necessary to make sure the entire process of developing, deploying and maintaing a website is as streamlined as possible without sacrificing one ounce of flexibility.
While no software system is a silver bullet, Webiva has been developed to be a modular, extensible system that can accomodate almost any piece of functionality, and new modules are being added and refined all the time.
The open source site at www.webiva.org
The community site is at webiva.net
A Unified content system has finally come to Webiva. This is obviously a little different from a lot of other content mangement systems (Cough..Drupal...Cough) which start with a centralized content system and add specificity from there. The downside to what we've done is that getting a unified view of all the content in the system was difficult. The advantages, however, were also pretty solid - since each content model could be developed on it's own it was easier to create and work with from both a user and a developer perspective.
From the developer perspective - create an ActiveRecord model, drop in a management interface and the sky's the limit in terms of what you can do without worrying about any restrictions your CMS is putting on your data model or DB queries. You get to go straight to the metal (or whatever the equivalent is in Rails - tin foil?) From a user perspective - both for a front end user and for a site admin, since each content model defines it's own paragraphs and site features each can be customized according to it's needs. Custom fields, ID's permalinks, custom relationships to other models. All without worrying about the CMS.
The downsides to this, however, as have already been mentioned, could also be restrictive. No sitewide search (Google did fine in a pinch), no unified sitewide rss, no easy toggle between front end and content editing.
Well, as of this weekend that's all changed. A content node architecture has slowly been added to the backend of the system over the past few months, and now it's finally been exposed. The first sign you'll see is the search bar that's in the top right corner of the backend (easily accessible via a Alt-S shortcut key - we're saving Ctrl-S for file saving). This search bar acts as a unified content search for the system. Type in a keyword and the system will run a mysql fulltext search on your content and return a list - either in the form of a autocomplete that jumps right to the page you want to edit or with a full search page that shows some more details about your content.

As an added bonus we've added in a little Domain-specific-language (I love those) type feature with a plugin architecture that can be extended by modules.
What this means is that from anywhere in the backend you can type:
(Alt-S) member:frank
And the autocomplete will show you the first 10 members that match that name. Select a member, press enter and you'll jump right to that members details. A Similar feature is available for edit: to jump right to a page on the site.

The second nice feature that this adds is the ability for paragraphs to register themselves with the system, so paragraphs can alert the system that they are displaying a certain piece of content (like a blog post) and in doing so enable a function on the front end of the site that lets editors jump right to the editor page of the piece of content being displayed.
And the good news? Since the centralized content system was added late in the game and slowly with a lot of planning and forethought - it's both easy to add to your models and completely optional.
class MyModel < DomainModel
content_node
...
That content_node class method adds content node functionality to your model (there's a separate call for content types), and models can continue to be saved with the standard AR methods - although an additional save_content method is added that lets you add in the saving user if the model doesn't include it already.
Once this code is in and tested - the next step will be adding support for a real search engine (I'm with you - mysql fulltext doesn't cut it - we're leaning towards sphinx at the moment) and exposing the search functionality on the front end.
Couple new features made it into GIT today - support for Page Groups and File Folders. Page Groups allow you to easily group similar pages together without adding anything to the page path, making it easier to keep your site tree cleaner by moving old pages or little-used pages into groups. Stuff like promotions, account management, etc the you don't need to access all that often will live happily in a group.
The second feature that was added was support for linking entire folder or files onto your site tree with a file node. These existed before for individual files, but now allowing a whole folder to be accessible makes it a lot easier to keep a consistent, simple url for important files that you want to expose on your site.

Wow, release engineering ain't easy, thank the flying spaghetti monster for Virtual Machines. While I have no illusions of being able to create the perfect installation documentation the first time around, my goal was to pick a popular platform - Ubuntu 8.10 in my case as it's my Desktop platform - and make an installation script that would handle most of the painful nitty-gritty for getting Webiva up and running.
If I hadn't been able to boot up a fresh VM with a clean version of Ubuntu I don't think I would have ever come up with something that was workable, as each time there was a manual step I forgot to add in or a step of the install that I needed to run manually.
The good news is that something that was originally a fairly painful manual process involving setting up databases, adding DB user permission, updating .yml files, and running a few different rake tasks in the correct order, now boils down to:
All the necessary Gems are frozen, including Rails, so there's no need to install extra ruby libraries (the quick_install.rb script runs a "rake gems:build:force" to rebuild all the gems that need it) All you need to feed into the installation script is the name of a your mysql root user (or are user with similar permissions) and the script will generate all the necessary configuration files, DB users and an initial website database to muck around with.
First and foremost multi-file selection that allows you to use both the keyboard and the standard drag rectangle to select more then file at once. Very useful for moving or deleting a whole bunch of files.
Second big change was adding in details for the selected file. This makes it easy to see who uploaded the file, when and any revisions that the file has gone through, including name changes. The details block integrates with the handler system so module can add in different details and operation that can be performed depending on the file type. Also added in an editor for text files that makes it easy to modify text and source files that are pulled the site
Third big change was a complete revamp of the list view - it now looks a lot nicer and has more detailed about the size, type and creation date of the file.
Last addition was adding an a search. Just click on the search tab at the top and type in any part of the file name get a list of results. Click on the file to automatically jump to that file in the file manager.
Quick video below shows these things in action:
While it might be slightly overwhelming the first time you see it - I tend to prefer slightly subtler palettes - it quickly becomes very comfortable to work with. The reason for this is that your mind has an easier time remembering where stuff is if it has some additional cues - spacial cues, color cues, size cues, etc. We are creatures of habit and by putting our mind in a comfortable and consistent visual framework it makes it easier to put it in the correct context for remembering how to do what we need to do. That's why every page in the backend (excepting the in-page editor) has a specific color associated with it as well as a consistent layout and set of bread crumbs, as giving your brain an extra little help will hopefully result in increased productivity.
As an example - I have a few different financial websites that I log into on a general basis, and because I'm slightly privacy paranoid, I don't have any of the passwords memorized by my browser. I've been logging into the same 5 websites for at least past 4 years and I never have to think twice about what username and password I need to use. Except when every couple of years one of the sites will change it's design, layout or login page. Suddenly I have absolutely no idea what credentials to use. In my mind my username and password aren't keyed to the name of the financial institution, they are keyed to the site itself. When the site changes, my mind suddenly gets all confused - it doesn't know what to do - I usually end up having to reset my password.
So, the next time your trying to figure out where that one page you were looking for was in Webiva, just try picturing the color of the page in your head, and that should at least give you a head start.