Shouldn't new features go into 4? Question is of course if this is a new feature or an extensions of an existing one. I have no opinion on that (yet), I only ask because I'm curious ;-)

let me add more woods to the fire @HLeithner

Basically it is a security fix that should be done in public. It's an extension to the last security fix in 3.9.12

I see ... thanks for the info, Harald.

@zero-24 I get a

Joomla\CMS\Form\Form::validateField() rule filepath missing.

What am I doing wrong? Patch has been applied with patchtester.

@zero-24 I've found the problem. On Linux the class is not found because case-sensitive file names, on Windows that does not happen. Name should be "FilepathRule.php", not "FilePathRule.php". Or maybe it works, too, if you name the validation value "filePath" instead of "filepath"? But we have lowercase everywhere else for the validation values in the XML's, and files names should be like "SomefunnythingRule.php" if validation is "somefunnything". I remember @wilsonge recently made such correction at other place.

Update: I've made a PR against your repo to fix that, @zero-24 .

@zero-24 Next error after file name has been corrected: It does not validate empty field, but it must be possible to have empty logo field in the Protostar template style. So when logo field is empty, I can't save and get the validation message. Silly question: Did you test your PR yourself?

@zero-24 Would be easy to just return with true at the beginning if value is false (i.e. null, empty string or boolean false). But is that always desired?

Yes that's fine. Just needs these standard lines at the top https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Form/Rule/ColorRule.php#L41-L49

@zero-24 Updated my PR for you with George's code for validating ok if not required and empty.

@wilsonge What about file name and validation value? Better "FilepathRule.php" and "filepath"? Or better "FilePathRule.php" and "filePath"? As it is now ("FilePathRule.php" and "filepath") it doesn't work for me on Linux.

I'm sure there's a handful of places in components in j4 where we've used FilePathRule.php convention (in the context of field names rather than rule names) but please check

@zero-24 did you miss that Media field allows to enter Image URL?

@richard67 All newly added classes should use CamelCase naming. Assuming filepath is not a valid word, the class should be named FilePathRule and XMLs updated to reflect this.

@zero-24 I've made zero-24#45 for you to save you some work.

this reminds me of the symlink issue and the resulting consequences

I have tested this item ✅ successfully on fe60e1b

Now it works on Linux, too ;-)

I have tested this item ✅ successfully on fe60e1b

Works for me on OSX per description

RTC. Upto @HLeithner if he wants to play safe and put this into 3.10 or stick with 3.9

This breaks external image URL functionality completely.

Yes it will. Thankyou. I forgot there was a URL field :D @zero-24 back to the drawing board

Scroll down to "Image URL" input box

By definition this is therefor a url and not a filepath

This breaks external image URL functionality completely.

In this case I think I play safe and done merge it ;-) thank @SharkyKZ

In this case I think I play safe and done merge it ;-) thank @SharkyKZ

Why not close the PR than too? @HLeithner ?

By definition this is therefor a url and not a filepath

By what definition :D When you follow the code path (example) it is just the path that is stored there and no real URL just the path and is is also handled as path. At other places we handle both cases for some reasons (example). So it seams that the definition / label is broken? So who defines what is correct?

And why at all should an field called media wich shows the current media in the media manager allow you to enter an URL when there is an actual URL field?

Doesn't mean that there should be a solution for the other fields.
You added this to many fields so I hope there are fields were this PR is valid and could increase security.

Alternative it could be moved to j4

You added this to many fields so I hope there are fields were this PR is valid and could increase security.

Well i have just added it to all media fields where i expected it to be used the same. And I still don't get why we should allow an URL there anyway but please decide and let me know :)

we could also do an URL check in the filter rule for sure just let me know what you want us to do.

And I still don't get why we should allow an URL there anyway but please decide and let me know :)

So you're saying that the "Image URL" field that exists in the modal should not accept an absolute URL (potentially to an off domain resource, i.e. a CDN) and that the media field should only allow you to select something from your local images directory as clickable in the modal? Because that is basically what you are forcing with this PR as is. This may very well be the desired behavior in a lot of cases, and dependent on server configuration may also be the intended behavior (if you have URL wrappers disabled, functions like file_exists() won't let you work with a URL, so you effectively can't put an absolute URL into the offline image in the global config in those cases), but I fail to see why the already massively limited media field should be changed so that it can ONLY accept files on your local site. Might as well just get rid of media management capabilities in Joomla if that's the case and let everyone fight with FTP or building their own <img> and/or <figure> tags.

Ok so my fault than sorry.