[4.0] Multiple Content Types (feature request)

[xmanflash]

I think a very powerful new feature could be added to Joomla very quickly, namely a Content 'Type' system.

As it stands, we currently have "Content" and Components. If we want a Content type of 'Event', it needs setting up as a category within Articles, or as a custom Component.

Developers/Web Admins then have to setup custom fields based on Category, at which point we have tried to setup a 'Types' based content system that is limited in terms of ordering articles across multiple Categories and so on.

I propose that there be a Content "Type" structure, (possibly with custom fields attached), that then allows the creation of Categories, Tags and Articles under each Type.

The "Articles" type comes pre-installed as per usual, but others can be generated at will.

The Admin Menu could then be changed to something like

"Content"

Articles
- Categories
- Tags
- Custom Fields

Events
- Categories
- Tags
- Custom Fields

This is obviously something similar to Wordpress / Cobalt / K2 and so on, but its almost just a rejigging of whats already there and could be fully compatible ongoing with previous versions of Joomla.

Components could automatically use and create these Content Types instead of introducing their own custom page / layouts, and then all the templating can be done around Joomla Content, not custom developers ideas of what Content should look like.

This will save us a lot of time at development and I think organise content better.

It will also make template overriding easier, and I think in many ways simplify Joomla in an area where many customers often get very confused (in multiple Components)

What do you think?

[ssnobben]

Great idea.

[pepperstreet]

I agree with the general idea and how it might be exposed to the user in the UI. Actually I am thinking about it since JoomlArt came up with their "content and menuItem" extends. They also integrated a modified "New Xxx content" button, which extended the regular new-button. Also the SeblodCCK exposes an extended "New" button and dialog. Indeed, something like this is missing in the core.

Since you mentioned the term "content type", I think there are two different approaches to integrate this idea and workflow. Technically there are different content "types" in Joomla, but I am not sure if this is comparable or even usable for this idea. J! types seem to represent really different things... to my knowledge it's more based on each component. Your screenshot and most applications would need "Article variations", so everything could stick with core articles.

Since Joomla supplies the new custom-fields and everything works on category-assignment, it could also make sense to use this as a technical basis. Some sort of an improved/extended UI that visualizes the different "types" creation. The new-article-process is easy if you know Joomla for a while... but for newbies it might look strange to create a generic article... then choose a category... and then, all of a sudden, they realize that there are different fields/tabs available. Easy to overlook, IMHO. Maybe a message/note could inform the user.

I am just thinking loud...
Everything could still work with com_content – just articles, categories & custom-fields. Currently the NEW article creation has no option to change the name, nor expose a different named button. Or an upstream dialog that lets me choose "what" type of article I want to create.

Currently there is only "Alt-MenuItems" and Overrides. No doubts, this is a great feature for frontend-submission, but more targeted to developers. I always missed an Alt-Submission form in Backend. BTW, it seems we can access an alt-form layout through the new custom admin menus... if I could add custom URLs to pre-filter the articles-manager... I could solve the initial question and type setup with core... (Wow, have to try that ASAP! ;) Haha, here is a related issue to improve the current Admin menus even further #17407 )

Maybe we can achieve a smarter and flexible article creation workflow.
Looking forward to the J! future :)

[artur-stepien]

