XAMPP thumbnails won't delete

[Martijn Geerts]

A colleague of mine want to start with Processwire, yesterday eve, he called & said: deleting images won't delete the thumnails.

His version op PHP is: 5.3.5.

Today i installed a fresh copy op xampp on an allmost untouched win 7 install, just to try if I get the same "result". The PHP version of the fresh install is 5.4.4. also have the same issue.

[SiNNuT]

I have noticed this before but never gave it much thought because i haven't made any image heavy stuff. But indeed, removing images, doesn't seem to remove any of the size variations you've generated, be it on the back-end (automatically) or in your own templates.

I have a feeling this is by design on logical or technical grounds (or both). Maybe it is because there is no sure way to know if a particular image is a thumbnail of an original or an 'original' itself. The db doesn't keep track of this afaik.

On the other hand, i can think of scenarios where you would want to delete an 'original' but keep other size variations.

[Soma]

If you're speaking about Cropimages (module), yes the cropped images won't get deleted. If using regular Image field in PW, the thumbnails will get removed.

[ryan]

Can you clarify whether you are talking about the CropImages module that Soma mentioned or ProcessWire itself? There was no mention of CropImages, so wanted to double check.

I did just test here, uploading a photo, making thumbnails in the API as well as through TinyMCE, and then deleting the original, but all thumbnails were also deleted (and they are supposed to get deleted). If you aren't talking about CropImages, I might need more info on how to reproduce and exact steps to follow. I don't think PHP version is a factor, but possibly platform. Also, what method are you using to confirm that the file is still there? Due to browser caching, the only way to tell if an image really is gone is to look on your file system in /site/assets/files/[page-id]/[filename].

[SiNNuT]

Can't speak for Martijn. But i can confirm that the behavior Ryan describes does not happen on my platform. If i do a fresh install of PW there are a couple of images belonging to the homepage. If i check the filesystem, in my case 'E:\wamp\www\dev_wcb\site\assets\files\1', there are the originals as well as the 0x100 and the 232x176 variations.

Deleting the images from the edit page in the PW admin: The (original) images are gone from the filesystem but the variations mentioned above are still there in E:\wamp\www\dev_wcb\site\assets\files\1

This is on a Win7 Home Premium, 64 bit.

Wampserver 2.2:

Apache Version :
2.2.21
PHP Version :
5.3.10
Loaded Extensions :
	Core
	bcmath
	calendar
	com_dotnet
	ctype
	date
	ereg
	filter
	ftp
	hash
	iconv
	json
	mcrypt
	SPL
	odbc
	pcre
	Reflection
	session
	standard
	mysqlnd
	tokenizer
	zip
	zlib
	libxml
	dom
	PDO
	Phar
	SimpleXML
	wddx
	xml
	xmlreader
	xmlwriter
	apache2handler
	mbstring
	gd
	mysql
	mysqli
	pdo_mysql
	pdo_sqlite
	mhash
	xdebug
MySQL Version :
5.5.20  

[Martijn Geerts]

If you're speaking about Cropimages (module), yes the cropped images won't get deleted. If using regular Image field in PW, the thumbnails will get removed.

Not speaking about module. It's just a regular install, without any additional mudule istalled.

It's the same behaviour as what SiNNut tells....

[DaveP]

I get exactly the same results as SiNNuT. Same version of Win7 unfortunately, so no help there, PHP 5.3.8 Apache 2.2.21 & mySQL 5.5.6.

<edit>Looks like a Windows thing. Probably won't affect to many production servers, anyway (?)</edit>

[ryan]

Thanks for testing. I agree, it does sound like it's a Windows thing, but probably something we can fix if we can track down why the files aren't getting deleted in Windows.

Can one of you running Windows try turning on debug mode (/site/config.php, $config->debug = true), then upload image, make thumbnail, then delete image. After that, go look in /site/assets/logs/errors.txt. Do you see any errors at the end of the file that look like they might be related to this?

[DaveP]

No error log created, so assume no errors. (And new file thumbnail is left behind.)

[Martijn Geerts]

Same here, no error log created.

Test was done on the default home page....

[Soma]

Maybe some code injection on where they get deleted in Pageimage.php to see if name and paths are correct will help.

[DaveP]

@Soma - any specifics? I can't get anything to echo or print_r from Pageimage.php.

[Martijn Geerts]

Can it be that the xtra . in the filename makes Windows go Boo....

[ryan]

Can it be that the xtra . in the filename makes Windows go Boo....

I'm not sure I understand -- what extra "." in the filename? If there really is an extra "." somewhere, I'd want to look at that first. But I've not seen that before, so need more info.

[Soma]

@Soma - any specifics? I can't get anything to echo or print_r from Pageimage.php.

I always use an exit() or die(); after the echo

