and the problem is?

The problem is that you need this data. E.g. when items can have multiple categories, you need to get the information about the current active category which you get in filter[category] array variable.

No idea if this is a problem for article view, but it is problem for another extensions. I don't know if it's intentional to make the API hostile to extensions (and it's not just this issue), or if it's just plain ignorance.

I couldnt guess that from your screenshot

The difference between Joomla 3 and Joomla 4 is that Joomla 3 sends all form data but Joomla 4 only order and cid variable (or another data in table row - I didn't test).

You don't need to see the screenshots, you can test it for yourself. Just order items in Joomla 3 and Joomla 4 and enable e.g. Google Chrome DevTools - Network tab (Fetch/XHR subtab) and see which Form Data items are sent when ordering items.

• In Joomla 3 - all form data
• In Joomla 4 - cid, order data (or another in table row).

That is all. All form data items are used by extensions because they have extended features in comparison to core - like e.g. multiple categories (items can be assigned to more than one category), etc.

You don't need to see the screenshots, you can test it for yourself.

Maybe but from your original post it was meaningless. It's called saveorderajax so why would it do anything other than save the order

To save the order, you need data. I don't ask for any other function. The saveorderajax function just does not send the needed data in Joomla 4. (In Joomla 3 everything is all right).

Sorry but I don't understand your answers. This issue is clear:

Joomla 4 - not all form data items are sent
Joomla 3 - all form data items are sent.

The problem here is not article view which is an example to test it, the problem is the saveorderajax feature.

Why would you need any more data than the order and the id

Not really a bug, but changed behavior.

The sorting js for joomla 4 was almost rewriten,
I suspect joomla 3 use jQuery(form).serialise(), that why it hold whole form.
Joomla 4 send only changed data.

Maybe we can add some more data, eg. active filters could be usefull in some cases for 3rd extensions.
PR are welcome.

I have updated the documentation:
https://docs.joomla.org/Potential_backward_compatibility_issues_in_Joomla_4
but unfortunately, I don't know the new structure of Javascript feature in Joomla 4 so there I cannot help.

Sending only cid and order does not reflect the ordering needs. And I don't think, adding only filter attributes is enough, because even additional hidden form fields can be set there. E.g. for my needs, filter values are enough but I can imagine, some other developer uses even hidden input form fields. But we will see when developers will start to overwrite extensions which are strongly based on Joomla API.

Jan

Hmmm, unfortunately, it does not take any other parameter set in row, order and cid is fixed. This is very unfortunate and very limiting - as if the CMS did not count on having any extensions at all. However, it must be clear to everyone that sorting e.g. items that can have multiple categories must have additional parameters. These are basic logical rules that were accepted in Joomla 3 by default.

CMS is content management system. System which is based on extensions and if it limits extensions (in comparing to previous version), then this should be marked as bug. Otherwise we can describe Joomla CMS as very hostile to its extensions.

I must be thick because I still dont see what or where the problem is.

The problem is, saveOrderAjax function does not send enough data to successfully sort and extenstion cannot send additional data manually because only two items: cid and order are set by Javascript function.

What do you need to know when you want to order items (articles) in Joomla?:

• order value and cid value (id of item) ... is enough

What do you need to know when you want to order items which can belong to more categories?

• order value, cid value (id of item) and catid value (id of category)

If item can be stored in more categories, it means, it has different ordering for each category, so only ordering value is not enough. You need to know the category ID too. So when ordering, you need to send category ID plus both of the values (order, cid).

And the Javascript function:

• does not send the category ID (the same for all other possible filter values)
• and does not allow to add this missing value, because it looks like, only order and cid is set as fixed in the Javascript function.

When we speak about multitple categories, this is only example. This is even valid for all other filter values.

The problem is, the saveOrderAjax selfishly uses only those values that are used in core, but no longer cares that this function must also meet the needs of other extensions.

As @Fedik wrote, it should at least send the filter values (and no idea if this will be enough, maybe some extension uses even hidden form fiels).

BTW info for developers facing the same or similar problem.

A dirty hack is to paste the filter values to URL, which means, that you need to manage GET data instead of POST:

$catid = $this->escape($this->state->get('filter.category_id'));
$saveOrderingUrl = 'index.php?option=com_component&task=sometask.saveOrderAjax&tmpl=component&' . Session::getFormToken() . '=1';
if ((int)$catid > 0) {
    $saveOrderingUrl .= '&catid='.(int)$catid;
}

Still didn't make all possible tests, so no idea, if this solution will not break any other part.

@PhocaCz can you provide a pull request including all parameters of the "filter" form please?

btw. the alternative could be to save the needed information in to the user state object

@HLeithner unless I'm totally wrong Joomla only supports the pattern of an item could be a child of a single category or alternatively written: an item cannot be a child of multiple categories. Thus the sorting JS is totally ignoring the category Id.
I guess the core shouldn't care about this as it's way out of the Joomla expected pattern.

My 2c

yeah that's a problem, seems to be the same reason why it's not possible to use the joomla subform element for more then it's limited scope :-(

Many thing in joomla are only written for the limited point of view and restricted to a single tasked without looking at what you could do with it if the developer thought 5 minutes about the possibilities... /rant

Many thing in joomla are only written for the limited point of view and restricted to a single task

That's actually a good thing that follows the UNIX philosophy, do one thing and do it well. In this case Jan can fork the joomla script (or use any other script that does the same thing) and add on top the required functionality (a 2 lines thing in this case). My point is Joomla shouldn't roll code that is not used directly in the project, Joomla can't foresee all the possible ways devs will try to abuse the APIs...

It's not black and white... as always... when I get back to the subform element, I would really like to use it in a more dynamic way but it's not possible to give the element a json string and it recreates the form base on it....

for this example, sending the current state doesn't hurt anyone. Even if I understood your point, we are the framework and should gave the users (in this case 3rd party devs) the tools they need. Always with the (in my opinion more important part) of maintainability for the core devs. (Means if it's a pain to maintain or is against the way it's intended then it shouldn't be done).

Yeah the UNIX philosophy is good and I like it but I also like systemd really much ;-)