I think that should be one of the priorities for J4. It is one of biggest disadvantages against Wordpress and Drupal. It is hard to explain to a regular user the concept of articles. And not without reason. In the end, what does article have to do with eg. car manufacturer, car model, car version etc. That makes no sense for the end user (and those websites are build for them). Joomla! code looks great, but it is time to worry about user experience and the general concept of content management system (cause now it looks more like a "articles management system".

[mbabker]

There's already the API and data model for this in core, UCM. But to be blunt, I don't see it being adapted because it comes with a major data migration (in addition to API and data model B/C issues), not to mention that there are critical pieces of the API that aren't well suited to work with this model (we lack a relational table schema, JTable has zero table relation awareness infrastructure). I had a rant about this the other day, hopefully the comments I'm copying into here make some sense without the full thread context:

At this point it's less of a code compatibility issue and more of a data compatibility issue, trying to migrate to where the UCM and content type tables are the root storage of all the things with the existing tables shortened to only be how they extend the core UCM data model would be about as painful as the 1.5 jump. And we all remember how that ended.

(For this one a question was posed regarding whether those issues with the migration complexity were a reason not to do it)

Well, is the risk of pissing off what's left of the ecosystem to do a major data model migration worth it? I don't think so. I don't see how core can responsibly migrate the data of just its 5 frontend facing components (content types), let alone provide the tooling needed to facilitate extension developers doing the same. From my perspective, there is a lot of tooling we have to put in core to fix a lot of the weaknesses, starting at the database layer (proper change delta management, proper tooling to analyze schemas, proper tooling to validate expected schema state versus what's in production; no, these SQL diff files don't count) and working our way outward, before we could even reach the point of having a useful data migration platform to go from the current status quo to UCM.

[brianteeman]

on the reverse its hard to explain to a user that they have to create their content-type from scratch every time. Drupal is not wordpress. wordpress is not joomla etc. every cms has its place and none of us should try to pretend to be the other

[helpwise]

Why is anybody creating a Type ? It would come with the normal "article" type as default. Nobody would see any real difference. It would also be able to be backwardly compatible.

We have normal and advanced SEF URLs in play today - select-able by Admin option. I am sure this could also be an 'advanced' option.

Even if it was built and enforced, it would be simple to import all old articles content into the same structure with an "Articel Type" and a half witted template rendering the same old stuff.

But with the schema and interface in place the renderer could also be smarter, and use the new features.

For almost all of our big customers we have to write custom components to get this capability.

The we are not wordpress/drupal argument is moot. Drupal and Wordpress have some great features Joomla is missing. Joomla has some great features they are missing. Are we thinking of users here ? Or are we (my team) the only people who have users that actually want to use Joomla for more than just a clunky blog, without having to build everything from scratch outside the weak articles framework ?

K2 did a lot of the work already. Cobalt was amazing but too technical, but neither are core, users see a different interface, and that is one of Joomla's natural weakness for users - custom components all look different.

We have just spun up a site running 50 individual membership clubs, each with their own subsite with multiple pages (replacing a wordpress multi install) and its so efficient that real life club admins love it. We had to build a full custom content component, a react front-end to ingest content updates, drag drop images and so on because Joomla is so limited in multi type content management.

We also had to write a system that managed Joomla's Menus for the over 500 menus at play.

Its running on AWS behind a load balancer and twin server RDS solution with Cloudfront (after some interesting technical challenges with referrers) and it absolutely sings.

There is a lot of good work Joomla could perform, with a lot less customisation if its masters had a cohesive vision. The politics of the Joomla decision strategy seems to be made by tech, who are always to busy and too burnt out to have vision. (I know this feeling first hand)

Let make Joomla great again. Or just keep tacking on things other people built for their own needs.

J4 missed a huge opportunity here to fix the weaknesses and make itself a platform for a much broader larger audience and its sad but inevitable that except for those who custom build around its weaknesses, its losing relevancy to most markets now.

[mbabker]

WordPress and Drupal both have a data model where they expand on some form of "type" system (Drupal is more CCK like whereas WordPress focuses on the "post" data structure as its types). Joomla's type system is standalone components whose data modeling and structure are defined by whomever is developing those tools, there isn't a UI to create these "custom" types in the same way you can with other CMS' without use of a CCK based component.

So it's not necessarily that Joomla doesn't have a type system available. It's just that the core data model was not designed to be one in the same sense as the other CMS', and there are pros and cons to that decision. And it's not that core couldn't be upgraded to have a native type system in the same sense as the other CMS', but is the pain of a complex migration going to be worth it over the long run (and I would suggest the answer is no, historically the project has not managed major upgrades/migrations very well and that mismanagement has influenced users into moving to other platforms since they have in essence had to start from scratch anyway, we may be getting better at managing our patch and minor releases but I'd suggest the project still has a long way to go to earn the trust of being able to do a complex major upgrade, and in some ways 4.0 is that test (without re-engineering the data model)).

[helpwise]

I agree with you that this is what is happening. Lack of vision and a strong sense of tech innovation could save Joomla, but fear of the past is holding back any real innovation. And the horrible thing is that the more we bolt on to Joomla (workflow etc) the more will need to be modified to make content types happen.

J4 should have been a make or break in my view. J is doing so poorly now in the numbers game that if we don't have all bases covered there is no real story. Content Types / and then being able to not have to create an XML file to create a menu item would have done it for us.

We have a system that has all the bits in play to achieve what we (I) want, and a small amount of rewiring to make it happen.

Such a shame.

[artur-stepien]

@brianteeman Its not pretending, its filling the gaps and that one is a big one. You ain't gonna explain to any of the users why their cars, books, computers or cartoons are articles. And no one is saying that Joomla! should not have a default "article" content type.

@mbabker I'm not after changing the component concept. I think its a great one and works better then what is build in Wordpress. If you're trying to build something bigger based on Joomla! for that its essential for many reasons. BUT you ain't gonna tell me the current "articles" component makes sense. Its placed in "Content" menu item that basically holds a single content type (why not change the item name to Articles if you can't reliably hold anything more then that in com_content, don't pretend its something bigger if those are just articles). I'm after fixing something that holds back the base of the Joomla! from version 1. Ask any one that builds websites for the clients if they are happy with Articles concept and if they would not like a content type base component.

As for how to bring it into the system. Why not start it as another component. Bringing it to Joomla! on 4.1 - 4.2 and then replace the com_content in 5.0? Give people the time to migrate and till then chose for their own if they prefer the articles concept or a content type concept. No need for rushing up things to 4.0 if there are risks like you mentioned.

[helpwise]

Exactly :)

[ssnobben]

Seems develpers dont understand the markets need and developers frustration. Ask your self why Joomla is not used anymore for publishing newspapers worldwide or e-commerce, blogs etc... What is Joomla and where its heading? Is it was it controlled by core developer(s) that already left the building?

[mbabker]

It doesn't matter when it's introduced, there is still a B/C breaking data migration involved (if built on the existing UCM model then you have to move data from #__content to #__ucm_content then drop the extra columns from #__content leaving only the com_content specific addons to the UCM model in place; same goes for banners, contacts, newsfeeds, and weblinks from a core perspective). That's looking solely at the data model/schema, unless you really want to have duplicate data spread all over the database and try to hook everything in Joomla to make sure said duplication stays in sync.

This is one of the times I'm annoyed that people flat out deleted our GitHub repos, there was work on this (and a bunch of other concepts actually) done in the old https://github.com/joomla-projects/joomla-cms repository that is now lost that could've been used to at least review, but now we're starting from scratch without any of the experience or ideas from anyone that played with the idea of such a migration.

Articles are an overly generic term. Until you start trying to slap things like custom fields in place or make adjustments to the edit page that really makes it feel like a specific content type (book, computer, etc.), at a high level it's a very generic catch-all type of thing. Content types, as I see them in WordPress (I don't work with Drupal enough to understand that system), cover a level of "filling the gap" in explaining to users they put their computer data posts as one content type, cartoons as another content type, etc. (which inherently makes doing some other customizations, like theming or options specific to a type a bit easier; WordPress posts and pages are in essence the same thing aside from the options in the sidebar) but in reality it's all the same thing but with UI friendly terms to make the backend navigational flow feel a little easier.