echo $variation->filename; exit();

Ryan the extra "." in the thumbnail filename PW is generating.

saskia-smaller.0x100.jpg

[ryan]

Does windows not support more than one period in a filename? That would be news to me.

[Martijn Geerts]

On the support forum of MS, a period is allowed in a filename. So thats not the issue on the Windows side I think. The thing about the . was just a wild guess.

[ryan]

If anyone wants to stake a stab at it, I think this is where I would start if I had a windows machine to test with. This is in the file /wire/core/Pageimage.php:

public function removeVariations() {

 $variations = $this->getVariations();
 $this->message("There are " . count($variations) . " image variations"); // ADD THIS

 foreach($variations as $variation) { 
   $this->message("Removing file: {$variation->filename}"); // ADD THIS
   if(is_file($variation->filename)) unlink($variation->filename);
 }

 $this->variations = null;
 return $this;
}

The two lines above that say "ADD THIS" are the ones I'd add to this file. Now when you delete an image, you should get your messages on the next screen. Let me know what you get?

Thanks,

Ryan

[Martijn Geerts]

Sorry ryan, have a festifall this weekend. So can't test it this weekend. After this weekend if needed will see if I have somewhere a working Windows install at home.

[DaveP]

Ryan, I think you've found it - see screenshots

The file names aren't the same - the image file has a dot between name and size, while PW is trying to delete it with an underscore.

But how come it works on Mac and Linux?

[Adam Kiss]

I think it's in the Pagefiles::cleanBasename... Can you try these changes, please? it should give us some info of what is happening with basename. Thanks

public function cleanBasename($basename, $originalize = false) {

 $path = $this->path();
 $this->message("before: {$basename}"); // ADD THIS
 $basename = strtolower(basename($basename)); 
 $this->message("lower: {$basename}"); // ADD THIS
 $basename = preg_replace('/[^-_.a-zA-Z0-9]/', '_', $basename); 
 $this->message("preg: {$basename}"); // ADD THIS
 if($originalize) { 
   $n = 0; 
   while(is_file($path . $basename)) {
     $basename = (++$n) . "_" . preg_replace('/^\d+_/', '', $basename); 
     $this->message("origin: {$basename}"); // ADD THIS$this->message("{$basename}"); // ADD THIS
   }
 }
 $this->message("final: {$basename}"); // ADD THIS
 return $basename; 
}

--- it looks like this on mac:

[DaveP]

@adamkiss it looks like that on a PC too.

[ryan]

Thanks for the testing guys. I'm actually thinking the problem might be in this function from /wire/core/Pagefile.php:

public function setFilename($filename) {
 $basename = basename($filename);
 if($basename != $filename && strpos($filename, $this->pagefiles->path()) !== 0) {
   $this->install($filename);
 } else {
   $this->set('basename', $basename);
 }
}

I think that Windows must be returning a different path or $filename than where PW stores them (perhaps an alias, or wrong slashes or drive letter in it or something). Can you try replacing the function with this?

public function setFilename($filename) {
 $basename = basename($filename);
 if($basename != $filename && strpos($filename, $this->pagefiles->path()) !== 0) {
   $this->message("Filename is: $filename"); // ADD THIS
   $this->message("Basename is: $basename"); // ADD THIS
   $this->message("Pagefiles path is: " . $this->pagefiles->path()); // ADD THIS
   $this->install($filename);
 } else {
   $this->set('basename', $basename);
 }
}

This should reveal what's going on, I'm hoping.

I'm double posting because I know editing it will break the code examples. But wanted to mention that the part where I added "ADD THIS" is what I suspect is getting called, and it shouldn't. But if we've got different paths to the same file, that would explain the problem.

What do you know, it connects double posts automatically now... here's my triple post, betting it gets appended to the first. Nice upgrade Pete.

[DaveP]

Dunno if this tells us anything or not.

It can't be anything to do with Windows' 'relaxed' attitude to forward slashes & backslashes, can it?

<edit>Wish I'd used a more sensibly-named file</edit>

[ryan]

Actually I think your screenshot reveals the problem. Take a look at the "Filename is:" line:

D:/wamp/www/pw-2.2/site/assets/files/1\lala_restaurant.0x100.jpg

Notice how the slash right after the "1" is a backslash rather than a forward slash. Then notice that the Pagefiles path is correct (ending with a proper forward slash). Now the question is where that backslash is coming from. I'm really starting to wonder about a PHP bug here. Look at how PW constructs that filename:

$filename = $this->pagefiles->path() . $basename; 

We already know that $this->pagefiles->path() ends with a proper slash from your screenshot. It's getting replaced somewhere. But I don't see any code between the two functions that manipulates it. I need to get XAMPP installed on my wife's laptop so I can properly debug this. Thanks for your help testing here.