blog

Rapid Prototyping with SilverStripe & Foundation

Wed, 29 May 2013 09:12:47 +1200

Guest blogger Ryan Wachtl is an independent US-based web developer and information architect with a passion for the art of programming and the science of design. He has been building sites with SilverStripe since the early 2.2 release and organizes the SilverStripe user group in Madison, WI. You can stay in touch by following @ryanwachtl on Twitter.

Fixing an Outdated Workflow

I think by now we can all agree that the traditional web project workflow, going from planning → wireframes → Photoshop comps → HTML/CSS/JavaScript → CMS integration → launch, is outdated and broken. It’s a comfortable and controlled workflow that relies heavily on hand-offs and sign-offs. The recently heightened focus on designing around content, designing for an ever growing device landscape, and emphasizing the quality of the user experience has led to the demise of this workflow.

Unless you have unlimited resources it's impractical to invest in wireframes that try to cover desktop, tablet, and mobile (and all the variations in-between). The same logic follows for design comps. I’ve also seen my share of lorem ipsum laden design comps that initially look great, but quickly fall apart when put into production and real content is “plugged in”. And finally, it is extremely difficult to convey interaction in static wireframes and PSDs. To get around these problems and build better solutions, I’ve come to rely heavily on rapid prototyping.

Rapid Prototyping to the Rescue

Rapid prototyping, or wireframing in code, is the process of getting your layout, content, and navigation into HTML that you can view, interact with, and test on real devices. The HTML prototype essentially replaces static wireframes and design comps. The key to successful prototyping is being able to get it into production fast and iterate on it easily.

Enter SilverStripe

I’ve adopted a workflow that combines three amazing open source projects that make prototyping not only fast, but also fun. Let’s start by taking a look at my toolbox. It’s rather minimal, but very powerful. And aside from the cost of some pen and paper, it’s all free!

Wachtl’s Rapid Prototyping Toolbox

Pen and Paper
SilverStripe
SilverSmith
Foundation
A Web Browser (usually Chrome, due to the ubiquity of Webkit)

My Workflow

After a thorough discovery phase and understanding the goals of the stakeholders and end-users, I focus on the structure and skeleton of the website or application (terminology borrowed from The Elements of User Experience by Jesse James Garrett).

Structure (IA)

Sitemap
Page Description Diagrams and User Flows
Content Templates and CMS Fields

Skeleton (In-browser Design)

Navigation and Content Discoverability
Responsive Layout
Test Usability and Device Experience (think ahead, plan for variations)

Structure

I begin by taking a close look at the structure of the content from two different angles. The first angle is figuring out how the content serves the business and user goals of the project, the second is how to craft the CMS in a fashion that will reduce the friction involved with managing content entry and maintain the integrity of the design. I use page description diagrams to prioritize the content on a page and sketch out any major interactions in the form of user flow diagrams or story boards.

A closer look at SilverSmith Fixtures

Using the fixtures feature in SilverSmith allows me to iterate on my sitemap quickly and with ease. If you’re not familiar with SilverSmith, it’s a fantastic CLI tool built by Uncle Cheese that features generators for SilverStripe project code, templates, and content. SilverSmith will take a _fixtures.txt file and build out a site tree from it. At this stage you can just edit your _fixtures.txt file and rebuild to test different navigation and content organization schemes.

silversmith build-fixtures

Once satisfied with the sitemap I can let CMS editors in to start entering real content. Seeing the actual content in the prototype allows me to break it apart into smaller chunks (for the CMS fields) and increases the value of the prototype.

Skeleton

One of my recent works is the SilverStripe Foundation theme. A theme that I use for rapid protoyping and ocassionaly building entire sites out. It's the fastest way to get up and running with the Foundation CSS Framework in your SilverStripe project. It uses Sass, but has no other requirements to modify. Add Compass or Bourbon to complete the mix, or just roll with it, as is. The theme gives you access to most of Foundations typography classes from within the class dropdown in the HTMLEditorField and it works best when paired with the Foundation Forms module. You can view a demo of the Foundation theme or grab it from Github.

SilverStripe Foundation Theme

A closer look at Foundation

The beauty of the Foundation framework lies in the ability to work almost exclusively in HTML. No jumping between template, CSS, and JavaScript files. Features such as modals, tabbed sections, and device visibility can be spun up by applying classes to your markup. While not necessarily the best approach for a production site, it works perfectly for experimenting with layout and interactions across different devices. For example, the following markup is all that is needed to code a functioning modal.

Beyond the Prototype

So, where to from here? A visual design process can be run in parallel with prototyping. I recommend using a process like Style Tiles. Style Tiles are a design deliverable consisting of fonts, colors and interface elements that communicate the essence of a visual brand for the web. The perfect companion to a responsive website prototype.

Additional Resources

SilverStripe Modules

I’ve only scratched the surface of SilverSmith and Foundation, you really should check them both out and see if they can find a place in your own workflow. In addition to utilizing those two projects there are a handful of other modules that I have come to rely on heavily for both prototyping and production SilverStripe projects.

UserForms (Github) (Packagist)
FoundationForms (Github) (Packagist)
UserTemplates (Github) (Packagist)
HTMLField (Github)
CustomMenus (Github)

Prototyping and In-browser Design

On to “The news!” - News via the ModelAdmin

Wed, 08 May 2013 17:03:44 +1200

Simon 'Sphere' Erkelens is a freelance developer, fulltime employee of We::Code in the Netherlands with a tertiary background in applied physics. Before that, Simon worked for Squal Media. He started using SilverStripe at the end of 2009. Simon has given multiple presentations on implementing Facebook API into PHP and on SilverStripe's lesser known features. Most of his personal development work is on Github.

I only develop core features. I'm not a front-ender of any kind. And if I have to... well, look at my website. As simple as possible.

On to... “The news!”

This news-module is compatible with Silverstripe 3.0.1 up to version 3.1. I wrote it because I got fed up with two things; first, was my own website, second was the most widely used blogmodule. It clutters the SiteTree, making it one big, confusing mess. These two factors encouraged me to write a slimmed-down version of a “news-in-the-sitetree” module.

The module is fully managed from the ModelAdmin. The downside of this decision is I had to make a sacrifice. The module does not track changes in the content. To make sure articles that have a new title still work, included is a Renamed-object, which tracks the changes of the URLSegment, but that's it. This decision, was to keep it a bit more “simple”. Mainly because news is usually just edited to fix typo's, not to fully change.

The news can be setup via the SiteConfig, where Twitter and Facebook (I think Facebook works) can be set up. Although those features require another module of mine. Also the amount of posts-per-page, comment-settings etc can be setup via SiteConfig.

Requirements are in the readme on my github page. Feel free to include anything from the readme config section here if needed/wanted.

Featured is comments on items. The comments are set up with a double anti-spam measure. First, there is the akismet protection as primary. But second, the well known "out of screen" input helps to prevent spam by having an invisible field for normal users, by positioning it absolute at -90000px or something. Spambots, however, do see the field and enter text in them. Entered text means it's a spambot.

Included are several shortcodes, like YouTube, Twitter's official "tweet" implementation, GeSHI code-highlighting via third-party libraries. These can be activated (globally!) or deactivated via the _config.php:

ShortcodeParser::get()->register('tweet',array('NewsHolderPage','TweetHandler'));
ShortcodeParser::get()->register('code',array('NewsHolderPage','GeshiParser'));
ShortcodeParser::get()->register('YT',array('NewsHolderPage','YouTubeHandler'));
ShortcodeParser::get()->register('slideshow', array('NewsHolderPage','createSlideshow'));

And addressed with, for example, [tweet id=326829146376388608] (You can find the ID by clicking the post-date and look at the URL. The full URL is accepted as well and will be split by the code to get the actual ID).

Besides that, there's also an option to create tags. A tagcloud javascript is included to create the tagcloud.

Newsitems are globally addressable with the Controller Extension, with a lot of options on what to show. Random, latest, latest related (via the tags) etc. The items all relate to a Holderpage. This holderpage can be translatable. By creating translatable, a new dropdown appears to set the language of the newspost. Possible future features might be to change the "only on one page" to "link to multiple languages", since English is quite widely accepted.

Furthermore, the post can have a publish from day X, which will then be preferred over the Created date. LastEdited is explicitly ignored in this case. Because often, a LastEdit just means a fix of a typo, no radical changes to the content.

Finally, there are reports. In the SS3 CMS, you can see the Tag-usage and comment-counts on the items created. This includes, for example, spamcount if you have Akismet enabled. Akismet comes included as a third party.

Upcoming is a report with the newsitems that don't have any tags linked. But I have not gotten into that yet.

Examples and more information can be found here:

Github repository: https://github.com/Firesphere/silverstripe-newsmodule
Contact: simon@casa-laguna.net

Improved Config API and secure default template casting in 3.1.0-beta3

Mon, 22 Apr 2013 08:59:38 +1200

We're proud to release our third beta of SilverStripe 3.1 (download), which gets us very close to the Release Candidate (RC) stage. Compared to previous beta releases, beta 3 has seen some large but unavoidable API changes. Please ensure to read the changelog and upgrading guide. You'll need to at least rewrite your static declarations in your Page and Page_Controller classes (incl. custom subclasses). Also, check that any used modules are compatible with the new beta. The easiest way to manage those dependencies is an installation through Composer.

The "old way" of setting configuration through static properties or methods at runtime has been deprecated with 3.0. The YAML-based Config API which replaces it has not seen widespread use though. This changes now, with most core configuration only accessible through this API. In order to enforce this change, the visibility of statics has changed to "private", which will throw errors if your codebase accesses those directly. The Config API helps us to provide a faster and cleaner bootstrap process, since less PHP files need to be autoloaded.

In order to reduce the chance of accidentally allowing XSS attacks, the value of $default_cast has been changed from HTMLText to Text. This means that any values used in a template that haven't been explicitly cast as safe will be escaped (< replaced with < etc). Please check your controllers and templates to see if this affects you.

On the CMS front, we're only adding a little polish. The pages list view is now more useful since it remembers the open tab and URL, meaning authors can use it as their default view. We've also added a "Show children as list" context menu in the tree to easily switch, and make it more feasible to manage large flat structures, such as blog entries without requiring interaction with the tree.

We hope you enjoy beta 3!

SXSW 2013: A Mixed Bag

Tue, 26 Mar 2013 14:41:53 +1300

Richard is a designer/developer/strategist/coffee addict/Twitter junkie/slash/slash/slash. He's been working with SilverStripe since 2009 and runs his own company design + awesome. In 2012, Richard blogged about OmniOutliner to SilverStripe. Find him on twitter @thezenmonkey.

Every March, tens of thousands of filmmakers, marketers, designers and musicians from around the world descend on Austin, TX for South By South West (SXSW). What started as a humble music festival has grown into a city-wide event crossing industry and cultural boundaries.

Lee Blazek (@surfjedi) and Richard Rudy (@thezenmonkey) - two SilverStripe developers from opposite sides of the globe, met in blur of jet lag and daylight savings.

The breadth and depth of this conference can be overwhelming for first-time attendees. Multiple simultaneous streams covering marketing, social media, music, film, design and development across multiple industries is enough to make anyone's head spin; and that's before you include workshops, networking events, concerts, parties and lounges. Where else can you see Nick Cave talk about his childhood, then go to a demo of Google Glass, followed by an in-depth HTML5 workshop or a panel with Joss Whedon, and close your night with a party featuring Deadmou5, Vampire Weekend or Prince?

Highlights

Google Glass Will Change the Way You See Things

Beyond the obvious amazing things that can be done with a wearable heads-up-display, the Mirror API allows devs to directly interact with RESTful services, meaning your SilverStripe sites and apps can easily be integrated. How cool is that!

Google Art, Copy Code - Bringing the Hacker to traditional Art Director/Copywriter team

Google has partnered with advertising agencies to bring a whole new level of personalization and relevance to the advertising. Right now, it's just a series of experiments and an app they developed in partnership with Volkswagen, but they demoed a talking shoe (no, Google is not getting into the shoe business) that uses accelerometers and GPS to track the user and give feedback. The lazy version complains if you walk to much, while the active one doesn't want to sit still.

One of the more interesting demos was the dynamic video that pulls current location and time of day to generate a video with live time, weather, plus footage of up-to-date feeds from a variety of sources. Notes from the talk are posted on Rick's Tumblr.

LEAP Motion

This product may be less relevant to web developers, but LEAP Motion had live, hands-on demos of their 3D motion tracking device. Imagine playing Fruit Ninja by swiping your finger through the air or manipulating 3D datasets with your hands. The technology is already small and affordable; it begins shipping in May. At gen 1, it's the size of a large USB key. Just wait until they get small enough to pair it Google Glass.

Intentionally Dealing with Responsive Design with intention.js

The design technologists at Dow Jones (Wall Street Journal) have developed a javascript library that works like media queries on steroids. Its core ideals are that HTML, CSS and JS should be separate; and that content and context (device) are exclusive but need to interact. At its most basic level it does DOM manipulation based on various parameters (screen size, input type, device orientation).

This library solves one of the key issues with responsive design: document order doesn't always coincide with visual importance of items on the page. With a multi-column desktop layout, often your secondary items are in another column from your main content and therefore further down the page. When you load the page on a mobile device, that secondary item is multiple page scrolls down instead of in a position of secondary importance. Intention.js will move it to its correct space using only data attributes in the HTML.

That's the functionality at its most basic level, but it can handle dynamic resource loading, animation, feature sniffing, class rewriting and more. The best part? It's fully extensible.

This was a four-hour session and I could write a whole post about contents.

Tim Ferriss - Acquiring the Skill of Meta-Learning

Tim Ferris (The 4-hour Work Week, The 4-hour Body) gave a talk on his new book The 4-hour Chef. Cooking is just a vehicle for what the book is really about: how to learn any skill quickly. He shared what he calls the DiSSS framework. In order to master a skill you need Deconstruction, Selection, Sequencing, Stakes, and Simplification. A more detailed run-down of his talk is available here on Rick's Tumblr.

The Food or "Oh, the Places You Will Eat!"

You can't talk about South-By without mentioning the food. Austin is a great place to eat. I could write an entire post about the food.

Last year's Top Chef winner curated a Food Truck Court (South Bites) with some of the best food trucks from the region. My favourite by far was Chi-Lantro, Korean-Mexican fusion food. Their bulgogi tacos with kimchi were amazing. This year I also made it out to Franklin BBQ, arguably the best BBQ in the US. The three-hour line-up was pretty standard (and not just for SXSW) and well worth it.

SXSW was a mixed bag this year

Though there were some great tech demo's and some really interesting sessions this year, SXSW is suffering some growing pains. The media has been saying it's getting too big, and they may be partially right.

The conference spans most of the downtown core which creates a bit of logistic nightmare to a conference goer. Getting into the sessions you really want often means sitting through the one before it to ensure you get a seat, or skipping a really interesting event to get to another venue.

Is it worth the trip to Austin?

Despite logistic problems, the tendency to get overwhelmed and the uncharacteristicly wet weather, SXSW is still the go-to conference, especially if you're interested in a variety of subjects. It's a unique experience every designer, developer, community manager, entrepreneur, film maker and/or musician should experience at least once.

Tips for going

