CroppableImage

[horst]

This is on the ToDo already. But we ("we" == "Martijn" in this case) haven't had time to rebuild the UI of the editor. It is still how it was in Thumbnails just with the two selects for quality and sharpening added.

[Peter Knight]

Hi Horst

I'm running CroppableImage on 2.5.17 for the first time.

I've created a field Type of CroppableImage and set Input Type to CroppableImage too.

When I set the Image name and dimensions in Crop Settings, I get the following error

Table 'brfsel_prowire.field_Supply_Partner_Logo' doesn't exist SELECT pages_id,count(pages_id) FROM field_Supply_Partner_Logo GROUP BY pages_id ORDER BY pages_id

[Peter Knight]

Table 'brfsel_prowire.field_Supply_Partner_Logo' doesn't exist SELECT pages_id,count(pages_id) FROM field_Supply_Partner_Logo GROUP BY pages_id ORDER BY pages_id

I looked at my database and there was no field called Supply_Partner_Logo

But there was a supply_partner_logo (lower case). Having updated the field name to lower case, I can now see the Crop button.

[horst]

Hi Peter, thanks for reporting that.

I have looked into that, but it seems it is related to PW core, not croppableimages fields in special, or maybe I have to transform the fieldname to lowercase at some point in the modules code.

• I have created a new field of type text and given it a capitalized name: My_New_Field
• The table was created as: field_my_new_field
• In the fields table it is registered with name = My_New_Field

I will further test it with core images field and others and look how it is handled there.

So, when creating a new field you can read in the description of the Name* input:

Any combination of ASCII letters [a-z], numbers [0-9], or underscores (no dashes or spaces).

But one can enter uppercase letters. Is this intended or should it be sanitized by PW to a-z_0-9 ?

[Peter Knight]

But one can enter uppercase letters. Is this intended or should it be sanitized by PW to a-z_0-9 ?

I use a mix of upper and lowercase for my field names. I should really settle on lowercase, I guess.

[Alfred]

Thank you for this great module. So far ik works very well.

One little thing  I noticed is that in the modules log file with every page load (site not admin) it writes the line:

2015-02-05 16:21:06 ? ? Saved module 'FieldtypeCroppableImage' config data.

The logfile contains more than 12000 lines since I installed the module 5 days ago (2.5.16 dev)

If you want more info I'll be happy to help you

Alfred

[horst]

@Alfred: OMG! I will have a look to this very soon. Also I already know where I have to look at first, I believe. I will come back to this ASAP with a result or with further questions.

Thank you.

[horst]

@Alfred: Now I can confirm that this is a new behave from PW. With PW 2.5.11 I have not have this messages in modules.txt, but after updating to version 2.5.17 I get this too. You said you run PW 2.5.16, so it is something between 2.5.12 and 2.5.16. I remember that there were many changes with the notifier and log functions in PW, so I will post an issue at Github to tell Ryan about it.

Edited February 6, 2015 by horst
added link to Github

[horst]

This one is fixed now:

The PW $config with recent dev versions now contains or can contain a variable logs:

/*** 9. MISC ************************************************************************************/

/**
 * Additional core logs
 * 
 * All activities from the API functions corresponding with the given log names will be logged. 
 * Options that can be specified are: pages, fields, templates, modules
 * 
 * @var array
 * 
 */
$config->logs = array(
	'modules',
);

Per default it is set to include "modules".

I have changed the croppableimage module to suppress loggin if this is enabled. If you use it with a recent dev version please update: https://github.com/horst-n/CroppableImage

And I have tested it with PHP 5.3 and it works, so the requirements are updated too.

[Marty Walker]

Hi Horst,

I'm having an issue when I upload an image (I'm running PW 2.5.18) which doesn't give me the initial crop. Instead I get a scaled down version of the full image. If I attempt to make a crop I get a larger version of the crop I just made.

Edit: When I rolled my install back to 2.5.17 it functioned correctly again.

[adrian]

One thing when cropping to large sizes (eg 1000px or so), then on hover preview won't fit on the screen - perhaps it can be displayed at a smaller size when it is greater than a certain percentage of the viewport size? 

