Broken editor settings.

This is actually a symptom of other problems. drupal_add_js() in D7 takes different parameters, theme functions take a single argument, and 'buttons' can't be used as a key in forms as it gets unset.

Once that is fixed, enabling the Teaser Break button will throw an exception because it's not "jQuery-wrapped" properly.

I've already been working on fixing these things but haven't gotten around to putting a patch up yet, so here it is.

That sounds very promissing. Unfortunately I don't seem to be able to apply this patch. I get an error "Unknown line type at line 125" and when I look into the patch there is a line with just a space followed by the new index entry. When I delete line 125 the error reads "Unknown line type at line 124". Any idea what I'm doing wrong?

BTW, the lines 119-127 in the patch look like this:

This wants to insert 22 lines (if I understand the patch syntax correctly) but there are only 6 available. I removed line 119-125 and then the patch gets applied properly but something is still missing.

A follow up error also seems to be that Drupal's drupal.js fires and error that str.replace isn't a function, hence the wysiwyg editor doesn't get launched.

You're right, that patch got messed up. Uploading a new one.

Thanks, that new patch can now be applied but I'm still getting this error:

Any ideas?

Did you re-save the editor profile after applying the patch? If not, it's still using the old broken profile.

Yes I did. It's still not working. On http://www.example.com/admin/config/content/wysiwyg I do also get errors like

and

after saving the profile.

I have also deleted the profile and reassigned it, but still the same effect.

Aha, my D7 checkout was outdated. Will take another look at this.

I encountered this issue when simply reloading the page in FIrefox in 6.x-2.x on D6. Does this issue still happen when forcing cache deletion (CTRL + F5 or CMD + SHIT + R on Mac) ?

Edit : Hmm, that's indeed a different error, but anyway it's worth trying.

Yes, it still happens after flushing cache. And I guess it is due to a JavaScript error:

Updated to work with latest D7 HEAD.

I added a small inlined CSS snippet to fix the "download" links for each editor not being inlined in the default theme. I don't think it will hurt other themes as it's only applied to that table on the profile overview page.

Thanks TwoD, this latest patch brings some improvements. On the settings page I'm now seeing the editor settings again.

However, when loading a node edit page I'm still not seeing the edit area within the editor (see attached screen shot). The error message is

Oh, missed that the format keys in the plugin lists are not always defined. Also took the opportunity to fix a typo in the ckeditor implementation. This should be backported to the other branches as well so I'm putting it in a separate patch.

Reworked some logic in the other patch so please apply both these patches instead and re-save the editor profiles. EDIT: Use the cleanup patch from #462146 instead of the ckeditor patch here.

Still no luck. This is what I've done:

1) Downloaded latest wysiwyg module
2) Applied patch wysiwyg-HEAD-612954-4.patch
3) Applied patch wysiwyg-HEAD-ckeditor-cleanup2.patch from #462146
4) Flushed cache
5) Resaved editor profile
6) Go to node edit form

Still getting the error about the undefined variable Drupal.settings.wysiwyg.plugins[params.format]

Also, after saving the profile there are Drupal messages:

The steps look correct, I tested again today and it works for me. There's just a small change needed to the cleanup patch, is_dir($file) should have been is_dir($path . $file)
Do you have the very latest CVS updates to D7 HEAD as well?

Yes, I do have the latest CVS updates from D7 HEAD and I also applied your correction to the cleanup patch. Stilll the same effect.

That's not a big surprise as I search all of the wysiwyg directory and the ckeditor directory for the definition of the params.format variable and it's not defined anywhere. But it's used several times in ckeditor-3.0.js - so that is causing a Javascript error and hence the rest of the code doesn't get executed.

Does that help somehow?

The changes to the wysiwyg.module file should have taken care of the first error you got about 'render element'.
The second error looks a bit weird since line 455 is in wysiwyg_profile_form() in my code with the patches applied and it doesn't fetch the form key until line 465. In any case, that error should also have been fixed by the part patching wysiwyg.module's implementation of hook_theme, so the theming function is given the right variables.
Are you sure the patching was completely successful? You could attach the files here (as .txt) and I could run a diff against my files to see what has happened.

