Composer complains about "content" block only for pages added programatically via Page API

Permalink
I created a new page type which has a composer control output ("content") in the page template defaults. Adding pages using this page type via the concrete5 interface works perfectly.

However, when I added the same pages programmatically (following the instructions here:https://www.concrete5.org/documentation/developers/5.7/working-with-... although the pages get added with no issue, when re-editing in Composer, I see the following error:

include(/<redacted>/concrete/blocks/core_page_type_composer_control_output/composer.php): failed to open stream: No such file or directory


In edit mode, the area where the output block is supposed to appear is showing this message:

The Synopsis page type composer form element will output its contents here (Block ID 13)


("Synopsis" is the name of the piece of content that is supposed to be edited in Composer)

I'm not sure what I'm missing, so hope to see if anyone could help point me in the right direction.

Thank you.

ronthebot
View Replies:
Remo replied on at Permalink Reply
Remo
I'm having the same problem, did you ever find a solution to this?
Remo replied on at Permalink Reply
Remo
It's not exactly nice, but this code seems to work for now:
https://github.com/concrete5/concrete5/issues/2991...

Still hoping for a better solution though!
ronthebot replied on at Permalink Reply
ronthebot
I ended up adapting the codes in the c5 core for creating draft pages. It's not nice either. In fact, your method looks cleaner than mine, but that was the best I could do given I was quite new to the c5 environment a month ago.

In case you are interested, below are the codes that I used. If I get some time, I might just refactor this to try out your method.

$pagetype = PageType::getByHandle($pagetypeHandle);
$pt = $pagetype->getPageTypeDefaultPageTemplateObject();
$d = $pagetype->createDraft($pt);
$parent = Page::getByPath($parentPath);
$d->setPageDraftTargetParentPageID($parent->getCollectionID());
$d->update($data);
foreach ($d->getBlocks() as $block) {
    if ($block->btHandle == 'content') {
        $block->update(array(
            'content' => $data['content']
        ));
    }
}
$pagetype->publish($d);
Remo replied on at Permalink Reply
Remo
Thanks! Well, I don't think my solution is much better, but I'm not sure we really want to loop through all those controls whenever we create a page, but I guess that's the way to go.. I'll wait for some feedback and then decide in which direction to go.
maar replied on at Permalink Reply
maar
Hi,

We have exact the same issue. I would really like a core opinion on this one. It is kind of a show stopper in an add-on we are building at the moment.

/Michael
Remo replied on at Permalink Reply
Remo
I'm using my workaround in two addons without any issues so far. It's super ugly, but you can get around having a show stopper very easily:

https://github.com/concrete5/concrete5/issues/2991#issuecomment-1419...
maar replied on at Permalink Reply
maar
Thanks a lot...

But how do I go around programatically adding content to fx. the composer form instance of the content block. Can't seem to get it right!

/Michael