CCK Capabilities: In the Core, How to Discuss?

For some time now, there has been heated discussions in the Joomla world about the need for "CCK" capabilities in the core installation.

There are different opinions about what "CCK capabilities" means, but in my opinion it involves at least the following:

Capability to create custom fields for Joomla content rather than having to only use built-in fields
Capability to accept front-end content submissions through forms comprised of the custom fields
Capability to search based on material submitted through the form fields
Capability to track user rights on forms and content, using the custom fields for editing

It is reasonable to ask for such things in a CMS as big and important as Joomla. For some people, it is a glaring hole that such capabilities are not built into the core.

I have spent the better part of this year investigating all available CCKs in the Joomla world. After an exhaustive search, I have settled on using Seblod for various reasons. Along the way, I have been attuned to the larger debate about whether to include CCK capabilities in the core. My search has also brought me outside Joomla, looking at other CMSs like Drupal, ExpressionEngine, and MODx, and to PHP frameworks like CodeIgniter and Symfony.

I'm not focusing on the nitty gritty of my CCK search. For now, suffice it to say that the more I use the Seblod/Joomla combination, the more I like it for a CMS option. For a framework, that's a different story. However, in this discussion, I'd like to focus on more general opinions, and open up for debate various ways to look at the "CCK" concept in the unique Joomla environment.

I have three goals in this discussion:

Find a better way to discuss CCK capabilities that gets away from Joomla vs. Drupal comparisons
Better understand whether CCK capabilities can and should be part of Joomla core
Consider what form CCK should take in Joomla, if it is to be part of the core

This post is my way of trying to make sense of what I've learned, and hear from others who have been thinking about the same subject.

Assumed CCK

On one hand, the call for CCK capabilities to be included in Joomla core is reasonable. I mentioned other CMSs and PHP frameworks. In those other systems, what we call "CCK" is an assumed element of site building. If you go into those other communities, as I did, and ask about "front-end submissions," people literally don't know what you're talking about because they just see it as knowing how to use the right PHP functions. They don't use the term "CCK." They just do it. This tells you something.

Wrong Comparison?

If you do various Google searches on CCKs, the hits include reams of discussions where people compare Joomla to Drupal, and sometimes to WordPress' custom fields. But I think this is the wrong comparison. Maybe it is odd to say this, but in the larger scheme of things Joomla and Drupal are more similar than different -- if you take a larger perspective and think of general Web design practices. Both view a CCK as a UI extension or module built on top of an existing system.

The difference is, Joomla has a framework at its core. Now, I don't think that framework is very well documented (we'll save that for another discussion), but the fact that Joomla has a full framework separates it from Drupal or WordPress in crucial ways. Rather than comparing Joomla to Drupal or WordPress, perhaps we should compare it to PHP frameworks or to CMSs like ExpressionEngine and MODx. Take a look at the way CodeIgniter or Symfony do CRUD. Look at how they document their frameworks. Can Joomla match that?

I mean this in an encouraging way. It would elevate Joomla in the whole debate to compare itself to those systems.

Assuming that Joomla should compare itself to frameworks or framework-based systems, what's the best way to make better use of Joomla's potential from the moment of installation?

Choice 1: Include CCK in the Core?

At first, all this seems to indicate that a CCK should be "in Joomla's core." We see a lot of people using this language in CCK discussions. But what does that mean? After all, anyone can essentially put a CCK "in the core" by just installing it, right? At the same time, every CCK has its own syntax. Yes, if something like Seblod was integrated from the beginning, it would probably end up looking different than installing it. And if Seblod was a part of Joomla core, Joomla would probably end up looking different as well. But the fact that Joomla uses a framework means that there should be a way to utilize available functions as part of the core (again, based on the idea that CCK can be an "assumed" element of building sites and not an "extension").

Since Joomla is based on more UI-type ways of doing things, for the moment let's assume that in Joomla a CCK would act differently than the same capabilities in a PHP framework. In other words, Joomla users probably won't be expected to build PHP forms to make it happen. It will be a set of UI functions, which always means setting some assumptions and limits on what can be accomplished.

Joomla is built on choices. Regarding CCKs, there are several: FlexiContent, Form2Content Pro, K2, Seblod, Zoo, and others. In my research, I've seen benefits to each one. They are different, and each has supporters. It's messy, but then again the Joomla world is more messy than the world of good frameworks or framework-based CMSs (perhaps the subject of another post).

Is it possible for Joomla to add core CCK capabilities without angering users and developers who are devoted to one of the existing extensions?