[helpwise]

We already have two SEF modes in J.3 , normal and advanced.

I don't see why we cant solve this issue with two publishing modes.

Sure its extra work, and sure people screwed it up with big code changes before, but we can allow people who want to do the advanced to do a one time convert, and then remove the legacy stuff in J.5 after a 3 years adjustment in period. I know that's a simplification of the tech, but its breathing oxygen into a stagnant pond from my point of view, which is slightly larger, more customisable (not blog) Joomla sites.

Having said all that I only push because for the last 20 or so years I have loved working with Mambo/Joomla and its close to my heart. I am happy to move on if commercially necessary. But its soooo close to being awesome. The heart seems to have been kicked out of it. But again I do appreciate all the effort having been put into it by everybody involved. Even those I disagree with ;)

[brianteeman]

@artur-stepien that is your opinion. i dont share it.

[artur-stepien]

@mbabker I do understand the issue with extensions/models/tables naming. The way how this should be implemented is something to discuss. Didn't saw the concepts in old repos you are saying about so I can't judge if they where the right direction, but they definitely show that there is a need in the community. And I can safely assume that this problem is one of the reasons that Joomla! doesn't keep up with Wordpress market share. It's hard to show end user the advantages of Joomla! if the main thing they see are difficulties in content management.

@brianteeman It isn't an argument. It's exactly a lack of one.

You can always create a survey at joomla.com and ask people what would they like. Both developers and end users. If that is something people are expecting, or if they are just fine with current situation. That will show you the big picture.

[ssnobben]

There is no investingation, no survey, no real user UX/UI testings and vision about the future market and needs. I just opinions everywhere...

[mbabker]

Surveys are biased toward what the survey writers want to glean and are only going to get responses from people either following the comms channel or interested enough to go out of their way to find it.

I can think of a few polls/surveys run informally by people or formally by project teams in the last few months that were very biased toward pushing their agenda, and only one or two where they really were unbiased information gathering attempts.

And to be honest, I think you're going to get a lot of end users who respond with things like "merge K2, JCE, and Akeeba to core" (which is exactly what the old ideas pool became before abandonment, I can still screenshot/datadump that if anyone wants proof) and IF you get developer responses it's either going to be at such a high technical level that end users aren't going to grasp it (which is why I've given up on a lot of architectural related changes in core and let the people who want to play with the UI do so because that's where user interest lies), a "don't touch the stinkin' API you fools!" message, or they're going to shrug it off because they've abstracted themselves so far away from core with their various RAD layers or internal frameworks that what core does doesn't matter to them.

[brianteeman]

but they definitely show that there is a need in the community

the fact that they never progressed beyond the basics shows what the interest was

[helpwise]

The arguments against this feature have always been "its too hard, and will break joomla like 1.5->2.5 did, and nobody has time anyhow". It never mattered who wanted it.

[adankupapa]

@mbabker per the last part of your comment, don't you think if things continue like this, Joomla will reach a point where it will have to be developed from scratch? Ignoring important things for the fear of breaking the system will just make it more difficult if the new features become inevitable. A stitch in time they say, saves nine. Why postpone the inevitable?

I believe the most important question we need to answer now is whether adding content types feature will make Joomla better in any way? If the consensus is YES, then the next question is CAN IT BE DONE? If that is also a YES, then we come to the HOW. It is at this point that one would expect the architecture arguments after which the leaders can set a road map.

@artur-stepien suggested

Why not start it as another component. Bringing it to Joomla! on 4.1 - 4.2 and then replace the com_content in 5.0? Give people the time to migrate and till then chose for their own if they prefer the articles concept or a content type concept.

If we try to highlight the many possible challenges with a new feature request, Joomla will take many years to gain market share it deserves. For, this is feature that is inevitable. A time will come when every CMS will need content types because The internet is not just made up of Text and links anymore.

my humble opinion on this.

[ssnobben]

mbaker left the building... so thats whats its worth...

[brianteeman]

Its an open source project so start coding and when you are ready submit it as a pull request

[mbabker]

I'm going to play the FUD angle since I've already started on this path. Given Joomla has historically not treated upgrades/migrations with a proper priority (and the currently in development 4.0 is the first true test of whether this has changed), do you honestly trust the project today to release a new major version that contains major architectural AND data compatibility breaks that does not result in a mass exodus similar to what happened with the 1.0 to 1.5 followed by 1.5 to 2.5 upgrades? What if Joomla follows the Drupal 8 path where it releases without migration tools in place (D8 has been stable for over 2 years and the migration module will be "stable" in their release later this year, almost 3 years after 8.0; that says a lot)?

