horst

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

If you choose a manually installation, I think you just has to manually go through all steps until the end. If you feel uncomfortable with this, you may create a site profile on your source website, and install a fresh PW with this site profile on your new destination site. This way, every thing is done for you automatically. The way with simply manually copying a site profile to a new destination does include a manually update of the DB and a manually refreshing of all caches. PS: another goody in this regard comes from @Soma, currently not available in the modules directory: https://processwire.com/talk/topic/13042-clearcacheadmin/ PPS: maybe, it is possible to create a little bootstrap script, that execute somas modules cache refreshing?

$max_execution_time = trim(ini_get('max_execution_time')); $can_change = set_time_limit($max_execution_time); I only know: simply testing if it can change. That image processing feature shouldn't belong to the Version List. Just wanted to throw it in and ask, if this would be useful to integrate somehow into Tracy.

Ah, sorry. No, there are no other needs in regard of mysql. I just mentioned this and pointed to Steve and Ryan, as I don't have much knowledge of mysql. But throwing in another thought, that I have had some time ago, what can be useful in regard of troubleshooting image processing issues: Selecting / defining a problematic image, and var_dump all infos of ImageInspector + the current image settings, calculated / merged like here.https://processwire.com/talk/topic/13125-get-image-quality-value-from-image-instance/ But I don't know if this could be something practicable for Tracy. (?)

Very good initiative @adrian! What I think could be useful is: max_execution_time (and if it can be increased) max_input_nesting_level xdebug & xdebug.max_nesting_level function_exists('gd_info') $gd = gd_info(); $ver = isset($gd['GD Version']) ? $gd['GD Version'] : $this->_('Version-Info not available'); $jpg = isset($gd['JPEG Support']) ? $gd['JPEG Support'] : false; $png = isset($gd['PNG Support']) ? $gd['PNG Support'] : false; $gif = isset($gd['GIF Read Support']) && isset($gd['GIF Create Support']) ? $gd['GIF Create Support'] : false; $freetype = isset($gd['FreeType Support']) ? $gd['FreeType Support'] : false; function_exists('exif_read_data') class_exists('Imagick') In regard of mysql, I think the version is important. For more, you may have a look at DiagnoseDatabase.module or ask @netcarver & @ryan.

I converted another site from a foreign system into PW. The previous page wasn't responsive, so I converted / redesigned it using Bootstrap 3. http://die-leserei.de

definetly! have posted an issue on github. PS: welcome to the forums!

How do you disabled it? Please can you try setting it to NULL, and not false? If this will work, I think it is a glitch here in Line 142 in ProcessPageView.module: if($config->usePoweredBy !== null) header('X-Powered-By:' . ($config->usePoweredBy ? ' ProcessWire CMS' : '')); See: !== null, if you have set it to false, it will result in boolean true, but afterwards, querying simply $config->usePoweredBy results in boolean false, what populates an empty string to the sended header.

I believe, saving the field before any changes can take effect is mandatory.

Sounds very interesting! I'm specially interested to know how the lock is respected. Is it only in your own functions and process module, or do all Process Modules respect it? (If yes to all ProcessModules, where can I view this?)

Don't really know, but if your above code doesn't work, you also may try with a $p->save(); after add() and before getting the $lastimage.

@jacmaes: many thanks for your feedback! I have updated the script in my post with your suggestion to work only with the image->name and not image->filename within str_replace(). Also I added a line at the end of the pages loop to uncache each no longer needed page, to save some memory.

@mscore: Haha, really, this is old-school: Tri-X and Rodinal! Great. So, in 35mm format, I ended up with the T-max films, (around 1985-1995). But I don't like(d) the big grains that much. Therefore I early switched to greater film formats: 6x6 & 6x9cm, 4x5inch, 13x18cm. But my last darkroom experiences with positives are 20 years back, iirr. Films (E-6 dia positives) I regularly developed with a JOBO ATL-3000 (the biggest drum contains 14 35mm films at once) until 2010. (between 2005 / 2010 only for the large formats 4x5inch and 13x18cm). All other and since then is/was direct digital. Are you not interested in larger formats? The costs for good equipment is very cheap since all in the pro sector is requested direct digital. PS: your site at instagram is very nice too. My favourites there, besides all the beautiful motives, are the "one breasted lover", the "seal dryer" and the "archival system". Seeing all this, I get longing!

Try $p = $pages->get("/"); or $p = $pages->get("template=home"); or $p = $pages->get("name=home"); Please, better do not use $page = ..., instead use $p or some other varname. $page is a prepopulated API var from PW what holds the current page.

Yes, it may of help for others too. That's why the script first collects all CropImage fields and their cropsettings. I will link to this post here from CroppableImage3 support thread.