adrian

Ben - I think the inputfield interface of this module is really nice so it does still have potential. This is obviously just my opinion, but I think the way the data is stored and searched needs an overhaul - it's got some real performance and flexibility problems. I think if someone was to update the way it stores the data and to properly incorporate the timezone enabled version of momentjs, it could be a really great tool, but as it is, I do think it's more trouble than it's worth.

You're dragging up some traumatic memories here ? I'll PM my version of the module that mostly works, but still has some limitations because the module uses the non-timezone enabled version of moment.js and it's using a really old version so when you go to update to a recent version and use the timezone enabled version, lots of other things break, etc, etc.

Sorry @ceberlin and @dragan - I probably need to add pagination to the "edit" mode, but don't have the time at the moment - if anyone want to tackle it, PRs greatly accepted ?

Hey @bernhard - these are the two settings that control this: https://github.com/adrianbj/TracyDebugger/blob/11582e03c22db697972a08dac0e01630b0dbcb79/includes/TD.php#L156-L157 I have hardcoded them to "1" so dumps are always collapsed, but I can certainly open them up for being modified. The normal way to do these sorts of tweaks with the Tracy core is to include those as part of the options array when calling the dump, but it's usually just too much typing and not worth the hassle, so need to come up with an easier way. No time to look into this today I'm afraid, but will do sometime soon. In the meantime, you can obviously change those for your current needs.

@MarkE - thanks for taking up the torch and trying to get some things fixed. Perhaps you could could get in touch with @Pete and get access to push changes to the main repo, or perhaps have the modules directory point to your forked version? Again, sorry I can't keep working on it, but I've never actually used it, so that makes it hard to justify the time, not to mention that I really don't know what is and isn't needed because I don't see the problems as they arise.

No, it's not in the directory. You should really take a look at @netcarver's awesome: https://pwgeeks.com/ - just type "cache" in there and you'll find some other cache related tools. Thanks for the rundown of differences - that will be really helpful.

Hi @MoritzLost - this looks great. I wonder if you could provide a quick summary of the differences with https://github.com/somatonic/ClearCacheAdmin Thanks again!

I'd install Tracy so you get a full debug trace so you can see what module is causing the issue with the setModuleConfigData() method. You could probably also just make sure all modules are up to date because I expect you're running an old version of a module where this has already been fixed.

@xportde - hi Thomas. Unfortunately with the way this module is built, it can only ever work for one branch. There are other ways to achieve what you are looking for - this thread (https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/) contains lots of useful info, but keep in mind there are lots of hooks you'll need to implement to ensure everything is locked down - it's one thing to hide part of the page tree, but you also need to hide the pages from the top-level nav under Pages > Tree. You also need to prevent direct edit access to pages outside the allowed branches. You may also want to consider modifying the breadcrumbs (like this module allows). Honestly I think it's a shame that the core doesn't support this natively.

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!