Honor the mapped page template when creating pages

[hissy]

Fixes #44.

Problem

CreatePageStructureCommandHandler::createRegularPage() resolves the mapped page template into $pageTemplate, but only passes its ID inside the $data array:

'pTemplateID' => $this->getPageTemplateID($batch, $mtPage->getTemplate(), $pageTemplate),
// ...
return $ccmParentPage->add($pageType, $data);

Page::add() never reads $data['pTemplateID']. It takes the template from its third argument, and when that argument is falsy it substitutes the page type's default template instead:

// concrete/src/Page/Page.php
public function add($pt, $data, $template = false)
// ...
    // if we have a page type and we don't have a template,
    // then we use the page type's default template
    if ($pt->getPageTypeDefaultPageTemplateID() > 0 && !$template) {
        $template = $pt->getPageTypeDefaultPageTemplateObject();
    }

So every newly published page receives its page type's default template, and the template mapping configured for the batch has no effect — exactly what #44 describes. The mapping itself is fine; the resolved template just never reaches Page::add().

This is easy to miss because publishing the same batch a second time looks correct: the pages then exist, so updateExistingPage() runs instead, and that goes through Page::update(), which does honor pTemplateID.

Fix

Pass the resolved template to Page::add() as the third argument.

This also lets Page::add() copy the page type defaults belonging to that template, via getPageTypePageTemplateDefaultPageObject($template). Previously pages were given the default template's blocks in addition to its template, so this corrects the default blocks too.

Scope

• Aliases and external links are unaffected — they have no page template.
• The multilingual home page branch further down already passed $pageTemplate to addHomePage().
• $pageTemplate is null when the template is unmapped or ignored, and ?: false preserves the existing "no template" behaviour, so the page type default still applies in that case.

Verification

Against a Concrete 9 site with a seminar_entry page type whose default template is seminar_entry, publishing a CIF page carrying template="seminar_entry_sidebar" (mapped in the batch). Calling Page::add() both ways with identical $data:

page type default template: seminar_entry
without 3rd arg: seminar_entry
with 3rd arg:    seminar_entry_sidebar

In a real batch of 52 pages, 11 of which specified the non-default template, all 52 previously came through as seminar_entry; the areas belonging to the sidebar template imported their blocks but never rendered.

Made with Cursor