Book early as close hotels fill up fast. If you're going with a group it's often better to rent a house. (I bought my badge Day 1 and still couldn't get a walking distance hotel)
Stay hydrated
Plan your days
Talk to everyone (some of the best conversations happen outside of events)
Be flexible (have back-up plans just incase your session is full)

Web Developers do it on the fly

Wed, 13 Mar 2013 10:02:37 +1300

Russell Michell describes himself in the context of work as an absolute web all-rounder, as comfortable on the command-line as he is with the front-end. Originally from Cambridge, UK he has performed his craft for startups, academia and agencies in the UK, Australia and in the years since his first OE to New Zealand back in '99. Russell is a web developer at SilverStripe in Wellington, having joined the company in 2011.

Usually when web developers read the words "on", "fly" and "the" (usually in a different order) various tech-solutions to as-yet-undefined problems present themselves, perhaps involving near real time data processing, AJAX UI interactions or some kind of HTML5 web-socket or Node application.

But not quite in this case.

My position is that the best place to apply the thinking and techniques orientated around application and site performance optimisation is "on-the-fly" during development. The opposite of this might be understood in a more traditional optimization project; a poorly performing app or site undergoes a major overhaul, performance is evaluated and tools are deployed, code is refactored, cut down or removed, tests are run and performance then re-evaluated - rinse and repeat as time/budget allows.

As a company or an individual, possession of a legacy project requiring such a process is not necessarily such a crime. Given the rapid pace of browser development of recent years and the ever-increasing range of technologies able to be deployed to public-facing projects, it is wholly understandable - if not forgivable - that feature creep and some bloat occur without due attention being paid to performance in terms of response-times and other performance metrics. Unfortunately it is precisely this lack of attention that incurs the technical debt which ensures that the single optimisation project becomes necessary in the first place.

I have worked on some very similar optimisation projects in the past and it's that experience that I draw upon as I develop features in the stuff I work on today. I can't help but see potential bottlenecks in logic or the way some feature or other is assembled.

Arguably the first point of call in any such optimization project is to reduce HTTP requests back to the server. The ease with which AJAX interactions can be coded with modern JavaScript libraries means it's all too easy to overlook the server load they generate. Just break out your browser debugger in network mode, and watch all those XHR requests fly past. The same goes for server-side redirects which still do little to impress non-sighted web users and when under load, the webservers themselves.

So as I code I'm already thinking about whether the functionality afforded by particular AJAX controller request for example might be combined with others to kill several birds with one projectile.

Depending on a team's development methodology, developers may argue that the full feature-set needs to be built first and refined afterwards as time and budget allow. While I agree that this sounds logical; to deal to everything in one hit, it does seem unfortunate that it is also this thinking that can lead to this refining step never actually being taken, and the public having 1Mb+ homepages foisted upon them.

With HTTP I'm able to use standard browser-based debugging tools to monitor activity. However, if a feature or application relies upon disk i/o and that feature needs to function well under load, I'll likely want to look at reducing or precluding as much of this activity as possible given that writing to a disk platter is much slower than writing to memory. Recalling an old Facebook engineering blog entry, the author described the reduction of what sounded like an initially minuscule disk i/o time, to an even tinier number. Given the sheer number of requests each node in the Facebook CDN likely receives, these minute optimizations made sense when scaled-up.

Note: I'm not really advocating the use of i/o analysis tools in the application development stage (though they would do no harm), rather I'm suggesting to remain aware of an application or feature's reads and writes, and how you might code them differently.

Many development frameworks will provide developers APIs and functionality to combine and automatically minify assets requested on a page by page basis, and it behooves us as developers to be aware of these and make use of them. This is especially relevant given modern requirements for ever more complex applications with increasingly numerous CSS and JavaScript files hanging off each page request. In terms of the "on-the-fly" approach, I try not to assume that my chosen framework's automatic use of this kind of functionality precludes my having to think about what I'm writing, how I'm writing it and the context(s) under which these assets might be requested.

Less is becoming more and more in this world, and this is as true for web-development as it is for anything else, from energy and carbon footprints to localized food production and transportation.

Takeaways:

Think about performance while you work as well as afterwards. Not everyone's ISP offers the same performance as your office's T1 connection
Start by monitoring how your application or feature performs using some of the free tools listed below
Reduce HTTP requests back to the server (AJAX, redirects etc)
Study all AJAX requests, especially those that are run just for an initial page load (ie: content that could be pre-loaded as HTML by the server before the page is served).
Fish and chips for tea

Useful links:

Blog post and WDCNZ optimization talk
Steve Souders, author and speaker on all optimization-related topics: @souders
Google PageSpeed browser addon for Firefox and Chrome
Yahoo Yslow browser addon
Facebook on Disk I/O

Converting Quinn.com from SilverStripe 2.4 to 3.1-beta

Wed, 06 Mar 2013 11:24:29 +1300

Fred Condo has a Ph.D. in the Management of Information Systems and Cognitive Psychology from Claremont Graduate School, and is Chief Engineer at Quinn Interactive. Quinn Interactive is a web design & development firm located in San Francisco, California specializing in interactive design, content-management integration, IA, and custom development. Fred got into SilverStripe in 2008. He has made 24 commits to the SilverStripe framework repository, which makes him the 28th-most prolific contributor to the project. You should follow him on GitHub here.

tl;dr

We did a 2.4 → 3.1-beta conversion
We made the minimal changes required to get the site running under the new framework
Bye, Data Object Manager!
The ORM’s new fluid syntax is great (unless you forget to save the result!)
It was easy!

About our upgrade

When QI began using SilverStripe, we converted our static HTML site to SilverStripe 2.3. Over time, we upgraded to 2.4, and eagerly awaited SilverStripe 3.

We’ve now developed new sites starting with SilverStripe 3.0, and are ready to convert sites from 2.4. To prepare to upgrade our clients, we converted our own site. We also changed our make– and rsync- based deployment to something more robust, Capistrano.

We chose to convert to SilverStripe 3.1-beta, reasoning that, by the time our clients started approving upgrade projects, 3.1 would be the generally available release. We also did not want to optimize at this stage, and do only what was necessary to run under 3.1.

Converting our code base

The conversion took 91 git commits. Twelve were Capistrano-related, so 79 commits pertained to SilverStripe and code-management overhead, such as merge commits. Because this was our learning experience, we kept changes as separate commits, rather than squash them together.

Our mysite/code directory contained 2942 lines of code before the conversion, and 2820 afterwards, a reduction of 4%. Our template files had 1399 lines before, and 1366 afterwards, a 2.4% reduction.

Template changes

The new template engine is strict about include files, so it uncovered includes that referenced nonexistent files. We just removed those lines.

<% loop %> does what <% control %> once did. There is other new syntax, too.

```diff
-                    <% if ShowInToolsPages %>
-                        <% control ShowInToolsPages %>
+                    <% if $ShowInToolsPages %>
+                        <% loop $ShowInToolsPages %>
                            <% if First %><% else %> | <% end_if %>
                            <a href="$Link">$MenuTitle</a>
-                        <% end_control %>
+                        <% end_loop %>
                    <% end_if %>
```

Directives now accept `$` on variable names, and `loop` replaces `control`.

Template calls now take comma-separated parameters. Where we used a string with artificial delimiters, we now have a more familiar syntax. `$Image.CroppedImage(165x165)` becomes `$Image.CroppedImage(165,165)`.

PHP changes

Module updates

We had to update modules to their 3.x-compatible versions. This often meant importing the code from the master branch. Many module repositories were not clearly tagged with 2.4– and 3.x-compatible versions. It required trial-and-error to get some modules running.

We could eliminate several modules, because the new framework is more capable:

Data Object Manager
Uploadify
Image Extension (our internal module of image-manipulation methods; we eventually kept 2 methods—see below)

Data Object Manager by Aaron “Uncle Cheese” Carlino is popular for SilverStripe 2.x. It is not available for 3.x, because GridField supersedes it. Here’s a sample change (from a getCMSFields() method) for replacing it:

ORM changes and fluid syntax

The ORM has undergone a big overhaul. DataObjectSet is gone, and a new fluid syntax simplifies data operations. To set up paginated items, we once had to manage pagination-related GET parameters, but can now focus on our custom code. Below, we use a GET parameter only for filtering on a year. See this line:

$result = $result->filter('Date:StartsWith', $year);

We tripped over this when it wasn’t working without assigning back to $result . The new ORM returns a result rather than modifying the existing one. This works nicely with the fluid, chained syntax, but needs help when a call is conditional.

Redirection functions have moved classes

Director::redirect() and related functions have moved to Controller, and become instance methods.

Image extension

Here are the functions from our image extension that we still wanted after the 3.1 upgrade.

Wellington's February 2013 Community Meetup

Wed, 27 Feb 2013 11:31:28 +1300

Thank you all for coming along to Molly Malone's last week! The first Wellington developer community Meetup of 2013 was held on a beautiful and warm summer evening, with great attendance (approximately 60 of you made it), conversation, and presentations.

CEO Sam Minnée spoke on the upcoming user interface and developer features in SilverStripe 3.1, most notably the side-by-side editing and device preview which helps support the emerging practice of adaptive content.

Sam Minnée talks about what's new in SilverStripe 3.1 from SilverStripe on Vimeo
Download Sam's PowerPoint presentation

Developer Robert Curry then spoke about migrating websites from Drupal to SilverStripe CMS, with good humour and fact infused. The evening ended with a general Q+A session.

Robert Curry introduces the Drupal Connector Module from SilverStripe on Vimeo
Watch Robert's presentation on SlideShare

If there’s something you’d like to hear or speak about at our next meetup in May, get in touch through the comments, via Twitter and Facebook, or email brooke@silverstripe.com. If you haven't already, join our meetup.com group for regular updates. We'll be announcing the date of the May meetup soon!

SilverStripe 3.1.0-beta2 is available

Tue, 26 Feb 2013 14:59:44 +1300

Like the subject-line says, we have a new beta release of SilverStripe 3.1 ready for you all to try.

Most of the work has been on bugfixing and cleaning up APIs, so there is not a lot of new features to talk about. Instead, the beta2 release is part of the ongoing work to get SilverStripe 3.1 ready for production.

If you haven't heard about what's coming in SilverStripe 3.1, you might like to watch the recent presentation I gave covering what's under the hood.

To install a test version, you can visit Pre-release Downloads, or you can use Composer. If you already have Composer installed, you can set up a new 3.1.0-beta2 site on your computer in the directory "~/Sites/newproject/" by running this command:

composer create-project silverstripe/installer ~/Sites/newproject 3.1.0-beta2

Although installing Composer is an extra step, we think that it is the best way of installing SilverStripe, because it handles module management and upgrades better than manually downloaded files. See the Composer Installation Docs for more information.

The next release will be SilverStripe 3.1.0-RC1, which we expect to have ready late April or early May. Between now and then, we'd appereciate any feedback and bug reports that people have. Note that we're not going to be adding many new features between now and the stable release, so that we can focus on removing bugs.

OAuth Server

Wed, 20 Feb 2013 10:19:46 +1300

Simon Welsh is a developer at PocketRent, a SaaS using SilverStripe. He is currently working towards completing his Honours degree in Computer Science and Maths, and was recently a finalist in the NZOSS awards for his development efforts within the SilverStripe community. Simon has written for the SilverStripe blog before, documenting his journey of upgrading to 3.0. Follow Simon's alias simon_w on both Twitter and the SilverStripe IRC channel.

The web has moved away from disconnected sites that don't know anything about what's going on in the rest of the world. Now, almost every site that is anything beyond your bog-standard brochure site has connections to at least one other site, though usually substantially more. This can range from simple things, like using Facebook and Twitter for log ins, to more complicated integrations, such as taking payments using Stripe, recording the payment in Xero then uploading a file to SS3. These sorts of sites are said to "consume" others.

Every so often, you want to produce a site that provides information that others can consume. Say your site is selling different types of fluffy pink slippers and you'd like other sites to be able to manage wishlists on behalf of your customers.

The obvious way to do this is to build an API for your site and let other sites consume it. To make the API, you can use a pre-rolled solution like the RestfulServer module, or you can roll your own controllers. No matter which method you choose, you also have to decide on how you are going to authenticate requests to your API.

The simplest way, which is what the RestfulServer uses by default to authenticate requests, is to use basic auth. This involves sending a username and password along with every request. This approach is very easy to implement, in fact the PHP manual has a page explaining how to do it. This approach requires that the consuming service stores the user's password and any change to the user's password means the new password has to be re-entered in every third-party service. The only way for users to revoke access to a service is to change their password.

To deal with some of these problems, OAuth was developed. OAuth uses tokens to authenticate requests. These tokens are issued by the provider (your site) after a user approves the client that is requesting a token. This way, the user only ever provides their password to your site, can change their password and not have to update everything and can revoke an individual app's access by revoking the particular token. OAuth also makes it easier to associate specific information with each authentication token, such as a set of permissions that a particular user has granted a particular application.

OAuth 1.0 requires signing of all your requests in a very specific way that was difficult to get right. This is what Twitter uses. OAuth 2.0 with Bearer (or similar) only uses a unique token. Facebook uses a Bearer-like token system.

Introducing the OAuth server module

When beginning on the design of the PocketRent API, we decided to go with OAuth for authentication, specifically OAuth 2 using Bearer tokens. This was mostly because we decided that the tradeoffs of basic auth outweighed its simplicity. We picked version 2 of version 1, as OAuth 2 just seems more sane. The difficulties of signing and checking signatures in an OAuth 1 setup weren't that important in the decision making, as there are libraries for almost any language that do all the heavy lifting for you.

Our OAuth module was designed to be applied to a controller and handle all the authentication for you. This means you just need to install the module, set up scopes and applications in the CMS, give out the generated access tokens for those applications and then the module does the rest.

This module requires version 3.1 or later of the SilverStripe Framework. Due to the way PHP handles the Authorization header, support for authenticating requests using headers requires that the getallheaders method exists in your SAPI. As of PHP 5.4, this is included with the Apache and FastCGI SAPIs.

The module is available from our SVN repository, or you can download a recent zip or tarball. Installation of the module is done in the same way as any other.

Module configuration

The OAuth module comes with support for using Bearer for authentication. If you would like to use some other authentication method, you can create a class that implements the `oauth\service\Service` interface and then set the `Injector`'s `class` value for `oauth\service\Service` after the `authtokenservice` config fragment. For example, if you wanted to use the `MyAwesomeOAuthService` as the class that handles the authentication, you'd use:

<code type="yml">
name: MyOAuth
after: #authtokenservice
---
Injector:
  "oauth\service\Service":
    class: "MyAwesomeOAuthService"
</code>

The included Bearer authentication supports different length tokens (defaults to 25 characters), token expiration (defaults to no expiration) and enabling/disabling support for authentication using POST (enabled by default) and GET (disabled by default) parameters as well as headers. These can be set by setting the `token_length` (number of characters), `token_life` (number of seconds), `allow_form_body` (boolean) and `allow_url_param` (boolean) config values on `oauth\service\Bearer` respectively. To disable token expiration, set `token_life` to a negative value. For example, to set tokens to be 30 characters, expire after an hour and to disallow both POST and GET parameters for authentication, you'd use:

<code type="yml">
name: MyOAuth
after: #Bearer
---
"oauth\service\Bearer":
  token_length: 30
  token_life: 3600
  allow_form_body: false
  allow_url_param: false
</code>

Setting up the module

Once you have configured the module, the next step is to set up scopes. This is done through the CMS here. Here, you create new and edit existing scopes.

With each scope you can set:

A name, which must not contain spaces and is what clients use to request that particular scope.
A description, which is displayed to the user when being prompted to authorise the client.
If it is a default scope, that is one that is automatically requested if a client doesn't request any scopes
If it can't be disallowed, that is a user cannot refuse to give this scope to a client if it asks for it.

The next step is to set up clients. This is also done in the CMS here. Here, you can create and edit clients.

With each client you can set:

A name, description, logo and website that can be displayed to the user whenever the client gets displayed.
A default endpoint that the user is redirected to in case the client does not supply a redirect URI with its request.
A list of valid return URIs. At the most lenient, each of these must be a domain name; at the most strict, a full URI.

After saving for the first time a client identifier is automatically generated. The client use this identifier and the return URIs when requesting access to a user.

Once you've set up the scopes and clients, the only step left before your OAuth server is ready for use is to provide some endpoints for clients to actually call.

Setting up your controllers

Everything you need to require that either an entire Controller or just certain actions use OAuth is all done using the `RequireOAuth` extension.

When adding the extension to your controller, you have three options depending on what you pass as arguments to the extension. The default option is to require OAuth for all requests to the controller without requiring any specific scope. This is achieved by simply adding the extension without any arguments:

<code type="php">
public static $extensions = array(
    'RequireOAuth',
);
</code>

If you would like to allow general access to the controller, but still require OAuth for certain actions, pass it `false` as a single argument:

<code type="php">
public static $extensions = array(
    'RequireOAuth(false)',
);
</code>

The third option is to only allow OAuth-authenticated requests with certain scopes. This is done by passing the required scopes as strings to the extension. For example, if you wanted to require the `read` and `write` scopes:

<code type="php">
public static $extensions = array(
    'RequireOAuth("read", "write")',
);
</code>

Using `$allowed_actions` it is possible to further restrict specific actions to requiring specific scopes using the `requireScopes` method made available through the extension and passing in the required scopes as strings. For example, if you wanted the method `delete` to require the `destroyer` scope, you'd have:

<code type="php">
public static $allowed_actions = array(
    'delete' => '->requireScopes("destroyer")',
);
</code>

The final check the extension allows you to perform is a conditional check for a scope. This allows you to provide additional functionality inside actions if a scope is present. This is done by passing the scopes to check for to `hasScopes`. I.e.:

<code type="php">
if($this->hasScopes('read')) {
    // you can read!
}
</code>

Client process

The only thing left to do now is let clients know how they talk to you. There are three parts to this. In the first, the client asks for permission to a user. They do this by sending the user to `https://yoursite.com/oauth/authorise?response_type=code&client_id=<identifier>&scope=<scope1>+<scope2>&redirect_uri=<uri>&state=<state>`. In this URL, `<identifier>` is the client identifier displayed in the CMS; `<scope1>` and `<scope2>` are scopes that the client would like; `<uri>` is the URI to return the user to once they either accept or reject the permission request; and `<state>` is an optional state parameter. These parameters can also be sent as POST parameters.

The user is then asked if they want to give the client access to their account. If they don't give permission, then they are redirected to `<redirect_uri>?error=access_denied&state=<state>` to notify the client. Otherwise, the user grants permission and is redirected to `<redirect_uri>?code=<code>&state=<state>&scope=<scope1>+<scope2>` where `<code` is an authentication code; `<state>` is the state value passed in at the start of the request; and `<scope1>` and `<scope2>` are scopes that the client has been granted permission for.

Now that the client has the authentication code the second step is to request an access token. This is done by sending a POST request to `https://yoursite.com/oauth/token` with the parameters `grant_type` with the value `authorization_code`, `code` with the authentication code received in the previous step and `redirect_uri` with the redirect uri provided in the previous step. Assuming everything goes well, a JSON object is returned to the client containing `access_token`, `scope` and `token_type` which contain the access token, the scopes the token has access to and the type of token (in a standard install, this will be Bearer) respectively.

The third and final step is for the client to make authorised requests. This is done by making a request to one of the endpoints you set up early with the "Authorization: Bearer <access_token>" header.

For more on this process, you can read the RFC for both OAuth 2 and Bearer.

You're now set up with an API that utilises OAuth for authentication that is ready for consumption by the world at large! As always, I'm available to answer further questions and can usually be found in the IRC Channel.

Tackling project risk: How long is that piece of string?

Thu, 14 Feb 2013 11:45:25 +1300

As someone who is passionate about business, Diana has a diverse background in many industries, most notably in a marketing or project management capacity. No matter which direction she went, she was always handed a website to upgrade, create, design, or manage. She took this as a sign to head into the web industry, and has since worked as a project manager combining her knowledge of business and marketing to help clients achieve their project vision.

I’m going to start with a bold statement: Estimates are always wrong.

Unless we are talking about a very small timeframe and only a few clearly defined deliverables, a technical project is almost never completed in the exact same number of hours/dollars as was originally estimated.

It's not for lack of trying, or that someone has been grossly inaccurate on purpose. It's essentially just the nature of creation: a client doesn’t know exactly what they want, often until they see it. Similarly, a vendor often doesn’t know exactly how they will deliver the requirements until they are elbow-deep in building it.

I am lucky enough to have been both a client and a vendor on web projects. From a client's perspective, you need an idea of how much that big idea will cost, so you can make decisions about ROI, or compare vendors. You also want to have a pretty good idea as to what you will have at the end of the project - will it meet the business requirements? No one likes to throw money at a vendor and hope for the best. You are accountable to internal streams and stakeholders - often many of them. The pressure to deliver quality and value as cost-effectively as possible is, in some cases, extreme.

As a Project Manager, I have heard my clients say “heads will roll if we don’t deliver” or “my boss is expecting everything we talked about at the beginning”, more times than I can count. I’m sure that these statements are true, but they create a very stressful situation for all involved.

Having a vendor commit to fixed scope and budget gives a sense of security, however false. It gives you a contractual ‘big stick’ to protect yourself from overruns and ensures that you get what you pay for. All of this is perfectly understandable and reasonable. I get it. Clients often wonder why vendors push back on signing up for this. Fixed scope and fixed budget gives vendors no room to move, so why would they?

Let's look at the other side of the coin.

From a vendor’s perspective, when presented with scope from a client, they are actually being asked ‘how long is a piece of string?’.

I have been involved in meetings that have gone like this:

Client: ‘I want a website’
Me: ‘Okay, what type of website are you thinking?’Client: ‘I dunno, maybe like YouTube, but better. That went well for them.’
Me: ‘Um, okay, YouTube was created and built over several years, and cost them many millions of dollars. Is that what you have budgeted?’
Client: ‘But I thought you guys were open source - surely you could do it for less than $50K?’

I’m sure you get the idea. Without knowing how long some things can take to develop in reality, the expectations of client and vendor might not be just in different ballparks, but different states! The art of a good site is to make it look simple and easy. In reality, it may actually be hard, time consuming and expensive to get to that point.

When my team look at a feature-set to estimate, many parameters are taken into account.

First up, and most telling, is our experience. If we have built something similar before, we can make some pretty good assumptions. If the business requirements are well defined, we can make even better assumptions. If it explains the acceptance criteria, or what ‘done’ looks like, even better. We think about how long we might think it would take us to complete, if it went well. Then, we ask ourselves how much longer would we need if everything hit the fan. Based on the risks around the feature at hand, we consider what would be the most likely scenario. This gives us a range of time or effort required to give the client that feature. We usually supply the assumptions and risks to the client to validate these are actually right. If the assumptions are incorrect, then it's back to the drawing board.

So now the client has a range. And with that, a dollar value. This might be a small range, or it might be ±200%: it all depends on how much detail we have about the features required. For example, I can say to you right now, we can build you a website for somewhere between $15K and $2million. Of course, what you get in that website will vary wildly.

If a client needs a more accurate estimate, then the detail needs to be more accurate. Even so, you can only go so far down that road - there will always be ambiguity in projects of any kind. I have watched as Business Analysts have written 150-page Functional Specifications for one feature of a site, thinking that this would give accuracy and clarity, and mean that changes won’t be required, only to have it fall over on day one, when some basic assumption is proven incorrect.

We all need to agree on one thing: an estimate is a baseline to start a project, based on information and risks we understand on day one. On day two, it will change, and day 12, and day 50, with many other days in-between. As far as I know, no one can foretell the future, and as a big risk management person, the best you can do is:

Plan for the worst case,
Hope for the best case,
Identify where any change is likely to come from,
Mitigate those actively as you traverse the project timeline,
Be honest,
Make good decisions based on all you can know at the time, and
Have a contingency plan/budget for when the thing you didn’t know was coming hits you.

Be prepared to change everything. Always reassess what you have done to date, and whether what you plan to do next will still add the business value. If not, change the plan until it does. Accept that you don’t know what you don’t know, until you do. If a client and vendor can work openly and honestly with each other as a team, keeping an eye on the original goal, then you will have a successful delivery.

Clients - cut vendors some slack. Estimates are always educated guesses, and the accuracy of that guess depends on you, and the experience of the team.

Vendors - realise there is more at stake than just getting a project signed up. There are business outcomes and KPI’s relying on you to not screw this up, so be upfront, show them the potential worst case. It’s better than pretending it will all go swimmingly. And then, at the end of the project, you can then tell them how long the piece of string was!

SilverStripe selected to build Common Web Platform for New Zealand Public Sector

Thu, 07 Feb 2013 15:43:44 +1300

Today we are proud and excited to announce that we have been selected by the Department of Internal Affairs to build the Common Web Platform for the New Zealand public sector.

To do this, we are building a Platform as a Service version of SilverStripe CMS targeted specifically at the needs of the New Zealand public sector. We are working with Revera, making use of their Government Infrastructure as a Service, alongside the set of open source tools that provide the best environment for creating and hosting SilverStripe websites. Development of the platform is already underway.

As well as being a great validation of our product, we see this as an opportunity to help push the envelope in the way that the public sector can make use of the web.

For more information about the Common Web Platform, please visit the ICT website. If you are from an eligible agency and are interested in making use of the Common Web Platform, please contact DIA directly.

Cross-posted from silverstripe.com. For more information, please visit the media release.

Drupal Connector Module

Wed, 30 Jan 2013 09:26:24 +1300

Robert is a SilverStripe developer who cut his teeth on computer games, first hacking them together between classes at uni and then professionally at Sidhe Interactive, where he worked on games for the PlayStation2 and Xbox consoles. After leaving Sidhe to "go indie" and develop websites to raise capital, he found that he really enjoyed working with web technologies and decided to make a go of it. This is Robert's first time as guest writer and he is here to introduce us to his latest project: the Drupal connector module.

The Drupal connector has finally arrived! With this module you’ll be able to embed or import content from a site running on Drupal 5+ into your SilverStripe 3 site.

Background

A lot of clients that we at SilverStripe HQ hear from already have an existing site, and unless the site is particularly small, they’re understandably not too keen on transferring the content over manually! It can be a massive task, involving either a web manager doing days’ worth of copy-and-pasting or a developer trying to decipher database schemas and writing custom database queries to export and import the data.

So the clever clogs over at SilverStripe Australia developed the External Content module that allows SilverStripe to connect to other content management systems and read the data in there. In an nutshell, the module allows you set up connections to any number of external sources and then either display that information in a page on the SilverStripe website or import it directly into the SilverStripe site as pages. If you’d like more information on this module, head to the GitHub page or this tutorial of how to create a new connector.

One connector that was missing was one of the most requested; Drupal. Drupal is a major player in the CMS space and a lot of sites are running on it, so consequently we get a fair number of potential clients wanting to migrate their content off their Drupal website easily and cheaply.

Drupal

Drupal organises page content into Nodes which are roughly equivalent to SilverStripe’s SiteTree objects. There is one key difference however - Nodes contain no hierarchy information. They can be organised into a tree with one of two main methods, a taxonomy or a menu.

Taxonomy structure

A taxonomy is a list of tags that can be nested to form a hierarchy. If a Drupal site uses a taxonomy to form a menu, then each entry in the menu tree is created as as a tag in the taxonomy. Every Node is assigned to its parent tag and appears nested beneath it in the site structure. A simple taxonomy used for a menu is shown below:

So as you can see, this looks very similar to SilverStripe’s tree. There is a slight distinction in that in SilverStripe every entry in the menu is a SiteTree (and therefore, is likely a page on the website), whereas in a Drupal taxonomy structure the non-leaf entries are just taxonomy terms. When viewing one of these “pages” on the site they will usually just list their child pages and no content.

Menu structure

A menu structure is much closer to the SilverStripe SiteTree model. Each Node can be placed into a menu, either as a top-level element or as a child of an existing element in the menu. There is still a separation between the menu item and the Node that is corresponds to, but that’s only an underlying code issue rather than a structural difference.

Walkthrough

Setting up Drupal

Though there are a few hoops you’ve got to jump through to allow your Drupal site to receive connections from external sources, although it’s all fairly straightforward.

First of all, you need to install and the enable the Services module. This module will allow Drupal to provide web services via a variety of interfaces (such as XMLRPC, REST, etc).

If you’re using 5.x you’ll need to specifically enable the Node, System Taxonomy and User services, so enable them in the Services module:

Lastly, enable the XMLRPC Server:

If you’re using Drupal 5.x or 6.x, then you’ll also need to create an API key. To do this, visit /build/services/keys. The domain can be anything you like.

Unfortunately there is a constraint in 5.x and 6.x that caps the number of nodes per taxonomy item that can be returned by a feed, and this can’t be exceeded without modifying the module. However, we can still increase it as far as it can go - visit /admin/content/rss-publishing and adjust the “Number of items per feed”.

If you are using Drupal 7.x, you also have the option to export by menus. To do this, you’ll need to install the Services Menu module and then enable the menu service:

Also it’s worth noting that you should create a new user just for the connector to use. If you do so, make sure it has all the appropriate permissions to use the services (and services menu) module.

Setting up SilverStripe

To set up your SilverStripe site to import Drupal content, you’ll need to install the External Content module and the Drupal Connector module and run a dev/build.

This will add an “External Content” tab to the CMS. From within this tab you’ll be able to create two types of Drupal connectors - one for menus and one for taxonomies. They’re very similar, the only difference being that one requires the name of the menu and the other the id of the taxonomy.

If you’ve entered everything necessary (including the API Key and Domain for 5.x or 6.x), then you should see the tree of the menu/taxonomy appearing in the left tree view:

From here you can either import the data as it exists right now into SilverStripe pages (using the Import tab), or create an External Content Page and view the content on the site as it appears on the Drupal site - even if new pages are added.

Contribution and future

You can start using the connector right now - you just need SilverStripe 3.0+, the External Content module, the Drupal connector module, and a Drupal site!

It’s still pretty rough right now - the importing process takes a long time and doesn’t provide any feedback, and it doesn’t pull any assets in with it. One of our internal teams will be doing a fair bit of work with this module in the coming months, too.

Get Mobile with SilverStripe: Our Workplace Challenge

Fri, 25 Jan 2013 12:34:22 +1300

Amidst the craziness of December 2012, we held an in-house mobile app competition at SilverStripe Headquarters, coined the "Jedi Challenge". The topic for the Jedi Challenge was to interact on the move. The application needed to be mobile and multi-user focussed. There were really no boundaries with this competition, which saw a range of entries from a recipe app, to a real-time, multi-player game. Head over to ss.com for the full story.

Santa brought you 3.1.0 beta 1

Tue, 18 Dec 2012 04:07:00 +1300

It’s been about six months since we released 3.0 stable into the world, and the whole team is proud to see it being adopted so well by the community at large. Since then, we've had over 500 pull requests to our core, mostly targeted at the new version, which is a fantastic result.

Typically, you had to wait for at least a year to get to the next major stable version. In the spirit of continuous delivery, we want to shorten this time frame a bit, and provide you with slimmer, but more frequent releases. Accordingly, the 3.1.0 beta 1 release has a lot of incremental, but less visible improvements. With the release being in beta status, we don’t expect any further API changes, and encourage you to download it and try the codebase (changelog, upgrading guide).

Even after extensive peer review on early CMS designs on the community mailing list, our major focus is still on interface usability, and ensuring that we provide adequate feedback on user actions. In SilverStripe 3.0 (like in most CMSes), you had to switch between the editing interface and a preview of the actual website. In 3.1, you can see the two side-by-side, provided you have a decent screen resolution. There are new options for previewing at different widths, and more useful controls for switching between draft and live content.

Image: Side-by-side view

Image: Preview modes

Talking to many CMS users, we also found that they are commonly overwhelmed by the various buttons to affect a page, e.g. to save its content to draft. So we’ve moved the minor actions into a flyout, alongside some useful metadata about the page itself. There’s an API for that, so you can add your own minor actions as well. In addition, the CMS change detection now highlights if a page needs saving by changing the button style.

Image: Grouped buttons

On the framework side, we’ve made some architectural changes to DataList and ArrayList, ensuring that they are consistently immutable, meaning they’ll always return copies rather than modifying themselves. This means that you can pass DataLists to other parts of your application without worrying that they will get modified, making code more modular and maintainable. We’ve removed a whole bunch of legacy APIs which were previously deprecated, most prominently the TableListField and ComplexTableField classes which are now replaced by the infinitely more awesome GridField class (there’s a legacy support module if you really can’t switch to GridField right now).

We’re also pleased to announce support for the Composer dependency manager, which makes installing a SilverStripe project as well as new modules much easier (see docs). Modules can define their own dependencies programmatically, which should make it effortless to create modular solutions and share nicely decoupled code between modules. Over 50 SilverStripe modules managed by Composer are already listed on packagist.org, a common repository for PHP modules.

To stay tuned and help out, keep an eye on our 3.1.0 milestone in the bugtracker. And read through our changelog overview to get a more detailed understanding of the release.

Why BSD?

Wed, 12 Dec 2012 18:53:53 +1300

Back in 2007, when we made the decision to open source our CMS, we were faced with a decision: which open source license should we release it under? Although at first glance it may seem like a bit of tedious legal administration, the choice of license cuts to the heart of the goals of an open source project.

There are many other licenses to choose from, such as GPL, BSD, MIT and Apache. MIT and BSD are very similar. The Apache License has a similar permissive intent, but is more explicit, and as such it is a lengthier, more complex document. We didn't spend too much time choosing between very similar licenses and instead quickly narrowed our choice down to two alternatives: BSD and GPL.

BSD is short for Berkeley Software Distribution and is the name of a Unix derivative. The BSD license is so named because it was originally used as the license for this software. GPL is short for GNU Public License, and was the license used by the GNU project, principally for the release of GNU/Linux. GNU/Linux is the operating system commonly known as Linux, the name GNU/Linux refers to the fact that, strictly speaking, Linux is just the kernel, and the GNU project developed many of the tools that turn that kernel into a usable operating system.

For us, the critical difference between the two licenses was this:

Modifications to a GPL-licensed project must be contributed back to the open source product, and cannot be released solely under a non-GPL license.
Modifications to a BSD-licensed project can be retained, and potentially sold commercially, by their creators. Very few restrictions are placed on the so-called "derivative works".

GPL presents an opportunity for commercial entities looking to release open source software, because the GPL won't be appropriate for some people and/or organisations. The GPL also prevents other organisations from creating commercial variants of SilverStripe, reserving that right for the copyright holder.

At the time we chose a license, SilverStripe already existed as a proprietary product, and GPL initially seemed like a safer choice. However, ultimately we found GPL was out of step with our goals.

Dual-licensing may seem appealing as an open source business model, until you work through the details of what this means for contributions. If third party contributors retain copyright of their changes, then those contributions can't be included with any dual-licensed version of the software. This means you have to maintain two separate forks of the software. If, instead, we asked contributors to assign copyright to SilverStripe for their contributions, they are effectively losing significant rights that they have in those changes, because only the copyright holder has rights to release the software under other licenses. Sure, you could have contributor agreements that deal with this, but it makes contribution a complex legal issue, and will ultimately drive a wedge between the needs of the developer community and the needs of the commercial entity behind the software. To us, dual-licensing was a non-starter.

The second benefit we initially saw in GPL was that it protected us from other commercial entities that might create their own commercial variants. In the end, we decided that this wasn't a major issue. Yes, software takes effort to build and it is very useful, but ultimately, the lines of code that are protected by copyright law are not the most valuable asset of our business. Much more valuable are the people that know how to keep innovating, and the reputation we have for doing so. As such, although being protected from competition by copyright law would be nice, it isn't nearly as important as our team and reputation. We decided that this was a risk we could take.

There is a final benefit of GPL being that it tends to force software to become open source rather than proprietary. For some, this is the point: all software should be open source (also called "free software"). Although we at SilverStripe think that open source software is a great thing, and that it is definitely possible to build sucessful companies around open source software, we believe that "all software should be free" is too simplistic - it requires a one-size-fits-all view of the world that we don't share. So this wasn't a benefit of the GPL that we found compelling.

Which brings us to the BSD. We believe that BSD is the open source license that best recognises that open source software will sometimes be worked on as a commnuity project, and sometimes be commercialised. We have released SilverStripe open source, but we also run a business that aims to make money. All that the BSD license really says is that we are okay with other people doing the same. We think that anything less would be unfair.

Closeup on Application Platform Liked

Mon, 03 Dec 2012 11:15:00 +1300

The creators of liked.com consist of a team of six Swedish guys - entrepreneurs Marcus and Robert, developers Tomas, Eskil and Andreas, and a designer, Dawid, all located in Stockholm. They started to build the site one year ago during their spare time. Tomas and Eskil have been working with SilverStripe for about four years now within different companies and projects throughout Sweden. After many late nights of hard coding and design work, the project has become quite the success.

Developers Eskil and Tomas (with the beard)

You built the website liked.com. Tell us a bit about the website.

Liked is a search engine for Android and iPhone applications, on top of that we have added facebook connect so that you can create your own profile at Liked where you can add your favorite apps to what we call collections. You can also follow other Liked users, review and rate apps and comment collections.

Where did you find the inspiration to create Liked?

Marcus and Robert had an idea to build a social app search where you can connect with friends and share your app findings. They talked to Dawid who did a design of all pages that was needed. After this was done Eskil, Andrea and I started to build the first version of the site at nights after work and on the weekends.

How many users do you have and what’s the average number of downloads for a user per month?

The site is still in beta, so we have not started to promote it yet.

How much does it cost to download an app?

Downloading apps from Liked doesn't involve any additional cost, the price is the same as you get in app stores.

Why do you think people like liked.com?

We hope people will like the site because it will be an easier way to find new apps. The app stores of today are pretty hard to search in. We are also planning to give the developers more room to promote their apps. Also right now we are building a new version of the index page to give users a new way to search through all the apps we have stored. This new “inspiration” mode is still under development and we cannot not tell you how it works or looks yet. You will just have to wait until it’s live!

How does your business model work? Can you live off what you make with this business?

As we are still in beta we cannot live off this business at the moment.

How many people do you have working from where and doing what?

All develpment on the site is done in Stocklholm. Mostly me (Tomas) and Eskil working with the backend. Dawid with design. Marcus and Robert with SEO etc.

You built this project with SilverStripe. What parts of the SilverStripe Suite did you use and why?

We are right now using SS 2.4 with the dbsession, news and facebookconnect module. We have created a view of the Applications tables in mysql that we index using Sphinx. We created our own Sphinx wrapper class to run the search queries against this index. Below is a basic example of how that works:

$searchresult = SearchEngine::query();

$appsresult = new DataObjectSet();

/* Populating dataobjectset with applications from sphinx result */
if($searchresult['total'] > 0) {
    foreach ( $searchresult['matches'] as $result ){    
    
        $appsresult->push( DataObject::get_by_id("Application", $result['id']) );
    }

} else {
    $appsresult = false;
}

Since the site is running in a load balanced environment we use dbsessions to keep the session data consistent between the web servers.

We are using the Facebook Connect module by Willr for an easy way to register with facebook connect and get the benefits from the sdk.

How did you customise the tool to make it work for you?

Because of the amount of Application pages (eg. http://www.liked.com/ios/plague-inc/) that the site has, we are using DataObjects as Pages.

We are also using Sphinx to index the data and in this way speed up the search results.

Because of the total amount of screen dumps for all the apps that we list on the site is very large we needed a way to handle this. We didn’t want to download all the images and store them on our servers since this task would be very time cunsuming and it would take up a lot of resources and disk space.

We decided to store the images in an Amazon S3 bucket and connected that bucket to Amazon CloudFront front for faster loading. The first time an image is requested we fetch the image from the original destination e.g. iTunes. Upload it to S3 and update our database to tag this image as stored. Below are some code snippets that illustrates the solution we came up with:

1. Template:

<% control Application %>

<img src="$IconURL" />

<% end_control %>

2. DataObject:

public function getIconURL() {
    
    $icon = DataObject::get_one('Graphic', "Type = 'Icon' AND ApplicationID =" . $this->ID );
    
    if( ! $icon ) {
        return '/themes/liked/images/no-img.png';
    } else if( $icon->onCdn == 'yes' ) {
        return 'http://d30e0voobdlbps.cloudfront.net/' . $icon->ID;
    } else {
        return '/s3/' . $icon->ID;
    }
}

3. htaccess:

RewriteCond %{REQUEST_URI} ^/s3/(.*)$
RewriteRule .* s3.php?file=%1&%{QUERY_STRING} [L]

4. s3.php

$query = sprintf("SELECT MarketURL, onCdn FROM Graphic WHERE ID =%d",$id);

curl_setopt ($ch, CURLOPT_URL, $url);

$img = curl_exec($ch);

$contentType = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);

$s3 = new AmazonS3();

$response = $s3->create_object($bucket, $id, array(
    'body' => $img,
    'contentType' => $contentType,
    'acl' => AmazonS3::ACL_PUBLIC
));

if( $response->isOK() ) {
    $query = sprintf("UPDATE Graphic SET onCdn = 'yes' WHERE ID =%d", $id);
    $result = mysql_query($query,$link);
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://d30e0voobdlbps.cloudfront.net/".$id);
} else {
    header("HTTP/1.0 404 Not Found");
    echo "s3 error";    
}

Would you recommend SilverStripe to others? Why?

We would! It is a great MVC framework that keeps the code clean and easy to work with. The built in “Magic” saves time when coding. Eskil and I have started our own buisness Stök Media AB (haven’t had the time to build our own site yet :-) ) where we develop a lot of sites in SilverStripe, too.

