Thanks Brian for adding the "new feature tag", you are right. Are there people here sharing this evolution as a must for Joomla ?

To be honest I am not sure exactly what you mean

Ok , I will try to be clearer then :)

What I mean is to give the possibility to extend the existing joomla lists/blogs views but not only on a display level (overrides aleady exist!) but at a beahaviour level.

Many people complain about the lack of custom fiels on articles but custom fields have been existing in Joomla! for a long time: they are content plugins. Content plugins really extends the native Joomla article.

The next step, according to me, is the possibility to filter and order the existing Joomla lists / blogs of articles after these extra fields!

Let's take an example. Let's have a new date content plugin that will add some EVENT DATE on the standard Joomla Article. With this extra field we can set a date on the article that is not related to the creation of modification of the article but to the actual date of the event.

Let's then create some new 'events' (joomla articles) with a special 'event date' for each article.

Currently it is impossible, with the existing Joomla lists, to display the list of these events ordered after the 'event date' extra filter.

Another example: let's create a new content plugin that is a drop down list of values specifying the type de document we are dealing with. For example the values are:

• administration document
• invoice
• proposal

Now with this field (content plugin) in an article we can specify is the article we are creating represents an 'administartion document', 'invoice' or a 'proposal' . All these articles are in the same category though (because of other constraints for the purpose of the example)

Let's try now to display only the 'invoices' with Joomla lists: it's impossible

At the end, since we already have custom fields for years in Joomla! who could add the filtering / ordering features based on the installed content plugins on the Joomla lists ?

thanks for your reading !

Cyril

Cyril, I absolutely agree that filters are a must with custom fields. I think this is a matter of if someone is willing to put in the work for this. I doubt the community would be against this considering that having such searching capabilities would make searching for things potentially a whole lot easier. Take the JED for example, it has filter capabilities for finding items. Albeit the JED does not have a lot of filters at the moment.

I think Smart Search can already do this. Indeed, it was created in part to solve exactly this kind of problem.

Hi Chris, no, smartseach are something else. What I meant was to be able to add filters on the actual joomla lists.

According to me we have to modify the way the lists/blogs are coded to allow some content plugins filtering.

Without minimal effort it would open the way to dynamic context based lists

cyril

Hi, we actually have to rethink the whole way we build llists. If you take big Joomla CCKs such as SEBLOD you see lists ans searches are the same thing. Now in Joomla! we have separated lists (which are pretty static) from (smart) searches. I believe we really have a model issue here

Again the whole issue is not adding fields to the joomla! article but the way we build lists and searches.

thanks

cyril

That's the point I was trying to make. Lists are a kind of search, so if you want complete flexibility in building lists you need to look at it as a search problem, not a database problem. Smart Search allows you to build lists without referring to the original source of the data. You can even build lists across multiple sources and across sources that aren't even databases.

Yes Chris but the point is the router. Smart search currently is only used to make and display search results, and doesn't create but rely on existing urls. Joomla Lists / blogs create urls.
I believe this is a problem.

We need to unify lists and searches and allow them to be filtered by content plugins (= extra fields)

Currently the urls Joomla knows are only links to an article or links to a Joomla list/blogs. Smart search, trough the router, only knows and uses these urls.

If we could rethink the whole thing so that a list is a search.

thanks

cyril

Sorry, you've lost me now. I have no idea what you're talking about.

Glad its not just me then

On 22 August 2016 at 09:34, Chris Davenport notifications@github.com
wrote:

Sorry, you've lost me now. I have no idea what you're talking about.

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

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I think what @pulsarinformatique tries to explain is that is should be possible for the visitor to search in a list similar to what is possible on the back end.

