Item8783: ZonePlugin and JQueryPlugin seem to fail latest update

Upgrading to todays version results in:

Could not load /var/www/foswiki.local/tools/extender.pl There was a compile error: Undefined subroutine &Foswiki::Func::addToZone called at /var/www/foswiki.local/lib/Foswiki/Plugins/JQueryPlugin/Plugins.pm line 65. BEGIN failed--compilation aborted at /var/www/foswiki.local/tools/extender.pl line 147.

Error when trying to eval the file content: This installer must be run from the root directory of a Foswiki installation at /usr/share/perl/5.8/CGI/Carp.pm line 314. BEGIN failed--compilation aborted at (eval 248) line 147.

For this and all subsequent plugin updates.

Reverted snapshot and tried updating to latest JQuery first. Same error. Both JQuery and ZonePlugin seem to produce this.

OptimizePageLayout was unchecked.

After again reverting the snapshot, I confirmed updating other plugins is normal as long as JQuery and ZonePlugin are left out.

-- CraigBowers - 26 Mar 2010

confirmed from a fresh 1.0.9 + JQueryPlugin + ZonePlugin + ImagePlugin + AttachmentListPlugin

-- WillNorris - 26 Mar 2010

Feature proposal: Start a fund from Association dues for MD to hire an underling for beta testing.

-- CraigBowers - 26 Mar 2010

Problems:

1. MichaelDaum doesn't seem to use the configure web interface in his daily work, so doesn't notice these things.
2. Configure has a long-standing problem where for some reason, it seems to run pluginInit of all enabled plugins on each /bin/configure hit
3. But ZonePlugin is not enabled "out of the box"
4. So JQueryPlugin (when enabled) tries to call Foswiki::Func::addToZone() when /bin/configure is run
5. Which is missing, because ZonePlugin is either disabled or its pluginInit() didn't happen early enough and the monkey-patch to add this to Foswiki::Func is missing
6. Then configure fails with a call to an undefined subroutine

This is causing great instability.

CraigBowers, WillNorris - you should be able to work around this by carefully ensuring that you install and enable ZonePlugin before you do the same with JQueryPlugin.

If it's too late and you already broke your Foswiki, you will have to either disable JQueryPlugin in order to get configure up and running again, or manually add an $Foswiki::cfg{Plugins}{ZonePlugin}{Enabled} = 1; to your LocalSite.cfg

I did actually checkin a change (distro:f87063f8fc82) to JQuery that called addToZone() from a wrapper method that falls back to addToHEAD() if addToZone() is missing, but MD removed it (yes, it was ugly, but so is monkey patching core).

It would be great if mere mortals could continue using JQueryPlugin on Foswiki 1.0.x in a stable fashion.

The other point is that we have a defect in /bin/configure; Tasks.Item2595.

-- PaulHarvey - 27 Mar 2010

i don't have a broken configure, but i get the following message in error.log:

[Sat Mar 27 14:07:43 2010] [error] [client 189.165.144.183] FastCGI: server "/home/wn/sites.librett.org/bin/foswiki.fcgi" stderr: Undefined subroutine &Foswiki::Func::addToZone called at /home/wn/sites.librett.org/lib/Foswiki/Plugins/JQueryPlugin/Plugins.pm line 65.
[Sat Mar 27 14:07:43 2010] [error] [client 189.165.144.183] FastCGI: incomplete headers (0 bytes) received from server "/home/wn/sites.librett.org/bin/foswiki.fcgi"

-- WillNorris - 27 Mar 2010

Will, if ZonePlugin is definitely enabled, and you have restarted apache - try adjusting your plugins order so that ZonePlugin is first

-- PaulHarvey - 27 Mar 2010

doh, i forgot to mention that i had tried exactly that already.

-- WillNorris - 27 Mar 2010

i get the same error even when disabling fastcgi

-- WillNorris - 27 Mar 2010

There was a typo in ZonePlugin. Checked in a fix, and I was going to upload a new release but I see the policy is CoordinateWithAuthor - oops. I had assumed that seeing as JQueryPlugin doesn't work without it, that it would be PleaseFeelFreeToModify as I assume JQueryPlugin will move to FollowsReleaseProcess. - Kenneth is right, not sure why I thought it needed to be PleaseFeelFreeToModify for me to upload a new release - low sugar? :-)

-- PaulHarvey - 28 Mar 2010

I am sure Michael has brains enough to see it as a good and right thing that we fix obvious errors in plugins.

It is when you modify a way a plugin works or do major code refactorings that the coordinate with author comes into play. It would be bad for the entire project if correcting typos and syntax errors in code would always have to wait for the author.

-- KennethLavrsen - 28 Mar 2010

Uploaded a new release.

-- PaulHarvey - 28 Mar 2010

JQueryPlugin is proving more difficult. There is no easy upgrade path for Foswiki 1.0.x users who use /bin/configure. Their foswiki will be broken unless they disable JQueryPlugin before upgrading.

Failure mode can be reproduced as follows:

• Fresh 1.0.9, out of the box
• Minimal configure
• Install old JQueryPlugin (pre-addToZone)
• Enable
• Access /bin/configure
• Upgrade JQueryPlugin
• Upgrade fails before configure can finish: it tries to "eval" the plugin at some point towards the end - before it tries to satisfy the ZonePlugin dep - and fails with call to undefined addToZone() method.

