adrian

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

@tires - sorry this module really isn't seeing much love these days. Pete is long gone and I have never needed to use it so it's hard for me to continue supporting it, especially given that it really needs a new mail library among other things. To get your site working again, I think you probably just need to delete the email with the arabic characters in the subject that is causing the problem. If that's not available, I think you should be ok. It probably shouldn't be too hard to fix the bug though either but we'd need to know what $message['headers']['subject'] is returning - actually, dumping $arr just after line 536 would be best.

Are you talking about PHP's "safe_mode" ? I am thinking not because it hasn't been available since php 5.4. Sorry is there another safe_mode setting I'm not thinking about?

Thanks @flydev ?? for your hard work on this. I installed on a Debian server and had a few issues which I have managed to fix. I submitted a bit of a messed up PR - I think we were both working at the same time. All my tests were in native mode 1) The server must have the "zip" package installed - mine didn't which caused me some grief for a while. I suggest looking for this and warning if not installed. 2) I had to change the mysqldump command quite a bit - you can see in the PR, but key things were --single-transaction and specifying the DB and removing the --skip-lock-tables 3) Had to chmod the .sh script to 744 so it was executable, but obviously this may not work on all servers depending on the owner etc. 4) Had to change the directory and the exec call to actually execute the .sh file - it was failing to run otherwise. With those changes everything seems to work great, although I did notice that after running a duplication via the Process module, it no longer reloads the page when done so you don't see the new package unless you manually reload when it's finished. Thanks again!

Hi @Knubbi - can you please test the attached version of that action? If it works as expected for you, I'll commit it to the module repo. FieldSetOrSearchAndReplace.action.php

Glad that worked but I expect it will likely come back for you so it would be good to figure out what the fix will be. Please keep an eye out for it again.

Thanks @rick - don't worry about those VSCode reported errors - it just doesn't know about those classes, but they work as expected. I think it's likely that you have some non-escaped character or a character encoding issue in your log files that is causing the problem. Could try a mb_convert_encoding() on $logLinesData before it is sent to WireCache on line 44. If that doesn't work, maybe instead try utf8_encode() or htmlentities() or something else along those lines. There is this old topic: but I don't think it will help us much here.

Hi @rick - I'm not sure why that would happen but it would be helpful if you could dump the content of $data before line 449 in WireCache.php so we can see what is being passed to json_encode so we can see why it might be failing. You could/should probably also check the value of $logLinesData before line 44 in ProcesswireLogsPanel.php Please let me know what you find out.

Thank you! FYI - after setting innodb_buffer_pool_size based on that calculation query, my duplicator cron failed so I almost feel like that made things worse. I am beginning to wonder if InnoDB just needs more resources than MyISAM and my VPS server just doesn't have enough oomph ?

Thanks for the detailed info. I must admit to being pretty new to InnoDB and actually I am glad you mentioned it, because the other site with the bigger DB which is having no problems at all is on MyISAM, so I guess that is the difference. I have already played with a few of those settings you mentioned, but nothing consistently helped. The only thing that seems to be working is the change to set PHP time limit and max execution time to both infinite. It's also really confusing that this is only an issue when run via cron - it makes me think there is a significant difference in PHP or MySQL settings. Obviously PHP has a CLI specific .ini file, but I don't think there is anything like that for my.cnf. Maybe Duplicator should look into using WireDatabaseBackup's exec mode: https://github.com/processwire/processwire/blob/321ea0eed3794c5f2b50c216b603fad3e7347ce6/wire/core/WireDatabaseBackup.php#L131-L133 - any thoughts on trying that? Regarding your suggestion of disabling Tracy - I have been thinking for a while about having an option to disable Tracy when php_sapi_name() shows the script is running from the CLI. I haven't added it yet, but certainly could, although I doubt that's the cause of this issue. I am going to keep monitoring the daily cron over the next week to see if it works every day with those set_time_limit(0); ini_set('memory_limit', '-1'); settings and if it does, at least that will tell us something ? Thanks again, Adrian

Thanks for the update @flydev ?? but please don't forget about the notice caused by the undefined $zipFilename on this line: https://github.com/flydev-fr/Duplicator/blob/475318d2893e07ab225c89d738efd59d06277546/Duplicator.module#L44

Ok, I'm getting there ? @flydev - there is still one more notice in 1.3.13 - line #44 should be: $this->log("Logging {$logName}\n"); $logName, rather than $zipFilename which isn't defined. Regarding the mysql gone away error, it seems that has been fixed by doing this: //DUP_Util::setMemoryLimit(self::DUP_PHP_MAX_MEMORY); //DUP_Util::setMaxExecutionTime(self::DUP_PHP_EXECUTION_TIME); set_time_limit(0); ini_set('memory_limit', '-1'); I know this is not ideal, but it's time to move on so will have to do for now.

Thanks @Autofahrn - that new version does fix those notices. Unfortunately I am getting MySQL gone away errors again when running via cronjob. I don't expect that is to do with the new version, but rather that it's a bit random and the tests after I changed the max_allowed_packet setting didn't actually fix it. The weird thing is that the error is being triggerd ~6 seconds into the duplicator process so it's not a timeout issue.

Thanks @Autofahrn but that is the version I am using. Sorry, I take that back - I am using 1.3.12. Where do I find 1.3.13?