'params' is passed to Drupal.wysiwyg.editor.attach.ckeditor(context, params, settings) via Drupal.wysiwygAttach(context, params) by Drupal.behaviors.attachWysiwyg.attach(context, settings) which gets the parameter sets from Drupal.settings.wysiwyg.triggers[target_element_id] and adds the 'format', 'trigger' and 'field' keys to each set. The 'params' variable name is used both to mean a group of input format parameters keyed by their format id, and a single set of parameters for an input format, depending on how 'deep' down in the implementation you go. This is a bit confusing yes, but hopefully something wich will become a bit clearer as the module evolves.

To make sure everything gets set up properly on the server you can check that the Drupal object looks something like this:

Thanks for your detailed description. I first analyzed the errors from #14 with your hints and found out that the patches got applied properly but then copied to the wrong directory on the server. How embarrasing. Sorry.

The second probem with params.format is still there and I will look into that later today when I get back from a meeting.

OK, here is the analysis of the Drupal.settings object, see screenshot attached.

The portions Drupal.settings.wysiwyg.config and .triggers is defined as described and looks OK, however, the Drupal.settings.wysiwyg.plugins is an empty array and that's why params.format is undefined.

Drupal.settings.wysiwyg.plugins should be empty unless you have explicitly enabled plugins on the editor profile page.
'params' in the ckeditor-3.0.js is always defined as it is a reference 'params[format]' in wysiwyg.js. In wyswyg.js' scope, 'params' is a collection of several parameter sets one of which is passed down to ckeditor-3.0-js' scope if it's the active editor. Each one of those parameter sets always has its '.format' property defined on line 55 of wysiwyg.js. The problem is not that 'params.format' in ckeditor-3.0.js is not defined, it's that 'Drupal.settings.wysiwyg.plugins[params.format]' as a whole is not defined, ie the value in 'params.format' does not exist as a key in 'Drupal.settings.wysiwyg.plugins' when we try to access 'Drupal.settings.wysiwyg.plugins[params.format].drupal' in the pluginsLoaded() method in ckeditor-3.0.js.

The last part of the patch checks if 'Drupal.settings.wysiwyg.plugins[params.format]' exists (it has the value undefined which == false otherwise), and if doesn't the entire part of the code dealing with Drupal plugins is ignored.

If you're still using the testserver from above (http://testclub.paragon-es.de/sites/all/modules/wysiwyg/editors/js/ckedi...) it looks like ckeditor-3.0.js was not patched. I can not find any of the things that patch changed.

EDIT: Btw, I'll be installing the new Ubuntu on my machine today, so I might not be available until I get it set up properly.

Looks great, thanks. It's been the last file you pointed out which wasn't copied over to the server after patching locally. I'm now getting proper WYSIWYG editor behaviour on new nodes and I think you can close this issue - although I'm having another one when editing an existing node, but that might be due to invalid content inside that node. I'll check separately and create a new issue if it wasn't a local problem.

Thanks for your patience.

Great! Then we can get this into CVS later when I get my dev computer back up and running, or sooner if sun is around and does not find [yet] another mistake I've made hehe.

Note that we're only talking about wysiwyg-HEAD-612954-4.patch, here. The changes to ckeditor belong to #462146.

Thanks for testing!

Subscribe.

The combination of wysiwyg-HEAD-612954-4.patch and wysiwyg-HEAD-ckeditor-cleanup2.patch fixed this same issue for me.

Definitely worthy of RTBC

Committed wysiwyg-HEAD-612954-4.patch to HEAD.
The fix will soon be in the 7.x-3.x-dev snapshot and we now have a working GUI in D7 again.

Thanks for your patience, reviewing and testing!

Unfortunately, the change from #21 seems to be missing in the latest update.

