horst

On a side note: You cannot use - in your names, because - is the devider for suffixes in image variation names. Please change full-width to fullwidth or fullWidth! But back to your issue: I wasn't able to recreate it. What exactly have you done to install it? Passing in the class name here: Admin > Modules [ NEW ] -> ModuleClassName Which classname have you passed?

@adrian: the normal behave of CroppableImage is, that it creates any requested crop variations on upload. (To be more precise: just after upload, but before or during markup for the Inputfield-Item gets rendered) It does it in FieldtypeCroppableImage3::getCrop($suffix) // (exact the function that fails here!), so you need to debug this further: ... InputfieldCroppableImage3::getCropLinks ($pagefile) FieldtypeCroppableImage3::getCrop ($suffix) // called from InputfieldCroppableImage3::getCropLinks ($pagefile) in line 139 getCrop() is a hook event, defined in FieldtypeCroppableImage3 init(), line 44. It starts at line 172. You should look (step by step, if possible) where it has an early return, without creating and passing back the expected pageimage object. What part is failing in the process, when trying to get: $suffix // 175 $inputFieldInstance // 190 $templateName // 197 $cropSettings // 198 $img // 220 $imgPath // 222 $isReady // 262 ( <= is it this? // do we have a file? : is_file($imgPath). - So, if yes, the values above, starting at line 221, $img->basename seems to be not updated with the changed ones from your module?? hope this helps a bit. If you find out what failes, we can look further what is the best way to fix it.

Ok, thanks for clarification. No time here to investigate much further, have no free dev env here atm. Looking into the code, I believe this is the chain: InputfieldFile::fileAdded ($pagefile) // line 460 InputfieldImage::fileAddedGetMarkup ($pagefile) // line 490 InputfieldImage::renderItem ($pagefile) // line 522 InputfieldCroppableImage3::renderButtons ($pagefile) // line 56, coming from InputfieldImage::renderItem line 545 InputfieldCroppableImage3::getCropLinks ($pagefile) // line 74, calls many properties from $pagefile (!) Debugging that three vars ($pagefile, $suffix, $pagefile->getCrop($suffix)) around line 128, like Adrian said, would be useful.

@ukyo: what I tried to say is, that CroppableImage3 is an extention of the core imagefield and it incorporates all stuff related to uploading as is, without making any changes. Therefore, maybe it would be interesting if you have the same behave when trying with a regular core imagefield, or how that differs.

Yes, thats exactly what I mean. If one specify a fixed timestamp and this point is passed, I have added a delay to the current time and passed that back. As you said, this is the same as the delayed approach, but with little overhead. This can be simplyfied: send header with fix timestamp if it is in the future, otherwise send header with delay in seconds. Maybe, the delay should be configurable too?

Many thanks @adrian, now I'm back again in regular update process with the module. Yep! --------------------- I think only search bots will act according to retry-after. I have read on Googles advices on how they like to see handled maintenance mode for already indexed sites. And it was a 503 with a "retry-after" . If the estimated timestamp is passed, I added 60 minutes to the current time and sends this. Maybe, you can add this to the explanation, that one can check "send retry-after" but without a fixed timestamp too? This way we have enough possibilities, I think.

On a site that is always protected, it simply doesn't matter. But on a site, where I regularly only use some single protected pages but a big part is publicly accessible, there it is better to use SEO friendly headers when closing the whole site. It is important for sites that are already indexed, and temporarily are not accessible. That's why you thought it belongs to Petes module. But when I already have installed ProtectMode and it can close down the whole site, I have maintenance mode already, or not? Maybe best solution would be to offer both methods for the root page? Radio or something else for: protect | maintenance, plus a datetime via showIf for maintenance?

I think, sending a 503 and "retry after" should be done everytime if the whole site is closed / protected, regardless if you call it protect mode or maintenance mode. This is important for SEO. I think both of the modules, yours and Petes, should do that by default, when the whole site is not accessible for SearchEngines. (just my 2cents)