I'm sorry. It's not that either :(

Please re read the example I gave before.

Do you know Drupal Views ? This is what I try to achieve and this is what Seblod does already but it would be much better if it was embedded in the Joomla! core.

Even without a cck it would be great if, in the backend, we coud set up Joomla Lists / blogs so that they are filtered not only on catégories or title (any #__content field) but also on installed content plugins (which are somehow articles extra fields)

Is that clearer now ?

Thanks

Brian, I will see you on JoomlaDay Israel, we may have a talk there.

If you want to create something as complex as d views then I hope not

On 22 August 2016 at 10:35, Pulsar Informatique notifications@github.com
wrote:

I'm sorry. It's not that either :(

Please re read the example I gave before.

Do you know Drupal Views ? This is what I try to achieve and this is what
Seblod does already but it would be much better if it was embedded in the
Joomla! core.

Even without a cck it would be great if, in the backend, we coud set up
Joomla Lists / blogs so that they are filtered not only on catégories or
title (any #__content field) but also on installed content plugins (which
are somehow articles extra fields)

Is that clearer now ?

Thanks

Brian, I will see you on JoomlaDay Israel, we may have a talk there.

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

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Not as complex because D views interface is really not user friendly. However D views are very useful. If some of you know Seblod, this is exactly what they did.

We all know one of the top wanted Joomla features is a cck. There are many existing extensions that either are a cck or just add fields to native articles.

But what is missing is the possibility to filter the joomla lists on some values of these extra fields. The current Joomla lists are too restrictive.

And this is in part why I think core doesn't need a fully featured CCK solution. It's honestly far too complex for a lot of use cases and those who do prefer them IMO lean on them far too much for things that should be done with a simpler approach (I know of a few sites that use ZOO for a blog).

The core extensions aren't designed to be a one size fits all solution. Yes, people think they should be able to do more or be more easily adopted to use cases beyond what they do now, which you can to some extent with plugins (honestly, you could probably do everything with plugins if you tweak with loader priorities just right to overload the core extension classes, but at that point why not just make your own extension?).

At the end of the day though, there are two general suggestions that keep cropping up that I honestly believe aren't in the best interests of core; a fully functional CCK system, and plugin triggers that allow query manipulation. The former IMO being more complex than necessary in most cases and the latter being too dangerous and making it too easy to break sites.

I will agree (use the cck extension) the day the Joomla router will recognize itemIds that are not only Joomla native menu items.
If you take Seblod for instance it suits all these needs but the only real remaining issue is the router.

With the current approach the router is unaware of most extensions. It only tries to recognize direct links to articles or list/blog menuitems. If you ask JCE to build a link to an article that only has a seblod menuitem pointing to it, JCE (i.e. the router) will not find the itemid.

This is why I started the discussion on googleGroups which made Hannes propose the new router.

Calling it an itemid was a mistake 15 years ago. It should have been called
a menuid.

You're getting into a lot of other limitations than just the router. Generally, the routers don't do cross-component routing efficiently which is why most extensions have a route helper class for the different types of items it associates to menu items. A lot of things have issues dealing efficiently with parent menu items not being the same type as what you're actually viewing. I haven't looked at Hannes' code to see if that's addressed though.

Whatever we call it the issue remains :)
And yes there are a lot of issues here and don't know either if Hannes' code solves them.

And Michael, I don't agree about the fact Joomla! doesn't need a core CCK. We could build the core cck and show articles/categories/users/user groups the same way as we do now. They would only be ONE instance of what the CCK could do.

This way Joomla! will remains as simple as it is now and we could allow more power with the cck for those would would need it.

If you just want to filter articles, I think there should be some extended tag system filter. We should leave CCK to a more complex application and not to core joomla.

Actually there are many good CCKs already for Joomla!, SEBLOD being one of them. The real trouble that remains almost always is connected to the router that ignores non native menuitems. This is a real issue since it separates the CMS from the CCK. Let's hope the new router will help this way.

Another recurring issue is that the Joomla! MVC / OOP could be extended to the behaviours and not only on the display. If we could developp some derived joomla lists with new filtering system while keeping the inheritance of the native Joomla lists we would have a much complete system.

I don't know if someone already tried something in this area but just imagine that we could write our own joomla lists or articles that would keep the native lists and content properties while adding some more.
This way the router will consider these inherited elements as native elements while adding new functions to the site

All these discussions (customized joomla lists, a more flexible router, inherited lists...) are just attempts to make Joomla! more flexible

thanks

@pulsarinformatique I've been working on the new Joomla router LONG before you made your first posts about this topic to the Joomla mailinglist. My first proposal is from summer 2009 fpr Joomla 1.6.

Regardless of all of that, it is possible to use the custom fields to filter lists already. You could for example override the articles model with a plugin and then build that feature in. As @mbabker wrote, it does not seem to be a good idea to implement this in core by default. A lot of sites wont need this and those that might need it, most likely need a more customised feature than we can provide. All that said, please consider closing this request. The discussion has run its course and the featuer should not be part of the core.

Hi @Hackwar

I still disaagree. If we now can filter list according to tags (by the way why just one tag?) we should be able to do it 'out of the box' with custom fields. Leaving this to third party devs again means Joomla misses the target for some larger projects.

There is just very very little use of custom fields if we can filter contents according to them

Anyway the real question below is the lack of built-in cck, which is not the purpose of these custome fields

You are expecting a feature for newbies, while the custom fields are rather something for developers. If this makes it possible for most of the extensions out there to drop their own implementations and standardise on this, a lot is gained.

On the contrary, I'm expecting a feature for high end websites, things we do with advanced ccks for Joomla! right now.
I see you are counting on standards made by extensions developpers, which never happens. For me the model and standards should come from the core.

This is an endless discussion anyway because this is Joomla is made from the start, allowing people to drop their own implementation rather than providing a more structured way of building and managing contents.

I love Joomla! but I think it's high time it evolves in another way. Just adding separate components (tags, custom fields) to com_content doesn't make a coherent system for me.

Custom fields would be used often from non developers as well. Back in 2008 when I did not even know HTML and discovered Joomla I was on the hunt for custom fields. Categories are great, however often many of us want to show specific types of data to people upon first view.

By offering a means for having custom field lists I don't see this taking away from developers implementing their own methods for displaying custom fields. I suppose maybe a bias in some minor situations, but that's about it.

@JoshuaLewis I undestand that. But you are also expecting a solution that caters to all needs of all users and that should be perfect and fully featured from the start. At the same time I think you can count the number of people that read the code of the custom fields feature on two hands at max and the number of people having tested this will also be not a lot bigger. The current situation to me already is pretty good considering our resources. Then again, all of this is not supposed to be finished and done and never worked on ever again after this release. Quite the contrary. I expect more people to be interested in working on this when it is actually released.

So, right now you can get a feature that a few users can use and that a huge number of devs can use and which might be extended in the future, but you want to delay that into the undetermined future in favour of adding more features. Considering how many efforts died because the code was not released in a timely fashion, I believe that to be a dangerous path.

I definitely agree on releasing custom fields stable first. I'm purely thinking out loud for releases like Joomla 4. This discussion is aimed at seeing interest for it in the future.