What modal window?
Sounds like it is missing the needed JavaScript. The reloading is necessary because the available fields may change when you change the category.

Custom form in a modal window that uses data-remote with a raw view.

And because com_fields take over the form load it will always try to inject the javascript from https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_fields/helpers/fields.php#L330 into the header. That is not possible in a modal window that uses data-remote with a raw view.

So yes it will always miss the javascript.

As I pointed out in this comment, this javascript block is on the wrong place actually. But honestly I don't know where to put it. @dgt41 any clue?

The easy patch is to check

if (window.parent != window.top) {
window.parent.categoryHasChanged(element)....
}

But this just reveals the limitations of the current approach of building forms. Forms should, preferably be ajaxified, so no actual page reload is needed

@dgt41 that will not work as it a raw view modal. I does not have a header section where the field helper can put its JS.

Is that a modal which is supposed to support custom fields then?

I dose not matter as the code will inject to whatever form you create that has a category field with id catid. I can create a form on a page with just a category selector. As soon as I change the category it will reload the page. That is not the behavior I want when I just have a category selector in a component on the frontpage. Does that make sense? That is not have 3.6.x and previous version have been doing and will create BC for component that have a category selector.

I could change the ID to something else but then we need a converter in the code to match it up with the table on save.

I found a easy solution to the problem. Just remove the onchange from the field when the form is loaded in the view. This will override what the prepareForm function does.

I think, the whole code should actually first check if the extension is supposed to support com_fields (maybe check if the validateContext method exists?). At least I didn't see such a check.
If not, it may indeed have a chance to break things. At least it doesn't make sense to reload the form for each extension which has a category field.

It adds that code only when there are fields. If there are none, then the code is not added.

It adds that code only when there are fields. If there are none, then the code is not added.

Ah true, somehow the blind cow in me missed that code.

Just remove the onchange from the field when the form is loaded in the view

So this would not work as soon as custom fields come into play. The 3rd party dev needs to provide some own code which deals with that situation then.

The best solution would be to check in the getFields if there is any fields with assigned categories. If not do not add the onchange value to the field.

According to @laoneo that wouldn't work either. You need to reload the page somehow to make sure the custom fields are appropriate for the selected category.
If your form doesn't support adding JavaScript then changes are high anyway that something is broken. Or how does for example the date picker work? Or the "on the fly" creation of categories?

@Flowman Is there any occurance of this issue in core? Or does this need a 3rd party extension? If so, can you provide a way to test it?
Otherwise I tend to say it's not a bug but it's the normal part of implementing a new feature into an extension. You need to adjust the code to cope with it.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/13772

closed as "No Reply"