Is it even desirable to add CCK capabilities to Joomla core? If so, what would the steps be? How long would it take?

Choice 2: Better Document CCK Possibilities of Joomla's Framework?

CCKs (or the assumed set of steps that equates to what we call CCKs in Joomla) are by nature complex. That makes me wonder about making really deep CCK capabilities truly accessible through UI applications. All of the CCKs currently available take a lot of time and patience to understand, use, and build anything unique. Of all the criticism of Seblod (my chosen CCK), complexity is at the top. But let me be clear: I don't see this as a negative. I think there is inherent complexity in the very idea of "CCK" capabilities, and there is only so far you can go without "getting your hands dirty with code."

This brings us back to the idea that Joomla is built on a framework. Maybe we would be more successful changing the discussion to focus on documenting the Joomla framework better, so more people could build CCK-like functions as people can do in CodeIgniter and Symfony? Maybe we should drop the "CCK" term altogether and just focus on how to build particular CRUD actions? This might help elevate Joomla beyond faulty comparisons with Drupal.

Whatever the Choice, We Need a Direction

There are, of course, many other ways to look at all this. I'm just offering my insights after an intense period of looking into the matter. For myself, I now straddle two worlds: Joomla on one hand and PHP frameworks on the other.

One thing I feel pretty certain about: the Joomla world needs a coherent response to the call for CCK capabilities. There needs to be a message about how to accomplish this in Joomla, and honesty about the complexity of the goal. When it comes to CCKs, I think regular Joomla users need to know that it is not something that can be done with a simple "extension." By nature, a good CCK is different than any other extension. And as this discussion ensues, Joomla needs to focus on the fact that it is based on a unique framework.

What are your thoughts about all this?

While we're on this subject, please also check out Joss Sanglier's related post.

Tags: CCK, CodeIgniter, Drupal, Fabrik, FlexiContent, Form2Content, Frameworks, PHP, Seblod, Zoo

Comment by Joss Sanglier on December 6, 2011 at 12:22pm: Hi Matthew, I think part of the entire problem is the idea of a CCK at all.

With Drupal (and the same could happen to Joomla) a CCK was imposed on top of the existing system. With Joomla, what we think of as CCKs do sit rather uncomfortably on top of Joomla - even the new Seblod.

CCK type functionality built properly into the "core" would mean that the system would not be additive but inherent to the system. So, the standard #_content table would actually be a product of the CCK system rather than the other way around.

At that point, the entire idea of a "kit" becomes daft, since the functionality is actually controlling how the content side of the database is constructed, managed and used

How does this affect third party systems? Well, it doesn't have to, of course. Since the product of the new system is basically the same tables with the same names, other developers can still build on top of it if they feel that their way of managing content is better than the new joomla way of handling content.

There is an inherent problem with an add-on CCK - really it is a CMS on top of a CMS. With K2, that really is the case.

It is like adding more wheels to a car rather than fixing the ones it already has. From my point of view, it would make a lot more sense if talented people like the Seblod team were creating plugins and extra functionality for a solid joomla system rather than have to fill in the gaps first, which is what seblod does.

Comment by Matthew Schenker on December 6, 2011 at 3:11pm: Hey Joss,

I agree with you about the very concept of "CCK" and the idea of the thing being "imposed on top." That's why I believe Joomla and Drupal have more in common than it would appear from all the CCK debates.

