No, it's not an oversight. It's just not possible the way com_fields and versioning works.
Afaik content versioning works from the table using the observers. Com_fields works using regular plugin events and stores the fields data after the table is already stored. Withing the table, the custom fields data isn't available since it got removed during the bind event.

So because something was hard to do - it was decided to ignore the existing features of Joomla Articles and simply to not implement versioning for custom field data

This is not acceptable.

We either have a Version feature that is fully feature complete, or we remove versioning...

An admin would be fully expecting that everything related to an article would be handed by versioning... and apparently this is not the case

I said it is not possible. Not that it was hard.
Of course if you see a solution we can implement it. But I don't see how it could be done without tightly coupling fields to the extensions tables.

I said it is not possible.

Everything is possible.

This is the nature of an open source project - everything is possible!

So I guess we have then somebody who is volunteering if you know how to do it, thanks @PhilETaylor ?.

I never said I knew how to do it or volunteering to do it - please do not put words into my mouth.

But then I would trust the words of the maintainers. According to your comment I thought you know how to do it.

Whatever @laoneo its clear you are just trying to pick a fight.

The truth is that com_fields has been half-heartenly integrated to Joomla Article/com_content and now users in Joomla 3.7.0 will have a broken accurate versioning system for content.

Nothing in open source is "impossible"

Right now, saving a version of an article, doesnt save a version of the com_fields fields - this, by logical design, is incorrect and needs addressing.

If you dont want to bother doing hard work to integrate it correctly, then this needs communicating to site admins, with a warning, Else an admin will assume that ALL DATA associated with an Article is handled by Versioning - like it currently is in 3.6.5...

At the very least, communication about the extreme limitations of com_fields needs to be done.
At the very best, the full integration of versioning to com_fields attached to content has to happen.

The way fields is written, and the way versioning is written, and honestly the way the entirety of Joomla is written, does not make including field data into the versioning records practical (or even possible), nor does it really support the notion of multiple components functioning together at one time. There are too few hook points throughout the system and too inconsistent of hook implementations throughout different parts of the API (table observers aren't hooked to the plugin event system and tags and versioning use those observers). Frankly without writing every component in a way that makes it impossible to detach com_fields it is impossible to get a clean and full integration of everything into everything else.

So to summarise @mbabker - com_fields is architecturally broken before its even released. Great.

No, it is not a flaw of com_fields. It is a flaw of Joomla as a whole. The core architecture in the CMS just does not support very efficiently (if at all) some of the "core" features it markets. Tags, version history, and fields frankly are three "major" features which show very well why Joomla's code is bursting at the seems.

All the more reason to fix the issues!

Did we not have an Architect? ah yeah... Mr Johan J.....

Joomla is dying and no one gives a hoot.... lets just add another brick to the top of the pile, integrated pathetically... lets see how high we can build this tower on a foundation of flawed design...

Oh year - Joomla X/4 will solve all this magically with a new pretty UX as well....

fml....

If you really want com_fields to support versioning, here's what you need to address.

The versioning configuration for a content type is stored to the #__content_types table. That configuration is stored as a JSON string which holds the mapping data (what fields to include/exclude, the source table for each field, etc.). There is no API for working with this data, there hasn't been since it was introduced in 3.2 (November 2013). Even extension developers supporting tags or content history have to manually build all this stuff and run the INSERT/UPDATE queries on their own.

Come up with a way for com_fields to manipulate the correct records in that table and you have a starting point.

But, this is where it gets complex. The #__content_types table represents singular content types (so its configuration applies to all com_content.article objects). com_fields works in a way where fields can be assigned to not all articles. So in effect, you can't save that mapping data to the database because it can and probably will be different with many articles. The only way to manage that would have to be a hook point in all the versioning processing that some com_fields code could reach into and dynamically add all the appropriate data. And for that, all I'm going to say is good freakin' luck.

So no thought was given to this during the design of the architecture of this new feature? Or just simply ruled out implementing new features that are fully integrated to old features because it was easier to design a fake-ucm instead of implementing fields in a more structured, reuseable way....

This is why joomla gets an bad name

Now we have a new feature of content articles that doesn't integrate well at all

You can now revert/compare versions of articles but not it's data in its custom fields

And no one feels this is wrong!???

Regardless of the bad architecture under the hood - this workflow is simply wrong - and with no communication about the fact that field data is not stored in an article version this WILL become a support issue (that is if anyone actually uses versions!?!?)

Sent from my iPhone

On 3 Feb 2017, at 13:44, Michael Babker notifications@github.com wrote:

If you really want com_fields to support versioning, here's what you need to address.

The versioning configuration for a content type is stored to the #__content_types table. That configuration is stored as a JSON string which holds the mapping data (what fields to include/exclude, the source table for each field, etc.). There is no API for working with this data, there hasn't been since it was introduced in 3.2 (November 2013). Even extension developers supporting tags or content history have to manually build all this stuff and run the INSERT/UPDATE queries on their own.

Come up with a way for com_fields to manipulate the correct records in that table and you have a starting point.

But, this is where it gets complex. The #__content_types table represents singular content types (so its configuration applies to all com_content.article objects). com_fields works in a way where fields can be assigned to not all articles. So in effect, you can't save that mapping data to the database because it can and probably will be different with many articles. The only way to manage that would have to be a hook point in all the versioning processing that some com_fields code could reach into and dynamically add all the appropriate data. And for that, all I'm going to say is good freakin' luck.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

You're welcome to become the project's new architect if you like. Oh, by the way, historically the project doesn't support developers with strong architectural experience, it favors developers who contribute things to make the UI pretty. Why do you think WordPress supports a core REST API while Joomla still croaks serving HTML content?

As long as Joomla keeps favoring "feature of the day" versus getting a proper roadmap together, getting a proper architecture built, and properly integrating features together, it's going to continue being laughable. Let's be frank here, end users don't really care about the architecture. As long as the code base and developers are treated as second class citizens of this project, it's not going anywhere good anytime soon.

On that - we both agree

Sent from my iPhone

On 3 Feb 2017, at 14:18, Michael Babker notifications@github.com wrote:

You're welcome to become the project's new architect if you like. Oh, by the way, historically the project doesn't support developers with strong architectural experience, it favors developers who contribute things to make the UI pretty. Why do you think WordPress supports a core REST API while Joomla still croaks serving HTML content?

As long as Joomla keeps favoring "feature of the day" versus getting a proper roadmap together, getting a proper architecture built, and properly integrating features together, it's going to continue being laughable. Let's be frank here, end users don't really care about the architecture. As long as the code base and developers are treated as second class citizens of this project, it's not going anywhere good anytime soon.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.

Ever thought that maybe the versioning feature is the limiting factor here?
I can't even store evrything properly in it for my own extension because of its limitations. The feature isn't extensible at all. It's more or less hardcoded to the properties of a table. If it would work with the validated form data, then it would work for fields as well.
That's the real issue. It's not a flaw in the Fields feature.

I also think we need to accept that we have to go step by step. The base is done now with com_fields. Everything else like frontend filters and sorting, more fields or versioning needs to be done on a later step. It is just not realistic that we can have everything right from the beginning. Joomla has just not the manpower to do that.

Hi. any news about it now please?