@adankupapa Answering your questions, yes having some form of UCM or content type structure makes Joomla better for users who use workflows that suit that kind of data model. Yes, it can be done. Is the amount of API breakage to make it be done worth it though? I honestly don't believe so. I honestly believe, in 2018, that if you want to use a CCK in Joomla, you install an extension which was designed as a CCK first. The Joomla core data model, and inherently core components (which are realistically just different content types; "articles", "banners", "contacts", etc.) are not built as a CCK or a type based system and to make it work you essentially have to build a brand new data model in parallel to the existing model, a brand new set of components in parallel to the existing ones, and have a system in place that either duplicates the data across both of those sources or migrate everything in a very transparent and efficient manner. Even with a new set of extensions and data model, you break every integration expecting to work with com_contact or com_content as they're written today (and the structure they've had for 10 years, give or take). It's at this point that you're going to cause chaos, even if the core system upgrades cleanly you are literally going to break so many extensions that end users who don't know or care what content types are or why they might be beneficial to them are just going to see that Joomla screwed up another migration, they're going to have to build their new site from scratch, and they might as well check out the other options on the market instead of sticking with their existing vendor.

[impressionestudio]

My opinion is that we don't have to make Joomla to be able to create different content types. It already does.
The article should be a (general) content item and with the help of the custom fields it will become any type of content.
Then we can organize the different content types in the (article) content categories.
Of course, the basic fields for each article or content item will be the title, description (or simply text, with the read more capability), intro image, full image, link/button.
The link/button will be something like the "read more" but it can be any type of link.

[helpwise]

Hiya - as you say - that's basically what Joomla is already doing.

The thing I am trying to get Joomla to do is allow different sets of custom fields to be assigned to different content types.

Most of my customers would benefit from this - and we have been doing this for about 20 years (since Mambo).

I explained in depth earlier, but there is very little reason (other than planning/effort) not to push the allocation of custom fields into a "Type" and then be able to have Event Categories under that type rather than hook Custom fields into Categories, which was basically a clever hack for single content type Joomla sites, but ends up being a bit of a maintenance issue for both the admin and also the coder when used in more complex sites.

Joomla has the Components system which was designed for this, but building a component for customers is complex and often not viable in a mid size site.

So you are left to deal with Component vendors who, bless their hearts, do a good job but all look UX different, code different and think different. You end up giving the client hotchpotch of admin interface on a per component basis with advertising all the way though it.

Content types, would normalise the middle size Joomla site admin UX to a large degree imho.

[artur-stepien]

@impressionestudio Explain it to the client that his Bikes or Cars are Articles or Content. Good luck with that, some will understand, some will be annoyed by the system and migrate to Wordpress in the future (something I saw a lot). In the current environment developer have to chose between his income and delivering user friendly interface for simple content. That's nuts. And how that works for the Joomla!, well ... check the market share numbers and how they changed last years. Acting like everything is ok is plain stupid.

[impressionestudio]

@helpwise @artur-stepien
Guys, what I currently do when I have a special content type (e.g. product, bike, project, house) which is more complex than a typical article is to create custom fields and assign them to a specific category (e.g. products, bikes, projects, houses). Of course, I almost always use the CSS grid in order to display that special content item in any way I like. Also, sometimes, Javascript code or article override is needed.

I have to admit that this solution is very satisfying for me and I have created very nice content types that are impressive, easy for the client and fast since I avoid additional components. But since we have multiple content types, it is better to use the term e.g. "content item" instead of "article".

If I understood correctly, maybe @artur-stepien wants something more than the above. He wants to have "articles", "bikes", "cars" and other content types totally separated and displayed separately in the content menu in the admin area. Maybe this is too much to be covered at this moment.

But @artur-stepien, I don't believe that Wordpress supports a better solution for this issue or others. The disappointing truth for me is that people are not going to Wordpress because it is better but because it is a trend. The most "developers" don't know to judge which CMS is better. They do trivial things like asking their friend/partner: "Which CMS do you use? Ok, I will use the same.".

Additionally, the web development companies that create tools, apps etc do not care if Wordpress is good or bad. They care to make money, so they create tools only for Wordpress which has the biggest piece of the pie.

That is why, in other discussions, I try to convince other Joomlers that we don't only need to create a perfect CMS but also to make it look like perfect, to look trendy, to look like a next generation tool.

[pulsarinformatique]

Hi
This discussion is the same years after years. A built in CCK or at least a real UCM with content types management system has always been a priority in the surveys but the lack of free developpers to bring it into reality and some reluctancy from old joomla supporters killed the CMS.

[helpwise]

Amen to that. We should not need work-arounds for CCK features in 2021. Joomla 4 took a long time to make so lets see if it manages to gain some traction, because a well thought out CCK would have really helped win back some market share and set a very powerful foundation for a fresh new Joomla ecosystem. As it is we have a workflow system that only 2 of my Clients have ever been interested in and a great new admin template that I cannot find anything in now.

Joomla is incredibly powerful. And yet very under-developed. I don't hold out hope for a Joomla 5

[brianteeman]

While people like yourself sit back and expect others to do everything for you .....

[helpwise]

People like me? Did you read the first post on this thread? The effort I went to, to put over what I thought was a simple suggestion that would greatly benefit the Joomla project? I spent time on that and it was feedback from dozens of projects that would have benefited. I am not a Joomla core programmer, even though I knew one of the v1 and 1.5 core dev's.

I did my bit. I passionately argue still for this feature. I cant help program it, so its all up to programmers to decide what goes in I guess. Which is exactly why Joomla is where it is.

[artur-stepien]

New year, same trend in marketshare. https://w3techs.com/technologies/history_overview/content_management/ms/y. Even Wordpress screwing up with Gutenberg didn't gave a chance for Joomla.
Lets pretend we have nothing to worry about.

[brianteeman]

Same old story, same old answer. If no one does the work then nothing will happen

[artur-stepien]

Let be precise. The answer was: do it, then we will decide if we want it or not. That is not YES. That is more of "invest hundreds of hours and we will decide if it is worth to consider". Would you risk like this?

[helpwise]

I am stunned that in 9 years nobody in the Joomla DEV community had the strategic forsight, or time to try add this to Joomla for V4. Joomla has changed very little functionally since version 1.5, which was fantastic. Whoever screwed up the 1.7/2.5 (that docman bloke?) and caused a bunch of good developers to leave, destroyed Joomla in my view.

[pulsarinformatique]

Yes, same very old answer that burried Joomla. I already proposed to PAY for it years ago but it had never been heard.
I urged some CCK editors, who had the skills, to 'offer' their solution to the core before they die but they also refused, arguing they would not offer their livehood but most of them were abandonned a while after.

So the question had NEVER been the money because Pulsar wanted to invest for it while Joomla was still a solution we could sell.
Now it's too late

[helpwise]

I am just staggered that the two persistent architectural problems with Joomla content building, 1. needing xml files for menu types, and 2. custom fields attached to content 'categories' instead of a new underlying content 'types' system, are not understood to be the basis on which Joomla could replace Wordpress in terms of providing a larger, more streamlined ecosystem for plugin developers and provide an ability to create custom content in any way desired by the customer without plugins.

I was going to put one of my team onto seeing how much work it would be to make an 'Articles 2.0' to help the project. I thought what I had suggested schematically was a blindingly obvious 'great idea' and would revitalize enthusiasm for Joomla to some extent, especially in customers.

It would require a new schema

content root >
types >

• workflows
• custom fields > (create database entry per field as post_meta is the bane of all wordpress performance)
• content >

•   assigned template
  

• default template
• menu

imagine if you will "So I can create a Products content type with some custom fields, assign a workflow and add a menu to it anywhere and all without any plugins and their myriad updates ? wow.. Joomla really is better for us (mid size business) than wp.."

We could call Joomla the 'business platform"..

I read that Joomla4 has taken 9 years to get to this point. I installed the release this week. Its very very fast. Love that. I cant use the new admin but maybe that's just me. I love BS5 so that's also good. Its a much better technical platform now.

But without adding new function for the consumer, Joomla is basically still at 1.5. Plugin developers have all but abandoned the platform. there is nothing new in the store. Joomla needs to be marketed on its strengths but its innards are still weak.

Is there somewhere else that this can be discussed where marketing types are involved ? Its obvious programmers just see this all as work.

[laoneo]

Why you want it in core, instead of using an extension?

[helpwise]

Its about a unified content architecture, that all plugins can work from and retain a cohesive environment for quicker and more well integrated extensions. There have been a few addons over the years, (one of the best being Cobalt), but they were all architected around their owners requirements and vision, not a generic Joomla structural vision.

Every component has its own Admin look and feel, which fragments a users experience when in admin.

Having this basic structure in base code gives a standard everybody can work from that will encourage plugin and extension development as a unified environment.

I understand Joomla was designed for each component to be its own ecosphere, but then again why not rip out the user system and permissions and so on - In my view because they are foundational and work across the platform, which I argue Content Types, (including custom fields) are also foundational.

What you sit on top of them in the form of Components and Plugins/modules can then be more easily implemented.

[ssnobben]

Its seems difficult to understand or visualize for some people unfortunately. We live in different worlds..

[pulsarinformatique]

This is an old discussion but having separate extensions that don't share a common model is a real issue when you developp rich websites.
I know Joomla is not WP nor Drupal but those two other CMS have solved this question.
When you deal with SEF routing, googlemap localizations, general searches etc... : you have to install the extensions of the etensions so that these horizontal features are properly done.

Our solutions (Pulsar) for years has been to use a CCK (seblod) but even so we end up with a sub CMS inside a CMS.

But I gave up expecting it to happen since we lack the task force and even of consideration to make it real. This is why we are forced to move to WP even if WP is a real piece of junk codewise and modelwise.

[brianteeman]

You just said: "you can code it and then ask to merge it (creating a PR with the risk to get it declined)".

The first part of the sentence which you ignored says

you can go through the RFC process: https://github.com/joomla/rfc (first approvment then code)

So what is your next excuse for not getting involved and expecting others to read your mind and do it for you

[helpwise]

If somebody had told me about the RFC process 5 years ago when I first mentioned this, I would have done everything in my power to work with that.

I thought I had a good idea, which was based on what I was experiencing when building sites with Joomla out in the real world with customers. I added it to the "Ideas" part of the project GitHub.

I would have been happy to invest, work on and discuss this with anybody.

But I was basically told it was too hard to implement and we don't want to be wordpress.

Well that is certainly working out isn't it.

Brian, I am sure you don't mean it, but you come across as somebody I would never want to work with, ever. Almost all your comments across github are aggressive and condescending. Maybe think about handing over to younger less jaded and more enthusiastic developers. You do a lot of damage here.

[brianteeman]

Maybe I am just sick of the same people (not you but others) repeatedly complaining about lack of features but refusing to help or even to submit a more fleshed out proposal than simply saying - we want a cck or we want content types. There are a lot of issues to consider when implementing a complete rewrite of how content is handled and it is condescending to think that people havent already considered these and made a choice not go down that road.

Create a document outlining the feature set you require AND addressing how existing sites are impacted and there will be lots of people, myself included, happy to read and discuss it. But right now its just pointless

[helpwise]

I went to a fair bit of effort I thought. I don't understand the code myself, but did think though how it would work frmo an interface and structural and have tried to be as open and thoughtful (and excited) as possible.

This was an ideas section. Not a 'deliver a proposal and we'll think about it section' of Github.

What do I need to add to my first post, to have it read by interested parties ? Others seem to have understood it, so whats acceptable for review ? Is there a template or spec doc or what?

[nibra]

An RFC for a CCK feature has been started some time ago: joomla/rfc#26 . It would be helpful and increase the chance for this getting real, if you could describe your favorite approach to a native CCK over there. I'll be happy then to compile your contributions into the corresponding document. The goal is to compare the benefits and odds of different approaches to get to an educated decision.

[pulsarinformatique]

Hi
We definitively don't need Joomla to become WP. At Pulsar we are selling WP sites as well and I'm astounded how bad the WP architecture is. There is no separation between the behaviors and the templates , it's a real mess. There is no coding, just hachink!

But there is one WP shining feature that makes a big difference : almost all extensions share the same model and can communicate with each other.

I can understand the commun Joomla position that stands for providing a common architecture for each component. If we are not happy with com_content let's use another component (CCK or anything else), that's fine... at first glance only.

The big issue is that each component editor has to provide ALL the ecosystem around his solution: the googlemap, forms, searchs, various lists templates, seo optimization ... Soon or later the editor can't face the tremendous demand from any kind of users.

The interest of an open source solution is to allow different developpers to bring new bricks to a larger project.
Splitting the joomla community into each component sub communities was the death of Joomla.

Each sub community can't have the task force to cope with the increasing demand and all the efforts are wasted soon or later.

This didn't happen with WP because of the shared model.

History repeats itself. VHS wasn't better than betamax or V2000, Windows wasn't better than OS/2 and so on. WP won and is still a pile of mess.

cyril

[helpwise]

Brian.

"Most of what you wrote there is based on misinformation" Please explain.

"Wrong" Please explain.

"Wrong" Please explain.

At least I have the decency to try to explain myself. You seem to be on another planet.

Can I ask you a question. Do you actually develop websites for multiple customers using Joomla? Because if so you don't seem to understand much about its glaring limitations at all.

[brianteeman]

My largest website is a database of the english language for cambridge university press with over 50 million entries. For answers to the rest anyone who has built a website should know why you are wrong in your statements.

[helpwise]

Why are you telling me about your single largest website when I asked you about 'multiple (meaning varied) clients ?

Is this a 'yours is bigger than mine' contest ?

There are so many good use cases for making com_content more versatile in my customer experience that I find it hard to understand anybody not getting the concept, hence my question to you being you are so hellbent on misunderstanding and then spitting on almost everything I write.

" For answers to the rest, anyone who has built a website should know why you are wrong in your statements."

Simply put all of my comments are correct, until you bother to explain why they are wrong.

Then TADA - surprise - I found out you tweeted this (obviously about me) on the 22 Aug.

"I told you I needed this feature 5 years ago and described its functionality in 1 sentence and you still haven't implemented it. You suck! - that's not how the world works"

1. WRONG: I politely suggested a feature that I though would be useful for Joomla as a project based on my 20 years experience in web development

2. WRONG: I wrote a number of paragraphs and a graphic mock up of an actual Jooma Admin - that I spent ages building to help explain my proposal. This was meant to be an introduction to a broader discussion.

3. WRONG: I never asked you to implement it. I asked for discussion and feedback and to see if it was possible.

4. WRONG: Nobody said or implied "You SUCK".

5. WRONG: Nobody said or implied "that's how the world works".

Brian, please stop being ridiculous. If you dont like the idea, fine - just ignore it and go bully somebody else. Others of us would
like to see it in Joomla and are trying to work out whether its worth the effort or not, and ultimately how it might be achieved.

Nobody is trying to force you to do or be anything so stop inserting yourself into this as though you are being constructive because you are not.

[brianteeman]

I am still trying to work out what it is you actually want

[ssnobben]

Still dont understand..

[pulsarinformatique]

the issue is not if all the plugins store their contents in the same table but if there is a common model that allow third party editor to developp new content types or lists or anything that can exploit the datas of the first extension.
With WP every extension can work with others while it's the opposite case with J!

[artur-stepien]

About the RFC argument. There is already an RFC for CCK created in January. Can you guess the response? I do joomla/rfc#26

[brianteeman]

That's more a placeholder than any sort of concrete proposal

[nibra]

It's the start of collecting approaches and their pros and cons, so that we can make an informed decision about the best solution for Joomla. It is only waiting for people to jump in. If I'm the only one who has to gather the information from all the different places, then it will have to wait until I have enough time to do it. On the other hand, if that RFC gets momentum, it will change my priorities.

[helpwise]

I think this will be a good place to start gathering data for a proper CCK style addition to Joomla. This thread has been arguing the case for a CCK, but in reality its a mini version of what a CCK would be and can be - a mid way point if you will, with not too much effort by the sounds of it.

Its possible that thread is about to get some comments of its own :)