What do you think about SilverStripe 3.0?

We started working with it a while ago and the ModelAdmin enhancements were stunning! GREAT JOB!

Thank you for taking the time to answer my questions and goodluck with your project.

SilverStripe Framework and CMS 3.0.3 now available

Mon, 26 Nov 2012 15:36:20 +1300

SilverStripe is pleased to announce the immediate release of SilverStripe Framework and CMS 3.0.3 stable.

3.0.3 is the third release in the 3.0.x series, a series of releases based on the major 3.0 release aimed at fixing bugs, adding minor functional enhancements and addressing security issues that have been discovered since that release.

We recommend all developers who are developing sites on any version of 3.0 upgrade to 3.0.3 at their earliest opportunity. Not only does it fix many minor issues, it also includes fixes for four recently discovered security issues. As with all 3.0.x releases, we have focused on fixing issues with only the smallest possible changes to UI elements and APIs, and it is drop in compatible with 3.0, making upgrading simple.

This is likely to be the last significant release in this series, as internal focus is shifting to development of 3.1, where features with more significant UI or API changes are allowed.

Download 3.0.3 and view what's new in the changelog, see the bugs that have been fixed (and raise new ones). Or use the new composer support to get started.

Document Management System Module

Wed, 21 Nov 2012 15:06:27 +1300

