Great idea.

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 :)

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".

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.

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

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)).

@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.

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.

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

@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.

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.

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

@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.

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

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.

I don't say it is something that stopped Joomla! advance. But does slow it down.

@brianteeman Most of Joomla! users aren't developers, expecting from them to pick up feature abandon by its developer is at least silly. For the codding argument. Codding for the feature to be rejected is stupid. Every ones time is money. If there is a will to implement it, then we can talk about coding. That is the reason for this conversation I assume. To decide if there is enough support in implementing this. That's why I would be glad to hear from more people/devs.

@mbabker But I'm against abandoning com_contact, com_banners and com_weblinks. They are fitting perfectly to module system model right now. They are taking care of what they should take care. The issue is with com_content. If there would be problems with migration, yes some people would quit. But they are doing it right now exactly cause of UX. Last months I had 3 of such clients that chose Wordpress instead of Joomla! just because it easier to administrate for their small/medium business (and yes, they had touch of Joomla! before).

please mind your language. i have edited your post to remove the profanity

@brianteeman Fixed the post.

So you and me have two different visions of this feature. There's the current UCM data model (essentially what I'm looking at), and there's the WordPress Post Types which is basically the existing com_content with an extra column in the database, post_type, that does some magic UI stuff. Truth be told, I don't like either option as an enhancement/replacement to com_content.

All post types in WordPress do is rename the default "post" to something that might be a bit more user friendly (i.e. you want a "category" of posts for books separate from your "category" of generic blog posts) and gives the appearance of a special type of data by adding it to the navigation tree, really the only benefit here is this adds another context to do things (in Joomla terms) like manipulating data in plugin events, adding custom fields, or modifying the presentation layer (layouts). What are you really gaining here that you do not already have with the existing Joomla data model and extension points?

We need to keep also the eco system in mind. If we start to build stuff in core which can be (or is already) done by an extensions then it would be a bad message to the eco system.

If you need something complex like a CCK then there are good extensions out there. If this is not enough then probably Joomla is not the right system for your task.

Agree with @laoneo , @mbabker , @brianteeman
Inventing or changing to a new type-based structure for content is a bad idea. As mentioned in my previous comment, I see a lot of potential in UI/UX improvements. Actually everything can stay an "article", it is just a matter of how I present it to the site owner and user.
If I can "hide" or modify the generic term "article"; display suitable custom admin menus; create pre-selected category filters; custom front/backend forms; custom layouts etc...
the client and me are happy with it.

So the initial idea was to allow an article to have a Type, and that type be attached to Fields, instead of the fields be attached to Categories.

How did it end up as a "we cant make modifications to core code for migration issue reasons"?

It occurs to me that maybe some developers here don't use Joomla in the same way that customers do.

And rather than worrying about how many people we might lose due to a poor migration experience , what about the new customers I suspect we will easily pick up, because we made Joomla much much easier to understand and much easier to manage for our customers.

A customer would be much happier to add an "Event" to an event article under its own Event menu, and category, than the rather convoluted way they are currently done.

I really appreciate the core custom fields and use them a lot, (I used DPfields prior) but I believe the fields are assigned to the wrong thing - Categories. It should be Types, even if types are just a copy of the Categories system

If what is proposed is too complicated to implement without massive compatibility issues, I don't understand how, and am very happy to be corrected.

It seems to me to be able to be completely backwardly compatible, by assigning all upgraded articles to have a default Type of "Article" which would have the existing elements built in..

An extra database field in each com_content record (as per category) and then some massaging of Fields - to be able to be assigned to Views and rendered seems quite doable.

And being that fields is relatively new, and not well understood by clients, perhaps we should fix the limit in the initial DPfields code, which used Categories as Field assigments because that was all that was available to them, and 4.0 would surely be the best place to start ?

I respect the hard core devs on here who have helped Joomla be as awesome as it is, but would love to be able to see this looked at as a good value proposition, and technically simple adjustment, not the terrifying ogre it appears to be in some of the comments.

@laoneo "if we build in core stuff that are already in extensions then it could send a bad message"..

Then why were custom fields added? All I am suggesting is that custom fields be able to work on Types not categories, and that articles can be filtered in Admin menu items by their type so that customers can manage their site easier.

@mbabker - "What are you really gaining here that you do not already have with the existing Joomla data model and extension points?"

1. Assigning Custom Fields to something that makes more sense

