horst

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.

For updating from the legacy Thumbnail / CropImage to CroppableImage3 read on here.

It would be very easy to change from CroppableImage to CroppableImage3, but the old Thumbnail / CropImage uses a none-conform variation naming. It uses prefix_basename.ext, but since PW 2.5.11 we have basename.-suffix.ext. The way to go would be to use a bootstrap script that iterates over all pages, looking for Thumbnailfields, and if one is found, iterate over all images and (to be save!) in a first run copy the old variations to imagevariations with the new naming scheme. After successfully copied all crop variations, you should make a DB backup!! Than you can install the CroppableImage3 module and change the fieldtype of your images field to point to it. (Do a copy of your croppsettings before changing the type) Now you need to update your template files to use $page->image->first->getCrop('grande') instead of $page->image->first->getThumb('grande') After checking if all works well, you may run a variation of the bootstrap script that delete the old prefix_basename.ext variations instead to copy them to new naming scheme. Then uninstall the old Thumbnail module. As you said it is a lifesite, I suggest to run the bootstrap copy of the variations under PW 2.7 version. This would have no effect on your site. You also may upgrade the Thumbnail module to the CroppableImage (intermediate) module first, what can be done completly under PW 2.7. This way, you would not have to update two parts at once (PW no namespace to namespace, Imagefieldtype from old to new over different naming schemes). Upgrading from CroppableImage to CroppableImage3 is easier. But, if you can lock down your site for 20 to 30 minutes while switching to PW 3, changing images fieldtype and updating template files, it should be save to change from Thumbnail to CroppableImage3 directly. <?php // for PW 2.7 (UPDATED with @jacmaes bugfix for $new filename from below post!) $debugIteration = true; // true to iterate only over the first page with a desired field, false to iterate over all pages $doFilecopy = false; // true to really copy variation files, false for debug purposes $oldFieldtype = 'CropImage'; // CropImage $newFieldtype = 'CroppableImage3'; $timelimit = 60; // per single page // bootstrap PW include(dirname(__FILE__) . '/index.php'); // collect fields and cropsetting names $collection = array(); echo "<ul>"; foreach($fields as $f) { if($f->type != 'Fieldtype' . $oldFieldtype) continue; $collection[$f->name] = array(); echo "<li>{$f->type} : {$f->name}</li>"; $thumbSettings = preg_match_all('#(.*?),.*?\n#msi' , trim($f->thumbSetting) . "\n", $matches, PREG_PATTERN_ORDER); if(!$thumbSettings) continue; $collection[$f->name] = $matches[1]; echo "<ul>"; foreach($collection[$f->name] as $suffix) { echo "<li>{$suffix}</li>"; } echo "</ul>"; } echo "</ul>"; echo "<hr />"; // now iterate over all pages and rename or copy the crop variations echo "<ul>"; foreach($pages->find("include=all") as $p) { set_time_limit($timelimit); // reset the timelimit for this page foreach($collection as $fName => $suffixes) { if(!$p->$fName instanceof Pageimages) continue; $images = $p->$fName; if(0 == $images->count())continue; echo "<li>{$p->title}<ol>"; foreach($images as $image) { echo "{$image->name}<ul>"; foreach($suffixes as $suffix) { $old = dirname($image->filename) . "/{$suffix}_" . $image->name; $new = dirname($image->filename) . "/" . str_replace(".", ".-{$suffix}.", $image->name); echo "<li>$suffix<ul><li>$old</li><li>$new</li></ul>"; if($doFilecopy) { if(!file_exists($old)) { echo "ERROR: original variation is missing!"; } else { if(file_exists($new)) { echo "file already exists"; } else { $res = @copy($old, $new); echo "filecopy: " . ($res ? "Success!" : "!ERROR: $res"); } } } echo "</li>"; } echo "</ul>"; } echo "</ol></li>"; if($debugIteration) break; } $pages->uncache($p); // just in case we need the memory } echo "</ul>"; exit(); I have tested this with one page and two images, where I have done a little damage too. This was the output: