Even here the string " < something > " (without spaces) is missing.

Status set on Issue Tracker on "Confirmed".

Status set on Issue Tracker on "Confirmed".

did you try using the html entity for that character? I am pretty sure that the html spec for the title attribute doesnt allow special characters and you have to use the escaped html entity (but i could be wrong)

I did try that indeed.

<
<
<something>
\<
\&lt;

All of them don't work. Seems like they just get replaced by nothingness.

This is weird.
We can save single and double quotes, for the menu title and also for a class (one can get class="breadcrumb "myclass"" when saving in the text class field "myclass".

Somewhere in code, < and > are forbidden in the table params whether straight or as htmlentities.

it is expected behavior,
there is default filter string for field menu-anchor_title,

and, I am not sure we should allow raw < > in that field.

it would not be raw when output as it is converted to entities there

there is default filter string for field menu-anchor_title

Indeed in the text type we have $value = (string) $value;
I could not find on the net why < and > in a string kill the string.

It will act the same when entering a Note in the module

Indeed in the text type we have $value = (string) $value;

nope, not that easy ?
if the field does not have a defined filter attribute, then an input filter will fallback to default, see
and there default clean type is "string", see

It is default behavior for all fields, without defined filter="blabla" attribute

Got it.

Then, for example, would it be sensible to add filter="raw" for the Module Note (and other similar fields)?
i.e. get

<field 
			name="note" 
			type="text"
			label="COM_MODULES_FIELD_NOTE_LABEL"
			description="COM_MODULES_FIELD_NOTE_DESC"
			filter="raw"
			maxlength="255"
			size="40"
			class="span12"
		/>

and, for the menu-anchor_title, as it passes through htmlspecialchars, do we need to let string as default?

Concerning class fields, shall we use filter="cmd"?

and definitely for the cachetime fields add filter="int" ?

filter="raw"

no, never do that ?

class fields, shall we use filter="cmd"

class fields can have multiple value eg "class1 class2", and use of cmd will break it,

filter = raw would open this up to xss

i think this is one of those cases where sensible security settings prevent the ability for some users to do what they want and there is nthing we can do

i think this is one of those cases where sensible security settings prevent the ability for some users to do what they want and there is nthing we can do

Too bad. I hoped for a solution, because I'm currently needing this in a project I'm working on.
Does anyone know of an alternative/foreign character that looks the same?

The nearest available in almost all fonts will be the

« »

« »

I am going to close this as there is no change in the code that is possible and the suggestion of @infograf768 works