Asset Management

There are many ways to skin the asset management cat in Drupal. Under Drupal 6 you might add image fields to your content types and then display the images using template customizations. Maybe you create a content type explicitly for images or files and then use Views to create a slideshow or listing of documents. Perhaps you don’t care about having your assets represented in the database and you combine a file uploading module with your WYSIWYG module and everything just gets dumped into a directory.

Drupal 7 has introduced the File entity. The Media module is making use of the new D7 file entity and aims to provide a unified interface for uploading files and displaying your asset library while integrating with WYSIWYG editors, fields and Views. There are a lot of moving parts to wrap your head around here.

File Manager

Concrete5’s File Manager is part of the core and is so great it needs a bullet list:

• All uploaded files are represented as objects.
• File objects have default attributes (think fields) and you can easily add additional attributes if you need to.
• The File Manager interface has built in searching and sorting functions and is universal throughout the application.
• Users can easily upload multiple files from their computer, the /files/ incoming directory that is created by the concrete5 install routine or from remote URLs.
• File objects can be organized into virtual groups called File Sets that can be used to drive slideshows, document listings, etc.
• All files have versioning and the File Manager has a great interface to review these versions. You get a nice chronological listing of versions and which user created them.

The concrete5 attribute system (think fields) includes Image attributes you can add to Page Types (think Content Types) that basically work like node reference fields. If you need to relate an image to a specific page, add an image attribute to that page or its Page Type (think Content Type) and you’re good to go.

 

From concrete5 for Drupal Developers and Designers by Chris Hvizdak

In-context Editing

As is the case with most CMS applications, the front end / back end dichotomy is a big part of the Drupal content editing experience. If you want to change the body or field content of a node you load it up in the edit form on the back end. If you want to change supporting content (sidebars, etc.) you might visit the List Blocks page or truck over to the Panels admin pages. Site editors need to make the connection between the public facing page they want to edit and at least one admin page that displays their content in a completely different visual format.

Concrete5 offers an extremely polished in context editing experience. Editors navigate through their site like a regular visitor, throw pages into “Edit Mode” by clicking the big "Edit" button on the persistent toolbar and then make edits through modals without ever leaving the public facing page. Editors never need to work with their page content abstracted into a form on the back end.

It’s easy for editors to create complex content like forms, surveys or slideshows using core blocks and then position these blocks anywhere on a page with the drag and drop interface. Every page on a concrete5 site is essentially a simplified Panels page.

Despite the greatness of in context editing there are times when a project will require that content be created through the back end. The concrete5 core team understands this and has added a feature called Composer. If you are working on a project that requires content be created through a form on the back end, Composer will allow you to leverage concrete5’s block, attribute and Page Type features to setup an "out of context" content creation form.

Site Structure

In Drupal we’ve got the List Content page that displays a paginated table of all the nodes on our site. By default, the table lists all nodes from all content types with the most recently created node first and the oldest node last. The table of nodes on the List Content pages has no bearing on navigation structure.

Sitemap

concrete5’s Sitemap accomplishes the same basic function of listing content but is designed to do a lot more.  Instead of a listing content in a table, the Sitemap uses a hierarchy tree that is intended to be directly reflected in the site navigation using the core Autonav block. The drag and drop interface of the sitemap allows editors to easily move pages from one section of the tree to another. If you build out your navigation with the Autonav block a change like this is instant on public facing navigation menus.