horst

this is the 14.000 topic.

Based on my experiences with several thousand images of mine, several thousand images of my customers and many image variations from many sites around the world (from the showcase directory), I can say: The core rendering engines seem to do a pretty good job ! But that are just my experiences.

CroppableImages uses the core images rendering engines. So there is no special "Croppable image rendering". Your original image left is very blurry, and the one on the right site is much to much sharpened. Please try a variation with sharpening soft or none.

Hhm, I agree. I need to check this. Thanks.

Holy ghost, @CaelanStewart, it feeled that you have liked my post just before I had posted it!?!

@CaelanStewart: I have added it, but changed the default! So, everytime now you get a refreshed version. I think that way round it is more like the common expectations. Only if one have a more advanced usecase, he may be aware of the switch and has a need for it. https://github.com/horst-n/PageImageManipulator/commit/ef8a6af6acc49e31d39fa63d6faa696428e30f83

Hi @CaelanStewart, thanks for trying out and debug the PIM. First thing, - in your code example above, you only have specified the mandatory $prefix in the first call of ->pim2load(). The other calls are completly empty, what may lead to the max_execution_time timeout. Please check, if you really call it without defining a prefix in your code at the webserver, or if you only forgott it in the example above. (?) With the issue you find out about the cached variations array, please try to comment out the line 796 in ImageManipulator02.class.php and see, if this makes a difference, please.

No, it should work with whatever PW accepts via installed ImageRenderingEngine-Modules. Your Image is black. How work this image out with api rendered image variations? What is the source image type(s)? Is it with all images, regardless of type / format?

instead of trying to figure out elsewhere if a class is loaded (file is included) or not, i only do it inside the file that should be included. if(!class_exists("myClassName")) { class myClassName { // ... } } This way, one can include it multiple times in any order from everywhere without worrying.

AC is the city code of my hometown, the relevant part is following.

I add it to the ToDo, but may take some time to get done.

What is the intention of the question? Lesser to write? Or something other?

alternatively this could be interesting: https://processwire.com/talk/topic/14511-e-commerce-tutorial-with-processwire-snipcart-your-thoughts/

@tpr: Hah, - you are more than welcome to contribute in this regard, Mr. AOS!

Yep, with FormBuilder this should be much easier. Also there were some threads / posts I remember, that handled about formbuilder and email attachements. I would go into the dedicated formbuilder pro forum and check the posts there, or ask there for help, if you do not find examples. If you do not see the Pro Forum for FormBuilder, you should send a mail or PM to Ryan, so that he can add your account to the whitelist of that forum.

content of our cron.php: and the PwCron.module file: Everything is working fine from 20161107-10:15:06 until now, without errors, in a 5 minute intervall. EDIT: Did you refreshed the modules cache after changing the class-, file- and directorynames?

Hi @Junaid Farooqui, welcome to the PW an the Forums. I use a similar approach like you described. But I don't have to use templatefiles for all of my blocks. I only use a few main template files (mostly 2-5, and max around 10 for really large sites). For the blocks I use the Profield RepeaterMatrix, what is explained here: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/#repeater-matrix-is-released-alpha https://processwire.com/api/modules/profields/repeater-matrix/ With repeater-matrix you are able to level down the block / field files to different extends. My prefered usage is one matrix field with different blocktypes but one rendering file under site/template/fields. But one also can use one separate rendering/view file per blocktype under site/templates/fields/... Also it is possible to mix those usecases how you like. Repeater-Matrix was alpha in January 2016, but is stable now. Do cost a bit money, but is more than worth the saved time. You are able to build nearly an exact usage scenario with the free available Pagetable Field and additional template files for each blocktype. But it is more work and feels not that smooth like Repeater Matrix. Just another possibility here.

I have tried it, but added namespace to the files and also renamed the PWCron class-, file-, and directory-names to camelcase PwCron. Don't remember of any other changes. We have a cron setup to call cron.php every 5 minutes via CLI. All is working as expected after the changes described above, incl. the $wire API var.

There are two possible options to fit / contain images into a predefined rectangle / square: With the bare core options, you need to pass your width / height and an additonal setting for cropping = false. (the distribution default is true!) $containedImage = $page->original_uploaded_image->size(500, 500, array("cropping" => false)); If you find this to abstract or clumpsy, you may use the beautyful Pia, which reduces this to $containedImage = $page->original_uploaded_image->contain("square=500"); Optionally / additionally interesting in this regard maybe the weighten option of Pia here. ------ But both options only help in rendering images that fit into your defined boundaries. They will work with appropriate markup and css styles applied to them, but they do not apply a canvas to the image files. If you really want to increase the images filesizes for that, by adding pixels and not use css styles, you can use the ImageManipulators canvas method. It does exactly that. When using the Imagemanipulator with a recent PW version, please pay attention to use $image->pim2load()->...! the API examples all show the method for PW version prior to 2.6 ------ Examples with Pia and IM: $square = $page->original_uploaded_image->contain("square=500, quality=100")->pim2load("squarecanvas")->canvas(500, 500, array(255,255,255))->pimSave(); // or $bgColor = array(255,255,255); $suffix = "squarecanvas"; $innerSize = 480; $outersize = 500; $square = $page->original_uploaded_image->contain("square=$innerSize, quality=100")->pim2load($suffix)->canvas($outersize, $outersize, $bgColor)->pimSave(); // or $bgColor = array(255,255,255); $suffix = "squarecanvas"; $oneSizeFitsAll = 500; $square = $page->original_uploaded_image->contain("square=$oneSizeFitsAll, weighten=1, quality=100")->pim2load($suffix)->canvas($oneSizeFitsAll, $oneSizeFitsAll, $bgColor)->pimSave();

Yep, seems to be weird. Would be useful to see the code that is used to render the markup, and the info, where and how it is executed. And is there any sort of caching involved in the markup rendering chain?

hhm, Idon't know that template engine, and how it works. maybe you can debug the user / permissions for the calls? log into a file and compare, if there are any differences between superuser, normal call, ajax call, guest user normal call and ajax call?

which template is involved with the ajax call? does it have a file? which settings are bound to that template?

permission differences between guest and superuser check the settings for the template that you use for the ajax call.

I think you will need to modify your system / setup for this. One possible solution could be: add a hidden field to all templates / pages that may contain internal links hook into saveReady, check / collect all internal links from the current page save the current page id into the hidden field of each internal linked page Simplest solution to inform your client, is not to hide the "hidden field", but to show it readonly. If there are entries visible (that could be direct clickable links that open that page for editing into modals!), he has to change the content in that pages before. Additionally, you can hook into before page delete / page trash, and check the hidden field for entries programatically, to avoid accidental deletions before correcting the internal links. Another solution could be some sort of centralized maintained list / collection of all link relations. But your client seems to be enough tech savy so that the simple solution may fit already.