Yes and no. You cannot add it to a module config, but you can create a Processmodule with its own view page. There you can use an imagefield. https://processwire.com/talk/topic/8359-adding-image-or-file-field-to-a-module-configuration/ not full target, but a good starting point

updated my post above with the zip. It is an early version that I set to 777, to avoid overwriting with updates of the original module. I also must have one version somewhere in use, where the estimated end date is reflected in the user readable message at the login screen too.

@Christophe, once I have hacked a module (in an early version) of adrian to add exactly what you are looking for. GET http://fua.pw.nogajski.de/ [HTTP/1.1 503 Service Temporarily Unavailable 187ms] Date: Thu, 13 Oct 2016 20:14:54 GMT Retry-After: Sat, 22 Oct 2016 11:22:00 GMT So, if you like, I can upload it here as is, in a zip. Maybe, @adrian gets inspired and can add this into the current dev of his module as a maintenance feature, additonally to the site protect feature!? very old, hacked version of protect with maintenance.zip

@adrian & @ukyo: I'm not aware of any upload processing done by CroppableImage3. It only extends the coreimage field in some points, but nothing in regard of uploading.

What you need is a complete copy of your production site. That includes all files from wire and all files from site, plus index.php and .htaccess. Additonal to this you need a dev-mysql DB that is an exact copy of that DB of your production site. ATTENTION: the site/config.php file of your dev-copy need to be adjusted to point to the dev-DB, and not to the production DB anymore! The dev-copy should be on its own domain or subdomain. How can you call / access your dev-copy via HTTP? It better should not exist in a subfolder of your production webroot. If your production site is http://example.com/, the devcopy should NOT be accessible via http://example.com/devcopy/, but can be a subdomain like http://dev.example.com/

As a side note: you have the install (sub)folder in your production site? (this should be deleted on production sites after successful installation) There are not much third party modules. Following these steps should do it, hopefully: start your local copy and check if everything is working as expected, front and backend make a mysql dump of the local DB download the PW 2.7 legacy version rename your existing wire folder to wire.2-3, your index.php to index.php.2-3 and the .htaccess to .htaccess.2-3 copy the wire folder, the index.php and the .htaccess (htaccess.txt => .htaccess) from the PW 2.7 distribution to your local copy now load / reload a multiple times the backend and look out for messages. (turn on $config->debug = true; in your site/config.php) If this above steps will do, you additionally will need to change every html-editor textarea field type to work with CK-Editor, instead of the old, (now in the core missing TinyMCE). I don't recall any other things should take care of. The site/templates-admin/ folder can be deleted in your site profile too, after the successful upgrade to 2.7. If there will raise any other issue, please come back here and tell us.

The server software looks good. I would select PHP 5.4.x or higher. Upgrading to PHP 2.7, the legacy Version at a first step should be relatively safe, depending on the third party modules you run into that site. Can you post a list of all installed and used site/modules ? Regardless of that, you first should backup a mysql dump and the complete site folder! If you can, you than should install (locally?) a copy of that site and test the upgrade there. If not, it is also possible to do it on the live site, if you: can set it into maintenance mode some how have an external access to the mysql DB for backup and restore operations

Yep, GD-lib doesn't support any Image-Markers. Every thing get stripped. But in times where everyone tries to decrease page- and imagesizes, I think this is good. You always can access the EXIF of the original image. And to be consistent across different ImageREnderingEngines, the default is to strip all markers, but not IPTC(!). That's because IPTC will not be available in an image until someone has explicitly added it, not like with EXIF. @tpr: thanks! And yes, this is known to be an issue. It is an issue of the croptool(s). I remember that there were dev testing from Ryan and others, on how to solve this. But until know, nothing went into the code base. Every visually editor, like the crop tool or CroppableImage3, should detect the needed orientation correction and behave accordingly. ATM, all of those tools display the images uncorrected, determine the correct crop positions and dimensions, pass that to the imagesizer, imagesizer first detect wrong orientation and swap width / height but not for the passed crop positions / dimensions That results in totally wrong crops. What we need here is a standardized way to A) display wrong orientated orig. images corrected via CSS or JS in the cropping tools, B) a calculation function that can swap those "wrong" calculations to apply correct for orientation corrected images. Should this calculation be called by the cropping tools, before they pass the positions to imagesizer, or should they simply add a flag to show imagesizer to apply that calculation too with the orientation correction? A year back, I have experimented a bit with CSS transform: rotate(90deg), but lost the focus on it.

