Problem with EditRowPlugin on latest version.

-- RayHojka - 16 Apr 2012

Hi. I have just installed the latest version of foswiki on to a new Ubuntu Server 11.10 (running in a vmware virtual machine). Foswiki and extensions were installed from the Debian repository.

I have successfully managed to copy all the old topics users etc from our old (1.0.4) version of Foswiki.

However when I tried to add rows or edit existing rows with this plugin enabled it refuses to save any changes. I have just discovered that the plugin DOES save changes if the parameter js="ignored"

is either enabled as a parameter or as one of the prefernces. js="assumed" simply disables the whole plugin and js="preferred" fails to save any changes. Whilst js=ignored works

the icons are completely screwed and there is only 4 "icons" available.

I have disabled this plugin for now but I would really like to get it working correctly as we have it on a couple of quite large 9as in 50-60 row) tables.

Not sure it is related at all but I also tried to re-install natskin and natedit plugins but ended up removing these as Nateditor also refused to save anything.

Other than these two issues everything else seems to be working correctly.

Any help would be appreciated, especially with EditRowPlugin.

I just ran a quick test with EditRowPlugin and a fresh 1.1.5 installation. (not Debian though). It seemed to work fine.If you upgraded your existing LocalSite.cfg, did you run configure and address any errors, choose the correct version of JQuery (1.7.1) and disable deprecated and enable new JQuery plugins?

-- GeorgeClark - 16 Apr 2012

Hi George and thanks for the help.As stated this is a completely new installation. I installed, Actiontracker,breadcrumbs, autocompletionlib, editrow,form, glue,history, image and renderlist plugins and all enabled. I also have natedit installed but currently disabled because of the issues mentioned.

I changed jquery version from the 1.4.3 it was on per your instructions. The only 'issue' is a warning about the chili plugin when used with firefox. I always use IE8 with the wiki so this is a non-issue.So I guess the question is are any of these causing the problems I'm having.

The only other plugins are the 'default' plugins after installation.

When copying from the old installation I was very careful NOt to overwrite any of the new files.

I know its probably going to be something fairly simple but my knowledge is limited. I am not a programmer (apart from a bit SQL) so any help is appreciated.

-- RayHojka - 17 Apr 2012

I don't have time to verify these statements, but:

AutoCompletionLibPlugin is not maintained. It depends on a JQuery lib extension which probably conflicts with the core JQueryPlugin. Even if you got JQueryCompatibilityModePlugin to work, it's using an old version of jQuery and a deprecated autocomplete jq-plugin.

-- PaulHarvey - 18 Apr 2012 - 02:06

Thanks Paul.

I removed the AutoCompletionlibplugin as you suggested and this has at least got the icons issue sorted but changes still will not save.

I have also removed the natedit plugin and disabled breadcrumbs and checklistplugins. I also saw a note on here that Commentplugin should start before ActionTracker so I added that to the plugin Order list which is now TWikiCompatibility,Spreadsheet and Comment.

Removing the AutoCompletionPlugin also removed the JQueryCompatibilityPlugin.

-- RayHojka - 18 Apr 2012

If you have google chrome or firefox, you can use in javascript debugger to monitor messages from the JS while it is running. It's highly likely that will give you a strong clue. Also watch the "Net" panel to ensure all javascript files were able to be loaded.

-- CrawfordCurrie - 18 Apr 2012

Hello Crawford

I tried your suggestion in Firefox and this was the result of the net pane:

Hopefully this will make sense to you !

The JS pane had no output at all.

In the config I have the machine name as ukpb1ul00001 which is an a domain called phoenix.loc. Running in Firefox seems to insist on having the phoenix.loc part as well so I added the FQDN to the permitted redirect hosts line in config. This does not stop the redirect from failing with an Access Denied error message. IE8 simply refuses to save without producing any errors. If I then click on the redirected url it takes me to the amended version of the page but clicking on Ok takes me to webhome. If i can get to the amended page how can it produce an Access denied erro?

Sorry to be such a pain over this but I really need to get this working before I can move over to the new version.

-- RayHojka - 20 Apr 2012

Dont seem to be making much headway with this problem. The icons issue is now sorted but changes to the row will not save with this plugin running. Changes made using the table edit button DOES work. Unfortunately I have a large table which really needs editing on a row by row basis rather than the whole table.

-- RayHojka - 18 May 2012

What is the "more" info required? I need some progress with this asap.

-- RayHojka - 24 May 2012