adrian

@porl @tpr - I am not using latte, so can't easily test, but let me know if there is a change I can make to Tracy to help fix this.

Thanks @Robin S - lazy of me to not check the settings for that. Thank you!

@Robin S - what do you think about supporting the "List of fields to display in the Admin Page List" setting if it has been populated? Thanks!

Yeah, sorry about that - the Tracy core just uses PHP's mail() and I wasn't sure how to hook into the send process so I could implement wireMail - of course it turned out to be easy, but it wasn't documented so had to dig a little.

Another new version which takes care of an issue that has been lingering from the very first version 🙂 The option to send error messages to your email address when in Production mode now supports wireMail() so it will use whatever wireMail module you are using. There is also a new module setting for defining the "from email" address, as well as the old "to email" option. Remember that messages are only sent if the output mode in settings is set to Production and also note that you will only get one email - all subsequent errors will be logged in the Tracy logs files but won't be emailed until you clear the "sent email" flag. It's sure nice to have this working as a way to track errors that occur on a production site during regular use. Let me know if you find any problems.

@Ivan Gretsky and @szabesz - new version adds a new "Bar Position" module setting that lets you choose between bottom left and bottom right. Let me know if you notice any problems.

@Knubbi - did you manage to test that version?

Hi @Ivan Gretsky - the core Tracy package comes with the ability to drag the bar but I disabled it long ago because it was causing too many problems and I didn't really see many advantages. Perhaps you can solve the issue you are having with the "Starting z-index for panels" option in the module settings. If that doesn't work for you, let me know and we'll figure something else out.

Ok, so I decided to play around with writing a DOMDocument based approach which hooks into Page::render and replaces all: <img src="/site/assets/files/1234/image.png" alt="my image" class="my_image_classes"> with: <picture class="my_image_classes"> <source srcset="/site/assets/files/1234/image.png.webp" type="image/webp"> <img src="/site/assets/files/1234/image.png" alt="my image" class="my_image_classes"> </picture> Because it happens on page render, this approach works with images embedded into RTE fields, as well as those added via regular <img> tags in template files. It automatically copies classes from the original <img> tag to the picture tag. I still don't know whether this is the best approach or not, but so far so good 🙂

Thanks for your thoughts - I must admit I am a little behind in adopting webp, but it's time to get up to speed for sure. I would love to say that I could get clients to optimize before uploading, but it's just not going to happen for all of them and unfortunately they often upload images in the MBs in size, not KBs, so I definitely need to do compression of some sort. I see some sites where they are displaying thumbnails of images which are well over 1MB and even on my 150 Mbps connection, they still visibly load quite slowly so I think it's still important to consider this. Please also consider that in some countries (especially here in Canada), mobile data is stupidly expensive, so even if it's fast enough, it's eating into valuable monthly bandwidth if you're not on WiFi. Thanks for the suggestion of going with Strategy 3 for WebP - I am curious about images inserted into an RTE - do you use DOMDocument (or preg_replace) to scan for <img> tags and automatically wrap them in <picture> tags and add the <source srcset> tag or do you have another strategy for this? Thanks again!

Yes, I am using the "Optimize on Pageimage->url() [EXPERIMENTAL]" option - it's the only way that makes sense to me to actually use this module because I don't want to resize the original and I don't always do a size() or crop() call on images. I've commented that log line for now, but I am curious about your thoughts with webp - are you suggesting that if webp is implemented, then there is really no point using this module at all, or just don't use the experimental feature?

@matjazp - I think this is a relatively new thing - I have noticed that the autosmush.txt file is getting a LOT of "Unsupported extension svg" entries. I have an SVG logo in the header of the site, so every page load is triggering this. Just wondering if there could be an easy way to prevent these from being logged? Thanks.

@Typografics - would you mind doing a little debugging and see if the problem occurs with all the custom panels disabled? Also does uninstalling and reinstalling Tracy help?

@Typografics - I'd be curious to know if enabling Tracy again brings the problem back because I haven't heard of anything like this before, but would obviously like to fix it if there is a problem.

FYI - https://www.smh.com.au/business/companies/google-says-goodbye-to-the-cookie-monster-increasing-user-privacy-20200115-p53rj5.html