happywire

Great replies from all of you thank you very much. In due time I will get back to a few people with some particular questions regarding their posts here. Overall, this is very much appreciated. ?

Thank you. ? It times out on the frontend upon uploading the image and visiting the page in question. Tried it and cannot have that happen with any client. Also in that particular case no picture tag is needed. That means up to 3 times as much or even more data is sent as compared to webp. Given we strip webp from the requirement and do not do image conversion in the frontend, how else would you go about it? Take an example where the client uploads a batch of 10 images each between 5-12mb in file size. Take a given list of variations between 120px width and 5120px or more width. Only keep the sizes you want without having default or other variations mixed with that srcset. Make sure you are only using sizes that really exist, so don't have a srcset of 2000px width when the largest variation is 1200px in width. How would you tackle that?

@wbmnfktr Great reply thank you. Is there a list of features you check for in a shared host? What do you deem important things a shared host should have? For example I have a nice script that pushes and pulls between dev, stage and production, including db. This uses ssh, mysql & php (cmd line), scp and rsync, so those would be already quite good to have on the host. I imagine similar to WP, PW also needs some search and replace of the local dev domains to the live domain in the db. No worries I am doing all this locally and then pushing to stage or live. So I guess/hope https://interconnectit.com/products/search-and-replace-for-wordpress-databases/can be used for that? I would like to refrain using FileZilla, clearing db on host, uploading db, then somehow changing local domain to live domain in there and then uploading files manually. Have heard about Duplicator for PW but not checked it out yet, bottom line, if dev can be pushed to stage or live with a single command of a simple script, that is what I am after. Then, I am now with a client that does not have any image processing features (webp conversion) on their shared hosting and it is a pain to work with. Client was with this host before we started work. So ImageMagick with webp support or GD enabled and compiled for webp support on PHP would be 2 more points to have in place. What else?

@horst Thank you. In theory or simple pseudo code, or if you can just talk me through the process, how would you go about obtaining the responsive image syntax above? a) from a given set list of sizes between 120px width and 2560px width create the srcset array that checks existing variations for an image without mixing default variations or variations created by modules with it b) make sure no variations that do not exist for an image are included in the srcset array, so an image that has a max width of 1200px does not have a srcset item of 2000px width in the syntax, meaning don't just have a fixed syntax for each image but really make the syntax from the image and its variations At the moment I am still searching for a solution to this.. and to be honest I feel rather bad about this, asking so many questions, thinking I am the only one in the forums that seems to have trouble coming up with a decent responsive image workflow that results in the given responsive image syntax above..

