Is there a way to add an editor like Redactor to a custom TextareaField?
Happy New Year!
You mean on a custom commerce-product?
This takes 2 steps (and is site-specific at the moment):
- Add a unique-ish input_class to the TextareaField. For example, this is the product description field defining a
$fields = new TextareaField($this->commerce, [ 'name' => 'description', 'label' => $this->adapter->lexicon('commerce.description'), 'input_class' => 'product-description', 'translations' => $this->getTranslations('description'), 'validation' => [ new Length(0, 1024), ] ]);
- Add that class name to the
commerce.enable_rte_textareasystem setting - multiple values can be separated with a comma. For example,
Do note that this requires Commerce 1.3+, this is not yet supported in 1.2 or before.
Thank you! So to be clear, I’ll have to wait for the 1.3 release or did I miss that?
Commerce 1.3 is currently only available in the pre-releases channel, which isn’t recommended for production use. So, don’t worry, you haven’t missed anything!
We’re working hard on it, and hopefully won’t be too much longer before the first release candidate is announced.
Is it possible, that this feature is not yet enabled in the latest 1.3.0-dev7? I added the class to the custom textarea field and also to the system setting, but there’s no RTE showing up. When I inspect the field from within the dashboard, the correct class is added.
Hm, no, that is definitely in dev7. Does it work on the product description when you add
product-description to the
commerce.enable_rte_textarea system setting?
Unfortunately not, that’s how I tried it first, then I tried a custom class name. No difference.
The console when opening a product shows this:
[Redactor] Initialising configuration set #1 for elements: Array [ "-description" ] 0: "-description" length: 1 > <prototype>: Array  ...
Does this help in any way?
Here is my exact field in case I’m doing something wrong:
$dataFields = new TextareaField($this->commerce, [ 'name' => 'properties[description_long]', 'label' => 'Product Description Long', 'input_class' => 'product-description', 'value' => $this->getProperty('description_long') ]);
Hm, that does seem to suggest it is trying to initialize it. And Redactor is definitely supported (as is TinyMCE RTE, but not the old TinyMCE).
And there are no other errors?
I’m using Redactor here, no other RTE installed and Redactor is also showing up on the regular
Nothing else in the console, the log shows:
core/cache/mgr/smarty/default/[...].file.manager.tpl.php : 27) PHP warning: Undefined array key "onRichTextEditorInit" core/cache/mgr/smarty/default/[...].file.manager.tpl.php : 27) PHP warning: Attempt to read property "value" on null
Not sure if they are related though. Those seem to be part of the frequent errors appearing since upgrading to PHP 8.0.
Give your own field a different input class, e.g. product-long-description and also add that one to the system setting. One class = one instance in this case.
Still a no. I added the class
rte, also to the system setting (seperated by comma).
If I inspect the long description field, I see leading hyphens (
-) before the
properties[description_long], is this how it’s supposed to be?
<div class="horizontal field "> <label for="-properties[description_long]">Product Description Long</label> <textarea id="-properties[description_long]" name="properties[description_long]" class="rte" rows="3"></textarea> </div>
Not really, but that’s unrelated, has been that way for a while, and is not really causing any issues. We have something in our tracker about it.
I’ve just tested it on my environment and it looks like the problem is the ID of the field (which is autogenerated from the name) contains the
[ ] brackets. Redactor uses
querySelector to find the element to parse, which means those brackets are parsed as if they’re attributes.
So that explains why it only works for the core field, as that’s not a property and doesn’t have the brackets in its ID.
So this looks like a bug. Will need to do some more testing and see about the best way to address this…
1.3.0-rc1 is coming out very shortly, which does not yet contain a fix for this issue, as we need a bit more time to sort it out. Rest assured it is on our tracker so we will work on it after the release.
Just to update this thread as well: This was already fixed in 1.3.0-rc3.
Thank you as always for the quick update!