Should have just written custom fields as a CCK because that is what most everyone is expecting it to work as.

That sounds very sad. Does it mean that in your eyes any such
implementation is hard or even impossible, please?

On Wed, 11 Sep 2019 15:52 Michael Babker, notifications@github.com wrote:

Should have just written custom fields as a CCK because that is what most
everyone is expecting it to work as.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/joomla/joomla-cms/issues/26258?email_source=notifications&email_token=AEB3ZXLTRINOP6C2E2JMOCTQJDZZ7A5CNFSM4IVPTQ6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6OR23I#issuecomment-530390381,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEB3ZXIUB3AFK5PRQIWRCL3QJDZZ7ANCNFSM4IVPTQ6A
.

Custom fields was built as a means to collect and/or display extra data in supported contexts. It was not built as a CCK, which inherently provides a system for extending the data model of whatever type you are using and providing extended query and display functionality (such as adding more query filters).

Hence, my comment. Everyone wants to use custom fields as a CCK. Except it isn't a CCK. So either use a CCK component if that's what you need, or convince people that the core components and custom fields should be written as a CCK.

Thank you for the explanation. OK, I look into the available CCK components. My effort to convince [about CF to be written as CCK] is this request apparently. Well, it was labelled J4 so, there is a chance that something is going to happen...

OK, I looked at them and I may choose one or the other. But that [choosing a proprietary CCK to store a content] is, what I wanted to avoid in the last years. And when custom fields came around I screamed with joy: Hurray! Native implementation of new fields to any content. They can be unique to each article, can be displayed in lists and sortable and no way that it'll be stored and work differently than the other fields [published date, meta, author, etc.] -- I thought foolishly. There should be a disclaimer somewhere: "CF are not CCK, you won't be able to do this and that".

I used a CCK fpr many years. Joomla Custom Fields was at last an opportunity to get rid of it for good. I have just spent many month exporting and importing content from CCK to Joomla! I am content however I would much appreciate a way to insert custom fields easily in blog layouts and lists.

@mbabker can you give real life example what for cf was build for? How to convince that joomla core CF shoud do what almost everyone wants to use custom fields for?

its not posible to core 3.9.14 joomla user in frontend article filter by custom fields

4.0 joomla frontend article filter by custom fields user in frontend filter articles by custom fields

Would love to see this implemented

We know CF were not designed as a CCK from the start. But for many simple sites it would be enough to have the same fitlering feature with tags we already have.
Joomla blogs can be filtered with tags so it would be feasible with custom fields.
Of course the performances won't allow complex sortings but it would be enough for simple sites.

As for thinking about implementing CF as CCK there was the UCM attempt that has been left aside. So either way we loose :(

So, What is the current level of conviction on this subject?
Is there a "development line" or a "formal request" for Joomla core to have a real CCK (not the actual and limited CF)?

@Sukinoz I think the new RFC process is the right way https://github.com/joomla/rfc/pulls and I'm pretty sure @nibra will help you setting up a new RFC for this.

@kofaysi, @EJBJane, @pulsarinformatique. @Sukinoz, this kind of request ist exactly, what the RfC process was designed for. To start the procedure, we need
a) a description of what needs to be done,
b) a justification why that is beneficial for Joomla and, last but not least,
c) a couple of people willing to elaborate the proposal.
If one or more of you are interested in working on that, please give me a call.

Maybe you should actually tell the community about this RFC process - just an idea

The voting ended some days ago and the repository migrated from joomla-x to joomla last week.

I'm pretty sure there will be an announcement when it's ready and maybe a magazine article @nibra can you confirm this?

Yes, article to JCM was submitted 5 days ago. VET is informed. More will come.

Just one idea could be:
a) a description of what needs to be done
Need a system for extending the data model of whatever type you are using and providing extended query and display functionality (such as adding more query filters). In resume, improve the Joomla Content as a Content Construction Kit.
b) a justification why that is beneficial for Joomla and, last but not least,
Using a third party CCK prevents using the vast majority of Joomla's own utilities, as well as the vast majority of other third-party extensions.
c) a couple of people willing to elaborate the proposal.
A am interested in working on that, but my programming knowledge is very basic. My experience is based on the management of several media websites, based on joomla, with hundreds/thousands of articles published by the editorial team.

Hi Sukinoz

this has been a very old topic among Joomla users :(

the need of a native cck has been one of the top priorities but has always been dismissed by the core dev team.

A few years ago an akward tentative had been started with the Unified Content Model (UCM) which has been dropped too.

Drupal is based on a CCK, even Wordpress has a native unified model for all his custom posts.

One of the most tedious issue we have with joomla is that it's mainly a framework for developping independant applications (components) that don't know each others. This is exactly the opposite of a CCK basis

sorry

At the end of the day any idea requires someone to write the code. There is no such thing as a core dev team.

Thank you, @Sukinoz, created a branch on joomla/rfc for this. Please discus this topic there. Pull requests with additions to the document (proposed/cck-meta.md) are welcome.

BTW:
I need your realname and email for the document; you can mail me directly (email address is in my profile).

@pulsarinformatique, thank you very much for the excellent summary.
@brianteeman, you are absolutely right. Hopefully from here someone can be motivated to lead (and write) this idea.
Ok @nibra, I will write you. Although I am not familiar with the "pull requests" and github methodology.

I'm closing the issue in regards to the rfc process. There we can find a solution for this topic.