Item11648: Add NatEditPlugin to core

Add NatEditPlugin to core

• Remove surplus and out-of-band dependencies
• Audit for security problems
• tidy
• Implement fallback for non-JS sites (if required)

-- CrawfordCurrie - 15 Mar 2012

I can't edit on trunk.foswiki.org, tried clearing my browser cache. See attached screenshot.

There were no errors retrieving any files from foswiki.org according to firebug's net panel. Iceweasel 10.0.2

• Screenshot_-_240312_-_17:59:15.png:
  

Additionally: we need to update docs for nojs installations, to remove natedit from their SKIN path (previously they just had to change the {Validation}{Method}).

-- PaulHarvey - 24 Mar 2012

Additionally: WARNING: NatEditPlugin has no module defined, it might not load! on each WysiwygPlugin test

-- PaulHarvey - 24 Mar 2012

trunk is missing

$Foswiki::cfg{JQueryPlugin}{Plugins}{NatEdit}{Module} = 'Foswiki::Plugins::NatEditPlugin::NATEDIT';
$Foswiki::cfg{JQueryPlugin}{Plugins}{NatEdit}{Enabled} = 1;

So its css and js isn't loaded. Fixed now.

-- MichaelDaum - 26 Mar 2012

can't switch back to wysiwyg, once in raw edit mode

-- MichaelDaum - 26 Mar 2012

Ah, I thought that breakage was unique to the selenium test environment - well, I'll try to have a go at this on the weekend.

-- PaulHarvey - 28 Mar 2012

Guys,

I have serious concerns that NatEdit isn't worth it if we lose the permissions editor tab. That is the killer feature for NatEdit, so I really want to address this problem.

At the same time, I have big problems with SetVariablePlugin. We've tried several times to fix the (save) performance issues, and I am thankful and appreciative to Michael for those efforts, but in the end I have had to disable the %GET/SET features entirely, due to mysterious and difficult-to-reproduce crashes (it's sometimes dying trying to expand some template recursively... I suspect I have a plugin somewhere with improper default value due to missing TMPL:DEFs in save context, all I know is that the problem is gone after nuking any expandCommonVariables-on-save).

Even if we fix these obscure crashes, I'm not convinced the %GET/%SET approach as taken in SetVariablePlugin is the correct one for core.

So, can we please think of a way to:

• Keep the permissions tab somehow.
• Maybe that means moving the Set+ and Local+ stuff to core. Let me know if you agree in principle, I'll write up the proposal.
• RestPlugin might be relevant.

-- PaulHarvey - 29 Mar 2012 - 23:41

A REST handler for the get/set operations would seem to be the logical approach. Whether that merits importing the RestPlugin - which is a whole other can of worms - is debatable.

-- CrawfordCurrie - 30 Mar 2012

Saving preference variables is done as part of a normal save. So there's no REST involved here.

-- MichaelDaum - 30 Mar 2012

I don't have a problem with importing the ability to set preferences during a save to the core - it's only a few lines of code. See AddRequestSetToCore

-- CrawfordCurrie - 07 Apr 2012

Created Item11959 to deal with the WYSIWYG transition issue

-- PaulHarvey - 20 Jun 2012

Current changes break it for all foswiki < 1.2.0. There's also an issue with the recent changes to the "save" code causing performance problems.

-- MichaelDaum - 25 Jun 2012

Removed dependency on SetVariablePlugin. Please test.

-- MichaelDaum - 18 Jun 2013

Commenting is disabled while not logged in