[pulsarinformatique]

Actually, unless an existing CCK editor decides to "offer" its developpement to propose a new com_content, we won't have time nor the strength to wait for any viable solution to come.

CCK editors have very dark future with Joomla and may consider switching their business model and invest otherwise

[artur-stepien]

@pulsarinformatique In fact, I could create something like this but with current workload anything that could be called alpha would be ready not faster then at the end of the year. With testing, feedback and any fixes the window looks more like 2 years. But that's not a problem, the problem is a lack of will to implement that into the core. Without that there might be a problem with support.

@brianteeman You're talking about code or a brief overview of how it would work (how it would be implemented).

@helpwise When it comes to Custom fields I don't think you know what they are and how they work. They can be used by any extension. Binding them to Types is as bad as binding it to com_content. Its more of an optional functionality for developer use then a separate feature. Same thing with categories. They shouldn't have a separate link or section. They should be linked to a certain extension using them (they work strongly on context).

[brianteeman]

An overview. But something more concrete than has been written so far and including the benefits of such a system for the average web site and how to deal with existing site content.

[pulsarinformatique]

@artur-stepien : yes, delivering a stable and professional CCK or similar takes years! this is why I wrote it's too late to start writing it from scratch.

[pulsarinformatique]

Hi, again, since Joomla has this great MVC architecture with components, according to me, the only solution we have is to find an existing cck component and include it in the core package.
Unless we have a core cck, there won't be any real ecosystem around it. All the existing CCKs died or will die because of the ever diminishing base of users and no isolated editor can support it.