The user is not aware that they need addToZone(). Their Foswiki is left in a broken state

Let's please put the ourAddToZone() wrapper back in place until we release Foswiki 1.1.

-- PaulHarvey - 28 Mar 2010

Problems: MichaelDaum doesn't seem to use the configure web interface in his daily work, so doesn't notice these things.

I wasn't aware the extensions web was a private repository that a developer could upload grenades or trojan horses to. Ok, that's using the most extreme take on it, appolagies if I'm being overly grumpy. But seriously. How can this not be tested against at least the most common configurations expected to install it? I get that everyone is running varied platforms, but shouldn't plugins at least be expected to be tested against the one distribution that the community specifically distributes (and to new users at that), the debian VM (which uses bin/config, and all developers regardless of hardware or host OS can additionally run and check against)?

But ZonePlugin is not enabled "out of the box"

Ok but in this case the previous version of JQueryPlugin and ZonePlugin were both installed and enabled. This was a update.

I gather from your later comments there, the only work-around is to disable JQuery before update with bin/configure?

Do the plugin installers (specifically ZonePlugin and JQueryPlugin) have the ability to disable JQuery as an initial install step, and re-enable as a post install step?

-- CraigBowers - 28 Mar 2010

Craig, generally it doesn't matter that a developer does not use configure web interface or not. Generally if a plugin installs with command-line installer it will work with web interface as well.

Sadly there are bugs in 1.0.9's /bin/configure that prevent an easy fix. Your idea to disable JQueryPlugin via a PREINSTALL hook is a good one that I tried also, but sadly I discovered that the PREINSTALL methods are not called unless running the installer from command-line. GeorgeClark has filed a task to fix this for 1.1 and 1.0.10.

The problem here is that ZonePlugin does courageous things to Foswiki 1.0.9 - adds a feature we are introducing with Foswiki 1.1 - and JQueryPlugin is now hard-coded to assume this feature is available.

I think the best solution is to re-introduce distro:f87063f8fc82. This enables JQueryPlugin to run even if the addToZone() feature is unavailable.

-- PaulHarvey - 29 Mar 2010

I think you may have a backup career awaiting you in the realm of diplomacy, Paul.

As to pre/post install routines, didn't George update that task to the pre-routines only being skipped for the first extension? Sounds like you've found otherwise, alas.

---

Also, it's not like this is the first time I've posted an issue here or on IRC just after a JQuery update. And it's not the first time you've jumped in to troubleshoot and/or save the day. Just saying it's seems of late a simple install/update test in a VM (nay, the VM) before posting the update in the extensions web would flush out show stoppers like this for, well the greater community. It's great and all if things run fine in trunk, or with patternskin+no plugins, with WYSIWYG disabled, when it's installed via command line on Irix or Minux. That's just not where the user-base lives and what the test environment needs to be.

Trying to finely tread the line between looking a developer gift horse in the mouth, and feeding a little constructive criticism back upstream. As an end-user, we gain a lot of comfort reading of the ever-greater phalanx of unit tests the code has to successfully work past before unleashing on thousands of installs. It's a head scratcher when several times in a row (or thereabouts) a key plugin like this blows out the pinions of your wiki. Especially when you're stuck in a limbo of partial functionality, a hack-a-round state waiting for an update, or a new dependency pushing for the latest updated version in order to get something else working. Stay pat with known issues, or wince and try some new ones. Rock, meet hard place.

This isn't a subtle edge case, with nuanced causality. It's as simple as, click update, and boom!. Shouldn't that fail any reasonable pre-release check? "Sorry, yeah, missed that bug I inflicted on ya because I skip the whole HTTP interface layer, and peek/poke memory locations directly"

When JQuery+NatSkin is good, it's very very good. When it's bad, it's, well, terribly Taxing/Tasking.

</soapbox>
</venting>

-- CraigBowers - 29 Mar 2010

You're right. Maybe we should have a Friday rule - "no release uploads on Fridays"?

If it's any consolation, JQueryPlugin will be a core plugin in Foswiki 1.1 so changes like this will have to go through the full release process: proposal, acceptance, unit tests, tests amongst devs, build, release...

MichaelTempest has also begun Selenium test integration with Foswiki which will allow us to write unit tests "for the browser" to easily test the vast amount of javascript we use as well. The initial effort will focus on WysiwygPlugin/TinyMCEPlugin but could (and should) eventually extend to full surface testing of our Foswiki skins.

What's my point... well, just that things are getting better, we promise. More of us are using and paying attention to perlcritic, MD seems to have shipped jslint to check javascript quality, and none of the developers seem to be accepting short-sighted "quick fix" code, so I remain impressed with the overall quality of work going in to Foswiki.

But that's not everything, we should be doing better on testing, and I hope that will improve for JQueryPlugin once we release 1.1.

-- PaulHarvey - 29 Mar 2010

Added a check to JQueryPlugin's initPlugin() handler to disable itself when the prerequisites (either ZonePlugin installed or Foswiki API >= 2.1) are not met. This should fix the interim situation where the update breaks in between. Please check.

-- MichaelDaum - 29 Mar 2010

Checked. All fine here now thanks.

-- CraigBowers - 30 Mar 2010

Commenting is disabled while not logged in