Stefanowitsch

I find this is a really good addition, thank you for including it in your module!

Hi @Juergen! I tested your module, you did a great job and I found two small details that I would like to point out: 1. "for" attribute missing on labels (when using InputCheckboxMultiple and InputRadioMultiple) 2. <label> elements (when using InputCheckboxMultiple and InputRadioMultiple) need "uk-form-label" classes to apply margins (of course only when UI Kit styling is selected in the module settings) By default the <label> surrounds the input so that the "for" attribute is not needed. But if you use this option: $form->appendLabelOnCheckboxes(true); ...then clicking on the label does not activate the checkbox/radiobutton next to it (because of the missing for-attribute). Another thing that would be really convenient: Is it possible to allow multiple file uploads via the InputFile class and to show each file that is chosen for upload under the field (before submitting). Something like this: The idea is to get an overview over the files that should be submitted and also give the user the option to remove specific files.

@Juergen thank you! I was looking at the GitHub documentation and these classnames are still listed there: InputSelect text - InputSelectMultiple arrayVal -

@Juergen I am experimenting with your module to see if it fits my needs, I was wondering if you forgot to include the "InputSelect" and "InputSelectMultiple" Classes in your module? I get an error when trying to create a select field and the class file is missing in the InputElements folder: Error Class "FrontendForms\InputSelect" not found

Thank you very much @Robin S I modified the code a little bit to fit my needs and now it is a rally simple but very effective solution for handling global media / file management in ProcessWire.

Yes I already send a PM to kongondo asking where to download the latest version of the Media Manager. This module still looks very promising. But on the website https://mediamanager.kongondo.com/ neither a documentation nor a download link is available.

Hello there! Since I started creating sites with ProcessWire I wished there was a central media management option. You know - a place where you can upload all sorts of data (well, mostly images) to use them throughout the whole website. It is something that nearly every other CMS offers and many clients of me which used Wordpress or Typo3 are used to this kind of media management and it's kind of hard to tell them that this is not possible (in that way) with ProcessWire. I know from the past that there was a Media Manager Module from @kongondo but this module seems not to have been updated in years. Are there any other solutions or techniques that you developers use?

Thank your for letting me know! I updated the module to Version 1.0.1.

I can't help but agree!

@nbcommunication I found my problem. 🥵 It wasn't your module at all but instead another module that I was using which interfered with the webp image creation for the srcset attributes: Delayed Image Variations I was using this Module because the image variant generation on image-heavy sites (using the size method) took very long and resulting in time out errors of the server. As described in the module thread: After uninstalling the module all the paths in the srcset attribute point towards the webp versions of the image and also the quality settings are applied as set in the module settings page! I am sorry for causing so much work for your tests! 😔

The output of both is: "0 Bytes" I then tried this: <img src="<?php echo $image->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp->url; ?>" /> Which results in in a "502 Bad Gateway" error (for the jpg image file path), because the img src in the DOM refers to the "jpg" version: <img src="/site/assets/files/1651/startbild_architektur.2550x1440-q10.jpg" width="2550" height="1440" sizes="auto" alt="" uk-cover=""> The jpg version however is not created (probably because webpOnly is 'true'). The webp version is created in the filesystem (and the quality setting is working!) but this webp version is not used in the src attribute.

@nbcommunication thanks for testing it out! I tried to replicate the steps you took but my results are still the same. First, outputting the srcset array gives this: array 0 => '/site/assets/files/1651/startbild_architektur.640x361-srcset.jpg 640w' 1 => '/site/assets/files/1651/startbild_architektur.1024x578-srcset.webp 1024w' 2 => '/site/assets/files/1651/startbild_architektur.1500x847-srcset.webp 1500w' 3 => '/site/assets/files/1651/startbild_architektur.1920x1084-srcset.webp 1920w' 4 => '/site/assets/files/1651/startbild_architektur.2550x1440.2550x1440-srcset.jpg 2550w' Note: The webp images are not created in the first place, only after reloading the page they get generated from the -srcset.jpg versions (depending on the current screensize, thats why the array is mixed with jpg and webp images). What I still don't understand is that for the largest image variant - 2500px in width - the webp image variant gets created in the file system but is never ever used in the srcset attribute. I extended my browser window width on > 1920 to make sure it will be loaded. In my case the max size for an image variant hast to be lower than the size given in the config. Only then it will be used in the srcset. That's why I am using 2500px instead of 2550px for the srcset in the module settings. $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; I entered a webp quality setting of "1" in the module settings but this setting is not applied. All webp variants were created at 90% quality based on the filesize. This behaviour is the same on all of my local DDEV projects and on the live servers. I don't use Imagick though, it's the standard GD engine instead.