The bigger problem comes with testability if the core doesnt use the code

for this example, sending the current state doesn't hurt anyone.

Sure but we don't have the form in the script, so it's not that easy to do it for everybody (eg old scripts assumed always that the form had an id adminForm or something like that and this is really bad and we shouldn't bring it back)

when I get back to the subform element, I would really like to use it in a more dynamic way but it's not possible to give the element a json string and it recreates the form base on it

What if I told you that Adobe has the perfect Web Component for this particular case (I use it very often)

The bigger problem comes with testability if the core doesnt use the code

That's a part of maintainability.

Sure but we don't have the form in the script, so it's not that easy to do it for everybody (eg old scripts assumed always that the form had an id adminForm or something like that and this is really bad and we shouldn't bring it back)

should we bring jquery back? should be a simple one-liner ;-)

What if I told you that Adobe has the perfect Web Component for this particular case (I use it very often)

It's not available in Joomla...

@HLeithner what's pathetic is that developers instead of opening PRs with the changes they want they open issues and keep complaining about other people's code...

Here's the 3 (or so) lines of code: #36353

@PhocaCz can you provide a pull request including all parameters of the "filter" form please?

Unfortunately I can't, I don't know the solution, I'm just a passive user of the Joomla API and its methods. What I described here is just a dirty hack for one filter value - for a category. Sending all values in general is a matter of modifying the Javascript method.

Personally, I don't think it's important to know the name of the form, because if we move something, we are inside the form. Thus, we just need to find the parent form of the active element.

I'd like to point out to all discussants that I'm one of the few developers who try to make the extension have the same form, the same UI/UX as Joomla itself. This is also why these extensions are popular, because basically the user can't tell the difference if he is managing an article item or a component item. And here you are telling me to write my own solution? No, because the uniformity is important. To make the system attractive to the user it is good that all parts of the system are more or less the same. And that's what we're trying to do in the Joomla project. And that's why Joomla API should be ready for more options/features than just core.

I may be one of the few here who points out the backward compatibility violation between version 3 and between version 4. And do you know why? Well, because others have completely ditched the core of Joomla - they are using their own solutions and working on an independent solution to leave Joomla behind. But I still hope, this is not the goal of Joomla CMS, to upset extension developers and send them away (including insults just because they points out a mistake).

BTW: I would like to use the topic of sorting/ordering to point out that sorting is sometimes impossible. I originally thought this only applied to subforms, but it applies to sorting all items, see example - menu links:

A possible help is to hide all parts of the item except the title (as displayed in GIF). But the problem is that the items don't have a uniform output - the items in the menu links are different from the article items. Therefore, choosing what to hide using JavaScript is not easy and is very inconsistent for different part of the system.

A possible help is to hide all parts of the item except the title (as displayed in GIF). But the problem is that the items don't have a uniform output - the items in the menu links are different from the article items. Therefore, choosing what to hide using JavaScript is not easy and is very inconsistent for different part of the system.

Of course that's not a solution that a terrible hack. What you want is enabling scrolling when you drag and that's not even a Javascript thing it's a CSS. The solution is far easier than any hide monstrosities, think simple...

Unfortunately I can't, I don't know the solution,

You don't have to, I already have a PR #36353. One more thing, everything around JS and CSS should be treated as BREAKING CHANGES. If some selector from Bootstrap 2.3.2 or some JS from the J3 still works for all your cases then it's fine but it's shouldn't be the expectation. J4 was a major version with a transition to BS 5 for the CSS and to vanilla JS for all JS scripts, so things are expected to be slightly different...

Of course that's not a solution that a terrible hack. What you want is enabling scrolling when you drag and that's not even a Javascript thing it's a CSS. The solution is far easier than any hide monstrosities, think simple...

This terrible hack now helps people to sort items in Joomla as they are not able to do without this terrible hack:

https://www.youtube.com/watch?v=aq_uks3gM1o

This terrible hack now helps people

Great for you, then. Could you test the PR and if it solves the problem here close the issue?

BTW you're solving a problem that has a solution with 1 line of CSS with Javascript that I'm pretty sure has some severe effects on a11y, and other unseen problems, but your code your rules...

The fact that you can't sort in Joomla is a11y problem, not the solution mentioned above. If it's a one line issue in CSS, why doesn't it exist in Joomla? It would save me so much time, I wouldn't have to invent these helper system plugins for users and attend to other features.

your refusal to contribute or test is the real issue.

???

Reading through the posts, you are attacking people who are trying to improve Joomla and help Joomla users as best they can. Are you both sick? Do you take drugs or drink alcohol? I don't understand you at all.

If it's a one line issue in CSS, why doesn't it exist in Joomla?

Because it's not a problem, you can already drag and scroll:

Which OS do you use? This does not work on my OS - the scrollbars do not move.

As a developer I use a Unix based OS, either MacOS or Ubuntu

Testing on Windows, on Kubuntu (Ubuntu with KDE), this just does not work. And if fact, I didn't do the system plugin for myself, I did it because users asked me.

Joomla 3 ... OK

Joomla 4 ... Not working

And if fact, I didn't do the system plugin for myself, I did it because users asked me.

Let's accept that you're right and scrolling doesn't work on Windos, then the solution is not the rather weird solution you came up with but adding this: https://github.com/eevleevs/scroller TO THE CORE JOOMLA DRAG AND DROP.

you are not using the mouse wheel while draging right?

you are not using the mouse wheel while draging right?

I have a trackpad so no mouse wheel or other helping wheels (dropped them many decades ago ?)

btw maybe you should not hijack check this issue (even if it's your own)

In Joomla 3, the scrolling works automatically - when you move, it scrolls
In Joomla 4 you need the mouse wheel (which is very problematic as the move works on click and I would say, a lot of people use the same finger for left click and the wheel - so the finger is in conflict) BUT - the wheel does not work for subforms

Let's accept that you're right and scrolling doesn't work on Windos, then the solution is not the rather weird solution you came up with but adding this: https://github.com/eevleevs/scroller TO THE CORE JOOMLA DRAG AND DROP.

Look, I'm not here to debate which solution is better or not.

People have come to me that they can't sort in Joomla 4 if I couldn't do something. That they would like if all the data was collapsed to make it easy and friendly to sort.

I made them a system plugin that solved this situation for them right away.

Now, since I'm not a Joomla JavaScript developer there's only one thing I can do. Point out this problem. If someone knows a better solution and will make it for core, I will just appreciate it. This is not a competition. This is a feedback.

The scrolling thing is fixed with: #36354

For the record: this is the last time I'm responding to such rude behaviours.

For the record: this is the last time I'm responding to such rude behaviours.

Are you referring to your posts?

@HLeithner what's pathetic is that developers instead of opening PRs with the changes they want they open issues and keep complaining about other people's code...

• "pathetic" - what is pathetic about sending feedback, about bug reporting?
• "instead of opening PRs with the changes they want they open issues" ... I am not the Joomla Core Javascript programmer and didn't create the Javascript which just didn't work in this case ... But this should not prevent me from sending feedback ... this is not about what I want.
• "keep complaining about other people's code" ... I'm focusing on the faulty code, not the people, how many times am I going to repeat this?

Of course that's not a solution that a terrible hack

then the solution is not the rather weird solution you came up

Your responses are full of hate and anger, you manipulate, lie, in your sentences you try to demean others and then complain about something only you do. People who report bugs and try to help the Joomla project somehow are not your problem. Your problem is yourself.

As I wrote above, I'm one of the few who test various problematic parts, that's why I also give feedback. I've gotten used to your rude behavior, but I will continue to give feedback on problematic parts.

And just so you understand, here's the third time. I don't care who created what, I care about the code and its functionality. This is not a competition. It's just feedback.

So how should I understand your answers? That it's pathetic when someone reports a bug because he/she wants something? That hot fixes are just weird solutions and terrible hacks?

I don't understand this behavior at all. Here is a user who describes the problem clearly (even explains it with examples). He tests it in Joomla 3, then in Joomla 4. He describes the differences in behavior. Describes clearly why the feature was the way it was in Joomla 3. Then adds some solutions for developers who need to fix this problem as soon as possible. And he's bombarded with comments about why he won't do PR, that he wants something and that he's not contributing at all, etc. How old are you that you don't understand that the person who didn't create the code and reports its misbehaviour may not know how to fix the problem? The person who didn't create the code probably doesn't have the knowledge to fix it after someone else does. What's not to understand about that? How can this be an excuse for such aggressive comments?

@PhocaCz I was planing to stop contributing to Joomla once child templates were settled for 4.1 but I guess I can do that earlier. C ya

@dgrammatiko

You don't understand anything what I wrote. This is not a topic about you, this is a topic about ordering. Why are you applying this to yourself, why personally?

But worst of all, you have the knowledge to fix the code in minutes. Why does it always have to be such a big deal?

How about trying this tone:

"This issue can be solved with this code, but I don't agree with this solution. Let's the leadership decide if we change it or not" Dot. Respect. No comments needed.

You’re quoting me and then telling me it’s not about me? And a few posts above you asked if I was on drugs or drunk?

Really now?

Why does it always have to be such a big deal?

I’ll tell you why: most of the bugs that you report are based on some very weird interpretation of the API. Eg in this case you go against the Joomla fundamental architecture and you assign an item to multiple categories. That’s not how Joomla was designed to work and quite frankly it shouldn’t really care for such implementations. You want to scrap joomla’s architecture? Fine, but don’t say the default things are not working with something that’s outside the designed specs…

I've only read so far, but I also have to write something.
Why does this trial come to me like when small children argue about a shovel in a sandpit?
If there is a solution, do it (correct, add), there is no need to discuss. Be happy for your feedback.
Stop applying problems to yourself, don't deal with emotions and solve an existing problem.
Thanks...

@coufalpetr there are PRs for all the "bugs" mentioned here: #36353 and #36354 but it's up to the author of the issue to close it (after confirming that the solution is solving the problem) @PhocaCz prefers to write many words instead of testing the code...

I’ll tell you why: most of the bugs that you report are based on some very weird interpretation of the API. Eg in this case you go against the Joomla fundamental architecture and you assign an item to multiple categories. That’s not how Joomla was designed to work and quite frankly it shouldn’t really care for such implementations. You want to scrap joomla’s architecture? Fine, but don’t say the default things are not working with something that’s outside the designed specs…

This is where you are wrong, I applied what the Joomla 3 API allowed me to do. When I converted the component to Joomla 4, I found no mention of this change in the backward compatibility violation. That's not a reason for feedback?

I am here in the position of a Joomla API user and I am sending feedback about a change that was not mentioned anywhere. And I explained quite clearly and in detail that the Joomla API is meant to serve extensions as well. As you can see from the discussion, I myself have found another solution and am not dependent on this fix. Of course, not fixing it can also be a problem when other developers start rewriting their extensions. The example of items in multiple categories is a standard feature that even users call for in Joomla core.

My reports concern unexpected changes (mostly not listed in the list of backwards compatibility violations). They concern things that the Joomla API used to use by default and now can't without any information.

And giving information why a feature that worked in Joomla 3 and doesn't work in Joomla 4 and why it's good to have it is not a reason for aggressive answers.

The second part was about a clear bug, there is nothing to explain here at all.

@PhocaCz prefers to write many words instead of testing the code...

No, I'm just defending myself against your accusation, then I can start testing.

And yes, I will of course test them as I do always, but I need to create completely new instance as on my test development server, it works OK due to my changes. So this takes some time.

If the function from J3 is missing in J4 and it was not mentioned anywhere, you have to admit that Phoca is right. Feedback is important. If the problem is fixed, it's great. Other discussion is useless and you waste time on it. Speaking of which, is there a list of missing functions (functions that are in J3 but missing in J4)? Respectively, a simple overview of what is missing in J4 compared to J3? Did anyone record it while editing? Thank you.

So guys, I'm locking this now.

The problem is not in this thread, it's more a personal problem between the attending people and that's really sad. I'm a bit surprised that Jan uses such a aggressive tone out of the blue because someone else doesn't understand the use case. Especially as I know Jan personally and he is a really nice guy without any aggressive tendencies (at least my observations).

Anyway the answers he got wasn't nice and was also in a rude tone so rereading this thread makes it a loose-loose situation for good and respectful communication...

The only positive thing of this thread are the 2 pull requests by dimitries for I'm very thank full. Hopefully jan can test the 2 PRs and give a proper and respectful feedback on it so it can get merged and makes Joomla better.

Also closing this because we have 2 PRs #36353 and #36354