Content Type Management

We have a system which allows us to define content types. For example we have a post content type, profile post, profile post comment etc. add-ons can add their own so we have a xengallery_media content type in XFMG, etc.

The systems which use content types do so to allow us to make those systems content agnostic. This means when we do something like display an alert, there's a whole load of code that is generic and shared between all content types automatically and usually only a small bit of code which is different for each content type.

As an example, when viewing an alert there's a block of code that's the same for all content types (in the Abstract alert handler) which renders the template for the alert. But each content type must implement a "getContentByIds" method because this does need to be implemented differently. The good news is, although some of these default methods in the Abstract handler should mostly be the same, you can still overwrite them or extend them as necessary if you need to.

The process for implementing alerts is roughly as follows:
  1. Create a content type entry in xf_content_type
  2. Create a record in the xf_content_type_field table with the content_type you set above, alert_handler_class is the field_name and the class name of your alert handler should be in the field_value field.
  3. Rebuild the content type cache by deleting the contentTypes field from the xf_data_registry table (note: you don't need to do these steps 1-3 if you are running my Content Type Management add-on).
  4. Create your class and that should extend XenForo_AlertHandler_Abstract and at minimum implement the getContentByIds method.
  5. You will also need to create a template for each alert action. You will get a clue as to what the template names are (by default) by looking at the
    _getDefaultTemplateTitle method in the Abstract handler. You will likely need to override the canViewAlert method too if your content is subject to permission checks. For example with post alerts we ensure you can actually still view the post the alert is for.
  6. Then all you need to do is to call the XenForo_Model_Alert::alert() method including things like the content type, action, user ID to be alerted, user details of who the alert is from, etc.
And that should be it.

Behind the scenes the alert method will take your content type, and check to see if there is a alert_handler_class field and if so what class is used to load it.

All my Content Type Management add-on does is it removes those first three steps. The add-on has a UI to define content types and fields, and it rebuilds the content types cache automatically. But hopefully the rest of this explanation helps understand how content types work.
 
  • Like
Reactions: sbj
Thank you very much for the detailed explanation. I didn't know what "content type" is until now. In theory now I know.

So Xenforo has implemented in each handler class (alerts, spam, like, ...) methods specially to deal with content types. So I only need to create my own content type, and then can use those built-in methods in those handler classes to have access to their feature. For example you built the XFMG content type in the database, because you wanted to have alerts, likes, etc. for it.

But from what I understand, we don't need to create a content type, if we want to have access to alerts for example. But because we shouldn't reinvent the wheel over and over, XF provided this content type architecture, which helps the developer to make use of this "generic and shared code" you talked about.

Did I understand this correctly?


A side question, why is step 3 needed? Creating a new content type isn't sufficient? I don't know much about caching but I assume every time somwhere when caching is involved, I have to empty it so it rebuilds itself to update the new entries?
 
Last edited:
Top Bottom