A year ago, I thought "front-end submission" and "CCK" was some special effort. But as I began working with PHP frameworks (my favorite being CodeIgniter) I've learned more about the MVC approach and come to see "CCK" as something that should just built into proper Web work. Then I learned a bit more about Joomla's framework and began wondering, "So, why can't we have more natural ways to do CCK-type operations here?" Maybe it would just take better documentation (the material I have seen on Joomla's framework usually leaves me more confused than I was to start off).

Sometimes I think the only reason it's special to talk about "CCK" in Joomla is because there's no clear way to use the Joomla framework as one can use CodeIgniter or Symfony (for example). An extension like Seblod opens up a world that should be open by default!

There's strange thing behind all this is that Joomla is meant to be easier to use. For beginners, it is. And for advanced developers, it is. Where it's painful is for "intermediates" like me who are ready to go beyond UI stuff but who don't have enough coding knowledge to decipher Joomla's framework on our own. Strangely, for someone like me, it's actually easier to build a project entirely in code using CodeIgniter.

For me, Seblod has saved Joomla. If it were not for Seblod, I would probably have stopped using Joomla a while ago because I would have hit an absolute roadblock.

Thanks,
Matthew

Comment by HarryB on December 12, 2011 at 2:06pm: I thought Drupal 7 had basic CCK functionality built into the core. And that it is both additive and supports the default content. Or am I missing some point here?

Are you talking about the physical database table structure and how CCK is implemented rather than its functionality?

Comment by Matthew Schenker on December 13, 2011 at 5:35am: HarryB,

My point was that when the subject of CCKs arises, the immediate comparison everyone in Joomla makes is to Drupal. On one hand, this makes sense. Both of them look at CRUD operations as something you add on in the form of a CCK. But since Joomla is based on a framework, I think it should leave behind this comparison and instead aim to achieve what is done with a framework (e.g., CodeIgniter or Symfony) or what is done with a framework-based CMS (e.g., MODx or ExpressionEngine).

Now, if you look at those systems, there is no "CCK" discussion. They take it as a given that CRUD operations are just something you do. In fact, with frameworks, "CCK"-like operations are such a basic assumption that there is no such thing as a site that doesn't do it right from the start.

This is the attitude I'm hoping can be developed in Joomla. How do we make it so the idea of "CCK" is so built in that we don't even think of it as anything but a normal step in site building?

If you start down this path, you'll realize that this line of thinking gets into the very idea of what we think of when we think of page creation in Joomla (for example, default fields vs custom fields). At that point, we can start to consider what we need in a "core CCK."

Thanks,
Matthew

Comment by Eddie Luc on December 14, 2011 at 7:18am: Fabrik does a really good job.

From the point of view of Drupal, CCK is extensible.

Once you create a CCK in drupal, other modules can:

- use it, ie. drupal locations module. views module.

- built on top of it. gmaps etc.,.

- extend it, views module

So CCK is like OO inheritance in some ways with Drupal.

With Joomla, so far, the CCK apps are confirmed within the developer's domain, other groups cannot really use it or extend it. It is creating silos.

cheers

Ed

Comment by Joss Sanglier on December 14, 2011 at 7:52am: I am writing a large document that basically goes through the possibilities of building a CCK into the core of Joomla. It is non technical (because I am non-technical) but maybe it might give some brave Joomla devs a roadmap to follow.

Comment by HarryB on December 14, 2011 at 8:02am: Eddie...

+100 !!

Comment by Matthew Schenker on December 14, 2011 at 8:17am: Eddie:
I've used Fabrik, and found it to be a powerful application that crosses the bridge between a form component and a CCK. This raises another angle on the CCK question. In Joomla, even a powerful form component has a difficult time getting true CCK capabilities. For example, I use RSForm Pro. It can track who submitted a form, and filter information based on the submitter. But to go to the next level and allow users to edit (update) or delete their own entries with RSForm Pro is very complicated. In a proper CCK, all CRUD operations would be one and the same. I don't know all the reasons, but somewhere in Joomla's core are roadblocks to natural CRUD operations, which is why (I believe) we end up needing CCKs. And that leads, as you put it, to this scenario where each CCK creates its own environment within Joomla. If this were not true, we would not be having discussions about CCKs. Instead, it would just be assumed as something you do with Joomla. And that brings me full circle to my point about looking at frameworks and framework-based systems, where no one talks about "CCK" and instead just creates forms with CRUD operations.

Joss:
I think it's great to develop some materials to move the discussion forward and challenge the Joomla community to solve this dilemma. I look forward to seeing your work!

Comment by Amy Stephen on December 16, 2011 at 10:21am: Agree Eddie. Not sure I see collaboration improving in the Joomla community anytime soon, either. The ecosystem is just not setup in support of that.

The Joomla project is talking about an integrated content environment of some sort that they hope to include (last I heard) in the framework that will be in 2.5. That environment will not be immediately hooked up to the CMS but it is intended to provide that common architecture that the various CCK people can use. Not sure if it is also intended to help with extensibility and interoperability between extensions, or not.

Not been around a lot because I am slammed - working on Molajo, life, etc.

Nice to see everyone.

Comment by Joss Sanglier on December 16, 2011 at 10:25am: *Waves at Amy"

I was just thinking about you! I will be sending you the link to the PDF I am currently slaving over when it is finished. I suspect that because of its nature, it may be of more interest to Molajo that Joomla, though I am very happy to be proved wrong .... again.

CCK Capabilities: In the Core, How to Discuss?

You need to be a member of All Together, As A Whole to add comments!

Badge