horst

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?

Updated to be in sync with the new introduced attachment function in core WireMail. (PW 3.0.36) The attachment function was introduced in WireMailSmtp since its initial release. But it hasn't had the option to specify alternative basenames for added attachmentfiles, as it was introduced in PW core this week. Now you can call in both, PW core WireMail and WireMailSMTP: attachment($filename, $alternativeBasename = '')

You mean, the popup thumbnail, that appears when you hover the crop-button, isn't updated automatically when you close the editor popup window?

$options is an always populated array in template scope. And if there is no pageStack defined ($options["pageStack"]), it is a direct call to this page, what you don't want allow. Welcome to PW and the forums!

@Robin S, you should ask @tpr, - he has made the last / enhanced version, if he updates it. EDIT: and if tpr cannot further maintain it, it would be fine if you can do!? (I already have enough modules in the directory, that all need to be maintained)

mod_security?

@Wanze, I ping you, as the above question seems to be for you.

Ok, I think the Profile-Exporter shouldn't include the values for the cache table, as mentioned in my post above. One of us should raise an issue on the modules github site.

Another way could be to just remove the lines from the mysql dump, where it populates the caches table. Let the creation of the table in the dump: DROP TABLE IF EXISTS `caches`; CREATE TABLE `caches` ( `name` varchar(128) NOT NULL, `data` mediumtext NOT NULL, `expires` datetime NOT NULL, PRIMARY KEY (`name`), KEY `expires` (`expires`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; But remove all following rows that insert data: INSERT INTO `caches` (`name`, `data`, `expires`) VALUES('Modules.info', ... , '2010-04-08 03:10:10'); INSERT INTO `caches` (`name`, `data`, `expires`) VALUES('Permissions.names', ... , '2010-04-08 03:10:10'); INSERT INTO `caches` (`name`, `data`, `expires`) VALUES('ModulesVerbose.info', ... , '2010-04-08 03:10:10'); INSERT INTO `caches` (`name`, `data`, `expires`) VALUES('Modules.site/modules/', ... , '2010-04-08 03:10:10'); INSERT INTO `caches` (`name`, `data`, `expires`) VALUES('ModulesUninstalled.info', ... , '2010-04-08 03:10:10');

Just to clarify: with the profile export module and than installing on a new site with this (exported) profile works well! (there is no need for refreshing any thing manually). Only when one simply copy a site folder from one server to another, (= manually install) then you have to manually install a mysql dump and manually refresh the modules cache.