Has anyone succesfully managed to create a CMS content type?

[Alfa1]

Edwin Brown posted a blog on Programming your own CMS Content Type. (http://www.vbulletin.com/forum/entry.php?2396-Programming-your-own-CMS-Content-Type.)

I wonder if anyone managed to add one. I'd love to see it.

I have searched vb.org but AFAIK there is no hack here that introduces a new CMS content type.

[Alfa1]

It has been a few months since this thread has been opened. Has anyone succeeded in creating a CMS content type?

[Andreas]

I did a Proof-of-Concept implementation last september with Alpha 2 but never released it.

[Alfa1]

Andreas, could you share that proof of concept?

As we are a year later now, I wonder if anyone else managed to create a custom content type?

[Dead Eddie]

Andreas, could you share that proof of concept?

As we are a year later now, I wonder if anyone else managed to create a custom content type?

I did half a proof of concept about a year ago. From what I recall, the blog post wasn't much help, so I copped a lot of it from the code within the article content type and reading through the abstract classes.

As I recall, the process was about twice as involved as I'd imagined it needed to be. The more I hacked away at it, the more I began to realize why they made certain decisions, but I don't remember if I agreed with those decisions or not.

Ultimately, I quit because there was a bit of effort involved (learning + doing) for what was essentially a proof of concept that I didn't have a use for. Didn't want to keep going on something that I wasn't going to actually use.

I'm going to start a very simple content type (stores TV program description, meta data on those shows, and a basic review) over the next few weeks. Or, at least after I get my current project off my to-do list.

[Alfa1]

Please let me know when you have more information about CMS content type creation to share.

[arvid]

But there is an example in the blogpost you linked to in the first place? What more do you hope to get out of someone else's proof of concept? I'm just in the middle of creating my own content type, but sadly I cannot share it due to contract regulations...

[Alfa1]

I have yet to see one working custom content type. Various addon coders had planned to make their addon into a custom content type but none actually did this.
Dead Eddie found the blog post to be of little help and he had to study the article content type. So that explains a bit.

I need to create at least 6 new content types and these will become my big board its main content. It will grow big and active so I really need it planned well.
My main concern is if vbCMS has the needed architecture to be effectively contain complex content types and the associated comments. Do you consider vbCMS a solid foundation to build upon?

[arvid]

So far into the project I find everything solid, but I'll try to get back to you here to write about any hickups or thoughts as the project moves on.

I haven't come that far yet though - started researching yesterday and building initial proof of concept half through today. :) Hoping to have my basic proof of concept ready sometimes early next week.

This far though I find the linked article quite useful.

[arvid]

Well, now a week later I have a first draft of the content type I wanted to create.

My thoughts this far:

- The framework is great and seem quite solid
- The code commenting of the current content types are sometimes a bit lacking and/or outdated
- The blog Edwin wrote is really nice and helps alot, but some parts are referencing outdated names / functions
- If you're not used to object oriented PHP programming, the learning curve of programming your custom content type would be quite steep
- If you have experience in coding custom widgets it helps since some parts of the process are overlapping

[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 (https://www.vbulletin.com/forum/entry.php/2396-Programming-your-own-CMS-Content-Type.) (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 (https://www.vbulletin.com/forum/entry.php/2370-Widget-Programming))
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 1312462546 at 1312462546 ---------------

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::populateViewContent 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::populateViewContent. 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:

/**** 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