Create the Edit Template

Before we make our view interface work, let’s make the edit interface to this block type actually load the proper data into the form fields. If you edit this instance of the block

You’ll notice we get the proper form. This is to be expected -- we already have an edit.php template in our block type.

Unfortunately, it isn’t loading any of the data that we saved in the block. That’s because we haven’t added any custom code into the edit template that attempts to set the data properly.

Variables in Scope

In view.php and edit.php templates, Concrete CMS automatically loads the variables that appear in the $btTable database table. These are set in scope. Let’s test this. Add

print_r(array_keys(get_defined_vars()));

at the top of edit.php, and add a new copy of the Page Header block to the page. You’ll see this:

Array ( [0] => fileToInclude [1] => args [2] => env [3] => a [4] => cp [5] => ap [6] => controller [7] => form [8] => view [9] => b [10] => bt )

A lot of these are internal and can be safely ignored (although some are useful, like $b, which is the currently rendered block.

It gets more interesting when we look at the defined variables on the block that we previously added. When you edit this block, you’ll see

Array ( [0] => scopeItems [1] => c [2] => a [3] => dialogController [4] => bID [5] => fID [6] => customPageHeaderTitle [7] => overridePageName [8] => controller [9] => form [10] => view [11] => b [12] => bt )

Some of these are the same, but you’ll see fID’, customPageHeaderTitle and overridePageName. That’s because they’re automatically available within the view.php and edit.php templates for existing blocks that have been added to a page. That means, to implement this template, we simply check for their existence, and output them in the various HTML elements. This is what the template looks like once we’ve updated it:

<?php
defined('C5_EXECUTE') or die('Access Denied.');
if (!isset($fID)) {
    $fID = 0;
}
if (!isset($overridePageName)) {
    $overridePageName = false;
}
if (!isset($customPageHeaderTitle)) {
    $customPageHeaderTitle = '';
}
?>
<div class="form-group">
    <label class="control-label"><?=t('Background Picture')?></label>
    <?php
    $fileManager = Core::make('helper/concrete/file_manager');
    print $fileManager->image('fID', 'fID', t('Choose Image'), $fID);
    ?>
</div>
<div class="form-group">
    <label class="control-label"><?=t('Override Page Title')?></label>
    <div class="checkbox">
        <label>
            <input type="checkbox" name="overridePageName" value="1" <?php if ($overridePageName) { ?>checked<?php } ?>>
            <?=t('Yes, override the page title with a custom title.')?>
        </label>
    </div>
</div>
<div class="form-group" data-group="custom-page-header-title">
    <label class="control-label" for="customPageHeaderTitle"><?=t('Custom Page Header Title')?></label>
    <input type="text" id="customPageHeaderTitle" name="customPageHeaderTitle" value="<?=$customPageHeaderTitle?>" class="form-control">
</div>
<script type="text/javascript">
    $('input[name=overridePageName]').on('change', function() {
        if ($(this).is(':checked')) {
            $('div[data-group=custom-page-header-title]').show();
        } else {
            $('div[data-group=custom-page-header-title]').hide();
        }
    }).trigger('change');
</script>

We start it by checking for the existence of the three variables we’re going to output in the HTML tags; if they’re not present, we set them to their defaults. Then we pass them to the image() function, and output them in the <input> tags. When we edit the block now, we can see everything set the way it needs to be: