Problem with CropImage field

[Lars]

Hi,

I have a field called thumbnail_image. It is used in 14 of my templates. It started out as a normal image field reducing uploaded images into 150X150px images.

After installing CropImage I altered the field type from normal Image into CropImage.

Something went badly wrong. Already while saving the field change something went wrong after confirming I wanted the change. Unfortunately I did not save the error message at that point.

Now I get error message in the following cases:

1: While trying to edit a page based on any of the templates that has the thumbnail_image (CropImage type) field.

2: If trying to delete the field thumbnail_image (CropImage type) from any of the 14 templates. Once confirming "Delete" I get the error screen.

3: If trying to edit the thumbnail_image field I get the error screen instead of the Edit Field screen.

In all cases the error message comes on a plain white page as text only with the following text being the same for all three cases:

Warning: Creating default object from empty value in C:\wamp\www\wire\modules\Fieldtype\FieldtypeFile.module on line 54

Catchable fatal error: Argument 3 passed to FieldtypeFile::setupHooks() must be an instance of Inputfield, instance of stdClass given, called in C:\wamp\www\wire\modules\Fieldtype\FieldtypeFile.module on line 56 and defined inC:\wamp\www\wire\modules\Fieldtype\FieldtypeFile.module on line 80

This error message was shown because site is in debug mode ($config->debug = true; in /site/config.php). Error has been logged.

 

 

I cannot remove the CropImage module since the field is in use.

I cannot delete the thumbnail_image field since it is used in templates.

Hoping for some assistance so I can avoid re-creating all my 14 templates...!

I do not mind loosing what is already in the thumbnail_image field.

 

[Lars]

Update:

Deleting all rows from field_thumbnail_image using phpMyAdmin enabled me to delete the field thumbnail_image from all my 14 templates.

It i still impossible to edit the field thumbnail_image itself though (in my case the url is: http://localhost/processwire/setup/field/edit?id=151), I still get the same error message as above.

[ryan]

xorotle, I've not been able to duplicate this, though have tried a couple of times now. As far as I can tell, CropImage is working well with the latest dev version (2.4.18). What version of PW are you using? The line numbers you indicated don't line up with more recent versions of InputfieldFile. So I'm wondering if you might be able to solve this one by upgrading to a newer ProcessWire. Also double check that you've got the latest CropImage as well. 

[Lars]

Hi Ryan,

I am using the latest ProcessWire-master.zip from the normal main download. readme.md says "ProcessWire 2.4" without any subversion number.

Today I tried to simply delete the module from outside (since I could not do it through GUI). I moved the module folder "FieldtypeCropImage" to temporary location. After that I got warnings in red for each pageload complaining fieldtype CropImage did not exist, however each page in back-end still loading.

I went into modules and installed CropImage again. PW said it upgraded CropImage, and from there on all works. My problem is gone.

Thanks!

[horst]

Ahrrrgh! I get this same error now for the second time.

Warning: Creating default object from empty value in wire\modules\Fieldtype\FieldtypeFile.module on line 59

Catchable fatal error: Argument 3 passed to FieldtypeFile::setupHooks() must be an instance of Inputfield, instance of stdClass given, called in wire\modules\Fieldtype\FieldtypeFile.module on line 61 and defined in wire\modules\Fieldtype\FieldtypeFile.module on line 98

Recoverable Fatal Error: Argument 3 passed to FieldtypeFile::setupHooks() must be an instance of Inputfield, instance of stdClass given, called in wire\modules\Fieldtype\FieldtypeFile.module on line 61 and defined (line 98 of wire\modules\Fieldtype\FieldtypeFile.module)

I'm using PW 2.5.6 dev and I get this while working on a Fork of CropImage.

I couldn't find why this is always raising now and makes it unpossible to enter the edit-page of the field or any edit page where that field is used.

Yesterday it raises the first time and I only could get rid of it by completly drop the DB and start from scratch. Today I have used a DB-Backup where the module isn't installed and no fields of this fieldtype exists. So I can set it back workable quickly.

I will try to investigate further on this, but want to note this here because of the similarity with what Lars has described, (same error and CropImage!)

-----

EDIT:

Just some notes for later, if I don't get it solved by myself: it is reproducable for me now by starting with a fresh DB, installing my module and when creating a new field after pressing submit:

• I get the exact above error
• in DB a table is created: pages_id (INT 10), data (VARCHAR 255), sort (INT 10), description (TEXT), modified (DATETIME), created (DATETIME)
• table fields holds a new entry which is complete

Edited October 29, 2014 by horst

[horst]

I have tracked it down to this:

The last executed Lines in FieldtypeFile.module are:

	public function getInputfield(Page $page, Field $field) {

		$inputfield = null;
		if($field->inputfieldClass) $inputfield = $this->modules->get($field->inputfieldClass);
		if(!$inputfield) $inputfield = $this->modules->get($this->defaultInputfieldClass);
		$inputfield->class = $this->className();

When this is called, $this holds an empty defaultInputfieldClass.

Therefore $inputfield becomes null, what is returned from modules->get($this->defaultInputfieldClass) in line 58. (sure, it cannot get a module "")

And thus it crashes!

When the FieltypeFile is initialised, it has this line in construct():

	public function __construct() {
		$this->defaultInputfieldClass = str_replace('Fieldtype', 'Inputfield', $this->className);
	}

but in my case, at this time $this holds an empty className AND an empty defaultInputfieldClass. (it must have to do with load priority or if a module is autoload or not, I think)

Later, when coming to getInputfield() at lines 56-58, className is populated with the right name! Now once more calling the line from constructor, it goes a bit further:

        if(!$inputfield) {
            if(!$this->defaultInputfieldClass) $this->defaultInputfieldClass = str_replace('Fieldtype', 'Inputfield', $this->className);
            $inputfield = $this->modules->get($this->defaultInputfieldClass);
        }
        $inputfield->class = $this->className();

It loads the Field-Editpage, but lacks a InputfieldType: Session: Missing required value (inputfieldClass)

I think, somewhere between running the constructor and coming to getInputfield, there must be a same situation like above, where it fails to populate a variable, I think.

Does someone know if Fieldtype- and / or Inputfield- modules can / should be set to autoload? Autoload doesn't help here.

Edited October 30, 2014 by horst

[ryan]

Horst, is it possible that the module in question extending FieldtypeImage is overriding its constructor without doing a parent::__construct() ? It doesn't look to be an issue with FieldtypeCropImage, because it doesn't override the __construct(). But you mentioned this is not CropImage, but a fork of it, and the behavior you describe sounds like FieldtypeImage that's being extended is uninitialized (i.e. not having it's constructor called)?

[horst]

Perfect Ryan! Exactly what I have done: using/adding a constructor without inheriting the parent constructor. Shame on me, !

It hasn't had a constructor before. I have written a lot of code, without calling the page / Module, maybe for 1,5 hours. Then I went to test it. First error was that needed dependencies are not included. I do it quickly by adding a constructor which includes the two libs. Going on with my Test, only focused on my new written functionality, it goes past the first submit when adding a new field. But I only had in mind my newly written code, completly forgott the added constructor! And then I haven't understood why my code has so drastically broken things. Stupid me

Now everything is working again, thanks!