I have the pleasure of introducing a new module that we created here at the SilverStripe HQ - The Document Management System (DMS) module.

History

A few years ago, community member Aaron Calino (UncleCheese) created the Data Object Manager module for SilverStripe 2. This module was packed with features that allowed users to manage DataObjects related to pages. However, as Aaron has stated in this forum post, the new GridField class in SilverStripe 3 does much of what Data Object Manager did in SS2, so he won't be making a version of Data Object Manager for SS3.

We found ourselves needing something similar to the old Data Object Manager module in one of our recent SS3 projects. We took this opportunity to create a great new open source module, a module built in the same spirit as the Data Object Manager, built on SS3 from the ground up, and built to serve as the basis for sophisticated Document Management with SilverStripe now and in the future.

Design goals

We had several goals in mind when designing the DMS module:

Painless association of files with pages
Simple, clear and reliable file storage system
Extensible and customisable architecture
Easy UI for uploading, replacing, and linking files

The first item in the list needs some explanation. Traditionally, SilverStripe has a "Files and Images" section where you upload files, then add these files to your page when you need them. This has the advantage that you can easily reuse a single file on multiple pages. However, more often than not, you will only ever need a file uploaded to a single page, and having to separately upload the file into "Files and Images" unnecessarily complicates the process. Additionally, if you want to replace a file with a new version, finding the underlying file from a reference on a page can quickly become tedious.

