phpThumb Woes after upgrade to 2.3.0

126 Posts

debussy Reply #1, 12 years, 2 months ago

I just upgraded a client site to from 2.2.7 to 2.3.0, got the usual round of minor fixes to run (mostly the Snippet output thing). However, the site uses the Gallery package in several places, and phpThumb is not outputting anything.

When you paste the generated img URL into the browser, this is returned:

Fatal error: Cannot redeclare phpthumb::__destruct() in /path-to-modx/core/model/phpthumb/phpthumb.class.php on line 254

Any (quick!) help would be much appreciated!

This question has been answered by debussy. See the first response.

[ed. note: smashingred last edited this post 12 years, 2 months ago.]

discuss.answer

126 Posts

debussy Reply #2, 12 years, 2 months ago

UPDATE:

I verified that, starting around line 237 in the phpthumb.class.php file, the following TWO classes are duplicated.

	function __destruct() {
		$this->purgeTempFiles();
	}

	// public:
	function purgeTempFiles() {
		foreach ($this->tempFilesToDelete as $tempFileToDelete) {
			if (file_exists($tempFileToDelete)) {
				$this->DebugMessage('Deleting temp file "'.$tempFileToDelete.'"', __FILE__, __LINE__);
				@unlink($tempFileToDelete);
			}
		}
		$this->tempFilesToDelete = array();
		return true;
	}

Once I deleted the dupes, new images are uploading fine... but existing images are acting very strange. I am either getting an image of an error message, or I am continuing to get the PHP dupe warning... I have manually emptied the core/cache... where is it still pulling the old phpthumb.class.php file that it still is getting duplicates?

EDIT: Removing the duplicated functions (above) will correct problems with phpThumb. As of 7/21/2014, the Gallery plugin still has other issues, though. [ed. note: debussy last edited this post 12 years, 2 months ago.]

29 Posts

ianelastic Reply #3, 12 years, 2 months ago

Hi,

I'm getting the same error
Just updated 2.2.14 to 2.3

Fatal error: Cannot redeclare phpthumb::__destruct() in C:\wamp\www\core\model\phpthumb\phpthumb.class.php on line 254

And I don't know if these are related problems or not:
- Pages that do not use phpthumb are taking a long while to render; approx 10-15 seconds, then about 5 seconds after cached.
- The manger runs VERY slowly.
- And the clear cache action just hangs with message "Console running..."

Otherwise loving the new look, but will be forced to roll back to backup of 2.2.14 if issues not resolved.

Any words of wisdom appreciated

cheers

Ian.

UPDATE- just removed phpThumb snippet and the error message has gone and the pages now render, and I am able to clear the cache.
However this is a vital extra and is really needed - hopefully an update will be released that works with 2.3

I am still greatly concerned that the system is still running very slow - have server requirements changed from MODx 2.2.x to 2.3 that would cause this?
Pages take about 15 seconds to render.
Then about 2-3 seconds when cached versions have been built.

FURTHER UPDATE - now convinced it is my hosting that is running slow

It seems to be database accesses that are slow, the MODx manager resource tree takes ages to populate.
Off to pop a support ticket to the hosting... and then going off for a lie down in a darkened room.

Loving the new MODx 2.3, everything working apart form phpThumb. [ed. note: ianelastic last edited this post 12 years, 2 months ago.]

126 Posts

debussy Reply #4, 12 years, 2 months ago

UPDATE 2:

I'm not sure how to override the caching mechanism to get phpThumb to regenerate existing images instead of being locked into errors, but I was able to perform a workaround to at least get our site back up to full working order... Our site has 2 albums: one I just disabled (it was an old internal page anyway), the other is a giant rotating image which is the main component of the home page (Have to make that work!!!). Fortunately, that album only had 4 images in it. I manually changed the ID of the image in all the requisite references in the gallery tables (to what they would be if I had uploaded new images) and then changed the file names to match (in /assets/components/gallery/files/<album number>/). This retained all the links, descriptions, etc. with those images, prevented me from having to download and re-upload them, and forced phpThumb to see them as new images and correctly output images instead of errors.

On top of that, it does appear that the Gallery plugin itself is somewhat broken as I can upload images, but I can't edit or reorder the images. Instead of floating, draggable objects, the image divs are all just plain, block-level, full-width elements. Upon inspection, the classes assigned to them, "modx-pb-thumb-wrap" and "x-view-over," are not connecting with any styling--or, it seems, JavaScript.

1,572 Posts

Paulp Reply #5, 12 years, 2 months ago

Both Gallery and phpThumb have not been verified as working on 2.3 as of yet

https://github.com/modxcms/revolution/issues/11630#issue-37173621

3 Posts

anders0n Reply #6, 12 years, 2 months ago

Hi,

I'm getting the same error too after upgrade MODX to 2.3 and I'm try to update phpthumb.class.php from phpthumb on sourceforge.net and my frontpage is rendering now.

Just like this!!!!

284 Posts

legues Reply #7, 12 years, 2 months ago

Hi guys

I identified this problem also.

What i did was:

1- Download the previous stable version on modx Revolution 2.2.14, and i copied the phpthumb.class.php from the core/model/phpthumb
2- Then i pasted the file on the new MODX 2.3, under the core/model/phpthumb directory.
3- Problem solved

Ok. this solves the problem, but has this file in the MODX 2.3 it´s a bit diferent, i guess it has some code changes, it´s highly recommended just to delete/comment the duplicated code on lines 254 to 268 on the original MODX 2.3 file:

/*	function __destruct() {
		$this->purgeTempFiles();
	}

	// public:
	function purgeTempFiles() {
		foreach ($this->tempFilesToDelete as $tempFileToDelete) {
			if (file_exists($tempFileToDelete)) {
				$this->DebugMessage('Deleting temp file "'.$tempFileToDelete.'"', __FILE__, __LINE__);
				@unlink($tempFileToDelete);
			}
		}
		$this->tempFilesToDelete = array();
		return true;
	}*/

I tried myself do this and everything is working as expected!!

My 5 cents!!!

[ed. note: legues last edited this post 12 years, 2 months ago.]

436 Posts

Dan Reply #8, 12 years, 2 months ago

This was identifed within hours of release and there's already a pull request in: https://github.com/modxcms/revolution/issues/11700

284 Posts

legues Reply #9, 12 years, 2 months ago

Quote from: absent42 at Jul 17, 2014, 05:13 AM

This was identifed within hours of release and there's already a pull request in: https://github.com/modxcms/revolution/issues/11700

Yes i know, but until the issue is beeing solved you can improve the situation as i explain above!!

165 Posts

pdincubus Reply #10, 12 years, 2 months ago

Quote from: legues at Jul 17, 2014, 05:38 AM

Quote from: absent42 at Jul 17, 2014, 05:13 AM
This was identifed within hours of release and there's already a pull request in: https://github.com/modxcms/revolution/issues/11700

Yes i know, but until the issue is beeing solved you can improve the situation as i explain above!!

Install and use pThumb instead - and in system settings set pThumb to use its own cache directory, name hashing and resizer instead of PHPThumb

Using resizer will fix the PHPThumb problem as it will just NOT use it at all.

Answered phpThumb Woes after upgrade to 2.3.0