What exactly is displayed in the right orientation in the admin? Expected behave is: original image with wrong orientation shows up as is, with wrong orientation every variation, even a copy of the original image, just with a setting for a lower quality, shows up corrected! * * this only works if: correct exif orientation information are embedded in the original image the server supports reading exif information If it does behave other than above, what exactly is the upload and manipulation process? (inkl. which image field is involveld, other modules that are hooked into upload ??)

Hhm, don't have time to check this. But if you are not comfortable with the magic get ATM, you may also add a separate method for every property you need public read access to: public function getUserSaved() { return $this->userSaved; } public function getUserEmail() { return $this->userEmail; } ... From within your hook function you may call this f.e. with $userSaved = $event->object->getUserSaved();

With newer PW versions there is, besides a billion other new goodies, also integrated memory checking before trying to manipulate / create a(n) image / variation.

You have set private $userName You can set it to public, but only for fast testing, but better: use the magic get method as I showed you in my first post above. You cannot access a private property from the outsite. The function that receives the Event is "the outside".

No, accessing a variable set in the scope of the hooked method only cannot be accessed. You need to pull it into the classes scope, like I shown in the module 1 example. You may access the passed vars by $event->arguments[n], and if your hooked function has a return value, you can get it and set it like: $resultOfhookedFunction = $event->return; // do some calculation, ... // pass back another result: $event->return = $calculatedResult;

module 1 // define a property protected $userSaved = null; public function ___saveUser($vars){ // add to the class property $this->userSaved = true; } // magic get allows to access private and protected properties too, not only public properties public function __get($what) { if(isset($this->$what)) { return $this->$what; } // or a more restricted and controlled method: $validProperties = array('userSaved', 'someOther'); if(in_array($what, $validProperties) { return $this->$what; } } module 2 public function init() { $this->addHookAfter('module1::saveUser', $this, 'userSaved'); } public function userSaved($event){ $userSaved = $event->userSaved; return $userSaved; // or if you want to change the return value of the originating event, you need to change its $event->return! $changedBooleanValue = true; // do something to calculate the result $event->return = $changedBooleanValue; // pass it back to the hooked event // if you want to access the value that was passed into the hooked method, you get it with $vars = $event->arguments[0]; // there is also a method like: argumentByName or that like, please refer to the docs or code base for it ... }

Hi @formmailer, I'm not sure if there are better methods, but I have successfully changed a fieldname directly in the MySQL DB. The steps I have done are: open a mysql editor go into rows of table fields find the field in question and change the name in column name last step is renaming the table field_youroldname to field_yournewname That was it. Now I'm able to access it in my templates via $page->yournewname. If you are not able to open that DB live, you may also dump a mysql backup, change the names in it and restore it back, to take effect. (with module ProcessDatabaseBackup, for example)

... $pwVersion = wire('config')->version; if(version_compare($pwVersion, '3.0.35', '>')) { $pages->addHookAfter('Pages::savePageOrFieldReady', $this, 'saveReady'); // Pages::savedPageOrField(Page $page, array $changes); } else { $pages->addHookAfter('Pages::saveReady', $this, 'saveReady'); if(version_compare($pwVersion, '2.5.9', '>')) { $pages->addHookAfter('Pages::saveFieldReady', $this, 'saveReady'); } } ...

No this is not intended. The original image never is changed in PW, at least 99%. The original uploaded image never is touched and should be in high quality (best 100%). Also, my opinion, it never should be outputed to the frontend. It is the source or master for all variations needed in a site. To be short, your suggestion can't work at least, as you can specify multiple crop settings, and how should they all be able to update the original image? But you can and should call every defined crop variation by its name everywhere you like it. Also you can call every other variation derived from Pageimage, incl. the original image. Does that make sense for you?