Search the Community

Generates a .phpstorm.meta.php file for ProcessWire autocompletion in PhpStorm. Features Autocomplete wire container keys for wire('...') and Wire::wire('...') Autocomplete module names for Modules::get() and Modules::install() Autocomplete field names for Fields::get() Autocomplete template names for Templates::get() Autocomplete unique page names for Pages::get() Autocomplete hookable methods for Wire::addHook*() Autocomplete page status constants/strings for Page::status(), addStatus(), removeStatus(), hasStatus() Autocomplete field flags for Field::addFlag(), removeFlag(), hasFlag() Autocomplete template cache-expire constants for Template::cacheExpire() Autocomplete Inputfield collapsed constants for Inputfield::collapsed() Autocomplete sort flags for WireArray::sort()/sortFlags()/unique() and PageArray::sort()/sortFlags()/unique() Optional: Field type autocompletion per Page class (when enabled in module config) Usage Default path: site/assets/.phpstorm.meta.php (configurable in module settings). The file regenerates automatically when fields, templates, or modules change (debounced). You can manually regenerate from the module settings screen. Optional: enable "Generate page-class field metadata" in module settings for field type hints per Page class. This is intentionally basic. For richer field stubs, use AutoTemplateStubs. Examples Modules $tracy = $modules->get('TracyDebugger'); // Autocomplete + correct class type for navigation and code insight Wire Container $page = wire('page'); $pages = $this->wire('pages'); $cache = wire('cache'); // Autocomplete for keys like page/pages/cache/etc. Fields $body = $fields->get('body'); // Autocomplete field names, fewer typos Templates $tpl = $templates->get('basic-page'); // Autocomplete template names Pages $home = $pages->get('/'); // Maps to the page class when page classes are enabled Page Status $page->status(Page::statusHidden); $page->addStatus('draft'); $page->removeStatus(Page::statusUnpublished); $page->hasStatus('locked'); Field Flags $field->addFlag(Field::flagAutojoin); $field->removeFlag(Field::flagAccess); $field->hasFlag(Field::flagGlobal); Template Cache Expire $template->cacheExpire(Template::cacheExpireParents); Inputfield Collapsed $inputfield->collapsed(Inputfield::collapsedYesAjax); Sort Flags $items->sort('title', SORT_NATURAL | SORT_FLAG_CASE); $items->sortFlags(SORT_NATURAL); $items->unique(SORT_STRING); Page-Class Field Metadata (Optional) $home = $pages->get('/'); // $home is HomePage (page class) // Field types are inferred from the template fieldgroup // e.g. $home->hero_image -> Pageimage or Pageimages depending on field settings Hooks $wire->addHookAfter('Pages::save', function($event) { // Autocomplete hookable methods while typing the hook string }); Notes Hook scanning reads ProcessWire core, modules, and admin templates to build the hook list. If page classes are enabled, page names map to their page class; otherwise they map to Page. Improvement suggestions and PRs are welcome. https://github.com/phlppschrr/ProcessWirePhpStormMeta

That's weird. I simplified it down to the bare minimum as per the example, and still not working. I wonder if it's some strange third party module interaction? I don't a lot of modules beyond the core loaded, just these: I've tried disabling all autoload modules (other than core) via Tracy debugger, and the problem persists.

<?php namespace ProcessWire; if($config->ajax) { bd('AJAX request detected'); echo "Replaced page content"; exit(); } ?> <script> function loadlist(segment='') { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("main").innerHTML = this.responseText; } }; xhttp.open("GET", "<?=$page->url?>"+segment, true); xhttp.setRequestHeader("X-Requested-With", "XMLHttpRequest"); xhttp.send(); } </script> <div id="content"> <div id="main">Basic page content</div> <p><button onclick="loadlist('')">Load List</button></p> </div> Note the replacement of the text in "main" and that Tracy detects the AJAX request.

I enabled a site module extending a core module: class ProcessPageEditImageSelect_Pickpage extends ProcessPageEditImageSelect implements Module, ConfigurableModule { public static function getModuleinfo() { return [ 'title' => 'Page Edit Image pickfrompage', 'summary' => 'Extends core module: Enables specifying a default page to pick images from if the page being edited has no image fields.', 'autoload' => true, 'permission' => 'page-edit', ]; } public function __construct() { parent::__construct(); } public function init() { parent::init(); bd($this->data); } public function ___execute() {} public function getModuleConfigInputfields(array $data) { $inputfields = $this->wire(new InputfieldWrapper()); $modules = $this->wire()->modules; /** @var InputfieldPageListSelect $f */ $f = $modules->get('InputfieldPageListSelect'); $f->attr('name', 'defaultPage'); $f->attr('value', @$data['defaultPage']); $f->label = $this->_('Default page for images if no image fields'); $f->value = @$data['defaultPage']; $inputfields->add($f); /** @var InputfieldPageListSelect $f */ $f = $modules->get('InputfieldTextarea'); $f->attr('name', 'templateDefaultPage'); $f->attr('value', @$data['templateDefaultPage']); $f->label = $this->_('Default page by template for images if no image fields'); $f->notes = "1 pair of selectors `{template}:{page}` per line, e.g.,: `1:/home/`, or `home:1`, or `contact:template=home`"; $f->value = @$data['templateDefaultPage']; $inputfields->add($f); return $inputfields; } } where the execute method is the one here and the init method returns the core module's data but my execute method has no effect. What's wrong with how I'm doing it? Thank you On pages where it doesn't apply, there's an error notice from the init method of the core module: Modules: Failed to init module: ProcessPageEditImageSelect_Pickpage - No page specified but nothing shows (Tracy debugging) if not autoloaded, and ___execute has no effect either way.

