Hey there,
I have a custom module. I have a text area (only one). I've seen what should be the answer to the question posted several times, but maybe I'm missing something.
I'm using the following as part of a form that is loaded onto a custom page via an item in the hook_menu function.
$form['submit_link_description']['description'] = array(
'#type' => 'textarea',
'#title' => t('Description'),
);
$form['submit_link_description']['format'] = filter_form(6, NULL, array('submit_link_description_format'));
What I load the page I get the textarea with the input format selector below it and the filter id 6 preselected. The textarea even switches from the standard input element to one wrapped in all the expected tags for the editor. However, no editor. I have the enable/disable rich text button. It toggles from std textarea to wrapped. The only editor that seems to work is NicEdit 0.9. I want to use CKEditor.
Incidentally CKEditor as well as all of the others work fine on node and contact forms include the contact admin form.
Any known conflicts or suggestions? Seems like a JS problem. Like something isn't firing to load the ckeditor.
Thanks,
Howie
Comments
Comment #1
aviddv1 commentedJust as a follow up - without changing anything I created a hook_block function and call
for my block content. WYSIWYG works perfectly. However, when I go back to my original page I get the form up top and the block at the bottom and the WYSIWYG doesn't work. So what is it about accessing the form when it's on a custom page that screws it up?
This is my menu item code:
Am I missing something?
Comment #2
twodHmm, if it's working in a block it should be working on the full page as well.
Are you seeing any JavaScript errors?
Checked with Firebug for Firefox or a similar tool to see if all files are loaded correctly?
In some instances it may appear as if the editor has not been loaded if its stylesheets are missing. You'd see the editor's elemenets added before or after the textarea, but you should be seeing this problem both in the block and on the page...
It's a bit hard to come up with ideas on what could cause this without being able to tinker with the code.
It would be great if you could put the module somewhere where I could download and debug it myself. If you don't want to make it public you can mail me a link via my contact form.
Comment #3
danmuzyka commentedDid anyone ever figure out a solution to this issue? I ran into the same issue on a custom form and spent hours trying to fix. The form array for the fieldset containing the textarea and the input format look exactly the same on both my custom form and the node edit form, but CKEditor loads on the node form via the WYSIWYG module but does not on my custom form. I've also checked that the same JavaScript is being written to the page...all of the following appear in the source code on both pages:
The WYSIWYG-related settings in
Drupal.settingsalso seem to be the same on both pages. I've tried setting the format as a child of the fieldset array that contains the textarea, as a child of the textarea array itself, and as a direct child of the entire form array. I also tried experimenting with different functions from wysiwyg.module (see commented-out code below), and thought maybe adding$form['#after_build'][] = 'wysiwyg_process_form';would solve the problem...no luck! Below is a sample of my code:Thanks in advance for any suggestions or pointers anyone has!
Dan
Comment #4
danmuzyka commentedMarking as active...
Comment #5
danmuzyka commentedHmm, for some reason I apparently wasn't setting up the 'format' fieldset correctly, and it wasn't getting processed by
wysiwyg_process_form(). I was able to get the desired behavior by setting the 'format' on the entire form (which I know is also a valid option). Maybe I had a syntax error in the way that I set up the field-specific 'format'?Here is my new (working) code:
Changing this issue back to original status ('postponed (maintainer needs more info)').
Comment #6
twodThe 'format' key needs to be on the same form "depth" as the textarea, just like you've got it in the first and second snippets. The problem was however that 'format' must be defined after the textarea, or Wysiwyg can't be sure which textarea it belongs to. (Defined order is what matters, weight is just for visual sorting and is ignored by Wysiwyg.)
You do not need to call any of Wysiwyg's functions once the format is placed after the textarea, it's all handled automatically by wysiwyg_process_form(), just like in your second snippet.
I'm closing this issue since no additional information has been provided by the original poster. Feel free to reopen the issue and mark it "active" again when more info can be provided.
Comment #7
phelix commented$ckeditor_format = mymodule_get_ckeditor_format();
I don't seem to have this function. I have tried mymodulename_get_ckeditor_format and also mymodulename_ckeditor_format did you need to use this function in order for this to work? Here is the c ode that I am using. I have been trying to get this to display on one of my custom fields I created in User Management -> Profiles in a text area.
Comment #8
twodmymodule_get_ckeditor_format()was meant as a placeholder for whatever code you use to determine which format should be the default choice (the first parameter to filter_form()). It defaults to using FILTER_FORMAT_DEFAULT if set to null, so I'll use that instead.As I said above, one does not need to call any of Wysiwyg's functions - or assign process callbacks - for it to find the format selector and attach an editor to the corresponding textarea, as long as the format key is on the same "level" as the textarea. You've currently placed the 'format' key directly on the textarea array when it should be its "sibling".
I'm assuming this is the only textarea with a format selector below
$form['Teacher Profile'], otherwise this will need a slight change. The last parameter to filter_form() will also need a change if some other element in the form uses the key 'format' or Drupal will try to write both their values to$form_state['values']['format']when the form is submitted.(Btw, I'm not sure "Teacher Profile" there is supported, you might want to try with just "teacher_profile" since that value won't be shown to the user anyway.)
If
$form['teacher_profile']['#tree']is TRUE, changearray('format')toarray('teacher_profile_format'), as the selected value would be in$form_state['values']['teacher_profile_format']after submission.Btw, if you wish to reopen an issue, please change its status back to "active" or it won't show up in the regular issue queue and there's big risk we'll miss it.
Unless this is used to be used in form.module - or you know you'll never use that module and your module is also called 'form' - please rename the function to YOUR_MODULE_NAME_form_alter() or it won't be called by Drupal.
Comment #9
phelix commentedThank you so much for your response. the space in the 'Teacher Profile' is actually what it is. And using this format does alter and change my form. So the items and changes I am doing here are showing on my form. However using this code here still does not display the wysiwyg editor to my textarea form. This form is on the Edit tab then under this it creates another tab called Teacher Profile and this info is in side here. These items were created with the profile module. Is there still something that I am doing wrong?
Comment #10
twodThis is the exact code I put in a D6 test module called 'add_wysiwyg', and it shows the editors for the new textarea on my Edit page just fine.
Since I have no other module which creates the 'Teacher Profile' textarea, I added a line to create it right first. (Otherwise I get a notice from Wysiwyg
notice: Undefined index: #id in ....sites/all/modules/wysiwyg/wysiwyg.module on line 200.and no textarea appears.)I also added
&before$formand $form_state since they are passed by reference (works without them, but better with them for clarity).Comment #11
phelix commentedYah, I am sorry to be a pain in the butt. But using your exact code will not get the wysiwyg editor to display. Still just shows a basic textarea. I know the function is working and the items are in the right path. Here is a print_r($form['Teacher Profile']);
This only seems to be happening while I am trying to edit the form going through My Account then clicking on the Edit tab and then clicking on the Teacher Profile tab that has been created. Any other ideas? Thanks!!!
Comment #12
twodNo problem. I'm just trying to narrow down the problem and make sure we're using the exact same code under the same conditions.
The form array does look correct, if it was printed from within the hook_form_alter() implementation.
Wysiwyg should be able to spot the 'format' key, find that three formats are available, get the settings for each editor profile assigned to them and add that data to the page.
Is there another textarea field on the same page which does have editors?
If so, where in
$formis it's 'format' key in relation to the one you're adding?When viewing the form, does your browser show any JavaScript errors?
Does
Drupal.settings.wysiwyg.configsget populated with the editor profiles' settings data for the formats which have editors assigned to them?Are you using a custom page template for the page where the editors don't show up? If so, does it print the
$closurevariable just before the closing body tag?Are the editors not showing up elsewhere where there's a textarea with a format selector?
Comment #13
phelix commentedWow, your a life saver! I did not have the $closure at the end of my page.tpl.php file. Adding $closure into my template fixed the problem. This editor now shows on the webpage. Thank you so much for your help. I have been trying to figure this out for so long and had completely ran out of ideas to get this thing working.
Comment #14
twodAh, that's why there were no errors, it never tried to attach an editor on the client because the script doing that was missing.
I'm glad you got it working!
FYI, there's an FAQ entry on this. ;)