IE problem ;-)

[Joe]

Hi all, I came across what I think is a bug, so I guess this is the best place to post this:

When using Internet Explorer (Version 10.01.11 on Windows7) the image preview for image fields in the admin area causes the browser window to freeze up, sort of. The screen gets darker, as when the lightbox pic loads, but nothing happens, the image doesn´t load, it stays that way, clicking anywhere in the browser window doesn´t change this, but the browser back button works.

I tested this on a virgin Processwire install. Calling the same page with Firefox everything works fine.

I don´t want to give the impression that I´m an IE-type , it´s just that I do have users who have Windows with IE as the standard browser and it´s lucky if they even know what a browser is, let alone installing another one.... As I said, I don´t need help in getting this to run on my machine, but I guess it should either be fixed or else I suppose the best solution is to remove the admin lightbox conditionally for IE...

Greetings

[teppo]

This is kind of related to this issue and this commit at GitHub: it sounds like Fancybox has problems affecting IE10 and since Fancybox is being replaced by Magnific Popup in 2.4 these issues should be solved at that point.

Another question entirely is whether it's worthwhile to fix Fancybox issues in current (stable/master) PW release..

Oh, and no worries, Joe; your IE-situation is very familiar

[Joe]

Thank you teppo!

I´m using Magnific Popup myself for the public-facing site and it works very well. So that´s good news I think.

Well no, I don´t think anyone needs to go to great trouble fixing it for the current PW release. I´ve come up with a quick fix for mine:

Changed line 80 of /wire/modules/Inputfield/InputfieldImage/InputfieldImage.module from:

"\n\t\t\t<a class='InputfieldFileLink' target='_blank' href='{$pagefile->url}'><img src='{$thumb->url}' alt='{$pagefile->basename}' /></a>" .

to:

"\n\t\t\t<img src='{$thumb->url}' alt='{$pagefile->basename}' />" .

to make the lightbox disappear in the admin. While for my scenario the admin lightbox is nice eye-candy, it is not really needed. Don´t know yet if I get around to finding a conditional fix for IE. The main thing for me here is that users won´t feel like something has crashed.

Looking forward to PW 2.4 to make a good thing even better!

[Joe]

So here´s a way to make the admin lightbox disappear in IE only. (and leave /wire/modules/Inputfield/InputfieldImage/InputfieldImage.module untouched). In /site\templates-admin/default.php I inserted the following:

// Hack to keep the lightbox link from appearing in IE
// Detects which version of Internet Explorer browser the user is using.
function iever($compare=false, $to=NULL){
	if(!preg_match('/MSIE (.*?);/', $_SERVER['HTTP_USER_AGENT'], $m)
	 || preg_match('#Opera#', $_SERVER['HTTP_USER_AGENT']))
		return false === $compare ? false : NULL;
 
	if(false !== $compare
		&& in_array($compare, array('<', '>', '<=', '>=', '==', '!='))
		&& in_array((int)$to, array(5,6,7,8,9,10))){
                return $m[1].$compare.$to;          // removed the dangerous line with eval here !
	}
	else{
		return (int)$m[1];
	}
}
if(iever('>=', 1)){ $content = str_ireplace("<a class='InputfieldFileLink' target='_blank'", "<a target='_blank'", $content); }
// end IE hack

I would have preferred to have the link open in the same window, however that way when pushing the browser back button, the CKEditor field is blank and the page has to be reloaded. I thought about removing the image link completely, but I´m not so good with regex (for taking out the link including the "</a> - and a bit too lazy to try and use it for a trivial thing like this ) and even though I guess it would not cause problems I didn´t give in to the temptation of replacing "<a" with "<bogus IE tag"

Edited February 4, 2015 by horst
changed the line with "eval" with Nicos code

[mike1]

Warning: You should not use the function iever($compare=false, $to=NULL) {} suggested by Joe because it has a big security issue.

Visitors could change their HTTP_USER_AGENT in order to make $m contain malicious PHP code that will be executed by eval()

[Nico Knoll]

@Joe: I think this should be doable without "eval". I think you should never use eval if possible...

Why don't you just use:

return $m[1].$compare.$to;

[horst]

@mike1: thanks for finding that.

I have removed this line with eval() in @joes code example.