Many past glorious brands have known a rebirth such as Apple. It's possible but this renaissance always comes with the integration of a third party innovation in the core.

It's quite easy to define the list of basic requirements for this selected candidate. We won't all share the same priorities but we can define a minimal set of functions. Anyway the choice may be mostly guided by the agreement of the existing cck editor to "give" his baby.

But why would he accept it ?

Mainly because he knows that alone he won't survive and if his "baby" becomes part of the CMS core it will drastically increase the demand for support which is a very profitable business model.

Don't get me wrong, I'm not saying the embeded CCK is the solution because it is the shinning missing function of Joomla! What I'm saying is that without a common integrated content model we won't be able to recreate a large scale ecosystem that will guaranty the future of the CMS.

Integrating an existing solution is the only way to avoid wasting time.

[helpwise]

Brian, please define "the average website", if you believe this is a criteria. My view is that Joomla works best as a middle tier website, not an 'average one' which would statistically be a Brochure site.

[helpwise]

"When it comes to Custom fields I don't think you know what they are and how they work."

Actually I do know how custom fields work, and that they are a concept that can be applied to many different parts of Joomla - such as they were in com_users. We use this heavily.

" Binding them to Types is as bad as binding it to com_content"

Custom fields are implemented in the category part of com_content are they not?.

