gebeer

Wow, that was quick. Thanks. Will wait until it goes into main and then update through module interface.

Hi @bernhard, after we upgraded RockFrontend and Less to latest versions in a project, we got this error in the backend: This is caused by the call to $this->createAssets() call in RockIcons.module.php init() method. Further tracing it back, we found that the L1101 in RockFrontend.module.php is the cause. Changing $lessFile = $this->getFile($lessFile); to $lessFile = $this->getFile($lessFile, true); fixes it. The getFile method has default false for $forcePath and returns an empty string when $forcePath is set to false which causes L1102 to throw a WireException. and ultimately leads to the error message from wire/core/ModulesLoader.php around L167. When passing $forcePath = true, the correct file path is returned. We checked and in our setup the createAssets method in RockIcons.module.php is the only caller of the lessToCss method in RockFrontend. This might be related to your refactor of RockFrontend/RockDevTools. While it is only happening when logged in as superuser, it still is troublesome because the error in the backend never goes away and icons don't display in the frontend. Frontend is still functional when not logged in as superuser.

You could do that with RockMigrations $rm->installModule('SessionHandlerDB'). Add it to the migration file on every site. Don't even need to spin up. Will be applied next time you login as superuser. That should suffice :-)

Yes, you can. The project files live on the Linux host machine (your Omarchy setup). They are being mounted to the ddev containers as docker volumes. The Docker daemon follows all symlinks to their real locations. So you can have a similar setup as on your current Ubuntu server. Kind of, yes :-) Depends on how juicy your new machine is. ddev spins up a few docker containers for each project. The more projects you have running the more containers need to be started. I have never started more than 3 projects at the same time. So can't really tell what happens if you spin up 10 or more. Are you working on multiple projects at the same time daily, do you really need them to be available at the same time? project startup is quite fast. So there's no need to have them all running all the time. You can manage them through docker desktop or Vscode extension or CLI, of course. All ddev projects are managed through one ddev-router container (Traefik) which acts as reverse proxy for http/s calls. So if you have multiple projects running, they can access each other through http. Just do it man. You won't regret. Linux has plenty of file explorers to choose from, you can find a decent replacement for XYplorer for sure. I live in Thunar. It has a plethora of plugins (batch rename etc) and is very customizable. As for Omarchy, it is a very opinionated setup but should give you a great starting point. I moved to tiling WMs some years ago and now wouldn't want to miss them. It's just so much more organized. I know exactly which application lives on what workspace and can switch in a blink of a keystroke. Who the heck needs frickin floating windows, why were they even invented?

Ryan, thank you for clarifying. This totally makes sense now :-)

Hi @ryan, maybe I'm misreading this. But actually you would want bots to collect training data for PW, especially for the API reference part. This website does not publish content that is protected IP. It offers information that aims to attract developers and decision makers to use PW for their business. IMHO, blocking these bots is contra-productive. You are cutting yourself off from a growing number of developers that build projects with AI tools to boost their productivity. In the near future we probably will not be able to compete if we do not use these tools. The more accurate training data and context these AI assistants have for PW, the better they can perform and produce actually usable, production ready code. I would give the current approach of blocking these bots a second thought.

Thank you. Already got that one :-)

Thanks. I did that and then got this: After 2 Module refreshes that was sorted. But the rockpagebuilder_blocks field Fieldtype changed to text and I had to set it back to RockPageBuilder. Fortunately there was no data loss for existing blocks :-) In 6.x there must be some breaking changes, I remember. But I can't find documentation or upgrade instructions in the docs. Is that documented somewhere else?

Never had that folder. It was always RockFields. After module upgrade I have a .RockFields folder with the old version. But neither on install of RPB nor on upgrade a RockPageBuilder Folder was created.

Hi @bernhard, I just upgraded RPB from v5.x to latest 6.6.0. The custom thumbnails links are broken, even after a Modules Refresh. They have a wrong path .../modules/RockPageBuilder/... That path doen't exist and should be .../modules/RockFields/buttons..., I guess. Problem seems to be in RockFields/buttons/preview.php L5 After changing this to $url = wire()->config->urls->siteModules . 'RockFields/buttons/'; it is working

