This morning I updated my clone (git pull; npm install), ran the query to update the fields table and then applied the patch. When I go to Articles / Fields / New I get a fatal error:

 Fatal error: Class Joomla\Plugin\Fields\Calendar\Extension\Calendar contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Joomla\Event\SubscriberInterface::getSubscribedEvents) in /Users/ceford/Sites/joomla-cms/plugins/fields/calendar/src/Extension/Calendar.php on line 26

Remove patch and New Field works fine.

This morning I updated my clone (git pull; npm install), ran the query to update the fields table and then applied the patch. When I go to Articles / Fields / New I get a fatal error:

 Fatal error: Class Joomla\Plugin\Fields\Calendar\Extension\Calendar contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Joomla\Event\SubscriberInterface::getSubscribedEvents) in /Users/ceford/Sites/joomla-cms/plugins/fields/calendar/src/Extension/Calendar.php on line 26

Remove patch and New Field works fine.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/41348.

Thank you. I'll think about it.

This pull request has been automatically rebased to 5.1-dev.

@ceford Please check. Is it working now?

AND add code

this.listOfHidden = this.$headers.map((th, i) => th.classList.contains('d-hide') ? i : false).filter((i) => i !== false);

in \media\system\js\table-columns.js in 11 line.

@richard67
Please tell me, is this a useful PR? Or is it against the rules of the community? Just to not worry about it.

@richard67 Please tell me, is this a useful PR? Or is it against the rules of the community? Just to not worry about it.

@korenevskiy It's not on me to decide anything, and I don't have an opinion on it. But maybe it will help to find testers if you remove the "[Draft]" from the title of this PR.

@richard67 Thanks for the advice. Please tell me, this PR also consists of a reference \media\system\js\table-columns.js . But this file is not in this repository. What is the best way to add a correction to the Media Repository and wait for the tests, or debug it first and make sure it works well, and only then add a PR for the correction \media\system\js\table-columns.js ?

@korenevskiy Why don’t you just look up how it is done for other JavaScript resources?

@richard67
Thanks for the tip. If I understood correctly, there is a folder equivalent to MEDIA_SOURCE.

Please tell me what is the meaning of the properties of the JS class with the first letter $ ? At first I thought that arrays denote there, but no, I was mistaken.

Please tell me what is the meaning of the properties of the JS class with the first letter $ ? At first I thought that arrays denote there, but no, I was mistaken.

@korenevskiy I am no javascript expert, so I don’t really know, and I don’t have the time now to investigate that. Why do you always ping me? There are more people around who can help, not only me.

@richard67 It's just that you are the person who rejected my useful PRs with meaningless arguments. It's not that you rejected, but that the arguments didn't make sense. Therefore, in this PR, I thought to ask your opinion in order to be 100% sure whether this PR makes sense.

ALTER TABLE `#__fields` ADD `show_in_list` BOOLEAN NOT NULL DEFAULT FALSE AFTER `only_use_in_subform` ; 

I'll ask you one last question. In which SQL file do I need to add this line so that a column is added to the kernel? I didn't find any examples in other PRs. I assume that me need to create a file
/administrator/components/com_content/sql/5.0.1-2024-02-02.sql
and add line in
/installation/sql/mysql/extensions.sql
/installation/sql/postgresql/extensions.sql

IF NOT EXISTS( (SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA=DATABASE()
        AND COLUMN_NAME='show_in_list' AND TABLE_NAME='#__fields') ) THEN
    ALTER TABLE `#__fields` ADD `show_in_list` BOOLEAN NOT NULL DEFAULT FALSE AFTER `only_use_in_subform` ;
END IF;

I think this is the script that needs to be saved to a file /5.0.1-2024-02-02.sql ?

@richard67 It's just that you are the person who rejected my useful PRs with meaningless arguments. It's not that you rejected, but that the arguments didn't make sense.

@korenevskiy After this statement please do not notify me anymore here. I will not respond. Shall someone else help you with SQL.

@ceford Please help me, How do I place the SQL correction in the PR?

@ceford Please help me, How do I place the SQL correction in the PR?

Sorry, I do not know.

@korenevskiy the basic idea is not bad, I made a RFC some time ago (joomla/rfc#31). But it needs are more global approach. Just doing it in a small area doesn't makes so much sense and makes the whole system more complicated.

This PR has been discussed in todays maintainers meeting and we made the decision to close this PR. Thanks for working on this.

Great right. I don't mind closing it.
But what does deeper problem solving mean?
This PR is just a draft. So I was trying to solve an approach, i.e. a method that then needs to be scaled.
In this PR, we could discuss field plug-in events, solutions.
I already had a small idea in reworking this PR so that the code could be partially transferred from the MODEL component to the PLUGIN. This would preserve the concept of CMS programming methods.

@korenevskiy the basic idea is not bad, I made a RFC some time ago (joomla/rfc#31). But it needs are more global approach. Just doing it in a small area doesn't makes so much sense and makes the whole system more complicated.

This PR has been discussed in todays maintainers meeting and we made the decision to close this PR. Thanks for working on this.

I have read the RFC.
I also agree with the redesign of the forms.
I've been writing complex dynamic custom fields plugins. For example, a field with the output of graphs or a field with the output of temperature readings of objects.
I faced a number of terrible limitations. I realized that the fields are not intended for this at all, they can only display lines next to articles.
I have experience and I would also make comments on the current implementation.
I would suggest abandoning the SimpleXMLElement object. In fact, the objects of the form and field classes are wrappers around the SimpleXMLElement object. From a programming point of view, a SimpleXMLElement object is just a deep array whose contents have no types or interfaces. Another problem is to transfer an object from the plugin to the field output layout, you need to serialize these objects into a string, and then deserialize them in the layout in order to create a graph or other complex content from the object.

It is very important that field class objects can be created without assigning an XML object in the SETUP() method, and the SETUP() method should also be optional.

@korenevskiy the basic idea is not bad, I made a RFC some time ago (joomla/rfc#31).

There is also a problem of double rendering of the custom field.
If you put a code in the layout field

Factory::getApplication()->enqueueMessage(' Test render layout: ' . rand());

You will see how the field is rendered 2 times. Of course, the result in the article will be shown 1 time. But there is a fact of double rendering.