I simply suggest to extend com_content to include a foundational 'types' system and move (or add) custom fields to the 'type' rather than use Categories to allow that feature. Categories is the wrong place but because of the limited architecture available, I understand why it was included there.

My menu structure in the first post explained this in a way that I had hoped would be obvious, but everybody seems to be overlaying levels of confusion about what is being proposed that I had not intended or anticipated.

Either I had not explained it well, or people are not capable of reading well. Either way, the general enthusiasm for this seems highest amongst non-coding website developers, and lowest amongst Joomla coders.

[brianteeman]

@helpwise
Now you know why I was stating that fields is not based on categories

Where to from here

Instead of shouting that no one listens etc it would help if you tested the features that already exist for a very long time.

future full CCK style addition,

I still have no idea what you mean by this as opposed to what I outlined

@ all
Most of what you are saying is either unexplained or already possible. Please review your statements about "i need x or y" and try to write out a full sentence explaining the functionality. And when you have done that please review the sentence again to make sure someone who has never heard of a CCK will understand what you mean. And finally actually check that the functionality is not already possible.

[helpwise]

Oh Brian. You should have been a headmaster.

Now you know why I was stating that fields is not based on categories

• Precise application of fields IS based on categories. This is all about controlling content structures.

Instead of shouting that no one listens etc it would help if you tested the features that already exist for a very long time.

• what features already exist that I can test ? I asked for next steps to move this forward. We seem to have gone back..

I still have no idea what you mean by this (full CCK) as opposed to what I outlined

• The difference is that categories/articles would not sit at the root of the CCK. Types is the generic term for that spot, and upon it sit all the goodies. Custom fields, Articles, Categories, Tags, Filtering, template, workflow, menus and permissions on a per Type basis.

[helpwise]

@nibra "Please help to elaborate joomla/rfc#26"

• I have elaborated multiple times in many different ways over many years on this thread since starting it (as xmanflash) in 2018. Are you now asking me to re-elaborate on another thread, started this year? I have spent literally hours here trying to explain, only to be maligned, insulted and continuously misunderstood. I am not doing any more. This whole process is ridiculous. The idea is a good one. I give up.

[leoalv]