JFTR: I did wipe the installation and re-installed with dev version 252 (instead of 253). With 252 there were no issues installing the latest Tracy directly from the Module Repo. So this topic can be considered 'closed', as it's definitely not a Tracy issue but a dev core issue.

Thanks wbmnfktr, I did move the files manually and installed Tracy, resulting in a different 500 error upon trying to configure it. I suspect this to be a dev core issue rather than module issue. This is a new installation, so I can easily wipe this and start new. Edit: I also installed an old version of Tracy - or tried. Same error. And that version definitely used to work.

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

@Jonathan Lahijani - not sure if this is what you are looking for, but all Tracy's settings can be overridden in config.php like: $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, ]; Not sure if those are the exact options you want, but hopefully that approach works for you.

@biberI am not the one you need to convince. It‘s your data and you can do with your database whatever you like. I was just puzzled by what you want to achieve or whats your problem is or if there is any at all. All still not very clear to me to be honest. What caught my attention was that I got the impression that you wanted to alter the text representation in the database, as the database values don‘t show up UTF8 chars but store German Umlauts in an encoded representation. Thats where my advice came from, not to alter or manipulate DB charset/collation manually, if text shows up correct in the frontend. Doing so will most likely corrupt your database and you need to go deep inside the rabbit hole to get charset/collation and data right. Of course you can modify, copy, rename or delete fields with PHPMyAdmin or from the Adminer module from the backend. Adminer is part of the Tracy Debugger module for example. However, for me it‘s just not clear, what you try to do and why it‘s necessary to do. If it‘s just for experiment, than I would just go with phpMyAdmin or Adminer and change some content and see what happens. By the way. I write most of my websites with plain HTML5, CSS3 and vanilla Javascript/Typescript and or PHP 8. Just for projects with multiple users or changing content, I prefer Processwire CMS/CMF which saves me a lot of work. However in those cases I rely on the PW core and API and only modify/dig deeper into the core or database if there is a real need for me to do so.

Got it working, thank you very much! 🙂 If anybody else if having trouble, here is how to do it: First, add this to your ddev config: web_environment: - TRACY_LOCALROOTPATH=$DDEV_APPROOT/ This will add the path of the project root as getenv('TRACY_LOCALROOTPATH') in the web container so that you don't have a hardcoded path in your config. Next add these mappings in init.php: \Tracy\Debugger::$editorMapping['/var/www/html/public/'] = getenv('TRACY_LOCALROOTPATH') . 'public/'; \Tracy\Debugger::$editorMapping['/var/www/html/src/'] = getenv('TRACY_LOCALROOTPATH') . 'src/';

Hey @Pete - I maintain four different Tracy core versions which are all included and used based on the version of PHP available. I have also made a real effort to ensure PHP 7 compatibility (maybe even 5 - not sure). A Tracy upgrade is basically instantaneous on all my servers/installs so I've never thought of the compiling process as an issue. Adding a namespace is probably more of a big deal with so many panels and reliance on the Tracy core itself - maybe just a matter of lots of backspaces to start loading things from the global namespace. The one other module I namespaced was AdminActions and it was a real challenge but that was mostly due to trying to support installed custom user actions whether they were namespaced or not. Still, it put me off namespacing others. I'll try to find some time to see what's involved sometime soon.

