horst

Current state is that only the images are created and removed. There is no markup generation or additional url output implemented yet. But will be added soon.

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 ?

Yep, if I remember right, you also would have to change code in php files that processes the zoomed variations.

Nope. 100% would be 0 px, what is not useful. ? Also in different tests it showed that more then 50% maybe very often lead to unwanted results. The max percent what seemed to be useful (for very careful) users was 70%. My bet is, that Ryan uses 50% to support it as a good and successful feature to a broad community.

You overide each pagereload the complete session vars. I think that the $gebruiker is not created and available on every page load, but only on a special template. You may use a conditional that secures you that a (new) gebruiker is sent and need to be transfered into the session: $gebruikerarray = json_decode($gebruiker); if(!empty($gebruikerarray->naam)) { // add new data to sessions vars ... } OR you look if $gebruiker is available or not, or if a post submitt was sent, or ...

Ok thanks for trying. It was a shot into the blue. I will setup a repeater field locally and debug it. (Maybe tomorrow)

@PWaddict Good to hear that you solved together with adrian the timestamp issue, and thanks for reporting the Notice. Please can you try if the following code solves it? // replace the old lines 66 - 69 with this lines: 66 if(preg_match("/_repeater[0-9]+$/", $field)) { 67 $explodeArray = explode("_repeater", $field); 68 $pages_id = intval(end($explodeArray)); 69 $field = str_replace("_repeater{$pages_id}", '', $field); 70 } else {

You can add get params to every url: example.com/apagename/?param=value To work with it in processwire template files, we have the $input variable instead of the global $_GET variable. There is also $sanitizer. I'm on mobile, so please look out in the docs for the $input variable. (poviding links via mobile is a pain ?)

@arjen the support via lazyload sounds very interesting. This way we only have to care that both fileformats are available on the server. There is no extra markup needed. Only downside is the missing noscript support. So the usefulness depends on the usecase. ?

Very Cool! Yes, he also has game boys. No Arduinos until now, but RasPis. But these "Sound Things" are exactly what he is after. Many thanks! ?

It is page names, that only supports part of the ascii charset, and only lowercase.