@nbcommunication Hello! It's me once again. After excessive testing I found out that the modules webp quality settings were never applied to generated webp iages when outputting the srcset like this: <img srcset="<?php echo $image->size($imgFormat)->srcset ?>" ... The webp versions that were created always used a quality setting of 90%, no matter what I entered as value in the module settings. The solution: I had to place this line in my config.php to kind of "override" the default webOptions of ProcessWire: $config->webpOptions = array(); By the way the default options are set to this: 'quality' => 90 'useSrcExt' => false 'useSrcUrlOnSize' => true 'useSrcUrlOnFail' => true Only then (when the 'quality' option is missing) the entered value from the module settings is applied correctly. I did not test this with the $image->render method, though. Can you confirm if this is the intended behaviour?

@nbcommunication Thanks for the hint. I think there indeed lies my problem. Let me try to explain: I am using the size method to crop images to use the aspect ratio / format that I need for my layout (for example a hero slider uses a 16:9 image ratio). The $imgFormat value in that case would look like this: 'title-img' => [ 'width' => 2550, 'height' => 1440 ] <?php echo $image->size('title-img')->srcset() ?> So then the PageImage module takes this image to create variations based on the set rules in my module settings: 640 1024 1500 1920 2550 So there exists a 2550px version of the image (created by the size method) but I have to include this width in the size set rules, otherwise only the image variations up to 1920px will be used in the srcset attribute in the DOM. And this might be the problem: When adding the 2550px rule the cropped 2550px wide jpg image is used int the srcset attribute and not the wepb version (all other image sizes use the webp version, they just weren't created yet - instead queued - when I testet it lately). So to make it finally work for my case I have to crop the image larger than used in the srcset. For example 3000px wide. In that case the 2550px webp version is generated and used correctly together will the other sizes from the set rules in webp format.

Hi @nbcommunication Yes, my markup for outputting images looks like this: <img srcset="<?php echo $image->size($imgFormat)->srcset() ?>" src="data:image/svg+xml;charset=utf-8,%3Csvg xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg' viewBox%3D'0 0 <?=$config->imageSizes[$imgFormat]['width']?> <?=$config->imageSizes[$imgFormat]['height']?>'%2F%3E" sizes="auto" alt="<?= $image->description; ?>" uk-cover loading="<?= $key == 0 ? 'eager' : 'lazy' ?>" /> I am passing no arguments or options to the method call: <?php echo $image->size($imgFormat)->srcset() ?> I can confirm that all webp image variations are generated correctly by looking into the image folders. These image are 50% of the jpg size so the module should load those images instead the jpg ones per default? When inspecting the DOM the image srcset attribute looks like this (only one webp image is used) <img srcset="/site/assets/files/1264/startbild_architektur.640x412-srcset.jpg 640w, /site/assets/files/1264/startbild_architektur.1024x659-srcset.jpg 1024w, /site/assets/files/1264/startbild_architektur.1500x966-srcset.webp 1500w, /site/assets/files/1264/startbild_architektur.1920x1236-srcset.jpg 1920w, /site/assets/files/1264/startbild_architektur.2500x1610-srcset.jpg 2500w" src="data:image/svg+xml;charset=utf-8,%3Csvg xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg' viewBox%3D'0 0 2550 1642'%2F%3E" sizes="auto" alt="" uk-cover="">

Thanks again! It seems that one or two things are still not working correctly. First the webp image quality setting is still not applied. However the created webp versions have roundabout 50% of the original JPG image size and still look excellent so I don't bother about that. Another problem is that the srcset() method now outputs JPG image paths exclusively (in each case), even when there are webp images available that are way smaller than the JPG versions (Enable webp images ist set to "yes" in the backend). Does this has to do with the latest changes? <img srcset="/site/assets/files/1264/startbild_architektur.640x412-srcset.jpg 640w, /site/assets/files/1264/startbild_architektur.1024x659-srcset.jpg 1024w, /site/assets/files/1264/startbild_architektur.1500x966-srcset.webp 1500w, /site/assets/files/1264/startbild_architektur.1920x1236-srcset.jpg 1920w, /site/assets/files/1264/startbild_architektur.2500x1610-srcset.jpg 2500w" src="data:image/svg+xml;charset=utf-8,%3Csvg xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg' viewBox%3D'0 0 2550 1642'%2F%3E" sizes="auto" alt="" uk-cover="">

Thank your for the quick fix! I am not using the <picture> element, instead I am outputting images like this: <img srcset="<?php echo $image->size($imgFormat)->srcset() ?>" I played around with the quality settings but it still does not affect the generated webp images at all.

@nbcommunication I have a question about the webp quality value in the module settings. I was experimenting to find a good compromise between file-size and quality but it seems that (in my case?) the quality setting has no influence on the output quality of the generated images at al. The webp versions of the images are even slightly larger in size than the jpgs (???) Even when set the webp quality to 10% in the module settings the image still have larger file sizes than the jpg versions.

Thanks. Looking into the DOM tells me that the background image is missing for the slide: <div class="carousel-thumb js-slide slick-slide slick-current slick-active" style="background-image: url(&quot;&quot;);background-size: cover;width: 1836px;position: relative;left: 0px;top: 0px;z-index: 999;opacity: 1;height: 620px;" data-slick-index="0" aria-hidden="false" tabindex="-1" role="option" aria-describedby="slick-slide00"> </div>

@Bia is this a ProcessWire-Releated question or does a third party plugin like Owl Carousel or the Slider Component from the UIKit frontend framework not work properly? If possible please provide a link to this page, based on the image and the description it is impossible to help. There could be many different reasons the slider is showing white spaces like: - missing stylesheets - incorrect image paths - initialization errors (on the java script side) - Markup errors - etc. etc.

Live Reload should be enabled by default, if you activate rockdevtools in the config file. That's basically all you need to do. It can be customized, too: https://www.baumrock.com/en/processwire/modules/rockdevtools/docs/livereload/

This does not help either 😞 I have the feeling this in in my case a somehow cache-related problem (if that is even possible?) after tinkering with the namespace (and removing it again) in the _init.php and the included _func.php it is working now. Even without the namespace (?).

I have the module installed.

Hi @bernhard i have a question about porting old projects that used the asset bundling and minification from RockFrontend the new method in RockDevTools. My problem is that i get this error message on every project, after installing RockDevTools and trying to merge and minify my assets in my _init.php: Error Call to undefined function rockdevtools() My _initp.php looks like this: <?php /** * Initialization file for template files * * This file is automatically included as a result of $config->prependTemplateFile * option specified in your /site/config.php. * * You can initialize anything you want to here. In the case of this beginner profile, * we are using it just to include another file with shared functions. * */ include_once("./_func.php"); // include our shared functions if ($config->rockdevtools) { $devtools = rockdevtools(); // force recreating of minified files on every request //$devtools->debug = true; // parse all less files to css $devtools->assets() ->less() ->add('/site/templates/styles/less/uikit/_custom-import.less') ->add('/site/templates/styles/less/project/*.less') ->add('/site/templates/styles/less/custom/*.less') ->add('/site/templates/RockPageBuilder/**.less') ->add('/site/templates/RockPageBuilder/*.less') ->save('/site/templates/styles/styles.css'); // merge and minify css files $devtools->assets() ->css() ->add('/site/templates/styles/styles.css') ->save('/site/templates/styles/styles.min.css'); // merge and minify JS files $devtools->assets() ->js() ->add('/site/templates/uikit/dist/js/uikit.min.js') ->add('/site/templates/uikit/dist/js/uikit-icons.min.js') ->add('/site/templates/scripts/main.js') ->save('/site/templates/scripts/scripts.min.js'); }

@bernhard I am thinking of switching back to SCSS from LESS as it seems more popular and many components (or libraries) come with default SCSS stylesheets instead of LESS. What is really convenient about the RPB is that it auto-creates the LESS file with a prepopulated CSS class selector that matches the block class: .rpb-myblock { } This is a big time saver IMHO. So when choosing SCSS instead of LESS in the RPB settings this would offer a nice alternative.