Item9744: Foswiki::urlEncode error on configure page

Hi,

I have installed Foswiki-1.0.9 under windows server 2003 R2 using strawberry perl 5.10.1.3 and IIS 6.0

When opening /bin/configure.pl?action=FindMoreExtensions I am greeted with the following error at the top of the page:

Undefined subroutine &Foswiki::urlEncode called at C:/websites/foswiki/wwwroot/lib/Foswiki/Request.pm line 207. Content-Length: 157 Content-Type: text/plain; charset=ISO-8859-1 Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information. Undefined subroutine &Foswiki::urlEncode called

Extensions seem to install ok but i was wondering if you could help me to work out what is causing this error to appear? I have tried re-installing Foswiki from scratch but it has not helped.

Thanks, Steve

-- StevenHill - 24 Sep 2010

I get a similar one in configure.pl, typically four times...

HTTP/1.0 200 OK Content-Length: 157 Content-Type: text/plain; charset=ISO-8859-1 Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information. Undefined subroutine &Foswiki::urlEncode called

I'm running Foswiki-1.0.10, Server 2003R2 and ActiveState perl

-- MatthewKoundakjian - 02 Oct 2010

The Find extensions function loads each plugin module to determine what version is installed. Could you list which the extensions (Plugins and Contribs) that you already have installed, or if the log has more of a traceback that would be helpful. &Foswiki::urlEncode is a valid routine, so this is more related to the environment under configure, which doesn't fully initialized Foswiki. There are no more fix releases planned for the 1.0.x stream. If we can recreate this on 1.0.10 and 1.1, then the fix will probably be made in 1.1.1

-- GeorgeClark - 02 Oct 2010

I can confirm that the issue is still present when browsing to /bin/configure.pl?action=FindMoreExtensions under Foswiki-1.1.0-beta1. I'm using the standard set of extensions with only the FoswikiSiteSkin added. I'm pretty sure that this was occurring before I added the FoswikiSiteSkin extension though. Here's a quick screenshot to put the error in context:

I've had a look in the IIS logs but there doesn't seem to be anything of much use. Please could you point me in the direction of the Foswiki logs?

-- StevenHill - 04 Oct 2010

Just checked \working\logs\events.log and \working\logs\configure.log but I can't spot anything which would help us to identify the source of the error.

-- StevenHill - 04 Oct 2010

I don't get why Foswiki::Request is being called at all unless one of your extension modules calls it in initialization. configure doesn't use the Foswiki Request object IIRC. But it does load each extension module in the lib path to examine the installed version. I'm guessing that something it is loading is referencing the Foswiki::Request method.

When you upgraded to 1.1, did you go over the top of your existing lib directory? Look through lib/Foswiki/Plugins and lib/Foswiki/Contrib - are there any other extension modules there other than the default? Anything that references urlEncode? (Checking a default install didn't find any calls to urlEncode in those directories.)

-- GeorgeClark - 04 Oct 2010

I'm about to do a fresh install of 1.1 since I'm using the beta at the moment. I'll let you know if the error is still occurring before I make any changes or customisations.

-- StevenHill - 11 Oct 2010

Can confirm that the issue is present in a vanilla install of 1.1 running under windows server 2003 R2 using strawberry perl 5.10.1.3 and IIS 6.0

-- StevenHill - 12 Oct 2010

Thanks StevenHill. I'll work on trying to recreate this with Strawberry perl.

-- GeorgeClark - 12 Oct 2010

Excellent, thanks George. Please let me know if there are any additional diagnostics which I can perform to help with the investigation.

-- StevenHill - 13 Oct 2010

I've just upgraded Strawberry Perl to version 5.12.1.0 and can confirm that the issue is still present.

-- StevenHill - 13 Oct 2010

Unfortunately I don't have IIS available for testing, and this doesn't seem to happen under Apache. So far I have been unable to recreate this issue.

-- GeorgeClark - 14 Oct 2010

yes, I can confirm that IIS puts STDERR out to the user before the tag.

its a mess that I completely forgot about :/

There are a few IIS related tidyups and fixes pending - anyone that uses IIS want to take them on? (I'm willing to do so on a consultancy basis, as I really don't have spare time atm)

-- SvenDowideit - 14 Oct 2010

All my development experience is in .NET but please let me know if I can be of any assistance.

-- StevenHill - 18 Oct 2010

Changed this to status "New", as we have not recreated the issue. Also configure in 1.2 is almost completely rewritten. So we really need someone to recreate this and help with the debugging. Without a recreation and someone to work on this with an IIS server available, we have little hope of fixing it.

-- GeorgeClark - 01 Nov 2014 Actually made it Needs Developer. We need someone with IIS to work on these issues.

-- GeorgeClark - 30 Dec 2014

Commenting is disabled while not logged in