Hi @bernhard, on v6.9.0 if RM, with ProCache installed, the Cache Status setting does not migrate correctly. In the template migration file (using config migrations), we have '_cache_status' => '2' was copied from the GUI with shift+click. also value as int 2 is not working. However, when doing a migration, the Cache Status is set to Enabled (template cache) Is this a known limitation of RM? Or

That was quick. Thank you! I added a config checkbox in my Site.module to toggle behavior and added this to the hook function: /** * Switch LiveReload for backend based on module setting * @param HookEvent $event */ public function switchLiveReloadBackend(HookEvent $event) { $page = $event->arguments(0); $enable = $this->wire->config->isDev && (bool) $this->liveReloadBackend; if ($page->template == 'admin') $event->return = $enable; }

Hi @bernhard, is it possible to enable livereload only for frontend, like it used to be in RockFrontend? I think there was a switch in the GUI to enable it for backend. Now we only have the $config->rockdevtools = true; setting. Do we need to hook somewhere (maybe Page::render) to set it to false if template == admin, or something like this? Where to place the hook? I see in bot RockDevTools class and LiveReload class the check for the config value is in the constructor. So we would have to hook before the RockDevTools module is loaded, right? Or is there an easy solution, that I overlooked? The docs don't mention anything. Having reload in the backend can sometimes be annoying, e.g. when working on migrations and saving a file with unfinished migration or copying an existing migration file for reuse etc. Some control here would be much appreciated.

Thank you all for clarification. I am doing some tests atm with phpDocumentor to see if it can give decent results. Guess the PWDOC parser is custom magic inside https://processwire.com/store/pro-dev-tools/api-explorer/ Let's see if we can do without or reengineer it...

Actually, Context7 was what made me start this thread. Someone has already submitted the PW repo to their scraper. But the resulting snippets are mostly garbage: https://context7.com/processwire/processwire Now why is that? They do not scrape the very well documented PHP source files. If docs were in markdown, they would. I tried the MCP and it didn't have context for simple things like WireHttp. Does anyone know what tooling is currently used to create the PW API docs, phpDocumentor, phpDox, ApiGen or something different?

Just to clarify: obviously, the public facing API docs will still be in HTML, like at https://gebeer.github.io/mkdocs-processwire/ But the underlying files are all neatly in markdown in a separate repo.

Hi all, I would like to propose a different format for https://processwire.com/api/ref/ The PW docs should be provided as markdown. Reasons: much easier to parse for machines easier to feed as context to AI assistants Most of popular modern frameworks / libraries (laravel, whole node ecosystem, etc.) have their docs in markdown nowadays. And I think it is exactly for the reasons mentioned. Me and also others here like @wbmnfktr are having a hard time providing meaningful context to AI assistants in IDEs like Cursor, Windsurf etc. Once those assistants have good context, they do an excellent job with PW specific code. But currently there is a lot of manual effort required to provide this context. ProcessWire would be more accessible to a wider range of users if development could be assisted by AI in an efficient way. I created markdown docs with python mkdocs at https://gebeer.github.io/mkdocs-processwire/ WARNING: this is in it's early stages and far from complete/perfect. It is merely for demonstration purposes atm and needs a lot of polish regarding structure, index pages for each class etc. I am using a separate local repo for scraping the API docs and parsing them to markdown. The whole process of scraping/parsing/deploying still involves manual steps (though those could be automated). And it needs to be repeated at least for every master release of PW. So I would prefer if @ryan could produce the API docs in markdown in the first place. Your feedback / opinions would be much appreciated. Cheers

I ran the migrations again through modules refresh on the server after deploying. But the template was not created. That was in the instance when I did the deployment for the first time. I haven't tried to reconstruct the situation by reverting to the previous DB stage and run migration again. Don't have the budget for that in that client project, unfortunately. Sorry, if this is not comforting you. But sometimes we have to act under budget/time constrains. Though if this occurs again, I will further investigate.