Our solution is to directly associate files with the pages, skipping the "Files and Images" section completely. We then polish the process for doing so to make it as smooth, reliable, and painless as possible.

The files themselves are stored in a folder structure under a new "dms-assets" folder. We intentionally preserve the filename of each file (as opposed to hashing names) to make it easier to find your file again in case something goes wrong. We do, however, add the database ID number to each filename, so that the link to the database record is obvious and extremely fault-tolerant. We use a number of folders for the files, so that all the files don't just end up in one gigantic folder. You can configure how many files go into each folder to suit your deployment.

In case you're wondering about the scaleability of the DMS module. We are currently using the DMS in production with tens of thousands of documents and it doesn't even break a sweat.

Feature walkthrough

Here is a walk-through of some features of the DMS module:

When you first install the DMS module, every page in the CMS gets a new "documents" tab. On that tab you can click the "Add Documents" button, which takes you to the screen above.

Uploading is really easy. You just drag and drop (in modern browsers), and/or select files with a dialog box. Immediately after you upload files, you get the opportunity to either edit each file's metadata, or just click "Done" to go back to the page you were on.

You can also link documents from other pages. You do this either by typing in an autocomplete search field (referencing files by name and/or ID), or by clicking the "Browser by page" button to get a TreeDropDown view of the page structure. The linked document appears on the current page, as well as the page where it was originally uploaded.

