horst

@Martijn: I have installed this the first time now because I needed to overwrite some Admin Theme styles and also add some new. An awesome experience, - I just installed it, tipped the checkbox for including the AdminTheme-files and dropped the css files into templates/AdminCustomFiles.

Ah ok, - now I understand. I should had read better the descriptions. Version Control is the following Module of Version Control For Text Fields and replaces it. Version Control For Text Fields now is obsolete with PW 2.5+ and I should use Version Control also for one single Textfield. Thanks @Mike_Anthony, you have read it more thoroughly!

But the right Module page don't. It only says 2.2, 2.3, 2.4! That's why I have asked here You are on the wrong page. PS: I only need the small solution.

Hi Teppo, is it compatible with PW 2.5 ?

what is the name of your imagefield? does it contain mixed chars, I mean upper and lower case? If so, can you try it with a fieldname that only has lowercase chars? As I said above for me the caching works as expected with PW 2.5.19

This doesn't help me much because I have tested it today with PW 2.5.19 dev and it works well with caching here. ?? Maybe there is something different with previously installed and used fields, (before upgrading PW to 2.5.18 or 2.5.19) in regard to new created fields? Another thing you may test is a check for forceNew just before you call the getCrop: $forceNew = isset($config->imageSizerOptions['forceNew']) ? $config->imageSizerOptions['forceNew'] : false; $forceNew = $forceNew ? '<p>forceNew is ON</p>' : '<p>forceNew is off</p>'; $page->imageCrop->getCrop('test')->url;

@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?

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.

If someone want to give something for modules that I have shared, I would much appreciate if he/she donate something for children or children's projects where he/she lives. There is no better investment than our children and it makes good spirit and good karma! Edit: just to clarify: By "our children" I mean all (our) children!

No, it means: you cannot upload the same image to different imagefields on the same page! You can upload the same image to different pages because each page has its own subfolder under site/assets/files/.

@Martijn: I have tested it with PW 2.5.19 from this afternoon (14:00). I cannot replicate all of what you have reported. WHen I take a basename.png and use your code example from above I get the right output: // original => variation basename.png => pim_bright_basename.jpg // URL /site/assets/files/1/pim_bright_basename.jpg BUT it recreates it everytime new, also if I set the second param to false: $options = array('outputFormat' => 'jpg'); // Call PIM $pim = $image->pimLoad("bright", FALSE)->setOptions($options)->contrast(100)->brightness(100)->pimSave(); This is a bug or inconveniance by design, but If you call it this way it works as expected, without recreating it everytime: $options = array('outputFormat' => 'jpg'); // Call PIM $pim = $image->pimLoad("bright", FALSE, $options)->contrast(100)->brightness(100)->pimSave();

Hey Bea, this is so cool! You have released it! The Blog Post is nice too.

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.

I have downloaded 2.5.18 already an hour ago or so. So, cool to be able now to read everything here what is new! Thanks Ryan.

Have updated Pia to 0.2.2 because she also was affected by the same issue as CroppableImage. Recent PW versions now (can) log modules API actions into logfile modules.txt. This is suppressed now. If you use Pia and a recent PW dev version, please update to 0.2.2. http://modules.processwire.com/modules/pageimage-assistant/

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.

@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.

@Tyssen: yes, the pixelated ones are cached versions from before you specified upscaling = false. If you want to override them you can use one of the following methods: add a $image->removeVariations() before creating the new ones! Attention: don't forget to remove this once you are ready! since PW 2.5 you also can add 'forceNew' => true to your options array, this forces recreation of the variations every time a page loads! so please be careful and remove it after wards!! you may load Pia, Pageimage Assistant module. She has an option in the modules config page for forceNew that works sitewide if you are in debug mode and logged in as superuser. This way you do not need to alter your template codes and also it does not slow down your page for guest visitors if you forget to disable it.

Yep, FF has this too under developer tools since the last #n? major versions, but I need to click three times until I get this native tool. The other ones I use since FF before version 2 ! and I need to click only once to open it. Therefore I said / thought "something like that". But you are right @Lostkobrakai, - @pwired: you only need to open the network monitor from FFs developer tools and have a look to the response headers of your ogg-page.

@pwired: you need something like Live HTTP headers add on for firefox. It shows you all HTTP headers on a request:

Looks good!

@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.

I like this one very much: http://pik.peterkroener.de/?_escaped_fragment_=/presentations/Pik/@1#!/core/welcome.html@1 It has a presenter mode too: http://pik.peterkroener.de/presenter.html#!/presentations/Pik/@1

@mike1: thanks for finding that. I have removed this line with eval() in @joes code example.

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: But one can enter uppercase letters. Is this intended or should it be sanitized by PW to a-z_0-9 ?