This really seems like it's borderlining on full CCK functionality and would create a very tight inner coupling to the fields component from everything using fields if it were fully implemented.

Not saying the idea is bad, but it needs to be handled very carefully. We've already got a situation with the voting integration in com_content where there is now functionality from the plugin hardcoded into the component (meaning the component is coupled to a plugin!?).

yeah i admit the borderlineliness (O_o) with cck but adding custom fields without any functions for using it at 100% is very frustrating.
Filtering is not a priority I think but ordering is a really needed functions I think.
(we have already played with dpfields array for creating some ordering in the past and it's add alooot of power in our websites)

About the couple component/plug-in if I understand (english not my native language) your concern is about the dependance between com_content/Com_menu/com_fields+plug-fields ? If Joomla! team want to cerate later a plateform without com_content or com_fields we just add some test on plug-in/com_fields before populating order/filter list.
Or you talk about something more complex/highlevel ?

My concern is Joomla contributors are writing code in a way that very tightly couples features to components. As an example, you basically can't use the core tags data structure without com_tags. Same for the categories data with the com_categories component. And now we've got that problem with fields. All of them are good features, but they are all written in a way that means the only way to use the native core stuff is with those very specific implementations. It's why alternative content management components have their own data structures and implementations of the same core features versus being able to possibly reuse the core code.

It's very difficult to extend components in any way. In the end, it's just a wreck. Look at how the voting integration with com_content is handled. There's now a lot of stuff hardcoded right into com_content and the plugin almost is nothing more than a display handler. That's not how a plugin should be integrating features into a component, and that plugin actually is at a point now where it should just be removed and its remaining code just moved right into com_content as a "native" feature of the component.

So part of my concern is features are being added that make Joomla less modular by tying some of the "bigger" features together in a very restrictive way.

It's a coupling between com_fields and an extension we shouldn't do, and it would be very bad for performance as well.
Currently, com_fields interaction is purely through plugin events (and one helper method to verify the context). Your proposal would need hardcoding of SQL queries to the fields tables and would make the whole plugin approach useless.

The ordering capabilty can't be achive with a plug-in which add order fields in menu item link on a side and order the $items array in the front side ? Like this the plug-in could be disable (like a lot of oher function in joomla!) .

The ordering capabilty can't be acheive with a plug-in which add order fields in menu item link on a side and order the $items array in the front side ? Like this the plug-in could be disable (like a lot of oher function in joomla!) .

I don't see a way, since it still would need JOINs in the database queries over at least the #__fields_values table.
Since there are currently no plugin events to hook into the database queries, that isn't possible without hardcoding those JOINs into the extension models.

Where is the necessity of a JOIN (I'm not a pure php coder more a project manager ^^) => BO or front ? In Front we have already (if my memory is still good) manage to re-order the $items array based on a dpfields fields (hardcoded in a com_content alternative layout).
In BO we can't just add the order list option based on the assigned_cat_id of fields ? The hypothetic plug-in will check if the current item menu we are in is a category/blog etc items fields and show the fields which are attached to this category=> the plug do all the SQL. The order parameters are store in $$_menu.params where the plug-in in front read the filter parameters.
Sorry I know I talk with a limited understanding of how the whole Joomla! app work.

The join is needed in every place where you want to reorder (or filter) the list.
Of course you can reorder an array in a layout override if you like, but it's certainly not something we should do in core. Also filtering would still need a JOIN.
To my knowledge there is also no plugin event which would allow to manipulate the returned array of items. Plugin events always run on the single item afaik.

In the end, it would be a hack anyway, not something I would do.

Okay if I understand, so there is nothing to expect in that direction now or later ? For us (web agency) it's a strong signal we no longer wait for a com_content evolution and have to work only with K2, Seblod as soon as we need to create something else than a simple article. It's very sad because adding component is not what we like to do.
The day we could uninstall com_content is coming ?

Personally, I don't think we will add sorting or filtering based on custom fields anytime soon. That would need a bigger architectural discussion (eg plugin events in the query builder or so).
If you need such functionality, then a real CCK is the best approach imho.

Query manipulation events in general aren't a good idea. Even with Doctrine, the most you get is some events in the ORM which let you check/alter data in the persisted objects, but there really isn't a way (I'm aware of) to alter anything that issues a SELECT query.

@SemaphoreOxalis
Just wanted to let you know about an interesting 3rd-party filter extension by Joomlart.
Since they support different content providers and even their extra fields, there might be a chance for J! custom fields…!? Maybe its worth to raise that question and idea in their support forum.
Related Link to JA MegaFilter

@Bakual ,
Maybe adding a "searchable" database table column will allow other extensions to perform that filter. See #14872

I don't think it would help much with filtering/ordering.

As I wrote in many topics I don't see the real purpose of custom fields if you can't filter your lists according to these fields. As any database application the real purpose is the exploitation of datas (queries) not the model itself.

No one will see a comment on a closed issue

I got the comment in my mailbox ! And of course I agree with my french colleague ! Joomlart have a component to do that but it don't use the com_content view et re-create news one O_o These custom_fields don't really solve all the issue we have with Joomla content from the beginning and we still have to rely on other component for just ordering a list of article : very frustrating. Even our client (their not developper but end user) don't understand why this option is not existing in menu settings.

Please stop commenting on closed issues.
Open a new issue instead.

But as said many times already, com_fields was never supposed to replace or be a CCK. Thus there is no possibility for filtering or sorting. Use an existing tool if you need that as com_fields is the wrong tool then.

Is there no news?

@ajejebrazorf01

Please stop commenting on closed issues.
Open a new issue instead.
But as said many times already, com_fields was never supposed to replace or be a CCK. Thus there is no possibility for filtering or sorting. Use an existing tool if you need that as com_fields is the wrong tool then.
@Bakual