Has anyone succesfully managed to create a CMS content type?

[arvid]

I'm now well into my second custom content type and these are my experiences so far:

The framework is very object oriented and hierarchic in a sense that almost all classes inherit behaviour from parents. This is great since you get to write less code, but at the same time it makes it harder to get a complete view of what functions are availible and what versions you have availible in your class.

You often have to do a lot of file-searching to find out what happens when you call a specific function.

When you get the hang of it this is mostly a good thing, but it takes a bit of time to get the big picture...

Also, some of the features aren't as straight forward as you might think and even vB's own content types aren't 100% streamlined, so don't trust that copying them will get you a perfect base to stand on.
For example the getContentQueryFields() & getContentQueryJoins() functions in /packages/vbcms/collection/content/article.php are never used since they are overridden by the custom query in getLoadQuery() in /packages/vbcms/item/content/article.php.

Don't get me wrong - basing your content type on one of vB's contenttypes is clearly the best way to go, but don't trust that everything is perfect and 100% correct. =)

It's hard to give you tips just out of the blue, but this is the way I would recommend you would go when creating your own content type:

• Read Edwin's blog post (remember that it's not 100% up to date)
• Create your own product and add your own package to it (detailed in Ed's Content Type post, but a more clear explanation can be found in his custom widget blog post)
• Create your own content type as a copy of one of vB's content types. It will be messier then using the custom content type from Ed's blog post, but it will be more up to date. Remember to change all the Article/Staticpage names to your own name to avoid conflicts. And to use your own set of templates (this is detailed in Ed's blog post)
• When you get it up and working, start by changing something small like adding a new field to your content type and trying it out.
• As you get more familliar with the content type you can go on to change more drastic things.

Small steps and then test would be my general recommendation, so you don't get stuck somewhere and have lot's of code to check.

--------------- Added [DATE]1312462546[/DATE] at [TIME]1312462546[/TIME] ---------------

The framework is nice and quite flexible, but there are a few points where it is lacking:

- Quite complex to create your own content types - you really have to familiarize yourself with vB's way of thinking and the frameworks structure
- The rights management structure is really lacking. The different levels are too broad and inherit rights from each other. For instance if the user has the rights to publish she also has the rights to edit the section itself - not really ideal...
There is also no possibility to pinpoint the permissions more precisely to an individual content type for example (if the user is allowed to create and publish content she will also be able to create articles for example)

[Dead Eddie]

It is Object Oriented...until you get to the Controller delegate class. And, unfortunately, that's where most of the time is spent (at least...in my case it is, since their models are thin).

I've been basing my content type off of the article content type already out there. Some of what they've done is disturbing. There's 70 lines of code in vBCms_Content_Article:opulateViewContent that deals with comments that doesn't belong in this class...it belongs at least one level up. The content type shouldn't care about how comments are stored, or where they are. The framework should. And, if/when IB ever changes that, every content type you write is going to have to be updated (presuming you allow comments).

With 4.1.5, they also slightly changed how preview images are done. They're now checking to see if there is a thumbnail, and if so, to use that. Which is great, until you realize that that code is sitting smack dab in the middle of vBCms_Content_Article:opulateViewContent. However, it should be in an external class so that ALL content types can use it (and benefit from it).

There's a lack of consistency among variable naming that I found...annoying. Do you use underscores between words? Or just ram them all together? Both examples are used in the codebase. I loved how, within the article content type (preview view), they assigned the reply count to the view THREE TIMES. Surely, the last two were just to make sure it understands?

When you get down to the nitty-gritty, some of the comments are also atrocious. Within the same file (vBCms_Content_Article, although, I also found similar code in the section content type) you'll find this:

PHP Code:

/**** This saves the data from the form. It takes no parameters and returns no values
     *
     ****/
    protected function saveData($view)
    {
        if ($this->data_saved)
        {
            return true;
        } 


Seriously.

What's worse is that this function is called in places before there's a view established. Had anyone bothered to type that variable, they'd have found that bug really quick.

I'm also not 100% fond of the fact the CMS fails when I have to turn off a plugin that establishes a custom content type. It seems like they could have prevented that somehow.

I'm currently working on the config screen for my review content type. I'm still trying to decide if this is really worth the trouble. While the framework shows flashes of brilliance, it also shows signs of being thrown together quickly, and when they come back through and clean it all up, I'm not sure I want to rework my stuff to fit with how they've changed. Especially since I'm really not sure when any of that is going to happen. Nor am I sure I want to kill my CMS if I ever need help from customer service.

Anyway, the skeleton took roughly 6-8 hours to establish and get working. Some of that time was spent researching methods/classes within the framework. I also spent some time establishing some helper methods that will likely cut down on some of the keyboard time I'd have to spend...which leaves a lot of the work I'd spend doing on a future content type rewriting the code I think should be abstracted out. So, no. It's not tough. Especially if you've worked with MVC frameworks before. If I go through the trouble of finishing, I'm refactoring to push more of the data preparation to the model. My goal is to create a fat model (with a base model that other content types can extend), and create a controller delegate class that I can basically just configure and let run.

I just find it disappointing that nobody's found time in the last 18 months to make this process better.

[Alfa1]

I added your remarks to JIRA:
http://tracker.vbulletin.com/browse/VBIV-12910
http://tracker.vbulletin.com/browse/VBIV-12911
http://tracker.vbulletin.com/browse/VBIV-12912
http://tracker.vbulletin.com/browse/VBIV-12913