Didjee

@Robin S wow, this is really great! Thanks for spending your weekend hours on this update 😉

Hi @Robin S, Thanks a lot for this module! Exactly what I was looking for 😉 Version 0.0.8. of RepeaterMatrix introduced the 'insert before' and 'insert after' buttons. If I limit the use of matrix types to 1 item per type, it's still possible to add a new item via 'insert before' and 'insert after' (see screenshot below). Is it possible to prevent this?

@skeltern I think this solution of @horst solves your issue.

@horst Your adjustment of the webp() function fixes the issue! Thanks for diving into this!

Hi @horst, thanks for your code example, but unfortunately it still doesn't work as expected. See the attached screenshots below, both of the overview of generated variations in the backend. I made an 'extreme' cropping to show the difference with the original image. 1) The image variations before loading the template with your example code in frontend. I marked the cropped variation with a red border: 2) The image variations after loading the template with your example code in frontend. I marked the frontend-generated 900 pixel width variants with a red border. The JPG version is OK, but the WEBP version is not 🤔 Groeten terug uit Maastricht! 👋🏻

@horst I use the code below in my template to generate different sizes of a cropped image: <source type="image/webp" srcset="<?= $page->image->getCrop("default")->width(450)->webp->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->webp->url; ?> 2x"> <source type="image/jpeg" srcset="<?= $page->image->getCrop("default")->width(450)->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->url; ?> 2x"> After I re-crop the image in the backend the variations of the jpeg version are regenerated, but the variations of the webp version are not regenerated/showed in the frontend. Is there a way to overwrite the webp variants after the image is re-cropped? Deleting all variations in the backend before re-cropping the image doesn't solve this issue. See also this post (not related to CroppableImage)

Thanks Horst, that works! I need different sizes of the same crop to use in srcset for responsive images. I referred to this in your opening post:

The readme of the Github repo says: I use this to generate a smaller version of a crop (for mobile), but the image doesn't get resized: $page->image_main->getCrop("panorama", "width=640")->webp->url; Is resizing still not working as mentioned in the first post of this topic? Will it work in a future release of CAI4?

This module is exactly what i'm looking for! It works perfectly within a regular Textarea CKEditor field. Is it possible to get this module also working in a Textarea Rich Text (CKEditor) field within a ProFields: Table field?

Line 785 of ProcessJumplinks.module results in unexpected behaviour: $this->session->redirect($convertedWildcards, !($starts || $ends)); As soon as the start time of a jumplink is set (after the first hit), the redirect wil be 302 (temporary) even if the end date is empty/not set. I think only redirects with an end date should be temporary (302), otherwise permanent (301).

@Ryan: I did a fresh install using the dev branche of PW. I tested this locally using MAMP with PHP 5.3.29 / MySQL 5.5.38. I tested the following scenarios: Installed PW using the multi language profile without changing the admin name. Added a new language: no errors Installed PW using the multi language profile, changed the admin name from processwire to admin. Added a new language: no errors. Installed PW using the multi language profile, changed the admin name from processwire to sitemanager. Added a new language: getting the errors as posted earlier. Conclusion: I think this errors have something to do with the fact that the admin name is starting with site (as you already suggested here https://github.com/ryancramerdesign/ProcessWire/issues/764). It also has an effect on LanguageSupportPageNames.

@Adrian: manually adding the columns 'name1017' and 'status1017' to the 'pages' table solves the error, but I still can't see other page names than the default language (as mentioned here).

Same problem here, but I get the following error after adding an additional language: Error: Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'pages.name1017' in 'where clause' (in /var/www/vhosts/xxx/xxx/wire/core/DatabaseQuery.php line 91) My server is running PHP 5.3.10 / MySQL 5.5.38. I installed PW 2.5.3 using the 'Multi Language' profile. Additionally - I'm not sure if it's related to this issue - I can only see or edit the page name for the default language (as reported here with screenshots).

Hi, I installed PW 2.5.3 using the 'Multi Language' profile. The site works fine, but I can only see (or edit) the page name of the default language (English in this case). The page names for the other 2 languages are invisible or missing. All the necessary modules are installed. See sceenshots below. I didn't change anything in the setup or template files. Is this a (known) bug? My server is running PHP 5.3.10 / MySQL 5.5.38.

@Netcarver: I tried all possible solutions, but putting that extra line in .htaccess 'solves' the problem (at least it hides the error message). Within a week or 2 we are going to move the hosting account where the Xcache problem occurs (used for development) to a VPS. For the time being adding that line to .htaccess is fine. Thanks for your help!