« HS-CMS documentation home

Introduction

Benefits of HS-CMS

  • It is pretty great at caching.

  • HS-CMS supports multiple, separate websites in just one installation, unlike Wordpress and other systems. This means upgrading your HS-CMS installation is a one-shot deal across your sites (if they are on one server). (Of course, you could have a 1:1 relationship between HS-CMS installations and sites, but that seems like a waste of space for typical usages.)

  • It is kind of like glue for any systems you also want to have running.

    • Representatives are like pages that redirect to a URL not managed by HS-CMS, but they can have descriptions, tags, and more, and can show up in HS-CMS generated indexes, navigation menus, and RSS feeds.
    • Supports apps which are theoretically written in any framework or system you want, or none at all

  • Database-system independent (if ADOdb supports your RDBMS, like MySQL, Postgres, Oracle, MS-SQL, and more).

  • It is flexible and does not force any URI conventions on you, but supports whatever you are trying to do.

(See below, the "How HoganSystem...goals" section, for more)

Inspiration and Goals

The HS-CMS is inspired by two main things.

  • Mike Purvis' "The Perfect CMS", which discusses a system in which multiple software packages get along peacefully under one umbrella or roof. The concept is called "bridging" and essentially you should be able to house a core CMS, (say) Wiki software, a photo gallery, and more under one site, fairly seamlessly. He describes it like this:

    What if a package could create a seamless user experience without modifying the source of the other programs? ... The entire CMS is JUST user-management. All it stores is users, usergroups, and who belongs to what group.

    Then, “bridges” are written that make this ultra-light CMS attach to other pieces of software. So if you want a bulletin board, you install PunBB or phpBB in the /forum directory, and then add the appropriate bridge to this system.

  • Alan Hogan's "The Perfect CMS", which lists two driving principles of a perfect CMS:

    1. It’s my site. I want total control.
    2. It should be easy to use.

In summation HoganSystem CMS has three driving principles:

  1. Complete power and flexibility. It should be easy to add functionality.
  2. Fantastic documentation (I hope!) and a newbie-friendly attitude.
  3. Plays well with others.

You'll note that #3 is a subset of #1, but is an important point nonetheless.

Also, we don't require bridges. There are other ways of interacting with other apps, especially if those apps don't require users (as in log-in functionality). Bridges are in the game plan, though.

How HoganSystem meets its goals

We haven't met our goals completely yet, but we're headed in the right direction.

  • Support for pages and whole apps which are NOT part of our system
    • "Representatives" stand for pages which are not part of the HoganSystem installation or, possibly, not even hosted with the same domain name; this enables those pages to be included in things like navigation lists, sitemaps, and tag searches!
    • Apps are sort of similar, and may run using HoganSystem framework stuff, or could actually be running in any language/framework (Rails/Python/Django/PHP/Perl... Java... C... whatever) – the difference is there is some two-way communication between apps and your HS-CMS site. For example, HS-CMS could dictate to your app what the app's root URL would be, and the app could report to HS-CMS on what pages it contains (again, for sitemap/searching/nav purposes). (This isn't fully implemented yet.)
    • (Future) Bridging architecture, hopefully...
  • Flexibility is gained by allowing the painless addition of content filters (e.g. support for any markup syntax) and custom libraries at either the HS-CMS installation level or the site level.
  • Many "core" functions are really just there for convenience and can be replaced. For example, the comments module – you don't want to do comments our way? Ok, pop in another comments handler and change a line in your site config file.
  • Documenting everything as the project develops. Documentation for everything, without drowning newbies in too much reading.

Additional thoughts, and comparison with Rails, etc.

Many modern web frameworks boast that they favor "convention over configuration" or that they force users to do things in one particular way.

Well, as my 10th-grade English teacher Mr. Miller used to say, "homey don't play that game." That is, that's not how we do things here.

Naturally a lack of structure and convention has drawbacks. With, say, Rails, there is typically One Right Way to do something, and so another developer can guess what you've done without messing with documentation. Here, you're responsible for documenting anything crazy you've done. You can totally mess stuff up if you really wanted too. Yet this system has some huge (in our eyes) benefits. We allow customization of everything, without necessarily having to learn a whole approach to programming or figuring out how to ditch a framework's default modus operandi.