You can link any document in the DMS to any page. A document does not "belong" to a specific page. For example, if you upload a document to Page-A, then link it to Page-B, then delete the document from Page-A, the document will stay on Page-B, as if nothing had happened. Reference counting keeps track of everything.

Here is the DMS grid (powered by the SS3 GridField). It allows you to do a quick download, go to the detailed edit view, and delete or unlink the current file (if a file is only attached to a single page, then you get a "delete" button; otherwise, if the same file is attached to multiple pages, you get an "unlink" button). You can filter/search the grid by clicking on the "magnifying glass" button in the top-right corner.

You can also sort the list of files in the grid with drag-and-drop if you drop in this SortableGridField module. Similarly, the "Show all" button on the footer appears if you install this GridFieldPaginator module. Both are nice demos for how you can easily extend the functionality of the DMS with add-on modules.

The Detailed Editor view gives you the ability to view and edit a document's metadata. The DMS also has embargo and expiry built into it. So you can schedule documents to appear or disappear at a specific date. You can replace a document using drag-and-drop. "Find usage" shows other pages where the current document has been linked. "Find references" shows you pages where the current document has been referenced in the HTML content (more on that later). Finally, "Delete" deletes the document from this page and all other pages where it is used, giving you a warning pop-up before proceeding.

This feature of the DMS allows you to insert a link to a DMS document into the HTML content of a page. The DMS adds a new option to the CMS link editor. You can use the combined auto-complete-search/PageTree-browse view to find the document you want to link to and insert the link. Again, reference tracking keeps track of each link you add and allows you to view where each document is linked in the Detail View.

Finally, there has to be a way to display the documents in the website front-end, right? Of course there is. That requires a small change to your Page.ss template. Just add <% include Documents %> to the template wherever you want the documents to appear. That will give you a document listing similar to the one in the screenshot above.

Start using the DMS and contribute

We hope you like the new DMS module. Please try it out. Like all of SilverStripe, it is open-sourced using a BSD license. Click to download the Document Management System module.

We are keen to hear your feedback. If you have an idea for improving the module, please discuss it in the forum, or send us a github pull-request. Here are some ideas we have thought of already:

You can add a search box to your site that searches through the full-text of all documents using the fulltext-search module.
We are currently working on a simple method of versioning the files in the DMS. So, if you replace a document, the previous versions of that document are kept for archival purposes. This is coming soon.
A new feature we are thinking about adding is a view that shows you all the documents in the DMS in a single view, a view you can use to conveniently search and edit all documents in the system. However, it might take a while until we get to doing this.

Seeking support in SilverStripe's social sphere

Thu, 15 Nov 2012 16:17:27 +1300

I am a developer who uses the SilverStripe CMS. I have over four years experience in everything from small websites to large multi-user internal system tools. I was originally drawn to SilverStripe in my web developer infancy because of its strong and intuitive templating system, and I've never looked back. I give back to the community by providing support on the IRC channel, through which I've met new people and learnt a whole heap of things I never would have without the tools I'm about to talk about below.

So. You're a developer who has (perhaps recently) discovered SilverStripe. That is great! You're loving how easy its sleek UI and extremely supportive framework makes your life when it comes to developing websites or web applications. However you've just come across an issue that you're having trouble solving. Maybe it's a question about how something works, what the best way to achieve something might be, or maybe how to troubleshoot a problem you're having with the system. Perhaps you just want to say "Hi" to the community. Whatever your reasons, SilverStripe has a variety of methods to enable you to contact people who are willing to offer you support.

