Run through the history very quickly. Don&#x2019;t want to dwindle on the past, but it&#x2019;s always good to remember where we&#x2019;ve been. Talk about Boss Ogg (30 year old Americans who had a TV will get the reference). Talk about MPD, switching projects, and being tasked to find a CMS. Talk about doing the same thing everyone else does, blow a weekend installing CMSs.
Brilliant Idea. Roll your own. Sure, not like anything else was going on...
Not exactly mind blowing, but it&#x2019;s a start. But here&#x2019;s the amazing part. Look at the template editor... (next)
Notice anything familiar? That&#x2019;s the part of the system that I find so amazing. Even though we&#x2019;ve come so far in the past 5 years, the fundamentals created in those first 2 days have stuck. Sure, the code is totally different under the hood, but the concepts remain. I love that fact.
1.0 was nothing exciting. It was a first step, and that&#x2019;s all. From there, the system and community grew organically...
Geek Moot '09 -- Keynote
CMSMS: Past and Future
26 Sept. 2009
Ted Kulp, Shift Refresh Inc.
Who am I?
• 10 years development
• 12 years in Open Source
• Creator of CMSMS (2004)
• Creator of Silk Framework (2008)
• <plug>Started Shift Refresh, Inc., professional
support and services (2008)</plug>
A Brief History of Time
(in relation to CMSMS)
2004-2009 and Beyond
Why 2.0 didn’t happen
• Overly ambitious for one release
• Relied on a php version that was still too
• Not an issue anymore
• Too self controlling, which caused:
• Lack of involvement from the other devs
• 2.0 - Q1 2010
• PHP 5.2
• jQuery w/ UI and integrated AJAX
• Module API modiﬁcations (using ORM for objects)
• Module API smarty tags (Less php, more smarty in your modules)
• Centralized module templates
• Drag/Drop page admin
• MicroTiny WYSIWYG standard
• Tree based page permissions
• Complex content types (think: CCK)
• More separation of pages and content
• Admin panel smartiﬁcation (Mostly themes,
some admin pages as well)
• FTP Based module installer and upgrade
• Multi language
• Support for multiple content per block
• Allows for a default language for overriding when
a secondary language’s content box isn’t ﬁlled in
• Allows for alternate page titles and menu text
• API methods to allow modules to hook in their
text as well
• Too many ways to do this, some of which would make for a coding
• Most people want it (we think) for upgrading sites quickly -- In-admin
upgrades (in 2.1) solves this issue
• Have some ideas on how to do this, but it would require some real
fancy interface design. Might work better as a module
• Would like to have some kind of API for modules to use, which
would require a lot of generic serialization handling
• Might work better after the complex content types are up and
• Front End User Integration
• This will happen, we’re just not sure where it ﬁts yet.
• The main issue is that FEU adds SO much functionality, though
we’d want our users to be more generic. This would require
add-on modules to tack on the existing FEU functions.
• Silk Framework
• Going to require PHP 5.3
• Going to require more hacking up of the admin panel to write
it as a “Silk App”
• Will happen, but post 2.2