Uncaught [CKEDITOR.editor.replace] The element with id or name "" was not found.

Thanks for responding TowD...guess this is becoming a support request.

It's a custom content type and indeed, now that you mention it, there's an "Input format" fieldset sitting by itself that I hadn't noticed before, but I have no idea how it got there. I have had an issue or two with the use of features and adding/deleting fields, but I just don't recall working with this particular content type in awhile.

I've also got some modules that work with WYSIWYG, so perhaps one of those is causing the issue (Wysiwyg Fields (disabled but was enabled), WYSIWYG Filter, Node Picker (disabled, but was enabled), WIF 1.x to WF (disabled), Wysiwyg ImageField, and IMCE Wysiwyg API bridge).

I guess I need to check the following:

1. Disable all the extra modules
2. Dig through my features code
3. Check the dB for anything unusual
4. Go back in time and see if I can find a difference.

BTW, how would I post the code generating the edit form since any module may alter that form? (Or did you mean post the output of dsm($form)?

Thanks again,

Dan

Well I've narrowed it down a bit, but still not sure what's going on: I dumped the database of the site with the issue and loaded it locally. Immediately I saw that the issue did not exist locally (so it's not a dB issue), but I don't have all the same modules loaded locally. (However I did disable many WYSIWYG-related modules on the problem site but still no dice.)

So I looked through the $form object and the only real difference I see on the surface is as follows:
On the site with the problem, $field_event_media_attachment has an #after_build array element not present in the site without the issue which contains 0 (String, 40 characters ) content_multiple_value_after_build_proxy | (Callback) content_multiple_value_after_build_proxy();

Ok, so further research reveals that this is a CCK-native function introduced in the 3.x branch, and my local machine has CCK 2.9...not sure if there is a clue here.

Also, that same field's [0] array has several extra entries not present (as shown in the image attached), but again, I assume this has to do with CCK3...

I'm still scratching my head though because again, all my other content types work without a hitch...I just wish I could figure out where that empty field was coming from.

If anyone has any ideas on where I can probe, I'm all eyes.

Thanks,

Dan

I forgot to mention that my Features are showing as Overridden on the problem site, but I can't revert to the features code from my local machine (see attached image).

Hi TwoD.

I went ahead and, one-by-one, upgraded my modules to match my local and dev environments. I also upgraded my local CKEditor version to the same version on the dev server. In the end, I'm getting the same result: the local site works fine and the dev site has the empty field. (The only other differences are now things like PHP, Linux, MySQL, etc.)

I assume Backup and Migrate might be leaving off some tables, so one thought I have is to try and re-import the exact same dB I used to create the local copy.

Other than that, I still find it strange that the dev server is displaying a different status for features (always showing overridden for events, and it can't be reverted) than the local copy. I don't really have a problem sending you my features export, but it would seem I've narrowed the problem down to that (or at least it would seem). Is there any way that you know of for determining where an empty field may be coming from?

Lastly, even though I really would like to figure out what's going on, is there any way to patch WYWIWYG/CKeditor to ignore an empty fieldset? I still can't figure out how something like this could happen since there's no <div class="form-item" ... >...</div> before <fieldset class=" collapsible collapsed fieldset-input-format">...</fieldset>, but rather two fieldsets of class fieldset-input-format in a row.

Another update: this may go down in my own personal history as the strangest bug I've seen.

If I export the dB using Backup & Migrate and then re-import it to the same dev instance, no dice. However, if I export the dB and import it locally, then export that and import it back on the dev instance...bingo.

What I wouldn't give to figure this out...I come back to the only difference between content types: The event content type which had the issue uses the workflow module, which has the option of displaying on the node edit form.

When I imported locally, I received this error on import:
user warning: Incorrect file format 'workflow_states' query: SELECT ws.sid, ws.state, w.name FROM workflow_states ws INNER JOIN workflows w ON ws.wid = w.wid WHERE status = 1 ORDER BY sid in /var/www/mysite/sites/all/modules/workflow/workflow.module on line 1098.

Then after import, I got this error once.
warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'admin_landing_page_access' not found or invalid function name in /var/www/mysite/includes/menu.inc on line 453. (Not sure what admin_landing_page is...)

My best guess: the menu router is hosed on dev and somehow gets fixed (or at least "un-hosed") on local import. (I say this because I was also seeing pages where views was incorrectly trying to display a page view on the wrong path.)

If anyone has any ideas, I'm all eyes.

Thanks,

Dan

One last tidbit that hopefully may lend a clue: this issue appears to only be relevant to user 1. When I log in as an admin role (which has 99% but not 100% of all privileges), the missing field is truly missing.

Between that and somehow "scrubbing" the dB by backup/migrate locally then back to the dev server, there must be a clue somewhere. Perhaps some permission is being rebuilt with that process.

Again, I come back to the workflow...let me look into the 1% and report back.

EDIT: I take part of my statement back: the JS error reported still rears its ugly head, but I no longer can see the lone "Input Format" selector when logged in as admin vs. user 1.