adrian

There were some changes to module settings and functionality so no guarantees on this I'm afraid. There were just too many bugs in the old version that I got beyond caring about ensuring backward compatibility and I was installing on a new site. I think you should test on a dev site first to see if it breaks anything before running on a production site.

I believe it is also fixed in: https://github.com/adrianbj/MarkupSEO/commits/various-fixes-enhancements As far as I know, this is the most improved version of the original module available - lots of bug fixes and improvements. That said, I am not maintaining it anymore, but if anyone wants to keep it going, I would start from that version. Otherwise, take a look at SEOMaestro.

@Robin S - I know you already know that your request has been done, but just letting everyone else know that the Restore functionality is now built into the interface's tab system. Hopefully everyone will find this a useful enhancement.

Ah - I just took a better look at the Tracy core and even though I don't see it documented anywhere, there is a $snooze time which means that after this time has expired, you'll get another email notification. The default is 2 days. Would it help you if this was configurable in the module settings? Regarding filtering of certain errors - would you want those kept out of the Tracy error logs completely, or just not receive an email about them, but still log them? Not sure if I can easily do this. You could of course change the log severity settings so that no warnings logged, but that's probably not what you want.

@Macrura - it will only email one error of any type until the flag is cleared. This is Tracy core functionality, not something I added. I guess if you want an email every time there is an error, I could have the flag cleared on every page load so the behavior is overridden. The other possibility is hooking up error logging to send errors to Slack or similar, instead of email - probably a friendlier approach if you are getting lots per day. My question though, is why is ProCache giving so many errors?

Thanks for tracking it down Chris!

@dragan - new version won't enable email notification of errors unless both email "to" and "from" fields are set. I think this should sort out the discrepancies you are seeing.

Don't feel bad ? The warning should show up when an error has been logged in production mode and the "email-sent" file exists under /assetes/logs/tracy/ There are two ways to clear it - via the link in the warning, or by checking that "clear email sent" checkbox in the module settings. If you do the first one, and then try the other, there will be nothing to delete. Do you have the email fields filled out for getting emails about logged errors? Maybe I shouldn't show the warning if these aren't filled out because it isn't really relevant if you're not getting emails I suppose.

Thanks @dragan for finding the problem and providing the fix - much appreciated. I have committed a new version with the fix. PS - sorry about all the !important throughout that - it's quite a mess - it's difficult to override site frontend CSS as well as core Tracy CSS.

Ryan will review. In the meantime, you can access and edit it at: https://modules.processwire.com/modules/snip-wire/

I would go with double quotes and \n

Actually, the problem with the template file setup is handling multi-language version of the message body. I am thinking that perhaps I'll add a new collapsed fieldset to the module settings that has a field for each role (complete with multi-language support, as the current main "Email Body" field has). Any thoughts on this approach?

Hi @gerritvanaaken - please grab the latest version just committed and use: $u->emailMessage = 'My custom message'; Obviously you can wrap this in a conditional and define it differently for each required role. I think the idea of a template file could also be good and am certainly not against implementing it - this was just quicker to do for now ? Perhaps if you still want the file approach, you'd be willing to put together a PR?

@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.