adrian

Another heads up for folks. It's not a PW bug but maybe could be considered a deprecation. I started getting this error: # ProcessWire\\WireException: Unknown column name(s) for findRaw: date_format.id in /wire/core/Pages/PagesRaw/PagesRaw.php:1816 ```php 1813 | protected function unknownFieldsException(array $fieldNames, $context = '') { 1814 | if($context) $context = " $context"; 1815 | $s = "Unknown$context name(s) for findRaw: " . implode(', ', $fieldNames); ► 1816 | throw new WireException($s); 1817 | } 1818 | } ``` The issue is that I had a table field (date_format) and a findRaw() that tried to load this array of fields: ['id','format','countries'] However table fields have no "id" field. In previous versions of PW this was silently ignored, but now the refactor of PagesRaw into wire/core/Pages/PagesRaw/ added strict column validation in findCustomField(), resulting in that exception. Hope that helps someone!

Just a heads up for everyone - the latest release of RepeaterMatrix v14 will result in a 500 internal server error on PW v3.0.257. It works fine on v3.0.261 but I haven't narrowed down the min required version. Be sure to test thoroughly on dev first before upgrading.

Thanks @ryan - so the "page content" part is my concern but I am assuming that so long as we only add the PE field to pages that have publicly available content (frontend viewable) then it should be safe because it won't be able to read the page content from the "entire site" as per your initial post. I know I probably sound pedantic here, but I think this distinction is VERY important.

I wasn't talking about it maliciously scanning for training data. My concern was based on your comment about it coming "with full knowledge and expertise of your entire site, built in". I was concerned that you were explicitly telling it to read the entire the database so it knows all the content powering the site. Can you clarify what that statement actually means? It's the fact that it appear twice that bothers me - once at the very top of the page and then again above the PE field. Why is it needed twice? It just seems very noisy.

Do we need the: "Done! I've added a summary to the page about why ........... Here's what was written:" twice? Once in the banner and once above the engineer field?

You need to make your AI agents remember this one: Deprecated: Function curl_close() is deprecated since 8.5, as it has no effect since PHP 8.0 in .../pwtest.test/site/modules/AgentTools/AgentToolsEngineer.php:1174

Thanks @ryan - I am less worried about users abusing it (although still something to be aware of and I appreciate the snitch feature). I was mostly worried about it being able to read data from content that is either intellectual property or private user submitted data and process that on the AI service's infrastructure - we know how they are built on data scraped from the web, so I want to make sure our data (the stuff that is not publicly available on our sites) is not available to it. It sounds like so long as it's limited to templates with publicly viewable content then it is safe.

This sounds very cool, but I wonder if you can allay some concerns I have. Does that mean it can read any content from any field on any template/page in the site? I am just worried about it accessing and processing private data. Or does it only have access to field/template/page structure and not actual field data?

Hi @RuiVP - The listing of adminer-4.8.1-mysql.php indicates that you were running a version of Tracy that was at least two years old. The was an old unmaintained version of Adminer. We now use AdminNeo which is actively maintained. Side note: Adminer is also being maintained again after a very long hiatus, but I prefer the AdminNeo fork (the author and the product). That said, some shared hosts will always falsely flag tools that can manipulate the DB. They don't take into consideration that the tool is gated and only available to authorized users. I leave Tracy installed on all sites - in production mode it logs errors and full bluescreen traces as HTML files you can view. It can also email (or notify via Slack) of these errors so you get instant notification of issues.

I've just updated the AdminNeo core and included two new plugins: GeminiSqlPlugin and OpenWebUiPlugin for inline prompt based SQL command generation. I haven't tested the OpenWebUiPlugin one, so if anyone has any problems with it, please let me know.

I hope no-one minds, but I have removed dai() and bdai() in favour of adding a "copy as plain text for AI agent" button for the regular d() and bd() calls. which will put the following in your clipboard. Call: d($page); Location: site/assets/cache/TracyDebugger/consoleCode_1778105690621_f3xspie7xg.php:2 ProcessWire\Page #246 instanceID: 10 id: 3 name: 'page' path: '/admin/page/' status: 'locked, system' template: 'admin' parent: '/admin/' numChildren: 10 sort: 0 sortfield: 'sort' created: '2025-12-06 18:34:42 (5 months ago)' modified: '2025-12-06 18:34:42 (5 months ago)' published: '2025-12-07 12:34:42 (5 months ago)' createdUser: 'ajones' modifiedUser: 'ajones' isLoaded: 1 outputFormatting: 1 hooks: array (17) | '->render' => array (2) | | 0 => 'TracyDebugger->logRequests() in TracyDebugger.module.php' | | 1 => 'anonymous function() in TracyDebugger.module.php (100.1)' | 'Page::getRequestData' => 'TracyDebugger->getRequestData() in TracyDebugger.module.php' | 'Page::logRequests' => 'TracyDebugger->logRequests() in TracyDebugger.module.php' | 'Page::editable' => 'PagePermissions->editable() in PagePermissions.module' | 'Page::publishable' => 'PagePermissions->publishable() in PagePermissions.module' | 'Page::viewable' => 'PagePermissions->viewable() in PagePermissions.module' | 'Page::listable' => 'PagePermissions->listable() in PagePermissions.module' | 'Page::deleteable' => 'PagePermissions->deleteable() in PagePermissions.module' | 'Page::deletable' => 'PagePermissions->deleteable() in PagePermissions.module' | 'Page::trashable' => 'PagePermissions->trashable() in PagePermissions.module' | 'Page::restorable' => 'PagePermissions->restorable() in PagePermissions.module' | 'Page::addable' => 'PagePermissions->addable() in PagePermissions.module' | 'Page::moveable' => 'PagePermissions->moveable() in PagePermissions.module' | 'Page::sortable' => 'PagePermissions->sortable() in PagePermissions.module' | 'Page::cloneable' => 'PagePermissions->cloneable() in PagePermissions.module' | 'after Page::render' => 'anonymous function() in FrontendMatrixEdit.module.php' | 'before Wire::trackException' => 'anonymous function() in TracyDebugger.module.php' data: array (2) | 'title' => 'Pages' | 'process' => 'ProcessPageList' I feel like this is the best of both worlds.

But all you have to do is click the ProcesWire Core (Dev) link in the first column and it will upgrade to the latest commit anyway.

Ok glad Tracy is fixed, but I would strongly advise against using PHP 8.0 - no security updates isn't worth it. Just report the issues to those module authors and deal with the deprecation warnings until they are fixed (or fix them yourself locally in the meantime).

Did my commit yesterday (https://github.com/adrianbj/TracyDebugger/commit/b1f784a669f24b8b7409d192c7e4659ca1b0618f) not fix this? You will see some deprecations in other modules, but that's just part of the process - please report these to the module authors.

8.2 is also past its end of life and isn't getting bug fixes anymore. Just go to at least 8.4, if not 8.5. Did the very latest version of Tracy still have issues with 8.0? I fixed the last one you reported - did you see more errors?

I use it all the time to upgrade to the very latest core commits - it doesn't need a version number jump for me. I just wish the modules worked the same way.

Sorry, should be fixed in the latest version. That's another issue related to your old PHP version that I didn't account for. There have been a lot of changes recently and I just haven't tested on all version combinations. BTW - you really should be upgrading PHP - 8.0 hasn't had security updates in 2.5 years now.

Yep, I just released a new version to fix the issue you just reported. You can download with the PW Upgrade module, or via Github (https://github.com/adrianbj/TracyDebugger) or composer. The older versions are also available on Github under releases: https://github.com/adrianbj/TracyDebugger/releases

@Jonathan Lahijani - are you talking about the PW Upgrade module, or my old Toolkit module?

Sorry @RuiVP - looks like there was an issue with getNonce() helper in the version of the Tracy core you were using. Please update to the latest version which should fix things for you.

The Tracy core now supports some new AI agent tools: https://github.com/nette/tracy/releases/tag/v2.12.0 I have included this new version, but also extended it so there is now a new bluescreen panel with the Agent Markdown version for easy copying into your AI deity of choice. I also added a copy MD to clipboard button for those exception files generated by guest users (in production mode):

Hi @nbcommunication - I've actually set up my own report endpoint which logs to PW log files (csp-report and csp-report-only). I also ping via slack for any enforced violations. The only thing I still have in report-only mode now is "require-trusted-types-for". I have actually reported to a few open source projects I integrate about the changes to support "require-trusted-types-for" and they've actually been very responsive so I am hoping to be able to enforce this option very soon also. Note that I do exclude violations from browser plugins and the like, so my csp-report log is actually almost completely silent now. I do have separate policies for frontend vs PW admin which helps because PW still has various inline scripts and no nonce (yet). I am using Cloudfront but all my CSP and nonce logic is handled locally in my /site/init.php file - it's very different and much stricter than what I posted earlier above. I have Cloudfront enabled caching for all assets, but I am not using Procache for a variety of reasons, but performance with Cloudfront asset caching is a pretty good middle-ground.

@maximus - it hasn't been maintained in quite some time (and probably does need some work on some features), but https://github.com/adrianbj/ProcessModuleToolkit provides a way to upgrade all with one button click. Not suggesting your idea wouldn't be nice as well though.

I actually came across the need for this as well. @ryan - could we perhaps have: $page->isUrlHook In my case I have url segments enabled on the homepage and some logic to process them, but that logic can't tell if it's a urlsegment or a path created by a URL hook. I ended up with this for now: $urlHookSegments = []; $pathHooks = $wire->hooks->pathHooks ?? (new \ReflectionProperty($wire->hooks, 'pathHooks'))->getValue($wire->hooks); foreach ((array) $pathHooks as $hook) { $match = $hook['match'] ?? ''; if (preg_match('#^/([^/{(]+)#', $match, $m)) { $urlHookSegments[$m[1]] = true; } } if ($input->urlSegment1 && !isset($urlHookSegments[$input->urlSegment1])) {

There is nothing good about imperial 😜