Batch Add interface returns to start when folder chosen

[LumenDan]

Hi everyone,

The problem I am having is not actually with uploading files but with the batch-add interface getting stuck at the folder selection. The symptom is the same in both browsable and non browsable presentation.
After selecting a folder and clicking the OK button the browser requests searchnew.php?startdir=misc but searchnew.php seems to be unable to process the parameter and displays as if it were not present.

I have seen this error show up before on the forums with a variety of causes, for me it effects all folders in /albums and started with a previously working installation of 1.5.26. After the error first started I upgraded to 1.5.28 and still have the same problem.
I have followed suggestions in similar posts, re-written file permissions (all files and folders 777) and checked for the use of special characters.
All of my /albums sub folders are named with only lower case alpha numeric and underscore characters.   
examples of sub folder names are: clients, projects, products, mtc, lcd, story_chairs, misc.

I have read http://documentation.coppermine-gallery.net/en/upload_troubleshooting.htm and followed as many of the procedures as I can. I have not posted test user credentials as batch-add requires admin rights.
Single file add and multiple file add both work with no debug warnings.
Batch add shows the following debug warning:

Code Select Expand

/include/inspekt.php
Warning line 449: preg_match() [function.preg-match]: Compilation failed: invalid range in character class at offset 18

The gallery is located at www.showtrek.com/project_gallery/.   

I have copied the gallery, albums and database to my windows desktop (with XAMPP Apache and MYSQL environment) but I cannot replicate the error on my local machine.
I have also re-installed the gallery on the web host (keeping the database and albums folder and deleting everything else).

Can anyone suggest a possible cause for the error in this case?

Regards,
LumenDan

[phill104]

Which version of PHP is your server running?

[Αndré]

I have also re-installed the gallery on the web host (keeping the database and albums folder and deleting everything else).

I assume it will be the same result, but does it also happen with a clean Coppermine installation on your server? I also suspect the used PHP version, as it works for me both on my Windows and Linux testbeds.

[LumenDan]

Thank you for your replies Andre and Phill,

I performed a fresh install of Coppermine Gallery at an alternative location on my web server. I still have the same problem with the batch add interface.
http://www.showtrek.com/nindex/cp2/

The PHP version is 5.3.28

Regards,
LumenDan

[Αndré]

Do you have the possibility to change the PHP version on your server? If so, please test with another PHP version (newer or/and older) and post the results. I'll try to test your PHP version on my testbeds as soon as possible.

[LumenDan]

I think we are on to something here.

My web host allows me to chose from PHP versions 5.2, 5.3, 5.4 and 5.5.

When downgraded to 5.2 the batch-add works and successfully moves on to the file listing for the selected folder.
Versions 4.3 and higher all result with the same problem.

I have downgraded for now but I am not sure how long my host will support 5.2

I did observe that the higher versions do not offer zend_optimizer (selected by default for 5.2) in the package selection options.

I hope this helps.
Regards,
LumenDan

[LumenDan]

To correct the previous post:

Versions 4.3 and higher all result with the same problem.

It is PHP version 5.3, 5.4 and 5.5 that cause the batch-add to fail

Regards,
LumenDan

[LumenDan]

I have checked my windows test install, it uses PHP version 5.5.9 and I have no problems.
I set the web host to 5.5 for a comparison, it uses PHP version 5.5.10.

After comparing PHP info pages for both installations I can't see any significant difference.

Can anyone suggest something to look for in the web host's PHP info that may show a cause for the batch-add error?

Regards,
LumenDan

[Αndré]

Can anyone suggest something to look for in the web host's PHP info that may show a cause for the batch-add error?

Unfortunately I can't, at least not yet. I'll try to test this as soon as possible on my own testbeds. Maybe it just occurs on Linux hosts with certain PHP versions.

[Αndré]

For the record: just tested on a Linux host running PHP 5.3.10-1ubuntu3.11 without an issue.

[phill104]

Me too, just with PHP 5.4 on a WAMP install with no errors. I will try later on a Linux box.

[kiig]

For the record I also have this problem on 2 different servers, - both was upgraded recently by my host. I can choose from php 5.3, 5.4 og 5.5., none of them works.

I have been able to add the latest html 5 multifile upload on one of them - only one though, - and can batch-add that way :-) a life-saver thank you. but the other site cannot even install the plugin, - both are running the latest 1.5.28.

But, - just a heads up, - I also see this problem.

I did some testing with my host, - copied and upgraded the site to the current/latest, - installed a fresh coppermine in a new location, - installed the package provided by my host running Plesk in a third location, - none of them worked, - all behaving the same way.

Kim Igel.

[LumenDan]

I found a possible cause and solution

There may be a difference in the way my web server processes regular expressions in the later versions of PHP.
I followed up on the warning:

Code Select Expand

/include/inspekt.php
Warning line 449: preg_match() [function.preg-match]: Compilation failed: invalid range in character class at offset 18

serchnew.php checks for the startdir parameter and matches the result on line 542

Code Select Expand

} elseif ($superCage->get->keyExists('startdir') && $matches = $superCage->get->getMatched('startdir', '/^[0-9A-Za-z\/\\\\_-\s]+$/')) {
The first thing I noticed was the four backslashes in a row which seems like a redundant escaped '\' character inside the set.
The warning was actually caused by the '-' character, escaping the '-' character fixes the problem so I guess that the expression should look like this:

Code Select Expand

'/^[0-9A-Za-z\/\\\_\-\s]+$/'
I have also had success without escaping the '_' but the above is closest to the original expression.

I saw this issue when I was creating rewrite rules for search engine friendly URLs.
The regex checker tool that I use has no problem with '-' character on its own but my server returned a 500 error unless it was escaped '\-' .

Let me know what you think

Regards,
LumenDan

[kiig]

it certainly works for me :-) thanx alot.

I failed to find the corrrect preg_match in searchnew.php and gave up last night.
Nice surprise to wake up to this post. Thanx.

it works for both my Coppermines, - on different server, - both on php 5.3+
and I added the slash to escape the minus sign only - just like to suggested.

Nice find :-)

Kim Igel.

[LumenDan]

I guess our servers are interpreting the '-' to specify a range of characters in the same way that 'a-z' or '0-9' would.
In this case underscore would be the lower value of the range and '\s' would be the upper value which doesn't make a lot of sense, hence, causing a syntax error in the expression and returning no matches.

When the $matches array is tested as empty (false) the function continues as if there was no "startdir" parameter at all.

That is my take on the situation at any rate. 

Regards,
LumenDan

[Αndré]

That's it, LumenDan!

within a character class, you can place a hyphen as the first or last character in the range (e.g. [-a-z] or [0-9-]), OR escape it (e.g. [a-z\-0-9]) in order to add "hyphen" to your class

[steveski]

Just a quick note that after upgrading to PHP 5.5, we had the same problem.  Changed the single line per this post - and everything works great!

[LumenDan]

Are the developers following this forum or is there a thread that I should post to for bug fixes?

Having identified this regular expression there may be more un-escaped hyphens that could be found and fixed in the code.

Regards,
LumenDan

[phill104]

Yes we are following. We can make the change for the next release. If you find anything else feel free to add it.

[Αndré]

Committed suggested fix in SVN revision 8715. Will be part of cpg1.5.30. Thanks for investigation, LumenDan!