2. The ability to make the admin of Joomla content much easier, and rival Wordpress and so on.

I have about 100 Joomla clients, and they all struggle with the single articles concept in the back end when we give then Events, and Blog menu items, with multiple varied categories under them.

They almost always ask me why we didn't use wordpress, because it was 'so much easier to understand'.

And unlike many tech folks I know, I don't think of them as ignorant, but rather busy folks who's 28th responsibility is to keep the website up to date every month or so and could do with a helping hand in complex environments.

Think charities, not for profits and so on.

Then why were custom fields added?

I needed custom fields for DPCalendar and then had a look of available options to integrate into DPCalendar. Either way you had to use other extensions like Seblod, which is a full blown CCK, and way to complicated for a user who just wants additional fields for the events, locations, etc. Or we do it by our own as there was no simple to use solution available for 3rd party extension to be integrated with. com_fields (or DPFields) was made to be easy adoptable by 3rd party extensions and not to replace them.

i fail to see the difference in your example between types and categories could you explain further.

So far all I see is that com_content should be displayed as Content instead of Articles
and Field Categories as Content Type

Even for your use case is a free extension available which has dynamic content types and was made to be easy to use when you don't need a full CCK. It is DPFields 2.

@brianteeman - "So far all I see is that com_content should be displayed as Content instead of Articles
and Field Categories as Content Type"

Field Groups (not Categories) are not attached to Categories directly - they are selected in each Field as a single dropdown and form the Tab Name above the custom fields in the article edit page.

They do not determine an article type, but rather a grouping of some custom fields (there can be more than one group in any article and grouping them is important with tabs like "/Event Details\ /Event Contacts\ /etc....

Article Categories are also selected at the individual custom field level, although there can be multiple selected per Field.

Now, for my client to create an Event article with Event custom fields in it, they have to create an Article, and then select the correct joomla article category (Events), which then reloads and extends the article with the custom fields.

But what if my users Event is not in the Events Category but a subcategory that they just made ? If the Fields are not hierarchical and also used in subcategories, it gets messy.

To simplify things, an article would be created directly from a Type menu [Events] - as per the initial post, with all the custom elements already loaded ready to be filled in.

Yes Articles would be changed to "Content" and under it would be listed all Content Types ( as per the screen capture in the initial post) with Articles being the ever present default.

I hope that helped.. Its not quite as simple as you suggested, but also not as difficult as some might be suggesting.

@laoneo - Yes - it looks like DPfields 2 does something similar to what is being suggested ! - we used DPfields 1 quite a bit and it was excellent, but we migrated to Fields in J core since

As DPfields 2 further development has suggested - the content "Type" (or your name for it - "Entity") was well worth adding. Are you looking at putting DPfields 2 functions into J Core or are you wanting to keep it separate?

However, in the short term, can this plugin be extended to do the Joomla Admin menu suggestions in the OPs post ?

see #20233 for my views and (partial but easy to do) solution that can be (almost) achieved now in joomla 3

Actually - I like it. As I mention there, I think Categories are heirarchical and Types are not, but other than that and the fact the menu system is not bound to article category structures.. all good !

If we could have filter by tagging in the menu item as well.... ;)

(I just realized that as the OP I am writing this on another signon - sorry for the confusion!)

I seriously get that people find WordPress to be a better experience for many reasons. That does not mean that core should be refactored to duplicate WordPress. If Joomla is "just" WordPress wrapped in MVC and a different UI then really what's the point of having a separate product?

Joomla, WordPress, Drupal, Concrete5, Grav, Typo3, etc. etc. all might be suitable for similar end products and use cases, but that does not mean that they have to be built and operate the same way.

com_content is not designed with the same data model or workflow as the default WordPress installation and its post data structure. com_content does not need to become com_wppost.

Again, I really get that people have differing opinions on things they like or things that would make their work easier. And as it shows in how I respond here, I think a lot of that is driven by trying to massage a tool to work similarly to another tool even though it wasn't designed to work that way.

So the initial idea was to allow an article to have a Type, and that type be attached to Fields, instead of the fields be attached to Categories.

How did it end up as a "we cant make modifications to core code for migration issue reasons"?

