6

I was interested to see the answer to this question which mentions the <customContent /> tag.

I'd never come across this before, and I'm struggling to find much information on it.

  • It does not appear to be mentioned on Joomla's module tutorials
  • A search of core files shows it only to be used by mod_custom

How it seems to work is that you place it inside the <extension> tag of a module, but not within any other section such as <config>. It then creates a WYSIWYG editor above all other parameters of the module. It has no label.

However, unlike <field type="editor">, this saves the data into its own content field of the _modules table, as opposed to in the JSON string of params.

The fact it has its own field suggests to me that this might be the best practise way to add an editor to a module, but it seems odd that it's so rarely mentioned.

Do Joomla intend you to use this tag? Is it best practise?

Improve this question
3
  • Me too, it was the first time I came across this and still have no other idea about it. However, allow me to say that It looks to me like the cheat-codes in old e-games, that allowed us to win the enemy, gain points, change level and so on. They were there but hidden and only a few knew about them and used them.
    – FFrewin
    Commented Apr 24, 2016 at 19:52
  • I'd assumed similar at first (thinking perhaps something incorrectly namespaced in mod_custom that wasn't supposed to be used outside that), but it's the fact that every module has the content field in its database entry - which is a big database design decision - that makes me think it could be intended for something larger.
    – RichardB
    Commented Apr 24, 2016 at 20:00
  • Well, looking at it that way, it's a text field - so the way it is being used in the custom html module makes real sense. I guess since it exists, it is here to stay. So if the conditions are right for a new module that is being developed, it could be used to store text/html content.
    – FFrewin
    Commented Apr 24, 2016 at 20:11

2 Answers 2

Reset to default
2

I've tried doing some research on this of my own as I was interested to see what purpose it served.

Looking through some Github issues, it has been noted that customContent is valid, however undocumented.

I then however found this:

https://github.com/joomla/schemas/blob/master/xsd/v3/module.xsd#L30

These are the the valid attributes and elements allowed in a module XML file. So it makes me wonder if <customContent /> should be used in places other than core or not.

My suggestion would be to stick with <field type="editor">, as this ensure you're using the standard/default Joomla practice and also allows you to use additional attributes such as label, description, etc.

Improve this answer
1
  • Nice find with the schema link. As far as I can tell, the only benefit to the customContent method would be a tidier database, rather than having potentially huge amounts of HTML content in the module's parameters field. Agree with sticking with the field type for now, though, unless I see something official from Joomla or they add it to more of their core extensions.
    – RichardB
    Commented Apr 25, 2016 at 10:54
2

Well, I've just had my first case when using one or the other seems relevant.

In the database, Joomla's fields for both the "params" and the "content" fields of modules are of the type TEXT, which means a maximum of 65535 characters. If you try and save anything over this, it will crop the end. <customContent /> saves the content in its own field ("content"), and the editor field type saves it in the module's "params" field as part of a json string (which also contains any other fields for the module).

A client has just managed to crash their site by pasting a base64 image into the editor field, whose size was longer than this character limit.

Using the "content" field, this would just have cropped the last few characters and you'd get a broken image, which you'd need to go in to the editor and fix. In the json "params" field, however, this means the saved json is then broken and you'll get an "error decoding JSON" message and need to go into the database to sort it out. It cannot be fixed in the admin because the module is now corrupt.

I don't think there's a maxlength option on the editor field type, so both of these break it from a client's perspective, but actually crashing the site seems the worst outcome.

Whilst primarily it's a client-doing-the-unexpected issue, it also seems a core Joomla bug since it should surely check that the json will upload safely or not upload it, rather than save corrupt data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.