Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Drupal 7 introduces the form element #type text_format, which is a text-format-enabled version of a textarea.
// Retrieve the default values for 'value' and 'format', if not readily
// available through other means:
$defaults = array(
'value' => '',
'format' => filter_default_format(),
);
$my_richtext_field = variable_get('my_richtext_field', $defaults);
// Just construct a regular #type 'text_format' form element:
$form['my_richtext_field'] = array(
'#type' => 'text_format',
'#title' => t('My richtext field'),
'#default_value' => $my_richtext_field['value'],
'#format' => $my_richtext_field['format'],
);
Comments
Adding a WYSIWYG Field using the Field API
For anyone looking for how to set a field to be wyiswyg / #type = 'text_format' using the Field API, here is an example:
Sorry if that was obvious to anyone else. I just spent a long while trying to figure out why my 'settings' values weren't being passed through to the 'text_textarea' widget until I stepped through things and realized that the 'text_processing' key needs to go in a 'settings keyed array in the root of the field definition array, not nested in the 'widget' settings.
Hope thats helpful to someone!
This leads to an error:
This leads to an error:
Fatal error: Unsupported operand types in /includes/form.inc on line 1706
for me (D7, wysiwyg module, ckeditor)Use it on instances!
At least for me, using WYSIWYG with the field API works if and only if you use
within an instance (i.e. field_create_instance()).
Of course you can also use 'instance_settings' on the field type definition but if you are using fields of type text or text_long than text_processing is set to 0 by default most likely.
Defining a Format by String
You're able to define the '#format' by the string id of the filter you desire as well, although this is obviously not as flexible as other methods. I was having difficulties with filter permissions and text_format elements and using the id helped me out.
ex:
--Alec
Tandem
this causes an sql access
this causes an sql access violation when I view my formated form:
None of the examples here
None of the examples here seem to work in D7 for a system settings form. I can get the text format selector to display but the WYSIWYG editor never appears.
[Update]: Actually it does work, this seems to be an issue with a multisite install using the same db and code, but just a different theme under a subdomain. Even though both versions are using the same admin theme (Seven), the WYSIWYG shows up on one but not the other.
For me, none of the examples
For me, none of the examples work for a system settings form. I haven't been able to find any examples that work. Mine is not a multisite install.
Nevermind. The example in
Nevermind. The example in the article does indeed work in a system settings form.
is there any way to process
is there any way to process the formatted text to be ready for print?
How to render the Variable?
I used your info to build a custom theme-settings.php, which enables a new textarea with textformat in my theme-settings.
The form works perfektly, but i am not able to access/print the value in my page.tpl.php. The following code produces only the word "Array", because the value stored in the database is not the content of the variable but the Word "Array":
What's wrong here?
you must use check_markup
you must use check_markup function to process the filter format on your text before printing:
This gets rid of the word
This gets rid of the word "Array", but the value in the text_format field (which is a wysiwyg editor) is not saved. I get this error upon saving:
Wakken!
Try:<?php $pdata =
Try:
hook_edit_form
How can I fix the problin within the hook_edit_form?
Iam building a custom panel pane, and every thing works find with textfields. But text_format will not bs saved.
regards,
SE64