It's only after a TracyDebugger upgrade it struggles, so it downloads the zip via the ProcessWire Upgrade module but because there are a lot of files in TracyDebugger the FileCompiler takes a while to scan and times out or runs out of memory (I forget which but timeout seems more likely). Only happens during upgrade but times out because of the network chatter (for want of a better phrase) with the EFS mount. And then it doesn't complete the upgrade basically so you have to do it via CLI. The reason for EFS in a clustered setup is that nodes (servers) in an auto-scaling group come and go as you refresh things or as the instances increase/decrease automatically in number due to traffic demands, so having the sites on local EBS on one node doesn't work at all as they'd need to maintain their own copies of all files in sync for the sites on that cluster. So in this setup you put the sites on EFS (essentially a very fast network drive) so all nodes in the cluster have apache run sites from there and it's definitely more than fast enough for normal operations, just slow for things like FileCompiler when there are a lot of files to check when compiling a module. It checks them all whether they individually have a namespace or not as it has to decide which ones need compiling so TracyDebugger with this many files makes it try and do "too much" (a relative term, I know) in this setup. I like the idea with the backwards compatibility, but is there not stuff in newer versions of Tracy that isn't compatible with PW 2.x now anyway? I don't remember if PW 2.x even supported PHP 8 - probably not much beyond that anyway - so there may be some benefit to a version that only works with 3.x at some point. Just that usually adding the namespace to modules is relatively painless (though I've had some occasions where it was a little less straightforward I'll admit 😄) and then it's one less bit of overhead when keeping modules up to date. A selfish request to be sure, but maybe I'm not the only one? 😅

Hi Adrian, My search-foo is weak today so this may have been discussed to death but I couldn't find anything specific. Is there a reason why TracyDebugger module isn't in the ProcessWire namespace? The reason I ask is it compiles otherwise when file compiler is on - which for me is most of the time as there are modules I use that are not in a namespace (I am now religiously disabling template compilation though - just a few years late to the party on that one 😄). On an AWS setup where the site files are on an EFS mount Tracy is the one module that can take ages as it's a little slower to do this on a network drive. I've even had the updater module in ProcessWire fail to update Tracy and often just do it via CLI and it seems to be entirely down to PW having to compile the module. I realise AWS setups like this may still be a bit niche in this day and age but now, having mastered AWS pretty thoroughly (auto-scaling groups - my last bit I really needed to learn - are amazing!), I wouldn't go back. Feel free to point me to where this has already been discussed - as I say my searches returned bits and pieces around namespaces but not this exact thing. (Also I've been away from these forums for too long so if anyone else likes to geek out about AWS setups maybe we can have a chat somewhere on the forums or maybe there's already one I'm missing. I miss 2012-14(ish) where I was on here every day).

Random errors are the worst! 😉 If you have TracyDebugger installed already you might also want to look into the folder /site/assets/logs/tracy You might find some tracy bluescreen html files there which you could copy to your computer and open in a browser and see something like this: You can click on each item of the trace and you'll see where the problem occurred (top arrow) and also which arguments have been sent to the method (bottom arrow). Good luck 🤞

My debugging solution depends on the PW and PHP version I am one. In your case I would first try to upgrade the PW core with the latest version from the master or dev branch. For that I upload/copy latest wire/ folder with all files and subfolders to my site as wire.new/. Than I rename wire/ to wire.old/ and wire.new/ to wire/ and reload the page. Then I login to the backend and reload the admin and modules 2-3 times. Next I would check the logs and see if that already solved the issue. https://processwire.com/docs/start/install/upgrade/ If that doesn‘t solve the issues, I would install Tracy module and dive deeper into the issues. But before I do this, I always ensure I am on latest PW core with the recommended PHP version for the core version.

