is it really b/c to remove those two media files. What if another template is using them?

is it really b/c to remove those two media files. What if another template is using them?

@brianteeman I don't know. @Fedik As it was your PR which removed them from the sources: What do you think? Should we keep them?

If yes, then I have to add an exception to the "build/deleted_file_check.php" script so they are not reported every time as to be deleted.

@brianteeman In previous cases like this we did not keep the js files, see e.g. PR #42364 .

thats php not js

thats php not js

@brianteeman That's right. I asked other maintainers on Mattermost for their opinion. As far as I can see up to now, the JS never was part of any web asset json, so any 3rd party override would have to explicitly load that js file, and it is not very likely that there are template overrides for the multilingual status modal.

likeliness is not a consideration in deciding if something follows our b/c policy or not

@brianteeman But then the files shouldn’t have been deleted in the sources with PR #42082 at the first place, or should they?

The policy as written https://developer.joomla.org/development-strategy.html says that those files are not covered as they are rendered markup but the js is covered

The policy as written https://developer.joomla.org/development-strategy.html says that those files are not covered as they are rendered markup but the js is covered

@brianteeman But PR #42082 has also removed JS files from media_source.

Changed to draft as long as clarification is ongoing if the files shall be kept or not so the PR doesn't get merged by mistake.

is it really b/c to remove those two media files. What if another template is using them?

This file doing nothing useful, that may need for others. I do not see b/c here.

The policy as written https://developer.joomla.org/development-strategy.html says that those files are not covered as they are rendered markup but the js is covered

@brianteeman You are right, the removed js was not flagged as private: https://github.com/joomla/joomla-cms/blob/481a5d6f9fa65b3adad3d32b57e7d96a6c4e0c0d/build/media_source/mod_multilangstatus/js/admin-multilangstatus.es6.js

Will leave this PR as draft until finally decided or confirmed by the maintainers team and if necessary replace it by a new one to add an exception to the "build/deleted_file_check.php" script and some PR for the deprecations stuff on manual.joomla.org .

is it really b/c to remove those two media files. What if another template is using them?

This file doing nothing useful, that may need for others. I do not see b/c here.

usefulness is not a consideration in deciding if something follows our b/c policy or not

Sorry, but this does not make any sense. And I do not see where such case are covered by b/c policy.

If you refering to:

All JavaScript functions and classes that are not flagged as private.

Do you see any function or class in removed file? This file does not containe any of it.
This rule is more about our client side api, about global functions, classes and objects like Joomla, Joomla.Text._() etc.

And btw, I would consider all files under media/plg_x, media/mod_x, and most of media/com_x as private (with some exceptions).
Most of our "public" api is under media/system, rest is private.

I see. I missed the „functions and classes“ part, reading too fast.

Agree with @Fedik here, good to merge.

Agree with @Fedik here, good to merge.

Wait, there are more files coming from PR #42567 . But the discussion is the same for these.

I've updated the PR by the deleted files "media/com_cpanel/js/admin-add_module.js" and "media/com_modules/js/admin-module-edit.js" (plus the minified and gzipped ones).

For them the same applies as already discussed before for the other files and folder: They do not contain any functions or classes so they don't fall under our b/c promise.

See also again @Fedik 's comment above: #42567 (comment) .

Ok, we have just discussed this PR in the CMS Maintainers Team and have decided to play safe. That means this PR here can be closed. Someone (will see if I can find the time) has to provide the necessary documentation for deprecation and removal in 6.0.