Thanks for all the info. I guess then that it was a hickup on the server. Nothing unusual in the migrations for that block. 'templates' => [ $this->getTplName() => [ 'fields' => [ 'title' => [ 'label' => 'Headline', ], 'questions' => [], // page ref field ], ], And this was the first time that this happened.

Hi @bernhard, I created a new block type `Questions` through the GUI. All files and template `rockpagebuilderblock-questions` were created in that process. When I deployed that to our staging server, the template for that block was not created. So I had to add that template `rockpagebuilderblock-questions` to my RockMigrations to make the block work on staging. Is this normal behavior? Is there an API method that I could use instead of the template migration? Couldn't find it in the docs. Fields for that block are managed through the migrate method in site/RockPageBuilder/blocks/Questions.php. So the template migration is somewhat redundant.

Reviving this for a slightly different use case. I need to serve a different templates folder based on a certain URL segment. My code goes in site/config.php. In there $input is not available yet. So the logic uses $_SERVER['REQUEST_URI'] /** * Switch ProcessWire templates directory based on the second URL segment. * Type the second URL segment as key and the name of the new templates folder as value. * Example: '/imaging/' maps to 'templates-magazine' folder. * We use the second segment because the first segment is always the language (en, de, etc.) */ $config->templateSegments = array( 'imaging' => 'templates-magazine', // first url segment => templates folder name // Add other segment => folder mappings here ); // Check the second URL segment directly from REQUEST_URI $requestUri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/'; $path = parse_url($requestUri, PHP_URL_PATH); $segments = explode('/', trim($path ?: '', '/')); $firstSegment = $segments[1] ?? null; if ($firstSegment && isset($config->templateSegments[$firstSegment])) { $folder = $config->templateSegments[$firstSegment]; $config->urls->templates = "/site/" . $folder . "/"; $config->paths->templates = $config->paths->site . $folder . "/"; } Works well. in site/init.php I have a ProcessPageView::execute hook so that PW can find the template file and offer the "View" link in the page edit screen in admin. $wire->addHookBefore("ProcessPageView::execute", function (HookEvent $event) { // set templates dir for magazine pages in admin /** @var Pages $pages */ $pages = wire()->pages; /** @var PagesRequest $request */ $request = $pages->request(); /** @var Page $page */ $page = $request->getPage(); $editPage = $pages->get(input()->get('id')); if($page->template == 'admin' && $editPage->template == 'magazine-page') { /** @var Config $config */ $config = wire()->config; $folder = 'templates-magazine'; $config->urls->templates = "/site/" . $folder . "/"; $config->paths->templates = $config->paths->site . $folder . "/"; } }); Not the most elegant implementation, but works. Could have put this in site/templates/admin.php but decided against for separation of concerns reasons.

This looks very promising. I will adapt that format with frontmatter usage. Only, I want AI to rephrase only when I tell it to. For smaller things there is really no need for rephrasing imo. Would you mind sharing those rules? Grok 3 is really good in my experience. I use it mostly in the web app for DeepResearch tasks.

Hello @horst, I am running PageImageManipulator02 for over 10 years now :-). We recently switched to PHP 8.3 and get following deprecation warnings: I am only using the module to get a low quality version for lazy loaded images (pixelation and smoothing): $imgLow = $img->pim2Load('lowq', true) ->setOptions(['quality' => 20]) ->pixelate(3) ->smooth(255) ->pimSave(); Could I replace this functionality with native PW image manipulation API?

Sure: https://chromewebstore.google.com/detail/markdownload-markdown-web/pcmpcfapbekmbjjkdalcgopdkipoggdi?hl=en-GB

Yeah, Yifan has some great videos on the subject. And context is all that matters. Since LLMs nowadays support larger context windows, we can take advantage of that and pass quite a lot of docs for in-context learning. I have a docs folder in each project, mostly with markdown files that contain detailed requirements for a feature, documentation for obscure libraries etc. I then pass those to the assistant via the @files feature when needed. This makes a big difference in code quality. Haven't used PW-specific examples but will definitely try that out. So thanks for sharing this idea! I am using a Browser extension for downloading webpage content as markdown. It is quite fast and much cheaper than passing this in via @web to windsurf, which eats up lots of credits.