Custom Views and Edit Interfaces

Concrete CMS's file manager supports viewing and editing various file types. Image files, for instance, offer a view option in a dialog window.

The \Concrete\Core\File\Type\TypeList class manages this, determining viewer or editor availability for file types. Example for an MP3 file inspector:

$list = TypeList::getInstance();
$list->define('mp3', t('MP3'), \Concrete\Core\File\Type\Type::T_AUDIO, 'audio', 'audio', false, 'id3_reader');

Here, 'audio' and false indicate a custom viewer but no custom editor. For audio files, the "View" link in the file manager opens a dialog showing:

elements/files/view/audio.php

The filename in the define() function decides the final file. For a package-specified custom viewer, files load from the package’s elements/ directory, unless overridden by the application/elements/ directory.

Our custom ID3_Reader package's audio viewer needs a corresponding file to avoid errors:

<?php defined('C5_EXECUTE') or die("Access Denied."); ?> 
<?php $path = $fv->getURL(); ?>
<audio controls>
    <source src="<?php echo $path ?>" type="audio/mpeg">
    Your browser does not support the audio element.
</audio>

This uses the Concrete\Core\Entity\File\Version object $fv for the file URL and an HTML5 audio tag for display.

Editors are similarly implemented. Passing a string as the sixth argument in define() leads to loading a corresponding editing element. The $fv object is available in the editing element's scope.

Saving Custom Editor Output

Custom editors should save their outputs appropriately. Typically, this involves a custom route submitting to a package controller, which handles the file (identified by its ID in the POST request) and updates it with the new content from the editor.