Simple Joomla CCK #26
Conversation
|
I've been in love with Joomla for so many years that I can't remember. So understand that everything I say here I say with affection and constructive encouragement. And forgive me if my English is not very good. I want to take this opportunity to try that Joomla takes a step forward and go beyond the traditional content structure "Article" + "Image", to include a basic native CCK. There are many of us who do not want to stop using Joomla Native Content, because that would mean losing compatibility with so many good extensions that enhance Joomla. In addition to losing compatibility, when you decide not to use "Native Article Content", and install a specific component, you know that the future development of your website will depend exclusively on that component. In Spain we say "don't put all your eggs in one basket" ;-) It is sometimes difficult enough to find a good extension, without having to go around asking "is it compatible with...?" As @pulsarinformatique commented: Such is the incompatibility that is generated, and the loss of synergies, that currently in Joomla extensions there are even categories of "extensions of an extension". That is, extensions are developed only for users of another extension. For me, this is a loss of symbiosis and opportunities. Can you imagine a Joomla in which the extensions to manage events, courses, "real state propierties", even the products of an online store, all share the same native content structure? The synergies would be incredible. If, for example, someone develops a "content display module", or a wysiwyg editor, or a template... they would be compatible with all Joomla! A great symbiosis! As we can read on the home page of joomla.org: "Joomla! is an award-winning content management system (CMS)".But it is currently a content management system whose native content does not support things as common today as adding "real" custom fields, and then being able to filter and sort the content according to those custom fields. I say "real" custom fields, because a lot has already been said that the current "custom fields" are not what many of us expected: "There should be a disclaimer somewhere: Custom Fields are not CCK, you won't be able to do this and that" @kofaysi "Should have just written custom fields as a CCK because that is what most everyone is expecting it to work as" @MBaker At this point many of you will be thinking like @brianteeman : Unfortunately my programming skills don't allow me to write that code. That's why I'm here doing what @MBaker told me: "convince people that the core components and custom fields should be written as a CCK" If you also think it would be great for Joomla to have a basic native cck, think: can I help? by programming, giving ideas, spreading the word about this initiative, or simply leaving your comment of support... any help would be welcome. |
|
Thank you for your input, @Sukinoz! Maybe one should start with defining what is expected from a Joomla native CCK, and where and why the Custom Fields fail to serve the purpose, so we have a list of requirements. If anybody has specific usecases, please let us know (describe what you need and how you would like to do that). Please drop your two cents into the comments. Nothing needs to be fully elaborated at the moment. This is in a kind of brainstorming phase. All ideas will be condsolidated into the meta document in this PR and completed with pros and cons later. |
|
Hi I also tried to convice some most famous joomla CCK that in the long run they would suffocate under the weight of their own product and that the CMS will collapse itself if they don't merge their product into the core. Joomla main developpers were not aware of the importance of the CCK and CCK editors didn't want to loose the revenues of their product. At the end both will die :( The most complete Joomla CCK have become very bright products but the cost of their maintenance becomes too heavy and their market share is shrinking with Joomla. Should at least one of them have accepted to "give'" their cck to the community they would have ensure the future of the CMS and the basis of their future revenues, becoming one of the major CMS contributor. Unfortunately this is not the way things went. Cyril |
|
@pulsarinformatique When I last reviewed a couple of available CCKs some years ago, none of them were written in a way that would fit into Joomla's (desired) architecture very well. Allon Moritz' DPFields extension was different in this regard, so it was integrated into core as Custom Fields component to increase flexibility. But we should not lament what happened or did not happen in the past, but look to the future. At the moment, the main question is: Which use cases should be served by a native CCK? |
|
Having worked with powerful CCKs for 10 years the answer is straitghforward for me : I don't want to impose anything but I've been testing ALL the major Joomla CCKs (sorry in French https://www.pulsar-agency.com/actus-blog/entry/comparaison-des-ccks-pour-joomla). Please study SEBLOD very carefully, add keep this approach with some enhancements. This is the best versatile way to work by far. but , I tell you, I'm quire sure it won't happen since it takes YEARS to have such a mature product, Seblod editor has a different agenda and by then Joomla may vanish, unless we have a drastic change of mind, which is always the hardest thing to get. Cyril |
|
if seblod does everything that you want then why even discuss having somethin similar in core |
|
Please take me of this list.
…On 2/14/21 2:24 PM, Brian Teeman wrote:
if seblod does everything that you want then why even discuss having
somethin similar in core
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACCR6JJTHITGYK5PRKUIJTS67FJPANCNFSM4VTOS7XQ>.
|
|
If you care about joomla's ecosystem, then this should not even be considered for core. It would be another punch into the face of extension developers. |
|
I think that joomla 4 come with a step forward even in cck: the workflows. In the same time the proposed solution is far away from how a "workflow" should work in frontend. |
|
Hello everyone, in my opinion, for Joomla to slowly become a CCK, all that's missing is the multi-categories and the ability to easily create blog and article view templates. On the other hand, before convincing developers to help you. I think the priority is to finish Joomla! 4. There are many things that we need developers to do. In particular the media manager. |
I strongly disagree. One top joomla feature is the rigid assignment of one article to only one category. Otherwise will be just a kind of wordpress. |
|
Hello, Thank you all for participating. @pulsarinformatique (Cyril), I understand that you are tired and frustrated, but please don't give up. At least @nibra and I need you. @brianteeman , let me respond to your sentence:
First of all, let it be clear that you know much more than me about programming and much more about Joomla. Also I see that you are co-founder of Joomla and therefore you have my respect. I am a Joomla user for many years, and I have many people working every day using Joomla based websites. I have almost no experience as a programmer, but as a Webmaster and Joomla user I think I have enough experience to be able to give my opinion. But above all, I am a human person with feelings, and your rhetorical question seemed to me rude and out of place. Maybe it was not your intention, but that's what I feel when I read it. If you really want to know why even though there is a CCK that does everything (actually not everything), we would like to have something similar in the Core, we can explain it to you. No problem, ask and we will give you our reasons. Just a sample, without wanting to get long:
DISPLAY AND FILTER content listings by fields. For example, we have a list of activities to do on weekends. With fields such as "date", "free or paid", "city". We would need to be able to filter by activities in a specific city. And to be able to sort them by price or by date @laoneo , let me respond to your sentence:
Thanks for your opinion. But to say that because we want Joomla to have a native CCK, means that we don't care about the Joomla ecosystem, or even compare it to a punch in the face of developers, seems very rude to me. I understand that you may be annoyed by our attempt to want Joomla to have a native CCK, but I assure you that our intention is good, that if we say it is because we think it would be good for Joomla, and of course we do not want to punch anyone (neither physically nor metaphorically). I invite you if you want to kindly reason why you think a Native CCK would be bad. Maybe then we can understand you and try to avoid or compensate those points.
@denvarel
Thank you. If you need multiple categories, with a Joomla CCK I think that you would only have to create a multiple selection custom field called "categories", and play! “Easily create blog and article view templates”
Deciding whether it is more priority to finish Joomla 4 or make a native cck could be an eternal debate. Also keep in mind that even if it were evident that one is more priority than the other, you could not force anyone to stop doing something and start doing the other ;-) If you also think it would be great for Joomla to have a basic native cck, think: can I help? by programming, giving ideas, spreading the word about this initiative, or simply leaving your comment of support... any help would be welcome. |
|
You have read too much into my reply. It was a genuine question and in your second part you gave the answer - compatibility and integration. Have you perhaps considered that the reason you have those problems with your cck is not because they haven't thought to develop them but because it can't be done OR doesn't need to be done with their cck I've had repeated conversations with people for many years about cck - what they mean - where the current ones are lacking etc etc. The one commonality in all of those conversations would be a statement such as - but i have no skills to do that. Personally I still fail to see the need for anything extra in core and I havent read anything here that changes my mind. |
|
@brianteeman thanks for answering I deeply regret that I have not been able to change your mind. There seems to be a big gap between Joomla Developers and Webmasters.
We publish dozens of new content every day, such as news, job offers, courses, etc. with joomla, but that something that calls itself a "content manager" does not include the ability to filter that content by custom fields, for example, is very strange. |
This comment has been minimized.
This comment has been minimized.
@MBaker I'm not a Github expert, but I don't think anyone is emailing you. I imagine you are subscribed to this discussion and github sends you notices of updates. Surely at the end of those emails you mention you have an unsubscribe link. |
This comment has been minimized.
This comment has been minimized.
|
I just discover this "another discussion about Joomla CCK" with pro and cons. |
|
yes, and this is why we now use Wordpress, Laravel, Symfony in addition to joomla sites |
|
Having developed a component creating/building extension for Joomla, I am naturally against CCK solutions since it in a way fly in the face of the extension developers market share. Lets face it, if webmasters can setup a dynamic data driven relationship front-end without developers they will. I say that with a chuckle... Spending years to establish an easy and free, yet very advance and powerful solution to development extensions very rapidly. With which you can indeed do 100% every possible thing in terms of websites that you can imagine. I am therefore also very supportive of this extension market, as a volunteer in the JED with the motive to help extension developers succeed in Joomla. Therefore you should easily see and understand my own bias in this matter. That all said, there was a time where if you wanted a website you had to hard code the HTML, hmmm hey there was even a time if you wanted to change the color of a pixel on the screen you first had to poke it get the current color and then choose to change or move to the next pixel... so we can see that as the industry moves forward we are all forced to reinvent ourselves. But it is worth to mention that there is a long standing silent agreement to keep the Joomla core "small" or lets say as a starting point. This means far enough (developed enough) that it is easily extended by your extension developers, but also ready enough so webmasters can also with excitement make use of its features, so it should be easy to understand the next steps to make it greater, but not necessarily be the final complete solution for advance complex projects. But it must be able to master them with the skill of its owner/developer/webmaster/integrator. So reading over this thread and feeling the pain of both sides... we may need to accept that adding a CCK By this I mean, ideally as an evolvement of custom fields, so it is not to replace existing CCKs where they make sense. But that it will provide the needed inroads into the Joomla APIs and internal structures where by CCKs can benefit from the Joomla ego system (much more details here... I know. but just to establish the premise), so we do not completely kill the extension developers market. I know my point of view may upset or even discourage some... but if we can start at a place that serves all in some measure, then we are going to find the common ground to see a CCK integration emerge naturally from the core that is extendable, and calibrated by existing CCKs, and extension developers alike, which will fuel massive growth in the Joomla world as we (that is us as a community) in our own way try to keep step with the ever expanding underlining technologies. The idea that the core should do it all is not the nature of Joomla, it has always pushed towards the path of integration and extensibility that allows growth to take place around itself to the benefit of the whole to ensure inclusive and equal opportunity. And yes Joomla 4.0 as our first focus 👍 |
|
I agree on the "not implementing full CCK options", as already said, be we really need some extended option pour manipulating native content. @Llewellynvdm I really think you provide one of the right options to extend properly Joomla capability using core functions. |
|
Thank you very much @SemaphoreOxalis, I think your distinction of two types or levels of Joomla CCK is very important in this discussion. (We should make it clear at all times what type of CCK we are talking about, to avoid misunderstandings) In short, there are two levels of Joomla CCK:
Going back to the origin of this debate, it seems here the proposal is a "Simple Joomla CCK". (not the advanced one) @nibra, Would it be possible to modify the header of this conversation? Title: “Simple Joomla CCK" 1. Summary For example, if you have a list of activities to do on weekends. With fields such as "date", "free or paid", "city". You should be able to filter by activities in a specific city. And to be able to sort them by price or by date. 2. Why Bother? Adding some order and filter option based on the custom fields will help creating Content website, keeping the Joomla! spirit without bringing the CCK difficulties! |
|
@Sukinoz, thank you for the elaboration of the introduction text! |
|
@nibra I initially didn't want to add it here because there is quite a lot of info in that discussion that is pertinent, and was more than a little fed up with being misunderstood) but can you just let me know how you want the first post in this link formatted to suite your objectives ? I'll add what is important. joomla/joomla-cms#19150 (the first post by xmanflash which is also me) I wrote it after many hours of experimentation with concepts that I thought could be implemented fairly easily into Joomla, it was conceptual but i tried to explain exactly how it would work for me, as i had been frustrated by several projects that required custom fields implemented at a level lower than categories (which i had called 'Types'). I can copy / paste as is or would you like it formatted differently ? Brian Teeman did make some changes in the admin to accommodate the admin menu part of this idea which is useful, but the full functionality is still needed. Somebody had the idea that Categories could still be used as is, or maybe we call the root categories 'Types', which would certainly be a good workaround, but doing this properly, and being able to filter on types/categories/custom fields etc would be more efficient if content is reworked. @sakiss Thank for your contribution both to this page and also to the depth of effort in the filter plugin. Very interesting indeed. |
|
As a website admin As a website admin |
|
Yes @SemaphoreOxalis No visual interface could ever match all those complexities. Therefore I suggest we allow a code approach that will allow this "behavorial override" so that we can filter, sort and group results on any criteria. Only the code approach will allow the flexibility we need. In the same time we can provide a very simple visual interface like Easy Layout provides for 75% of the simple use cases. Starting with the code approach will also make the visual interface easier |
|
@helpwise I guess the link to the discussion in the CMS repo is sufficient, thank you! |
|
@pulsarinformatique Can you provide an example how the code approach should work from your point of view? |
|
TO @nibra : as I see it, the code approach would allow us not only to override the layout of components outputs but also the way the lists are computed. This is this so called "behavorial override" I mentioned earlier. With such a tool we would just need to alter the way the joomla lists are computed. We need a way, through code, to write our own SQL queries based on the joomla articles native columns but also the tags and custom fields. Personnally I would refactor the custom fields storage with an horizontal storage on addition tables. If a category = a custom type then for each category I would have its own related table, the ID column would match the ID column of the #__content table. I know people will complain about the SQL limitations of number of columns but for 99% of projects it will be enough. This storage refactoring will allow much flexible and faster searches. But even if we DON'T change the custom fields storage, having the possibility to inject a custom query to change the outcome of the native joomla article menu items would be the key for many sites according to me. Then we could provide a simplified tab in the category articles menu item in the back end. This tab in the menu item will allow some simpler filtering and sorting feature. |
I must be missing something then because the "code approach" can already be done |
Just a comment. What you mention is how JSN User Component extends the user system, by adding custom fields to a parasitic users table specifically for lookup speed rather than using the typical metadata (all custom fields stored in a json/xml format in one column in the primary table). Metadata is great for data display but not as part of pre-filtering content. I dont think we can reasonably filter data lists based on their custom json content simply for speed reasons, although MySql 8 does have has some great new features for that scenatio. The great benefit of a component is having data stored optimised for listing speed, the metadata is only great for pages. |
I think @pulsarinformatique think about something like this : https://www.advancedcustomfields.com/resources/orde-posts-by-custom-fields/ |
|
On joomla/joomla-cms#19150 it was clear that you just can't call a custom field in the actual overrides to perform the modification of the articles lists. As @SemaphoreOxalis wrote the WP_Query object is a good example of how easy it could become. |
|
Image - building a WordPress compatible content system - including WP_Query - into Joomla 'content 2.0' - we want more plugin developers right ? If the tables were separate for content types instead of bingn just POST and POST_META it would be super fast, and super easy to port content from WP. |
|
Please continue discussions here: joomla/joomla-cms#39461 |
1. Summary
A “Simple CCK” 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). Just a CMS extended with filter and ordering (by menu link or module with switch, etc) and some nice view overrides.
For example, if you have a list of activities to do on weekends. With fields such as "date", "free or paid", "city". You should be able to filter by activities in a specific city. And to be able to sort them by price or by date.
In resume, improve the Joomla Content as a Simple Content Construction Kit (but not a real or complex “Advanced CCK”, with real content-type management, logical relation between them and for creating web apps (like Flexi, Seblod, Fabrik)
2. Why Bother?
Actually, if you just want a CMS extended with filter and ordering, you need to use a third party CCK and stop using the Joomla Core Articles, which prevents using the vast majority of Joomla's own utilities (like Joomla Core Tags, Joomla Core Custom Fields, Joomla Core Categories, Joomla Multilanguage and Associations, Joomla Workflows, etc.) as well as the vast majority of other third-party extensions.
Adding some order and filter option based on the custom fields will help creating Content website, keeping the Joomla! spirit without bringing the CCK difficulties!
See joomla/joomla-cms#26258