How to override PostModel correctly

Created 6 years ago by cleancookie

I've created a model with the namespace App\src\Models\AppPostModel and added it to my bindings array,

protected $bindings = [
    PostModel::class => AppPostModel::class,
];

This is what my AppPostModel looks like,

<?php 

namespace App\src\Models;

use Anomaly\PostsModule\Post\PostModel;

class AppPostModel extends PostModel
{
    public function getMetaTitle()
    {
        return 'test';
    }
}

However now when I go to view a blog post, the blog's content isn't loaded but everything else is (eg, post title, author, date created, etc).

I tried binding my AppPostModel to the PostInterface instead with no avail. Has anyone managed to successfully do this before?

ryanthompson — 6 years ago

The bindings method should be a-ok but the post model is a little more complicated cause it uses the "type pattern". Did you confirm the method overrode correctly when you did that?

Another thing you can do is override the views and set the template variable within your content block (if that's all you are doing). Or use the SEO fields.. but I assume you need more overridden? If you don't mind sharing a bit more there might be a better way using hooks too.

You can set template data inside a view like this:

{{ template.set('meta_title', 'test') }}

Link

cleancookie — 6 years ago

Thanks,

Do you have any references to the type pattern that I could read up on? I tried Googling it without much luck.

My overridden version of getMetaTitle() was being called, the meta title was being set to test. I'm just stumped on why the post content isn't loading anymore. I tried digging into Pyro's code a little and got as far as noticing that inside PostContent::make a call to $post->setContent is made and it's passing in a blank string into it. But when I comment out my binding, it correctly passes in the blog post content.

Link

ryanthompson — 6 years ago

The "type pattern" is just something we've done internally with some addons. The Pages and Posts modules both use it.

In short it allows you to have two pages (or posts) with different custom fields from each other based on their type. So you manage your types - and what custom fields they each provide. Then you make a page/post of a given type and that defines what you have for inputs. Then you can structure your views / layouts around those unique fields.

Link