If you really want WordPress style Post Types, that is a major data model migration. Because in WordPress, the entire data model is based on the wp_post table. These post types expand throughout the platform to allow integrations to be customized in all sorts of ways. In Joomla, the closest thing to ever be proposed to this concept would be UCM, where everything is based on a singular core data model that is expanded upon. Similar to creating new post types in WordPress (which has to be done in PHP code through a plugin hooking the system), a new content type would be you installing a new component. Post/Content types are much more involved than simply adding a "type" column to #__content. First it's going to be to create an easier navigation structure in the backend to "group" similar content types (i.e. books, computers, recipes, etc.). Next it's to create field groups. Soon that would be requested to be expanded to the frontend (category views should be able to filter on content types), then content types should be able to have their own layout styles (also following the layout override rules). So, what is perceived as a "simple" addition with minimal if any B/C consideration, the fact of the matter is to do the feature correctly requires a major shift in how the system works (even if it doesn't change the entirety of Joomla in the way UCM would, it most certainly adds a major layer of complexity to com_content and its integrations).

It occurs to me that maybe some developers here don't use Joomla in the same way that customers do.

You're right, we all use Joomla in different ways. What's the problem with having a different workflow which inherently means looking at the platform and how it is built/maintained differently from someone else?

Lets repeat again. No one is trying to build another Wordpress. CCK doesn't need to be based on Wordpress solution, it has it flaws too. Joomla articles have faulty design that worked maybe 10 years a go but for modern websites are way to ancient. Yes you can always build extension for this like for anything else. But content management system is for content management. It would be glad if it would do it out of the box. If pure text would be what people need all websites would look exactly the same.

If you are against adding features like this to the system why not just go huge and remove com_content, com_banners, com_contacts and keep the system clean? Let them chose the solution they want with some suggest from system for those build directly from Joomla! team.

Joomla! extensions market or as you call it ecosystem is important. But if you gonna stop evolving cause some one can earn money on extension that system lacks you gonna end up with they situation that Wordpress already has. Huge base of extension that are mostly outdated. We all can see how did it worked for them (https://sucuri.net/reports/2017-hacked-website-report).

Most of clients I know stick to Joomla! only cause they know it or cause it is a bit safer then WP. They biggest flaw they see is UX (that improves a bit in J4). I was talking about this already few times. There is no point in repeating. I'm chosing Joomla! cause of its code quality. But clients mostly chose UX. We can ignore it. But that doesn't do any good for Joomla!.

I know I have no influence on where Joomla! will go. I just pointed out the issue and the arguments behind it. They got ignored as usually. So that is my second and last attempt to work on core. Good luck.

We need to keep also the eco system in mind. If we start to build stuff in core which can be (or is already) done by an extensions then it would be a bad message to the eco system.

If you need something complex like a CCK then there are good extensions out there. If this is not enough then probably Joomla is not the right system for your task.

Think this feature will only add value to the core the eco system. Yes, extension can be done very easily to achieve this, however, there's multiple ways of how people doing things, and when it comes to upgrading, sometimes things start breaking, and that yield bad experiences to users... consequently, Joomla! gets negative impact from bad implementation.

So, by introducing such feature, which still allows developer to be creative, but with some level of governance will help:

• the developers to avoid creating redundant functionality that is already part of the Articles and Custom Fields, etc.
• to avoid breaking when upgrade (caused by crazy implementation)

So, I think this feature request would be a great value added to Joomla!

Wordpress has this built into the core.  Programming it via plugins or
the functions.php theme file works a treat.

And they still a great eco system.  :)

Its one of the few remaining Joomla hold outs in my view.

Cheers,
Pete

On 07-May-19 11:42 PM, WEBCONSOL Inc wrote:

We need to keep also the eco system in mind. If we start to build
stuff in core which can be (or is already) done by an extensions
then it would be a bad message to the eco system.

If you need something complex like a CCK then there are good
extensions out there. If this is not enough then probably Joomla
is not the right system for your task.

Think this feature will only add value to the core the eco system.
Yes, extension can be done very easily to achieve this, however,
there's multiple ways of how people doing things, and when it comes to
upgrading, sometimes things start breaking, and that yield bad
experiences to users... consequently, Joomla! gets negative impact
from bad implementation.

So, by introducing such feature, which still allows developer to be
creative, but with some level of governance will help:

• the developers to avoid creating redundant functionality that is
  already part of the Articles and Custom Fields, etc.
• to avoid breaking when upgrade (caused by crazy implementation)

So, I think this feature request would be a great value added to Joomla!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#19150 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCKSOZJSYWWKTYNE4BGSGDPUGBKTANCNFSM4EJPE4HQ.