Hey @bernhard - you can put it anywhere (so long as Tracy is loaded, which basically excludes config.php, but it works in init.php, ready.php, etc. Or you could put it in any module file that is loaded everywhere. Another very simple test that adds "/test/" to the path and will work for all editor links. \Tracy\Debugger::$editorMapping['/site/templates/'] = '/site/templates/test/'; Can you share what values you've been trying to add to $editorMapping so I can maybe see why it's not working?

Hey @adrian, I came across a minor problem which prevents the Tracy console showing in the debug bar when bootstrapping PW in a standalone PHP script. The error shown is: ErrorException: foreach() argument must be of type array|object, null given in D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php:172 Stack trace: #0 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php(172): Tracy\Bar->Tracy\{closure}(2, 'foreach() argum...', 'D:\\laragon\\www\\...', 172) #1 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(143): ConsolePanel->getPanel() #2 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(115): Tracy\Bar->renderPanels('') #3 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(89): Tracy\Bar->renderPartial('main') #4 D:\laragon\www\[sitename]\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #5 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\Debugger.php(314): Tracy\DevelopmentStrategy->renderBar() #6 [internal function]: Tracy\Debugger::shutdownHandler() #7 {main} And this is what the debug bar looks like: I think it should be a simple fix - it looks like the line 172 is traversing $p->fields, but $p is a NullPage at this point. Kind regards, Ian.

Hey @bernhard - I am not sure if this works for all your needs, but you should be able to add to the array of path replacements whenever/wherever you want. For example: \Tracy\Debugger::$editorMapping['/assets/cache/Latte/latte-includes-foo.php'] = '/templates/latte/includes/foo.latte'; I feel like you could probably build out all the replacements you need by looping over the files in /assets/cache/Latte/ and replacing the path and filename as needed with some pretty simple logic. I feel like this should allow you to handle both scenarios in your recent PRs without changes to Tracy. Sound OK, or am I missing something?

@bernhard - thanks for the explanation of the Tracy being in the body issue - makes sense. As for the localStorage issue, maybe htmx is filling up localStorage then? Can you investigate what's in there to see why it's full?

Hey @adrian thx for your thoughts on this. With htmx you can add hx-boost to and dom element and htmx will convert all links in that element to ajax powered links that fetch the new page's data and then replace the content of the dom element instead of reloading the page. You could, for example, do this: <body hx-boost> and it would replace the whole body for you after clicking on a link. This would cause the tracy debug bar to disappear. That's why I did this: <body> <div hx-boost> ... </div> </body> Tracy injects the debug bar in the body, which means it can survive different swaps of the hx-boost content and shows new requests properly as ajax requests. This cannot be the issue. I have no tabs and I have a single d($page) call. If I find time I'll ask the folks at nette about it. Thx four your assessment!

@bernhard - I think the first issue might be something that should be fixed in the core Tracy project, but then I also don't know what you've had to do to "move the debug bar out of the swapped area" I don't think the second issue is related to htmx - sounds like maybe you have a lot of d() content stored - perhaps multiple console tabs? LocalStorage is usually limited to 5MB. I really need to move everything over to IndexedDB, but not sure when I'll be able to get to that.

Hey @adrian I'm using HTMX on my current project, specifically hx-boost which turns every regular link on the page into an ajax-powered link. It makes the request and then swaps out the content without a new page load. This is mostly great but sometimes introduces issues, for example the tracy debug bar needs to be out of the swapped area to stay on the page. I managed to do that and thought it was working well. The debug bar stays on the page and for each link that I click I get another AJAX entry in the debug bar, which is great 🙂 Today I realised that when I click the browser's back button I get this error and the debug bar disappears: tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34 Uncaught TypeError: Cannot read properties of null (reading 'Tracy') at new Panel (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34:31) at tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:453:30 at NodeList.forEach (<anonymous>) at Debug.loadAjax (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:451:48) at tool/?_tracy_bar=content-ajax.db1c54dcde_4&XDEBUG_SESSION_STOP=1&v=0.5514348022883848:1:13 Do you think this is something that can be accounted in Tracy Debugger? It's not critical, but a bit annoying. So if there is a simple solution for it I'd be thankful 🙂

You can apply any SQL you want by hooking into the PageFinder: $wire->addHookAfter("PageFinder::getQuery", function (HookEvent $event) { // get the DatabaseQuerySelect object $query = $event->return; // dump the object to tracy // https://i.imgur.com/BdDEQU3.png bdb($query); // modify the query to only find pages with name length < 5 $query->where("LENGTH(pages.name)<5"); // remove the hook after first execution $event->removeHook(null); }); bd($pages->find("id>0")); The idea is to add the hook directly above your $pages->find() call and inside the hook you remove it so that it does not apply to any other $pages->find() operations that might occur later. This is a DatabaseQuerySelect object: And with that object you can add any custom ->where() or ->join() or whatever you need.

@snck That may be a gamble... I think I've seen some situations where DeepL responses aren't very descriptive beyond the HTTP code that they return which can be frustrating. Unfortunately when I test my API key (free) I'm getting translations successfully. In your case the only way to get "Translation rate limit exceeded" is if DeepL returns an HTTP 429 code so that is another message that Fluency is relaying to you from DeepL and not originating with anything in the module. Whether the HTTP 429 applies in your case, I don't know. You may want to check the API key type that you have and ensure that it is valid for making translation requests. If you would like to see what DeepL is responding with directly and you aren't afraid to dig into some code then you can dump the response at L252 in DeepLEngine.php. Because the translations are made via AJAX in ProcessWire, you'll have to use the developer tools in your browser to view the response after clicking the translate button for a field. If you're using Tracy then adding bd() is the best way to see the result in your browser. Sorry I can't be of more help, there have been some instances in this thread where people have had some hiccups with DeepL. It doesn't happen very often and when you find the cause/solution for your issue here it should be smooth sailing.

Hey @adrian that works! I added a pull request for that and also added another one to improve dumps when using latte. The problem here is that when using latte files and adding a {bd('whatever')} in those files tracy actually picks up the compiled cache file and not the source file: source: /site/templates/latte/includes/foo.latte cache: /site/assets/cache/Latte/latte-includes-foo.php The implementation is kinda hacky and uses rockfrontend's dom tools to parse the html content of the dumps panel and then rewrite it to my needs. I didn't find a better option to modify what tracy puts in its bd() editorlinks output. If you know one let me know!