horst

Check if this is in the modules info: public static function getModuleInfo() { return array( // ... 'autoload' => "template=admin", // ... ); }

I don't know if there are any blocks for listeners / viewers outside of germany, hopefully not: Tim Isford Orchestra with John Grant (Haldern Pop 2011) :: http://http-ras.wdr.de/tv/rockpalast/live/2011/haldern11_tim_isfort_orchestra.mp4 Get Well Soon (Crossroads 2013) :: http://http-ras.wdr.de/CMS2010/mdb/15/150912/rockpalastgetwellsoon_1484112.mp4 Haldern Pop 2010 (Review) :: http://http-ras.wdr.de/tv/rockpalast/live/2010/haldern10_feine_kleine_dorfmusik.mp4 Calexico (20. Rocknacht 2006) :: http://http-ras.wdr.de/tv/rockpalast/live/2006/20_rocknacht_calexico.flv Brian Auger Trinity feat. Savannah Grace (Crossroads 2011) :: http://http-ras.wdr.de/tv/rockpalast/live/2011/crossroads11_02_brian_auger_trinity_web_l.mp4 Willy DeVille (2008) :: http://http-ras.wdr.de/tv/rockpalast/live/2008/willy_deville.flv Frank Turner (Reeperbahn Festival 2010) :: http://http-ras.wdr.de/tv/rockpalast/live/2010/reeperbahn_festival10_frank_turner.mp4 Miller Anderson Band (Crossroads 2010) :: http://http-ras.wdr.de/tv/rockpalast/live/2010/crossroads10_01_miller_anderson_band.mp4

https://processwire.com/talk/topic/4420-page-list-migrator/

On many hosts / shared hosts this is installed already. If not, you need shell access or need to ask your hoster to install it. But another thing is that you need PHP with enabled / allowed exec() function. In shared environments this function mostly is disabled / forbidden if php runs as a apache module, but is allowed if php is running as (fast)cgi. Maybe a check for exec() should be done by installation.

@Jonathan: Hi, it's me again, - I have some more thoughts / suggestions If someone want to use your optimize module and simply the ImageSizer (or any replacement of it), it's just fine as is. But if someone want to use the PageimageManipulator and the Optimizer, the option to temporary suppress the Optimizer is needed: $image->pimLoad('prefix')->someManipulations()->pimSave()->width(300); // this works fine, no need to suppress the optimizer $image->width(300)->pimLoad('prefix')->someManipulations()->pimSave(); // this doesn't work, we need to suppress the optimizer in the width(300) call! // we only want to optimize the final variation and don't want optimize intermediate images Next points all regard to pageImageOptimize() / pageimage::optimize(): With the initially module, the pageimage::optimize() was made for original images only. To preserve the original source (for quality etc) you create a variation with a name like basename.jo.jpg. That's all perfect. There is only a little issue: with the .jo in the name of the variations they get not fetched by the pageimage variation collections. As a result, when deleting / removing original images, these variations would stay as orphaned files. So, I know there is currently no way provided by PW to solve that (But there is already a private discussion with Ryan on how to provide a good support for custom imagefilename suffixes) As a quick (but bit clumpsy) workaround, you can change the .jo by a .0x0 - This matches the current used regex of the variation collections and isn't a name that could already exist. Not only after the use/need for the temporary suppression of the optimizer, there are application cases where someone need / want to call pageimage->optimize() not only on original images. For example when working with the PageimageManipulator: $image->pimLoad('prefix')->someManipulations()->pimSave()->optimize(); // here simply the existing file should be optimized, no need for a new variation name or a new pageimage object I have updated the pageimage::optimize() to recognize original images vs variations and act upon that. If the basic usage supports individual options per image, the optimize hook needs too: $options = array('joQuality'=>80, 'joThreshold'=>30); $image->optimize($options); ----------------- Finally some thoughts about how the different Pageimage modules could work together - If you implement support for PNG too, a name change to something like PageimageOptimize (PageimageOptimizer) would be useful. - Could it be useful for the average user that you do a check against the ImageSizer quality (hook)-before resizing? And if there is no individual setting, temporary set it to 100%? This way an average user do not have to know all about how it works best. And all users can save some code writing, no need for: $options = array('quality'=>100); $image->width(300, $options); just type $image->width(300) and get the best possible result. - with the PageimageSizerImagick (formerly known as ImagickResizer), the user can choose what type of metadata he want to keep, EXIF, XMP, ICC-profile. XMP isn't supported by JpegOptim, but the others too. Would it be useful to support these with the Optimizer? I can imagine that both modules have their own global settings in their config screens, but both check for individual settings on a per image basis: $options = array('keepEXIF'=>false, 'keepICC'=>true); $image->width(1200, $options); $image->optimize($options); I think their will be some more Sizers in the future, PageimageSizerImageMagick, PageimageSizerNetpbm, PageimageSizerWhatever and all of them should support and use the same options where possible. This way a user can write code for image handling independent of the image rendering engine. What do you think about this? I know its much at once and I have a bit of a guilty conscience to push so much stuff here. But I think it is needed that the existing and future image modules work well together and just by installing / uninstalling them.

something like this? : https://processwire.com/talk/topic/4730-page-list-fields-customisation/ http://modules.processwire.com/modules/markup-custom-page-list/

Many thanks for making this! No please, +1 for let it as is (clicking anywhere)

@Jonathan: Many thanks for this nice module. I have played around with it the whole evening. The JpegOptim runs smoothly together with the ImageSizer and with the ImagickResizer. Following are some suggestions for you. If you find something useful, please feel free to take and implement it: The ImageSizer supports unlimited individual options for thirdparty modules, but it isn't documented actually. You can add any assoc option to the images $options array in templates. But you need to avoid overriding the core ImageSizers options. Therefor I have prefixed all options from JpegOptim with a jo, followed by the initial option name in camelcase style. Now the options are parsed in this order: default settings, config page settings, template / image-options settings! Example that overrides the default setting and custom setting for quality and threshold: $options = array('joQuality'=>85, 'joThreshold'=>20); $image->width(300, $options); I have introduced an option that temporary suppresses the use of JpegOptim on a per image basis: $options = array('useJPEGOPTIM'=>false); $image->width(300, $options); Also I have played around with the option for lossless optimization, but this seems to be nearly useless (not lossless ) because it produces the same result like quality 100 and threshold 1. I have left it in the code, just for documentation. I don't have added / tested these enhancements with the pageimage::optimize hook. So if you want to use some of the above you need to test / implement it there too. I have found out that the JpegOptim produces best results and also mostly smaller results if the GD or Imagick source is rendered with 100% quality. If you render them with e.g. 80% quality, the resulting filesize from JpegOptim is slightly higher (sometimes). This can be due to more jpeg artefacts in the result from GD or Imagick Also it seems best solution to use strong sharpening (over sharpen the resized variation, what is the source for JpegOptim). $options = array('quality'=>100, 'sharpening'=>'strong', 'joQuality'=>80); $image->width(300, $options); Different tests and results can be viewed here: http://images.pw.nogajski.de/jpegoptim/ PS: as I have explained in my previous post it would be nice to keep IPTC if populated PPS: here is the code that helps testing: https://gist.github.com/horst-n/4757d5a34f2278657b6d#file-jpegoptim-testroutine-php

@Jonathan: looks very interesting. Haven't tested now, but have one suggestion regarding metadata: You have set "--strip-all" as default. I really would like to see that IPTC-data would be preserved if populated. This is the default behave in ProcessWire since version 2.3.0. IPTC data only is present if people explicitly have populated them, and in this case they have highly interest in keeping that information within the images and its variations. IPTC data is really small, not like EXIF or XMP. The default is to strip everything but not IPTC. You simply can replace "--strip-all" by --strip-com --strip-exif --strip-icc Or Imagesizer can / should apply a public function that adds it to the resulting files of your and other third party modules. So with jpegoptim it would be a bit faster and more straight forward to use its own flags. ------ I will test it soon, together with ImageSizer, ImagickResizer and the PiM and report back the results.

The best thing would be, if the main ProcessDiagnostics comes together with a DiagnoseRoutine that mimics the same as the installer routine does. I think this is highly needed because of that most "installations" from dev to live do not run the installer process and its checks. Therefor this one should be bundled with the main module and should not be un/installable separately.

<off-topic-too> </off-topic-too>

@Ivan: but you can tell the server if you want him to know it: https://github.com/serbanghita/Mobile-Detect

hhm, but this is not the solution. There must be something completely wrong, because if the images once are rendered, it should only took 0.02 seconds for each image, regardless if it is the first or the 19. ??

Yes, this is looking very weird. If it is on your local server, you can configure php.ini according to my suggestions above, (allowing set_time_limit(), etc). You need to check phpinfo().

I think only notifying, but no auto upgrade. It was discussed earlier. You need to manually compare and update .htaccess and site/config.php agianst a new version. Mostly the wire folder has no write access, or at least shouldn't have it.

as you can see all image renderings are less than a second. Only number 7 = nearly 3 seconds and number 8 is more than 10 seconds! It seems that this is a much to big image, maybe. Also the ini_set('max_execution_time', 30); seems to be disabled / forbidden on your server. I would try to get this enabled. Can you ask your hoster about this? Also you can try to use set_time_limit(30) instead first, but I guess this will be disabled too. You should have a look to your phpinfo() under safe_mode and disabled functions. Second point: do you really need that large images like under #8 that takes 10 seconds for rendering a 320 thumbnail? You can set a max dimension for width and height for the images-field under Setup -> Fields -> yourimagesfield -> Input -> Max Images Dimensions. This will render the uploaded image to these max dimensions (e.g. 1200 or 960 px or what ever you need) and takes this as source for all smaller sizes. Also it looks that your images don't get cached? Do they get recreated every time you run that script? This is not the normal behave and sounds very strange if so. ??

@David: this is already supported by the core ImageSizer. You can combine ImageSizer and PiM manipulations in any order you like: $croppedVariation1 = $image->size($width, $height, array('cropping'=>true))->pimLoad('prefix')->grayscale()->pimSave(); $croppedVariation2 = $image->pimLoad('prefix')->grayscale()->pimSave()->size($width, $height); // cropping is true by default in $config->imageSizerOptions in site/config.php If this doesn't suite your needs, report back please.

I'm not sure and haven't tested, but have you tried something like: pages->find("created_user_id=$userid") EDIT: Adrian wins!

Hhm, you are not looping through images but childpages. You may try to debug the times for the images rendering. Also you can do the resize to 320 and grayconvert in one step. <?php $timerstotal = array(); foreach ($page->children as $article) { ini_set('max_execution_time', 30); $timers = array(); $timer = Debug::timer(); $timers[] = Debug::timer($timer); // start image rendering $bw = $article->cover_image->first()->pimLoad('bw320')->width(320)->grayscale()->pimSave(); $timers[] = Debug::timer($timer); // finished image rendering ?> <a class="archive-item" href="<?php echo $article->url; ?>"> <div class="archive-item-img"><img class="archive-item-img-overlay" src="<?php echo $bw->url; ?>"></div> <div class="archive-item-text-container"><div class="archive-item-text"> <?php echo "<div class='archive-item-title'>".$article->title."</div>"; echo "<div>".$article->contributor->title."</div>"; ?> </div></div> </a> <?php $timers[] = Debug::timer($timer); // none image stuff finished $timerstotal[] = $timers; } // output timers echo "<pre>\n"; // or "<!-- \n" to output it as HTML comment var_dump($timerstotal); echo "\n</pre>"; // or "\n-->\n"; ?>

I have read Feb. 2013 in a board (I do not remember which) that someone said he is very happy about he has found ProcessWire after trying many other CMS for years. That lets me go to the site and after some reading I found the overview video. I loved how naturally and honestly he spoke over that CMS. Looks to me like real love. .(`'`)----(`'`)----(`'`). | '.' '.' '.' | | Ryan & PW | | | '(`'`)----(`'`)----(`'`)' '.' '.' '.'

There are no limits with this module but with your max execution time for PHP. add one line into your loop like here: foreach($images as $image) { ini_set('max_execution_time', 30); // this line resets the timer for max_execution_time with every loop. // following your code ... EDIT: It shouldn't take that long if images are already rendered. Please can you post your code of the loop here?

My DocumentRoot Path, (don't want it public)

This is the whole error. Nothing more, also no entry in the error.log.

@Nico: Loading the tab works now. Installing the Module (in general) works, also the module does its work, but when installing it I get a warning (with debug->true): Warning: Invalid argument supplied for foreach() in ...\wire\modules\Process\ProcessModule\ProcessModule.module on line 803 This is reproducable everytime I install the DiagnosticModules.module. So, in general it works, but there is something that seems not to fit 100%

@steve: here is a thread that fits into the section "Diagnostics needs a Module that checks the same things like the PW-installation-routine do". ------ @Nico: any progress on this one? :: https://processwire.com/talk/topic/6480-processdiagnostics/page-4#entry63854