Let me try.. perhaps I am not seeing the forest for the trees.. Given is this syntax for responsive images. <picture> <source sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.webp 200w, image.400x0.webp 400w, image.800x0.webp 800w, image.1200x0.webp 1200w, image.1600x0.webp 1600w, image.2000x0.webp 2000w" type="image/webp"> <img src="image.400x0.jpg" alt="A rubber duck" sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.jpg 200w, image.400x0.jpg 400w, image.800x0.jpg 800w, image.1200x0.jpg 1200w, image.1600x0.jpg 1600w, image.2000x0.jpg 2000w"> </picture> 1. In order to reach this I create an array for the srcset. If I go through the variations for each image on a page <?php $variations = $image->getVariations($options = ['info' => true]); the default thumbnail is included, not what I need or want. I create the variations that I want for the particular site and do so with particular ImageMagick commands when it comes to encoding and compression. If the default thumbnail is included in the srcset array with different ImageMagick commands it not only messes with the array (including an item that is not supposed to be there) but also "dilutes" the quality of the outcome. 2. Now would the default thumbnail always have the same filename 0x260 or 260x0 I could easily single this out of my srcset array. Since this is not the case I cannot use the default assets -> files - page ID folder to get all the images for that page and then create a srcset array from it. So this means, in order to be able to use the image field and have a nice UI for clients.. a) I need to work in a custom folder that only mirrors the original files uploaded regardless of the variations PW might or might not create b) in such a custom folder I need to create my exact srcset array as well as image variations I want/need without the default thumbnail c) such variations created in a custom folder need to adhere to the PW nomenclature so that they can be seen in the "Variations" UI of the image field d) while also making sure these variations are later copied over to the assets -> files - page ID folder in order for them to come up in the "Variations" UI of the image field. Well this also won't work since as soon as I copy my variations back over to the assets -> files - page ID folder they are mixed with the default thumbnail. This not only then gets included in the "Variations" UI of the image field but also leaves a sheer amount of duplicate content on the server. One "custom" folder inside the assets -> files - page ID folder that is used to create a clean srcset array and the default assets -> files - page ID folder that has all variations, including the default thumbnail as well as, like you said, more variations that modules added later on might or might not create. Especially this "might or might not" scenario is something I cannot support. Let's have a look at this way of creating a srcset array for jpg. <?php if ($page->images) { $variations = $page->images->getAllVariations(); echo '$variations'; dump($variations); // This however does not return more info on the single variation // So you need to go one level deeper foreach ($page->images as $image) { // ######################################################## // Make jpg srcset array ################################## // ######################################################## dump($image); $variations = $image->getVariations($options = ['info' => true]); dump($variations); usort($variations, function ($a, $b) use ($variations) { if ($a == $b) { return 0; } // Compare the values of the 'width' key to each other and sort them // Sort from largest to smallest > and from smallest to largest with < return $a['width'] > $b['width'] ? 1 : -1; }); echo '$variations'; dump($variations); // Remove first element from the $variations array. // http://php.net/manual/en/function.array-shift.php // That first element holds the default variation/thumbnail created by ProcessWire $removedDefaultThumb = array_shift($variations); // this will just output the first element/the removed element dump($removedDefaultThumb); // this will now hold all the custom created variations as needed/wanted without the default 0x260 dump($variations); $srcsetJpg = array(); foreach ($variations as $variation => $value) { array_push($srcsetJpg, $value['url'] . ' ' . $value['width'] . 'w'); } echo '$srcsetJpg'; dump($srcsetJpg); } Quite clear, if the default thumbnail a) is not the first element of the array, the srcset array is messed up b) is later replaced by another variation included through a module added later on, the srcset array is messed up c) does not have the 0x260 or 260x0 nomenclature (one could try and single it out through that), the srcset array is messed up Now, let's move over to the webp srcset array. 1. webp files cannot be created by PW at the moment, support for those is in the pipeline, however when that might surface is not clear. Sure there is Horst's patch one can use so that the webp file format is accepted by PW. 2. webp files or variations therefore need to be created in an external process. If this is to be automated for clients in the background one needs to hook the PW site up to something like this https://github.com/rosell-dk/webp-convert-cloud-service in order to first of all obtain webp files and their variations. 3. Since webp files are not supported by PW they also do not show up in the "Variations" UI of the image field. There is no way know to me at the moment to even include them there to have a nice visual representation of what variations for an image exist in fact. Sidekick, at the moment the "Variations" UI of the image field also does not sort the variations by width or height keys but by filename resulting in a list that is not ordered. 4. Let's assume somehow the webp files and their variations are created with an external service and this is automated for the client. This process needs to make sure that a) only ever the original jpg files uploaded in the assets -> files - page ID folder are converted and then copied (not moved) to the clean custom folder in order to get a clean webp srcset array from there b) the amount of webp variations exactly match the amount of jpg variations for that original jpg, but not in the assets -> files - page ID folder but inside the custom folder, as again the contents of the default folder might be touched/edited/overwritten by modules added later on that "might or might not" introduce further variations 5. Since neither the original jpg or its variations are added to the db and unfortunately the original jpg also does not have a key, i.e. "original", inside the result of getVariations($options = ['info' => true]) there is no clear way to obtain that original file and its variations to then be able to create the exact webp variations of those images. In short, at least to me, it appears that obtaining a clean way to show responsive images that use the above syntax is/will be quite some work if one wants a solid approach to this. Last not least, creating variations in the frontend times out, hooking into the process in the backend is fine, albeit I am also, at times, facing timeouts there when using large images. Telling the client to create "optimized for web variations" before uploading images is, at least for me, out of the equation. So yeah, perhaps all these points are a result of me not understanding how PW handles a proper responsive image workflow that results on the above responsive image syntax. If that is the case and you or anyone else here has a simple and solid solution, well that would be great!! I would really love to start coding up some nice websites with PW instead of dealing with how I can get past the stage of creating responsive images. And no, I don't really want to divert from the syntax for responsive images given above. https://caniuse.com/#feat=webp just being one of the many reasons. For what it's worth here is how ideally I like to go about making the webp srcset array for each image on a page.. <?php // ######################################################## // Make webp srcset array ################################# // ######################################################## // http://cheatsheet.processwire.com/page/built-in-fields-reference/page-id/ dump($page->id); $pageId = $page->id; // Then make the page specific assets/files/$pageId url out of it. $pageWebpBaseUrl = $config->urls->files . $pageId; dump($pageWebpBaseUrl); // => "/site/assets/files/1016" $pattern = '!.*' . $pageWebpBaseUrl . '!'; $replacement = $pageWebpBaseUrl; // Make an empty array that will hold our webp srcset. $srcsetWebp = array(); foreach (glob($pageAssetsFilesPath . '*.webp') as $filename) { echo '<pre>'; echo "$filename size " . filesize($filename) . "\n"; echo $filename; $filenameSize = getimagesize($filename); dump($filenameSize); // Looking at the dump you can see that the width of the image // is always at key/index [0] of the array. dump(getimagesize($filename)[0]); // Turn the filename into the url for the webp image $webpUrl = preg_replace($pattern, $replacement, $filename); dump($webpUrl); echo '</pre>'; array_push( $srcsetWebp, array( 'url' => $webpUrl, 'filename' => $filename, 'width' => $filenameSize[0], 'height' => $filenameSize[1], ) ); } dump($srcsetWebp); usort($srcsetWebp, function ($a, $b) use ($srcsetWebp) { if ($a == $b) { return 0; } // Compare the values of the 'width' key to each other and sort them // Sort from largest to smallest > and from smallest to largest with < return $a['width'] > $b['width'] ? 1 : -1; }); echo '$srcsetWebp'; dump($srcsetWebp);

..and https and http now work?

Thank you. However I still don't know what you are referring to unfortunately. Sorry for that. Have you got a link to that exact topic/thread/post please? I looked at the repo https://github.com/rosell-dk/webp-convert-cloud-service as well as its open and closed issues and cannot find anything about a PATCH request. Please, link me to it.. ?

As a freelancer or part of an agency, how do you do it, what do you suggest to your clients? Get a decent shared host or buy a possibly much cheaper VPS and do it all yourself? Looking at the prices of https://www.hetzner.com/cloud and comparing those to shared hosts that do have SSH access, have proper PHP modules/extensions installed and enabled, well what do you pick? I mean a shared host with a decent configuration can easily be many multiples of what the CX31 is for example. I am thinking the time it takes to set up a VPS including monthly maintenance and the option to easily scale if things take off might be worth it, no? Then again if you have many clients and all are on a VPS you do/did setup yourself and things go bad you are gonna find yourself in a bad place. This is for simple to medium sized websites, low to medium traffic, no high traffic portals or shops with thousands of requests per second/minute/hour. Then again if a client needs that and is on a VPS scaling would not mean "oh now we need to move host and it's gonna take a while.." How do you do it?

@Sephiroth I am not sure what "thread" you are referring to or that it is pointing out something about making a PATCH request. What do you mean? @horst So in fact it would be very advisable to rewrite the CURL parts of the example code using WireHttp in case a shared hosting does not have the CURL extension installed, right?

Sorted for that part. I guess you will now be able to also turn on or off https or what I do, either just visit the the local project through the http or https protocol. I used Wamp, then XAMPP and now Devilbox, from the things I have done so far, Devilbox has been quite approachable, if you use it for ProcessWire make sure to pick the right containers in the .env file. All the best amigo!

I could do that, but that would make it a lot less "nicer" to use for clients. So I would like to keep using the image field while also having it behave in a different way. I guess this all points in the direction of "write you own module for it"..

My reply is for @OrganizedFellow , I was just quoting a reply he made in a thread you started.

[solution] ======================================================== I am setting up and using a cloud service that encodes images. https://github.com/rosell-dk/webp-convert-cloud-service The usage of the service works with this example. https://github.com/rosell-dk/webp-convert-cloud-service/blob/master/docs/api.md#usage-example-php I am wondering, should I re-write this bit of the code below and use WireHttp instead of CURL? What negative implications could it have if I do not make use of WireHttp? <?php // from https://github.com/rosell-dk/webp-convert-cloud-service/blob/master/docs/api.md#usage-example-php $ch = curl_init(); curl_setopt_array($ch, [ CURLOPT_URL => 'http://example.com/wpc.php', CURLOPT_POST => 1, CURLOPT_POSTFIELDS => [ 'action' => 'convert', 'file' => curl_file_create($source), 'salt' => $salt, 'api-key-crypted' => $apiKeyCrypted, 'options' => json_encode(array( 'quality' => 'auto', )) ], CURLOPT_BINARYTRANSFER => true, CURLOPT_RETURNTRANSFER => true, CURLOPT_HEADER => false, CURLOPT_SSL_VERIFYPEER => false ]); $response = curl_exec($ch); // The WPC cloud service either returns an image or an error message // Verify that we got an image back. if (curl_getinfo($ch, CURLINFO_CONTENT_TYPE) == 'application/octet-stream') { $success = file_put_contents($destination, $response); } else { // show error response echo $response; } curl_close($ch);

Will do, noted and yes could be Devilbox is doing that, thx for your help.

This means that if I have a src size of 1024px width in my responsive images array and somewhere down the line during work on a site I install a module "xyz" that also does, for any reason, create a 1024px wide variation of the original those might get mixed up or worst case overwritten? So work starts, original.jpg -> original.1024x0.jpg is created. Later during further dev of the site module "xyz" is installed and it also, for any reason that also might not be documented in the module docs, wants to create a 1024x0 variation. Will ProcessWire overwrite the variation created first? Or would the ProcessWire internal code make sure to see "ah, module xyz is installed and it wants to create a variation, but there is already a variation with that filename and 1024x0, so better not touch it!" The implications would be that in the end the responsive image array I want to work with would be mixed up/diluted/changed/affected by images that I did not intend to be used, for any reason. So this really means I have to come up with a way to strictly separate the ProcessWire image workflow from the responsive images array? Or are people just fine with "ok, Ill upload this, whatever happens in the assets folders I don't care, I will just write a responsive image function that refers to those images and their variations, it should be ok.." Perhaps because I am new to ProcessWire it has not "clicked" with me how one can have a tidy/clean/solid way of i.e. producing this responsive image syntax below while also being sure that the images created for it will never be touched/affected/overwritten/changed by either ProcessWire or any future module for any reason. <picture> <source sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.webp 200w, image.400x0.webp 400w, image.800x0.webp 800w, image.1200x0.webp 1200w, image.1600x0.webp 1600w, image.2000x0.webp 2000w" type="image/webp"> <img src="image.400x0.jpg" alt="A rubber duck" sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.jpg 200w, image.400x0.jpg 400w, image.800x0.jpg 800w, image.1200x0.jpg 1200w, image.1600x0.jpg 1600w, image.2000x0.jpg 2000w"> </picture>