JEM-Project
JEM-Project copied to clipboard
Custom fields with possibility of not only text
There's a post which asks for savehtml. I think, it's not the problem to change one field for this, but which one, because each system will use the fields in an other way.
I played around (in the backend):
modify the custom field information event.xml
/administrator/components/com_jem/models/forms/event.xml
e.g. for custom field 1:
Change from
<field name="custom1" type="text"
size="20"
readonly="false"
class="inputbox"
label="COM_JEM_EVENT_CUSTOM_FIELD1"
description="COM_JEM_EVENT_CUSTOM_FIELD2_DESC"
/>
to
<field name="custom1" type="editor"
height="200px"
size="20"
readonly="false"
class="inputbox"
filter="JComponentHelper::filterText"
label="COM_JEM_EVENT_CUSTOM_FIELD1"
description="COM_JEM_EVENT_CUSTOM_FIELD1_DESC"
/>
This way you get the custom fields with editor and allows everything which is allowed in the "Event Description" textarea. The custom fields are limited to 200 characters.
It could result in chaotic content in the custom fields – would be good to allow only basic html or similar.
Just read the post in the forum.
type="safehtml" is also possible, and concerning the interface even smoother, because not the whole editor is loaded
@Jojo and @mckillo do you agree to change the code of th custom fileds to type="safehtml" etc.? I think it is a good idea
My thoughts about this: I think it is good to have html code not filteret out, but an editor is too much and an open gate to issues. The ones who know enough html can use it.
Note: The custom fields are problematic, because their use depends on the administration, how is decided to use each field in a site. e.g. event custom field 1 was used from stevent for the artist of an event (because of this it's the only field with 200 characters. The other fields had only 100 characters.
OK I see: field 1 and 2 have varchar(200) the rest varchar(100).
My suggestion:
We set every field up to 200 chars and add filter="safehtml".
This way for existing users all stays the same, except for the ones who try html. In addition, setting all fields to 200 chars is more consisten (=less confusing).
That means we change in field 3-10:
<field name="customX" type="text"
filter="safehtml"
size="20"
readonly="false"
class="inputbox"
label="COM_JEM_EVENT_CUSTOM_FIELDX"
description="COM_JEM_EVENT_CUSTOM_FIELDX_DESC"
/>
to
<field name="customX" type="text"
size="20"
readonly="false"
class="inputbox"
label="COM_JEM_EVENT_CUSTOM_FIELDX"
description="COM_JEM_EVENT_CUSTOM_FIELDX_DESC"
/>
and
ALTER TABLE `#__jem_events`
CHANGE `custom3` `custom3` VARCHAR(200),
CHANGE `custom4` `custom4` VARCHAR(200),
CHANGE `custom5` `custom5` VARCHAR(200),
CHANGE `custom6` `custom6` VARCHAR(200),
CHANGE `custom7` `custom7` VARCHAR(200),
CHANGE `custom8` `custom8` VARCHAR(200),
CHANGE `custom9` `custom9` VARCHAR(200),
CHANGE `custom10` `custom10` VARCHAR(200);
What do you think?
I'm not sure, but there was (years ago) a discussion why we have to limit the possibilities of custom fields to minimize abuse. But I don't find this. Perhaps we have to find these reasons and have answers.
I think it is good to have at least limited html allowed (only styling) but none with advanced possibilities like iframe etc.
In my opinion, I think that in this case, the admin can do a view override. Please, no iframe in JEM. I don't see the need to put these fields by default in HTML The admin can set up these custom fields by CSS (class from custom1 to custom10 for dt and dd). It's enough to custom these fields, and the content must text/plain, as all fields of the event. The admin has a field in HTML --> description of the event (and other in the venue description, if it's shown), even include article into the description. We don't need to devs any extra code of filters/security content for these fields.