Item8571: Plugins that need foswikilib.js need to call for it and not rely on the skin.

Upgrading to latest NatSkin components appears to have affected EditTablePlugin. The Javascript abilities to re-order rows, and delete rows is missing, even if explicitly set to on in the EDITTABLE tag.

If the topic prefs set the skin to Pattern, the EditTablePlugin runs normally.

• EditTableWithNatSkin.png:
  

• EditTableWithFoswikiSiteSkin.png:
  

-- CraigBowers - 18 Feb 2010

Confirmed with a clean svn install. Strangely, I don't get this bug on my production site.

Edit: Found the cause. NatSkin fails to load foswikilib.js. Simplest work-around for wiki admins, is to insert the following text in System.SiteBottomBar, just before the STOPINCLUDE:

%ADDTOHEAD{"FoswikiLib" text="<script type='text/javascript' src='%PUBURLPATH%/%SYSTEMWEB%/JavascriptFiles/foswikilib.js'></script>"}%

-- PaulHarvey - 18 Feb 2010

This is not a NatSkin problem.

EditTablePlugin (and other plugins) must add these file by itself and not depend on other skins to blindly load them.

Plugins have to agree on the FoswikiLib tag. I'd recommend to make it an uppercase FOSWIKILIB to minimize potential errors. There's other stuff at JavascriptFiles that can be loaded optionally. We better don't load them blindly even though they are not needed.

Other plugins that load foswikilib.js or other stuff from JavascriptFiles without using ADDTOHEAD or without agreeing on a tag to ADDTOHEAD:

1. FormPlugin
2. PatternSkin
3. TwistyPlugin/TwistyContrib (standard mode)
4. TWikiAjaxPlugin/TWikiAjaxContrib (probably legacy packages)
5. SlionSkin (probably not maintained anymore)

These are only those that make use of foswikilib.js obviously. There are a lot of other plugins that rely on these files to be loaded, like EditTablePlugin.

Marked this to urgent as some of the mentioned plugins are core plugins.

-- MichaelDaum - 19 Feb 2010

We need the core plugins fixed before releasing 1.1.

It is a good idea to change the headline when a bug is characterized. The NatSkin in the headline meant all assumed this a Nat Skin problem.

-- KennethLavrsen - 18 Jul 2010

[18:56] <Lavr> MichaelDaum do you have a proposal what should be done to fix http://foswiki.org/Tasks/Item8571  ?
[18:56] <Lavr> I am chasing release blockers for 1.1
[18:57] <Lavr> HolidaylistPlugin 1.032 has been released.
[19:00] <MichaelDaum> Lavr, yes: every js file attached to System.JavaScriptFiles should be loaded using a known zone tag, e.g. using %ADDTOZONE{"body" tag="FOSWIKILB" text="<script src='%PUBURLPATH%/%SYSTEMWEB%/foswiklib.js'></script>"}%. this will take care of loading the file exactly once and on demand.
[19:01] <MichaelDaum> or the equivalent on perl level
[19:01] <MichaelDaum> plugin affected most is TwistyPlugin ... which silently was loading behaviour and foswikilib for the other plugins
[19:01] <Lavr> I am not sure how exactly this should be done. You have an example plugin that already does this?
[19:02] <MichaelDaum> let's take EditTablePlugin
[19:03] <Lavr> I am following opening files.
[19:04] <MichaelDaum> EditTablePlugin::Core::init() should have a line saying: Foswiki::Func::addToZone("body", "FOSWIKILIB", "<script ....</script>");
[19:04] <MichaelDaum> TwistyPlugin needs to change too.
[19:04] <MichaelDaum> as well as all of PatternSkin where there's a script or style tag not covered by an ADDTOZONE or Func::addToZone
[19:06] <MichaelDaum> have a look at foswiki.pattern.tmpl and its script::skinbase. this undermines all of the zone concept.
[19:06] <Lavr> I see that EditTablePlugin already uses the old AddToHead but not in init. It is called in commonTagsHandler.
[19:07] <MichaelDaum> that's only loading the css...not the js it needs
[19:08] <MichaelDaum> I am not too deep into the code to spot the right place where the call to addToZone fits best so that things are loaded on demand
[19:08] <Lavr> If in practical we ALWAYS have at least one extension loading certain common libraries - why bug all extensions with loading the same things?
[19:08] <MichaelDaum> because most of the css or js is unused
[19:09] <CDot> Lavr: MichaelDaum: I don;t have a problem with doing that, as long as the DEPENDENCIES reflect the true conditions i.e. ZonePlugin required or not, JQueryPlugin required, etc. so the extensions are still compatible with 1.0.9
[19:09] <MichaelDaum> best practice is: when a plugin requires a certain js, it must say so.
[19:10] <MichaelDaum> fixing FOSWIKILIB (for EditTablePlugin) is quite a viral change that affects a lot of places.
[19:10] <Lavr> Yes. The compatibility also bothers me. When we start putting plugins that only work with 1.1 or requires some plugin people stil on 1.0.9 or 1.0.10 (soon) will be in trouble.
[19:11] <MichaelDaum> right now the html produced by foswiki+pattern looks like an assaulted beach on world war II
[19:12] <MichaelDaum> now we have zones and zoneplugin for backwards compatibility. it only needs someone to execute the cleanup.
[19:12] <Lavr> Yes. The amount of js and css and god knows how many icons is a serious part of the load time of pages
[19:13] <Lavr> If things go to the header anyway - I as a plugin author - would probably use the deprecated Foswiki::Func::addToHEAD to avoid compatibility issues.
[19:14] <MichaelDaum> it's like ie and css3: there are js libs to cure the pain
[19:15] <MichaelDaum> and I am not using them either
[19:15] <MichaelDaum> but if you really strive for lower latency and clean html. better use it.
[19:16] <Lavr> If things go to the head, does AddToZone with zone head give any advantage?
[19:17] <Lavr> Wife is screaming now that food is ready. Must obey SWMBO. Cu later
[19:17] <MichaelDaum> it has got all the advantages addtohead alrady has ... compared to manually loading js files like you see in foswiki.pattern.tmpl
[19:17] <MichaelDaum> in addition
[19:18] <MichaelDaum> addtozone takes care that css and js are not mixed up by enforcing all css being loaded first