@brianteeman What you are saying Custom Fields is true. I agree with you that Custom Fields is POWERFUL and can be easily integrated into any component as I read in the documentation (I haven't done it yet). To talk about my experience I have worked a lot with it, solving many needs, and creating solutions such as portfolios, image galleries, reservations, etc. But to achieve this I have had to create XML files to be able to select when creating a menu item, and in that .XML file it is necessary to create the fields for the control parameters to display the content and then make the modifications and integrations to them. PHP files.

As we can see, in order to obtain great results and take full advantage of the benefits of custom fields, it is necessary to know CODE, because natively in COM_CONTENT it gives us the possibility of displaying the field data in the content events After Title, Before Content and After Content, which is not very good.

This gives us the conclusion that BASIC USERS who do not know code will not be able to take advantage of the benefits of custom fields.

So my question for you as a Joomla co-founder and for all of us who want Joomla to improve is:
What can be done so that end users can also get great results with custom fields?

[helpwise]

In Joomla AFAIK one HAS to use an XML file to change a Category Template for a Category Page using the Menu.

The template setting only changes the default article pages that sit underneath that category.

Which is why Brian's list of things that can 'already be done' is not correct.

[pulsarinformatique]

@leoalv and @helpwise : do you want to allow non coders users to filter a native 'list of articles from a category' upon the custom fields ? The requirement some of us repeat and repeat here and there is to have the same thing we have with tags : filters on custom fields :

I know it would require some 'matching criteria' to be defined (such as equal, %like%, In ....) but this could be a good start,

I can live with category = content type , this is not our main concern acording to me, but this missing filters are a real obstacle.

[ssnobben]

Yes that’s why I also proposed to use an integrated 250 kb executing rule engine in Joomla core architecture long time ago doing a smarter decision delivery cms engine everywhere. ie 'matching criteria' is basic rule type for the core delivery modelling of different customized types of executions possible. Drupal have one…and Joomla ? Doesn’t even understand what it is and how to use it.

[pulsarinformatique]

Hello
Maybe another way to get the very same result is on https://docs.joomla.org/J3.x:Layout_Overrides_in_Joomla#Alternative_Menu_Items where we learn how we can create our custom menu items.

I'm looking at the full description of the XML file that is used here.

For instance I need to know how I can add filters with Joomla custom fields on the category blog menu item.

There should be somewhere the syntax to use but I can't find it.

Currently we have :

I whish I could have the same thing for a custom field

thanks for your help

[brianteeman]

There is no functionality to do what you are asking. You will have to write php

[leoalv]

@pulsarinformatique What I always do is create a layout as I mentioned above, then in that XML file I add all the fields that I want to control the custom fields, and in the .PHP file I choose where and how to display each field.

Now that you want to create custom fields and that these are seen in the edition of menu items, the main idea is to create the integration of custom fields to com_menus, in JDOC I remember seeing the documentation on how to integrate it into your component, but com_menus at being from the core, I think the solution would be for a plugin.

History: T3 before the existence of custom fields in Joomla, it allowed you to add custom fields in articles, categories, modules and menus, but these fields were added in an XML file. They said that in T4 they were also going to continue with that and improve it, maybe they have integrated it with Joomla custom fields, you can take a look.

[artur-stepien]

@leoalv You can bind into form creation and create all the fieldsets/fields or modify existing using a plugin.
This event is explained in here: https://docs.joomla.org/Special:MyLanguage/Plugin/Events/Content#onContentPrepareForm

[leoalv]

@artur-stepien Thanks.

[pulsarinformatique]

ok, it shows again that using custom fields to filter the menu items, which is a basic requirement, is far beyond the scope of non developper users. it's feasible but for developpers only

[helpwise]

While Joomla is still struggling to get its core content system to reflect user needs after 10 years, developers are dropping like flies or and/or diversifying to Wordpress to stay in business.

JoomDev is Closing Its Joomla Products
JoomlaShine officially closes its doors on 14 September 2021.

On a brighter note. My dev says the J4 code is much cleaner and much closer to PSR4. So a big well done Joomla.

[ssnobben]

Well some of these developers can’t compete in Joomla world and try to stick with one leg in Wordpress camp long time and then also losing more momentum for their Joomla dev and losing business to other better skilled Joomla extensions and templates developers instead.

They will not be successful in the Wordpress camp either long time bcs even there is more average joes to sell to there its more competition and lower prices & commissions.

As a Joomla developer you have to take care of your own marketing and pr against the Joomla market + existing/new markets opportunities and many Joomla extension developers doesn’t understand how to do.

Wordpress is much better to help template and extensions developers with marketing and that’s something Joomla suffers from and doesn’t understand how important it is. Just take the fact that there still not a JED TEMPLATED section in Joomla extension directory.

A very bad strategic decision, still today!

[PhocaCz]

Wordpress is much better to help template and extensions developers with marketing and that’s something Joomla suffers from and doesn’t understand how important it is. Just take the fact that there still not a JED TEMPLATED section in Joomla extension directory.

I fully agree and hold the same opinion.

Sometimes I participate in debates where the prevailing opinion is that extensions are evil and that everything is best done via core. Some people don't understand that a normal user is not able to simulate extensions using custom fields, template overrides and core hacks. Explaining to someone that people prefer Wordpress also because they can choose from a large number of extensions is also difficult.

And then there's the technical side, where there's the eternal struggle between backward compatibility (preferred by extension developers) and big changes (preferred by core developers).

An interesting debate that everyone is now underestimating because most just don't think strategically is the removal of Legacy MVC in Joomla 5. In my personal opinion, by removing Legacy MVC, 95% of extensions will stop working and I suspect that certainly over 80% of developers will not be willing to rewrite MVC (because they just don't see the added value). These debates, which are about strategic decisions, should be discussed now, because by the time 80% of all extensions are gone, it will be too late.