Search by composer broken?

[contrapunctus-1]

1. Mutopia overflow menu
2. Browse
3. Click any composer name
4. "Sorry, no matches were found for your search criteria."

Alternatively...

1. Mutopia front page
2. "Composers" section
3. Click on any composer name
4. "Sorry, no matches were found for your search criteria."

I've tried Firefox v77 on Debian Testing, and Fennec 68.11.0esr and Tor Browser (Fennec 68.10.1esr) on Android 9.

[dominicus]

@contrapunctus-1
Thank You for raising the issue and I confirm I too experience the behavior you cite.

[chrissawer]

Can confirm the site is largely broken at the moment :-(

It looks like the server has recently been upgraded to Ubuntu 20.04 and I suspect that has broken things

I took a quick look at piece-info.cgi and it looks like the query parameters are getting mangled in HTMLcommon::queryArgs - some kind of UTF-8 issue where each character of the piece id is becoming 2 characters when returned from the queryArgs function

Unfortunately I have not written any Perl for a long time and so debugging might take a while

Need to work out if it is a difference in the version of Perl between Ubuntu releases, or if some configuration option has been lost, in which case I can contact the server owner to get it restored

Any suggestions welcome

[glenl]

I've cobbled up a test which runs correctly on my Ubuntu 20.04 machine (run it from our cgibin folder). The perl used to parse the query string is pretty standard stuff. I suppose we could benefit from commonly used utilities/framework from cpan but I doubt the perl version is the problem.

Since all things are broken, can we try a simple test? queryArgs does a simple job; it splits the query into an array of pairs, then forms an associative array of this pair array assuming they all look like key=value. I think we may be getting values passed to us as "id=2+2+4+7" instead of "id=2247".

Note that we translate "+" to a space which further confuses things since that won't generate anything we can use. The simple test: Can we just take out the "tr" line that is doing this? As in remove the line,

$value =~ tr/+/ /;

... from the HTMLcommon.pm::queryArgs script? If the error message then has numeric values separated by plus signs at least we know what is going on.

#!/usr/bin/perl -T
use strict;
use utf8;
use POSIX;

my $rundir;
BEGIN {
    $rundir = ( (-e './HTMLcommon.pm') ? '.' : './cgibin');
}
use lib "$rundir";
use HTMLcommon;

binmode(STDOUT, ":utf8");

$ENV{'QUERY_STRING'} = 'id=2247&foo=bar';
print "$ENV{'QUERY_STRING'}\n" ;

my %FORM = HTMLcommon::queryArgs();
print "id = $FORM{'id'}\n" ;
print "foo = $FORM{'foo'}\n" ;

[chrissawer]

Hi Glen, thanks for the ideas and debug script. I think my idea about this being UTF-8 related was completely wrong!

I have played around a bit today and it seems that the problem has been caused by the line $value =~ s/[^A-Za-z0-9 ]*/ /g;

Commenting out this line on the main server seems to have fixed things although I haven't tested thoroughly yet.

Any idea what this line was trying to achieve?

I have installed a slightly expanded version of your debug script as follows, the first link to run it, the second link to view the source:

• https://www.mutopiaproject.org/cgibin/glen-test.cgi
• https://www.mutopiaproject.org/cgibin/glen-test.txt

This has the original and fixed versions of the functions inline, as well as a version with additional debug. Any other tests you think might be useful to run?

[glenl]

I just looked... that line isn't in the committed HTMLcommon.pm file. And shouldn't be.

Mystery aside, you are on the right track.