Sorry in a rush, but if this doesn't make sense, please let me know.

[Martijn Geerts]

@Adrian: Makes sense and I hear you. 

Have been sick for a looong time but feeling a little bit better after a week of antibiotics. This week I'll dive in your 'issue'.

[adrian]

Thanks Martijn - hope you're feeling much better soon.

I have another issue for you:

Notice: Undefined property: CroppableImageKeepCoords::$cropH in/site/modules/ProcessCroppableImage/classes/CroppableImageKeepCoords.class.php on line 93

[Martijn Geerts]

That one is for @horst I guess, thanks for finding !

[adrian]

On a roll today - looks like there is a permission issue when using a croppable image field in the system user template. When the field has been added to "What fields can a user edit in their own profile?" at /module/edit?name=ProcessProfile then the user gets a blank page.

Thanks guys!

[Marty Walker]

@adrian I'm cropping to a smaller size (200,200). Plus, the cropped image displayed at a larger size (2x) when viewed on the front-end too. On 2.5.17 it doesn't behave like this.

[horst]

There were changes from Ryan to the core image field with the commits to PW 2.5.18. I need to look to this but am not able before tommorow evening.

@adrian: have put it on my todo.

@martijn: regarding your PM, I try to add this within the init method from InputfieldCroppableImage.

[Martijn Geerts]

Tnx @Horst... 

[felix]

We've also experienced serious performance issues since the 2.5.18 update. It looks like crops aren't cached anymore but beeing generated on every visit. Also processing in general is painfully slow (wasn't the case with 2.5.17).

[Martijn Geerts]

I experience problems with 'prefixes' or that prefixes are not set at all. So maybe there's a core issue and not directly related to PIM or Croppable Image.

[adrian]

This is not directly an issue with this module, but I would like for users to be able to upload and crop their profile pictures. Ryan talks about the HTML uploader being disabled for profile editing (https://processwire.com/talk/topic/5644-images-in-user-profile/?p=60172), but I honestly think this needs to change as this is a common need on sites.

Do you guys have any thoughts on how "we" can make croppable image work properly on an image field in the user template when a user is editing their profile?

[onjegolders]

Hi Horst, like Felix I've been running into serious performance issues when using 2.5.18. I'll try rolling back a version - am sure you're already aware of this. Thanks.

[videokid]

We've also experienced serious performance issues since the 2.5.18 update. It looks like crops aren't cached anymore but beeing generated on every visit. Also processing in general is painfully slow (wasn't the case with 2.5.17).

Same here...

Any reason why the thumbnail suffix is different then the original Thumbnail module. I'm using 2.5.19 atm and instead of rolling back a version I'm using now

$imgUrl = 'site/assets/files/'.$pageId.'/'.$basename.'.-small'.$extension;

if, in my case, 'small' was added before the $basename, no hassle with extension stuff... 

I confirm Marty Walker, it's OK for me, for the moment I set half the thumbnail size I actually want to use

Overall... I'm very happy with this module... 

[horst]

Hey, regarding the serious performance issues, can you please tell a bit more about what it is what you have done etc?

• Is it in the Backend with displaying the items in the Inputfield,
• or is it in the Frontend
• or is it on Uploading
• or with the CropEditor?

I have installed the PW 2.5.19 and run some tests where I cannot see differences between PW 2.5.11. So, I don't have had PW 2.5.18 at hand.

Please can someone confirm that the performance issues consists with PW 2.5.19 and explain a bit more detailed what the issues are. (reproducable!)

Caching of the cropvariations does work as expected here.

Edited February 18, 2015 by horst

[horst]

Notice: Undefined property: CroppableImageKeepCoords::$cropH in/site/modules/ProcessCroppableImage/classes/CroppableImageKeepCoords.class.php on line 93

@adrian: this is a bit weird. I cannot think of any possibility how you got this.

In the __construct() it is explicitly set, at least it get populated with null. And there is no code in the whole class where it is unset. So, after initiating the class, it is set. The function where the notice came from isn't a static one, so ...? Can you reproduce it?