horst

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:

@desbest Uhm sorry for any confusion. @flydev is right. Welcome back to PW and the forums!

New? You joined the community in Oct. 2013

Simply said: YES! There are more then one, but ... The biggest point is, that you don't need any module to run complex sites and very complex sites with PW. PW at first is a framework, and then a CMS on top of that framework. I can put all my application logic into template files and the site/init.php, site/ready.php and site/finish.php via hooks. No need for modules at first place. So, in a second place, modules also can be very valuable. We have some of them in the directory. And of course, PW 3 should be able to run with most of them, at least if there is stated that they are compatible with PW 2.7. As a side information: The modules do not belong to the PW core. Most of them, (if not all minus ryans personal modules) are from "third party" authors. So, as of now, PW 3 is DEV-branch, and most of the modules authors simply haven't updated their module directory entries. But this is not that relevant. If you are interested in using a module with a PW version that is not listed there, you can ask in the dedicated support forum thread of that module. Here you normally will get fast answeres, I believe. But now to the biggest second point, why it is useful to use PW 3, when most of the modules in the directory stated as not compatible with it: https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/ PW3 has a file compiler for template files and modules, that in 99% of the PW 2.7 modules simply make them compatible with PW3. Nice eh? (And if you are unsure, ask in the dedicated support forum thread) Thank you for reading and enjoy PW3, (or what ever you like)!

It all depends on name formatting of the old crop variations! Please, to be sure, can you give one or two examples of the filenames (original image + varition name of the crop)? Also, how do you call them in templates. (with the older CroppableImage and the CroppableImage3, we use $image->getCrop("suffix")). I'm sure, we will find a practicable solution, but want to be thouroughly and careful. EDIT: How many cropsettings / thumbsettings are defined with a typical field in your sites? Can you post an example of the textarea content?

Do you know if there is a high setting allowed for timeout on this host? If so, you may try to temporarily add a line into your site/templates/admin.php (before the controller.php) $timeLimit = 60 * 15; // sec * min <= adjust to your needs set_time_limit($timeLimit); ------- In general, you also simply can copy all files to a new location. You then will need a mysql dump too. If you have no other tool at hand, you simply can install the PW module ProcessDatabaseBackups, before you do the copy. Create a full backup from within the PW admin, before you copy the files. The backup can be found under site/assets/backups/ database/...

Some years ago, (maybe 10 ?), I worked with a nice and useful tool: Tiny But Strong. It is a OneFileTemplatingEngine in PHP, with 1 PHP-class, 6 methods and 5 properties. If I recall right, I was able to do every thing with it. Besides Tiny But Strong, it also was Simple And Easy To Use. It is under constant development / maintenance since 2004!

Hey @Manu, welcome to the forums. Have you already read / tried this troubleshooting guide? http://processwire.com/docs/tutorials/troubleshooting-guide/ What have you done to solve your first issue?

Another approach, what works automatically everytime, and without additional support, (updating version numbers) can be: $timestamp = filemtime($config->paths->templates . 'scripts/myJsFile.js'); $myJsFile = $config->urls->templates . "scripts/myJsFile.js?ts={$timestamp}"; $config->scripts->add($myJsFile); I'm to lazy to add version numbers to all and everything. Also, last modified filetime is foolproof, not updated version number is not.

It isn't designed to support this. But I also don't see much disadvantage for this usecase. Lets assume the width you want to support is 1400, 960, 480. Setup the image field with min-width: 1400 and min-height: 788 (= 1400 / 16 * 9) Create a cropsetting image16x9, call it with 100% quality as master-source for the variations $master = $page->images->first()->getCrop("image16x9", "quality=100"); $large = $master->width(1400); $medium = $master->width(960); $small = $master->width(480); Or directly use the markup srcset module from @tpr and only pass the master to it!