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\File\Version\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.