adrian

Ah yes OK - sorry about that @Robin S - I thought I was making things better by embedding it within the PW admin so it has the header menu etc. While I think about it, you can for now simply load /setup/adminer-renderer/ instead and you'll get what you're looking for. You can even unhide that page and hide the other one if you want. It's funny really - now that the "Edit in Adminer" links open the panel version, I never use the standalone one at all, but I can understand why you might prefer it still, especially for the query string reloading.

Just a note to say that I've added a new Page Meta section to the Request Info panel. This displays all meta entries for the page, along with links to open the entries for editing directly in Adminer. Speaking of Adminer - it was recently updated to AdminerEvo and I changed the way links from Tracy to open Adminer work - they now open the bar panel version which I believe is a much nicer experience than the standalone Adminer page. I also added links to edit the values of all fields within the Page Edit interface. If the field has multiple values, it will open Adminer showing all entries instead. This is of course optional, so you can visit the Adminer settings (now merged into Tracy's settings) to turn this off if you prefer. Please note that when you first upgrade, you will likely need to do a modules > refresh to get Adminer to load properly the first time.

I am confused by your response - you can write a module to do it if you want, but the problem you had with those errors should now be fixed, so you should be able to use this module now.

Hi @virtualgadjo - sorry about that - should hopefully be fixed in the latest version.

@ottogal - I really don't know - it's not likely an issue with the perms set in config.php, but perhaps the module folders themselves. It might even be the "owner" being off, rather than the permissions, especially if you FTP'd things across initially. Anyway sounds like you have it sorted for now, so let's not worry too much about it.

Really great writeup @artfulrobot You might find that TracyDebugger helps with this to some degree - its "Processwire Logs" panel combines all logs into one ordered reverse chronologically. It also highlights when you have new errors / notices since you last viewed the site.

@Abe Cube - I know this is very old, but perhaps it will help someone else. I just had this same error and it turns out is was due to a mismatched class name and file name. I was testing something and my file was a typo: ProcessHiddenPageText.module.php while the class name was the correct ProcessHiddenPageTest.module.php As soon as I fixed the filename and did a modules refresh, everything worked as expected.

@Denis Schultz - new version of Tracy now uses AdminerEvo. Thanks again for letting me know about this new fork. Hopefully it has a long life. I had to tweak a few things so if anyone see any issues (should be mostly cosmetic hopefully), please let me know.

Hi @ottogal - not sure why that would happen. How did you update Tracy? I suppose you can't really tell anymore, but I wonder if the permissions for that folder were somehow preventing it from being writable by PHP. Anyway, updating is not something individual PW modules have any control over so certainly not an issue with Tracy per se. I shouldn't be related to the PHP version, but you do really need to get that updated - it was EOL'd 5 years ago so you've had no security updates in that time - I would think your host should be more worried about that than an old version of Adminer that was restricted to superuser access anyway - all module files in PW are restricted by htaccess. Thanks for the heads up @Denis Schultz - I hadn't seen that, but I'll definitely take a look and see what it would take to switch.

Tracy has included the updated version of Adminer since it was released almost 3 years ago now, so just update to the latest version and you'll be fine.

That said, I am not running on a multi-site setup so maybe that's the issue. Maybe it's due to a WireHttp call from one site to another? If you share that code, maybe I can test?

I tried that before, but I don't see anything being output in the console which is why I was hoping for a screenshot in case I wasn't understanding where you were seeing the echo'd output.

Sorry, I don't think I am understanding what you are seeing. Can you please post the code that is causing the problem and a screenshot showing the echo'd code in the console?

Hi @hellomoto - that doesn't seem like an error that is caused by Tracy, but rather one that being presented by Tracy. Have you looked at the issue of the undefined $var error on line 21 of ready.php?

Nope, 18 was a brand new version (after your bug report). Sorry, I missed that line - I did get the one (and one other) from your initial report, but that was one I missed. The latest should hopefully be OK now.

@gRegor - thanks - should be fixed in the latest version. Note that PW's core might also suffer from this here: https://github.com/processwire/processwire/blob/3cc76cc886a49313b4bfb9a1a904bd88d11b7cb7/wire/core/WireInput.php#L991

Fantastic @Robin S - I hadn't been paying attention to AVIF browser support for a while, but it looks like we are finally good to go: https://caniuse.com/avif Just a minor thing but I just added AVIF support reporting in Tracy:

This functionality is now available in 3.0.236 and now seems to work with AJAX loaded repeaters as well.

@bernhard - how about as a title attribute like this when you hover the Tracy icon? This way it's available if you want it, but it doesn't affect anyone otherwise.

Hi @TomPich - the latest version allows blank default filters and hides the parent selector (I moved it from defaultSelector to initSelector).

You might find this useful: https://processwire.com/modules/page-rename-options/

If you're getting that message after clearing the flag, then it means there are more errors being logged. The whole idea is so you don't get multiple emails each time an error is logged, so once you fix the code that is causing the error, you clear the flag and it won't appear again until another error is logged and emailed to you. Make sense?

@tires - an addition to the regex on this line (https://github.com/adrianbj/GetVideoThumbs/blob/31a7fb443abd1b1cb9143840954f3f25d52d4fe5/ProcessGetVideoThumbs.module.php#L129) should be able to support it. If you want to give it a go and send me a PR, I'd be happy to include it. PS - that said, most of the videos on piped don't seem to play for me - some do, but it's pretty hit and miss, so maybe not a very stable service at the moment.

Thanks @bernhard - should be fixed in the latest version. It looks like at some point PW starting deleting the fieldgroup along with the template automatically, hence the new error.

It is weird to me seeing all those paths like "ProcessWire\UserPage.php" in amongst the other full correct paths. They are clearly not valid and will trigger errors for any open_basedir restrictions. So it does seem like a question for Ryan from what I can see.