Like I said earlier, this commit was only of ysiwyg-HEAD-612954-4.patch as it's specific to D7 and involves no editor code. The patch for the CKEditor files, mentioned in #21, is dealt with as part of #462146: Add editor: CKeditor, which is meant for all branches.

Sorry, I don't understand. I'm getting the error from #12 again since I installed your latest dev release. That had been fixed before in here and I can't find any reference to a fix of that in the other issue you linked me to. What am I missing?

If you download the latest 7.x-3.x-dev snapshot (last updated Nov 14 with the wysiwyg-HEAD-612954-4.patch) and apply the patch in comment #178 from the 'Add CKEditor' issue and re-save your editor profiles, you should no longer see that error.

You should be able to verify that the cause for this issue is fixed by being able to configure settings for, and use, other editors in D7. But for all causes of this error to be fixed when using CKEditor, a second patch is needed.

The original error (same as #12) turned out to have two causes. The first was a problem on the D7 profile page causing all editor settings to be corrupted. The path I committed earlier from this issue fixes that and will make all other editors work as they did in D5/6.

The second cause of the same error only appeared in CKEditor, and was due to a missing check for there actually being any customized plugin settings at all. If at least one plugin/button was enabled, the error didn't appear. But if one tried to launch the editor using the default configuration (which is the case if you just select it for an input format and go straight to an add/edit node page), the editor implementation still assumed custom plugin settings had been specified. That was really a mistake made in the original issue about adding CKEditor and it exists in all Wysiwyg versions.

So, I first added a separate patch for the CKEditor implementation here, in #13. But then it was discovered that more things needed to be changed in the CKEditor implementation, so the original issue was reopened in parallel to this issue. The CKEditor specific patch from #13 in this issue was merged into the cleanup patch in the 'Add CKEditor' issue.

I unsderstand that this is a bit confusing, but I hope I can clear it up a bit. I guess this is the downside of using -dev snapshots vs real releases; Things can break from time to time and there's always a bunch of partial or uncommitted patches to keep track of if you want everything to work. :/ I hope we can make a real 2.1 release some time soon, but we have a few things to test and work out first.

OK, understood. Thanks for taking your time to explain it all. But why aiming for a 2.1 release? Both issues were reported against the 3.0-dev release and I was just wondering why that test for plugins wasn't submitted against the latest 3.x-dev release when it indeed avoided errors.

I did not mean these fixes won't make it into 3.x. It was more a general remark about we also needing to get these fixes into a stable release for D5 and D6.
This issue only concerns D7 because how Drupal itself works changed and Wysiwyg needed to adapt to that, so the fix won't go into a D5/D6 2.x release at all.

These two issues (and thus their patches) are really unrelated, but they just happened to generate the same error in the CKEditor implementation.

The cleanup patch in 'Add CKEditor' issue has not been committed anywhere yet. It did fix the error, and still does, but more fixes were added to it to fix it all in one go, thus it was delayed a bit. It will indeed be first applied to 7.x-3.x-dev (HEAD) and then backported to all the relevant branches, which includes 6.x-2.x-dev.

D7 will most likely not see any releases below 3.0 (and D5 probably won't see anything above 2.x). Wysiwyg 3.0 will introduce a new plugin API and some more features. Those will eventually be backported to a D6 3.0 release (there is an inofficial DRUPAL-6--3 branch waiting in CVS), but I think it's likely we also release an official update to 2.0 containing the fixes currently in 2.x-dev (DRUPAL-6--2). We haven't really discussed this in detail, but I think it would be appropriate to fix what's already in 2.0 without adding a bunch of new stuff as well, potentially introducing more bugs along with the new features.

I downloaded D7 and latest build of WYSIWYG today and added FCKeditor. Everything works except at error displays on http://website/drupal/admin/config/content/wysiwyg. The error is :

Notice: Undefined offset: 0 in wysiwyg_profile_overview() (line 386 of /home/website/public_html/drupal/sites/all/modules/wysiwyg/wysiwyg.admin.inc).

Any idea why this is happening ?