Support can be found in abundance through the (soon to be upgraded for extra awesome) silverstripe.org (not .com, that's the company, not the community) website. First things first, one should make sure to have at least read through the tutorials. Of these, the first two are most important, they will provide a basic background to the entire system. Beyond that, tutorial 3 can help solve many questions about forms, and tutorial 5 can be useful if you're new to creating relations. Even as an experienced developer I still find myself using tutorials 2 and 3 as quick references for things I cannot be bothered to look up properly.

Beyond the tutorials (that everyone should read), it depends on your level of expertise as to where you should look for help. Two of the most common reference sites are the docs and the API. The doc site holds many references and little tidbits of juicy info to give you start-out help with whatever you have in mind to work your problem through. This includes debugging help for issues that don't involve building something with PHP (or the unfortunate aftermath of having built something with PHP in the SilverStripe Framework). For the more advanced PHP user, there is a full API documentation available at api.silverstripe.org. This is my most common port of call and holds many quick reference notes for figuring out which method to use where, what is available in your current scope, or even just checking up on the correct syntax or method signatures to be used when coding your next function or subclass.

These resources are all well and good, but what if you're not a hardcore coder and need a little assistance in deciphering what they're trying to tell you? SilverStripe.org also has facilities in place for a more personal level of support (by personal I refer to getting answers from real people - not one on one full system tutorage/getting your work done for you for free, an unfortunate however surprisingly common mistake some people seem to make).

To this end there are the forums and the IRC channel available for personal contact with other developers using their favourite system around the world. The forums are a useful place for many beginners and contains a backlog of resources regarding installation issues, module setup and problems, and fixes to those problems. The issue here currently is that many of the more experienced developers find the forums a little too simplistic for the more power user style questions they wish to ask, or perhaps you're under too much pressure to wait for an answer on the forums.

For real time interaction, enter the IRC channel! Here you will find an active community of developers, usually from countries on your side of the planet (time zones are an interesting thing like that), all at various levels of experience with SilverStripe and more importantly, the Framework. These power users are there to bounce ideas off of and query for instant help. And as an extra bonus, most of the correspondence (both on and, err... extremely, off topic) gets logged for future reference at logs.silverstripe.org.

With the handy backlog of questions at logs.silverstripe.org you can perform a search by using the Google query "<your question> site:logs.simon.geek.nz" (the logs are provided by prominent community member Simon Welsh on his server). So asking questions also helps other people in the future who may have the same problem as you. If you don't get a reply to your question immediately, please don't feel left out. Many of the people in the channel simply idle there and answer questions when they can at a later time. This is why if you're on the IRC channel it is very important to actually ask a question! Many times people arrive and ask "Can I ask a question?" - to which there is no response before they quit. If they were to actually ask their question they could search through the logs at a later point to see if someone answered them after they left. Everyone in the channel is there to help others, so ask away!

Recap:

Read the tutorials. http://doc.silverstripe.org/framework/en/tutorials/
Search for examples and references on docs.silverstripe.org
Power users can make great use of api.silverstripe.org
Introductory personal help can be found at silverstripe.org/forums
Community provided live support at irc.silverstripe.org (or your favourite IRC client - #silverstripe on Freenode)
Search the IRC logs - logs.silverstripe.org
The trac bugtracker at open.silverstripe.org sometimes lists untested/uncommitted patches to known problems in the ticket's comments.

Bonus: Worth mention of course is Github and Google - these two resources are ever handy for module readmes and personal blogs about SilverStripe troubleshooting respectively.

This is just a quick cap of the major resources provided for one to find help about the SilverStripe CMS and Framework, far from exhaustive. Also worth noting is the core developer mailing list found on Google Groups: groups.google.com/group/silverstripe-dev - If you wish to join in and contribute to or voice concerns about the direction SilverStripe is taking as it progresses as a system worthy of web dominance (or just lurk for bleeding edge news scoops). At every turn there are friendly people willing to help you solve whatever issue you're having with your SilverStripe system; all you have to do is find out on which of the many available mediums you wish to put your question, and then ask!

Please remember

With these more interactive ports of call for help, (as with any online community interaction) a little bit of etiquette goes a long way. One must remember that this help is offered by the community in their free time, so basic courtesy goes a long way.

Please do not start off asking a question by ranting about how bad the system design is just because it's so different to whatever system you've used before. All you're likely to receive is a disgruntled "don't use it then".

We're all here because of our favourite system, and trying to aggressively convince a whole community that they're wrong is a sure way to get ignored. If you do have a criticisim, pose the question in a more approachable tone and you're far more likely to get listened to and have your opinion considered seriously.

The Dashboard Module: Make a splash in SilverStripe 3

Thu, 08 Nov 2012 11:34:51 +1300

This month, we welcomed the newest member in a long line of Uncle Cheese’s brainchildren – the Dashboard module. Dashboard is for SilverStripe 3 only, and with a highly extensible API and frictionless interface, it’s likely that you’ll find more than a few reasons to use it on your next SilverStripe project.

Why Dashboard?

One of the disadvantages of being a developer is that we rarely get to play the role of an end-user in the software we create. When clients and project managers ask me what I love so much about SilverStripe 3, I usually rattle off a bunch of technical things – the new ORM, the improved templating, the GridField API – things that mean nothing to a content editor. What most upgrade-fearing users are wondering is how SilverStripe 3 makes content editing easier, faster, and more powerful than ever before.

There’s no doubt that SilverStripe 3 does all of those things. That much is clear from the feedback I get when showing the product to end-users. There is, however, one criticism common to both SilverStripe 2 and 3 that I hear too often to ignore – the lack of an action-oriented splash screen (read: dashboard).

In typical end-user fashion, they don’t come right out and ask for a “dashboard.” Most of them are not familiar enough with the lexicon to describe the idea with such precision. Rather, I hear a lot of desire for features that only a dashboard could offer.

“How do I get back to the page I was working on yesterday?”
“Where is the button to write a new blog?”
“How do I get to the calendar?”
“Where can I see how many people signed up for the seminar today?”

All of these user stories send them on a journey of multiple clicks through trees and tables to find what they are looking for. A dashboard view would bring these actions to the surface, and offer a single-click, intuitive, user-biased path to a CMS action.

So Why Not Dashboard?

If the feature is of such high value, then why isn’t it already part of SilverStripe? To me, it makes a lot of sense to leave it out. SilverStripe is not a single-purpose application like WordPress or Magento. In fact, out of the box, it’s hardly an application at all. Until a developer builds something with the robust set of tools it offers, there’s not much you can say about what the needs of an end-user will be for a SilverStripe web site. Offering a pre-cooked dashboard risks capturing only a small number of common needs and leaving many more underserved.

An Open Solution

When I started building the Dashboard module, I knew the last thing I wanted was to offer a handful of static widgets that may or may not serve each user’s needs. Rather, like the SilverStripe platform itself, it should offer just enough out of the box, and invite developers to create custom solutions. Knowing that every developer understood the basic design pattern of creating a custom page type, I followed that template and offered an API that gave dashboard panels their own model, view, and controller. This means that each dashboard panel is self-contained and can render virtually anywhere, with any content you want it to.

How It Works

When you install Dashboard, the first difference you’ll see right away is that the “Dashboard” menu item is first in the list, usurping the Pages tab as the default view in the CMS. The dashboard is empty by default.

By clicking “New Panel,” you are offered a choice of several different panel types that come baked into the Dashboard module.

They include:

Recent Edits: Shows a list of recently edited pages, with links to edit each.
Recent Uploads: Show a list of recently uploaded files, with links to edit each.
Quick Links: Builds a panel of arbitrary links, either internal (in the CMS) or external (on the web).
Google Analytics: Shows the Google Analytics data for your entire site or a specific page on the site.
Section Editor: Shows a given section of the site, e.g. “blog” or “calendar”, displaying all of its child pages and offers links to create a new page or view all pages.
ModelAdmin Editor: Shows the list of a given ModelAdmin view and offers links to edit each record, view all, or create a new entry.
GridField Editor: Shows a GridField of a given page and allows direct linking to create and edit on the grid.
RSS Feed: Show an RSS feed from any public URL.
Weather: Shows the current weather of a given city

After choosing the panel type you want to create, the panel is installed on your dashboard. If it needs immediate configuration, it will flip over automatically. Otherwise, you can click on the gear button to enter this view.

On the back of the panel, you will find all of the metadata that defines how the panel looks and behaves. All panels have settings for their title and width.

Creating Default Dashboards

As a developer, you may want to offer each client a default dashboard so that users aren’t logging in to a buzz-killing blank page. You can apply a default dashboard in two different ways:

1. Retroactively: Apply this dashboard to all existing users, overwriting whatever dashboard configurations they may or may not have presently.

2. Proactively: In the future, all new users receive this dashboard configuration by default.

If you want to exert even more control over your users’ dashboards, the Dashboard module also offers a granular assortment of permissions, allowing you to specify which users can create, edit, sort, delete, and administer dashboard panels. By revoking all privileges, you can essentially give users a static, immutable dashboard view.

Creating Your Own Flavor

As mentioned earlier, one of the primary goals of the Dashboard module was to make it easy to extend and inviting for developers. There are only a few simple steps.

1. Create a subclass of DashboardPanel, e.g. “MyDashboardPanel.php”

2. Populate the $db array with any custom fields used to configure the panel, e.g. “NumberOfRecords”

3. Create a getConfiguration() function that returns a FieldList to for the edit form. This works just like getCMSFields() on a page type. Remember to call parent::getConfiguration()!

4. Create a template of the same name as your panel, e.g. “MyDashboardPanel.ss”

5. Create the view using any template accessors you have defined in your model, e.g. <% loop MyRecords %>

6. Include any JavaScript or CSS dependencies in the PanelHolder() method. Don’t forget to return parent::PanelHolder()!

There’s a lot more you can do when building a custom dashboard panel. The module is full of great APIs to help you create exactly what you want.

Data Visualization

The Dashboard module comes with a charting API, albeit fairly primitive. Using the Google visualization JavaScript API, it allows you to create charts for dashboard panels that display arbitrary data over a given span of time. Just add data in X/Y pairs, and return the chart to your template.

More Information

Download it here
Read the Documentation
Check out the screencasts