horst

I believe that this would need a huge rewriting of the complete images files (Pageimage and the SizerEngines). My first thought also was to enhance it to use different outputformats, as you can read above, (or maybe only in the github issues). But with this first take, I definetly want to use only webp and only as a sidecar file. Other things, like selectable and multiple outputformats are not in the first line. Thats because I have not that much time atm to start a huge rewrite, but want to have the compression advantage of webp integrated directly in PW, as this will be the first possibility included in the core, without usage of external tools and also without extra manipulation steps. And for that purpose, it seems to me enough to implement just another single param. It will be definetly not "easily", as the imagesizer was and is designed to only resize and crop a single image. It is not an image manipulator. And the todo work not will be the ImageSizerEngines but the Pageimage.php, the tempfiles generation and how all this currently works together.

Want to announce that I started with embedding support for the WebP format into the core. Current state in my dev-branch is, that you can call / create additional image variations in the WebP format by passing this param within an options array to any size call: // mandatory is: 'webpAdd' => true // optionally define a quality for WebP: 'webpQuality' => 80 // currrently it only is implemented in the GD-Engine, so you need to force its use, $options = [ 'forceEngine' => 'ImageSizerEngineGD', 'forceNew' => true, 'webpAdd' => true, 'webpQuality' => 80 ]; $image = $page->images->first->size(700, 700, $options); If you want to be an early tester, you can get a fork from here (patch-1), or you grap these three files: Pageimage.php ImageSizerEngine.php ImageSizerEngineGD.php More will be done between christmas and new year!

Yes. And, if you are not able to do a fresh install, you may install and use the Diagnostic-Modules from @netcarver to do a check on unknown server environments.

ping: @ryan This one would be really useful: https://github.com/processwire/processwire/pull/117 Also this is not an issue, it would be really helpful to have this enhanced debugInfo integrated into the current dev branch, before it becomes the new stable. It doesn't affect any other method or param, - only enhances the __debugInfo() method with useful informations. This would be really helpful for debug and support cases, if someone encounters a problem and ask here in the forums for help, we can get a good insight / overview in his/her current images system by simply asking to show us that info.

+1 ping: @tpr ??

@MoritzLost regarding earliest include of the autoloader, I think the site config.php is the right place. It is parsed / executed before modules, but it get not overwritten with core updates.

Hi @blynx, many thanks for this great module!

Hi Sam, there is PageimageManipulator available for PW: With it you can do something like: $imageBase = // get the base image here $imageOverlay = // get the thumbnail overlay image here // first wrap a 50px transparent (rgba) canvas around the overlay image and convert it to png format: $imageOverlay = $imageOverlay->pim2Load("prefix")->canvas($imageOverlay->width + 100, $imageOverlay->height + 100, array(0,0,0,0), "center")->setOutputFormat("png")->save(); // now stretch the overlay image canvas to match the base image dimensions: $imageOverlay = $imageOverlay->pim2Load("prefix")->canvas($imageBase->width, $imageBase->height, array(0,0,0,0), "northwest")->save(); // now merge both images together $imageResult = $imageBase->pim2Load("prefix")->watermarkLogo($imageOverlay, "center", 0)->save(); // The resulting pageimage can also be adjusted using regular pw image functions, if necessary $imageResultThumb = $imageResult->width(150); Better is to chain the manipulations of the overlay image into one call: $imageBase = // get the base image here $imageOverlay = // get the thumbnail overlay image here // two steps to create the canvas with the thumb at the desired position and convert the output to png format: $imageOverlay = $imageOverlay->pim2Load("prefix")->setOutputFormat("png")->canvas($imageOverlay->width + 100, $imageOverlay->height + 100, array(0,0,0,0), "center")->canvas($imageBase->width, $imageBase->height, array(0,0,0,0), "northwest")->save(); // now merge both images together $imageResult = $imageBase->pim2Load("prefix")->watermarkLogo($imageOverlay, "center", 0)->save(); Please refer to the PageimageManipulator page for the documentation of all methods and params, but ask here, if something is not clear.

I have built and used some custom newsletter systems already. But 100k is a huge number. With regular hosting accounts I'm able to send 500 mails per 250 second chunks in a single thread. So I never sent more then 15k. To send 100k would take 15 hours this way. If you not already know it, there is the wireMail system in PW available, plus some extending modules for different purposes. When I'm back in the office, I provide some links.

Regardless wich way you decide to go re the user question, there are already modules available that seem to implement parts of what you want create. Maybe they can serve as additional stuff for reading, or maybe they can be implemented as required (sub)-modules for yours. http://modules.processwire.com/modules/newsletter-subscription/ Also Ryan has posted something about building a bare email sending module in the near past. Currently does not find it, but will add the link if I do. EDIT: I found it, but it will become a ProModule: From the last Blogpost (https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/) the very last paragraph.

I think you are mixing ProcessModules with Other modules. The class skeleton of a process module has to look like this: class ProcessGoodNews extends Process implements Module { ... First add the prefix "Process" to your modules classname and also to the filename, and second you have to extend Process and not WireData. PS: the title can stay as is, Good News, or GoodNews, but the class name and filename should be prefixed with Process. PPS: I think you also have to prefix the execute() function name by three underscores: ___execute() < Thats wrong, as @teppo mentioned below. Sorry. PPPS: maybe some interesting reads about ProcessModules and different possibilities: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ https://processwire.com/blog/posts/new-module-configuration-options/ https://processwire.com/talk/topic/13618-does-using-dedicated-module-files-help-a-lazy-programmer/

I forgott about it, because @tpr made it an official and configurable module and took over the maintainance, whereas I served the startingpoint:

Difficulties in this approach maybe, that there are many chained variations are possible in the wild. Also the intermediate variations in chains never will be served to browsers, but need to stay, as removing them will raise unnecessary recreations. Maybe for image heavy sites it can be useful to define all used variations in a collection of (some sort of) selector strings and execute this in a sandboxed scope against a default image name (basename.jpg). Using the resulting variation name patterns as whitelist, for example. Regardind file-a-time, this may be error prone by using any sort of hosting, crons or maintenance scripts running on a server or in a hosting account.

Without the new module, you would have to temporary modify your template files by adding the following param to the options array "forceNew" => true for every pageimage call that you wants to be affected.

Have you also tried -1 ?