You do not need to add the fieldset element. Its not a fieldset as its just a single field and a fieldset also requires a legend

The problem is caused by the class here

<div id="batch-copy-move" class="control-group radio">

Hmm. The problem is that everything is done differently. For example, categories in banners.

Consistency is terrible. Great that you are spotting these.

Without adding the fieldset but removing the class

<div id="batch-copy-move">
	<?php echo Text::_('JLIB_HTML_BATCH_MOVE_QUESTION'); ?>
	<?php echo HTMLHelper::_('select.radiolist', $options, 'batch[move_copy]', '', 'value', 'text', 'm'); ?>
</div>

@Kostelano PHP code style check in drone reports mixed line endings for both files. Please make sure you only have Unix line endings.

@brianteeman Thanks, I redid it according to your advice.
@richard67 Thanks for the info, I will wait for the result of a new check.

@Kostelano Same result, see here: https://ci.joomla.org/joomla/joomla-cms/43741/1/6

Looks good - it would be great if you reviewed all the batch modals to make sure that no others have the same problems

I have tested this item ✅ successfully on b08f65e

@Kostelano You still haven't fixed the mixed line endings which are reported by the style check in drone and about which I have informed you here 2 times, now the 3rd time. As said, files in our source code have to have Unix line endings, so check and remove all windows line endings.

@richard67 I remember, I have not forgotten. I'll fix + see other batch processing modals a bit later.

I have tested this item ✅ successfully on b08f65e

Expected result

@Kostelano It still neds to fix that PHP code style issue with mixed line ending.

@Kostelano PHP code style seems to be fine now. Current drone failure seems not to be related to this PR.

Previous test results are still valid since the commit which invalidated the result was just a code style change. I've restored the results in the issue tracker so they are properly counted.

RTC

Thanks