-- MichaelDaum - 20 Jul 2010

I am concerned noone is taking ownership of getting this fixed which probably is because the involved plugins traditionally have different maintainers.

I would love to try and do this but I cannot see a clear pattern how this should be done. It is very confusing for me. I will try and ask more on IRC to learn what the idea is. What I do not get is how you avoid getting the same .js file loaded multiple times by different plugins.

I am especially nervous that anything I do will make the plugins not work for people upgrading them in 1.0.9 or 1.0.10 after we release 1.1 and roll new defaults out on foswiki.org.

This problem was reported against 1.0.9 so it is not related to trunk or our new plugins. It is related to the fact that for a long time some plugins have relied on the skin to load these common libs. And then suddenly NatSkin stops providing the libs. And then it is suddenly PatternSkin's fault and all the plugin's fault.

In the very principle things have worked fine until now.

If we start adding ADDTOZONE tags ot add to zone calls in the default plugins then they become dependent on an AddToZonePlugin which has only been tested by a handful of people - with respect to people still on 1.0.X. I do not think we want to do this to our 1.0.X users.

So we should stick to API that was available in 1.0.X until we have most users up on 1.1.

Or we get a proper solution how we can separate which plugin version configure sees from our Extensions web. We really lack a mechanism so we can have 1.0 and 1.1 versions of the same plugins. Until we have that we need to use 1.0 API for the default plugins.

-- KennethLavrsen - 20 Jul 2010

I have looked at the problem and it is not easy to fix.

In fact it is dangerous. And as Michael said above - viral.

The PatternSkin - and for sure most skins people have made - call the standard collection of Javascripts without the intelligence of the Func::addToHead or addToZone.

So adding an addToHead in the plugins means that the same js files get loaded twice.

We cannot just do that. People upgrading an EditTablePlugin cannot get new addToHead/Zone and get the entire js environment goofed up.

I am not sure I want to fix this in 1.1.0.

I have some questions.

PatternSkin is traditionally not kept compatible when we release minor/major. So I guess it is OK to use ADDTOZONE in the skin.

Is the tag="id" in %ADDTOZONE the same as the $id in Func::addToHEAD( $id, $header, $requires )?

Will these mutually exclude each other so the same JS is not loaded multiple times?

Is there any other way a plugin can know that some JS is already loaded?

-- KennethLavrsen - 20 Jul 2010

yes. yes. yes. no.

-- CrawfordCurrie - 24 Jul 2010

I have done all the core and core extensions (big job) so dropping priority from Urgent to Normal for the rest.

-- CrawfordCurrie - 25 Jul 2010

Fixed for FormPlugin, closing.

-- ArthurClemens - 30 Apr 2011

Commenting is disabled while not logged in