gebeer

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.

Thanks for sharing this. It is much more comprehensive then mine: # Project Guidelines ## Expert Knowledge - ProcessWire CMS PHP development - Tailwind / Flowbite markup and classes ## Core Technical Requirements - PHP 8.3+ - ProcessWire CMS - Tailwind CSS - ES6+ JavaScript - Webpack NPM/NPX ## Development Principles - PSR-12 and SOLID compliance - Type-safe PHP implementation - Defensive programming with early returns - DRY code organization - Exception handling with WireException - Logging via ProcessWire log() API ## ProcessWire Best Practices - API-first development approach - Markup regions for output processing - Strategic hook usage in site/ready.php and site/modules/Site.module.php - Input sanitization through PW API - CSRF protection implementation - Field/template migrations with RockMigrations - use of functions API preferred. (`pages()` instead of `$pages` etc.) ## Frontend Standards - Mobile-first Tailwind / Flowbite design - WCAG 2.1 accessibility compliance - Progressive enhancement strategy - Modern browser support (last 2 versions) - CSS custom properties Will definitely take some inspirations from yours. Judging from parts of your rules, it almost seems like you might have read https://neoexogenesis.com/posts/rust-windsurf-transformation/ :-)

Actually, my rule is quite different from aider architect mode where the architect agent plans and lays out the implementation steps on a higher level and then passes that to the coding agent. Love aider and am getting really great results with it, too. My prompt simply rephrases the original user prompt in more technical terms and most of the time more on the spot for the request at hand. Please let me know how it is working for you. Since the prompt is just a few days old, there might be room for improvement.

What is this about? When working with AI enhanced IDEs like Cursor or Windsurf, we often tend to give somewhat ambiguous requests like these exaggerated examples: or Much better wording for these examples would be AI tends to deliver much better results when we give it concise, technical instructions that fit the context. My approach I have tried to "automate" this in some ways with simple AI rules. Both Cursor and windsurf have a feature called AI rules where you can set global and project specific rules that the assistant will follow. This snippet is in my global rules: ## User Prompt Rephrasing Every time you encounter the exact keyword "rephrase" in a user prompt, do the following: 1. rephrase the user prompt in concise technical terms focusing on: - specific technical task scope - affected components/files - required functionality changes 2. preserve the users intent in the rephrased prompt 3. output the rephrased prompt and ask for confirmation with exact phrase "Act on the rephrased prompt? [y/n]" 4. IMPORTANT: after asking for confirmation, STOP and wait for explicit user response 5. proceed ONLY after receiving "y" confirmation, otherwise ask for clarification 6. when proceeding, act only on the rephrased prompt How it works Now, whenever I add "rephrase" to my prompt, the assistant will act accordingly. Example: Benefits The rephrased version offers several benefits over the original version: Component Clarity - Original was vague, rephrased version explicitly lists required components (GUI framework, drag-drop handler, PDF converter) Scope Definition - Clearly separates existing functionality (PDF conversion) from new requirements (GUI wrapper) Implementation Direction - Suggests specific technical approaches (tkinter/PyQt) while maintaining flexibility The AI assistant will perform better with the rephrased prompt because: More precise input leads to more precise output - technical specifications eliminate ambiguity about what to implement Breaking down into components helps the AI reason systematically about the solution architecture Explicit requirements (e.g., "single file processing") prevent the AI from making incorrect assumptions about scope Clear instructions to AI yield clear results. Or as the old saying goes: garbage in, garbage out :-) A bit of theory behind the concept The idea for a rule like that came to me when I heard about the concept of "Latent Space Activation" in Large Language Models. Very brief explanation from Claude: My rephrasing prompt supposedly has some impact on latent space activation. Claude again: Does it really work? I've been experimenting with this for several days now and my subjective impression is that I really get better results with this approach. Better, working code often on the first shot. Try it yourself Have a play and let me know if you get better results, too.

Hi there, I'm experiencing unexpected behavior with markup regions where multiple pw-append actions are being processed in reverse order. I have been using markup regions for several years in multiple projects and never came across this. There are no project specific potential causes for my problem that I could identify. Involved HTML markup syntax is correct. Setup Delayed output strategy with site/templates/_main.php (simplified): <html> <head> </head> <body> <main id="maincontent" class="content"> </main> </body> </html> site/templates/products.php: <div class="bg productsintrobg" pw-append="maincontent"> <!-- Products Intro Section --> <div class="container"> <!-- Products Intro Content --> </div> </div> <div class="bg productcatsbg" pw-append="maincontent"> <!-- Product Categories Section --> <div class="container"> <section class="productCats teasers row"> <!-- Product categories content --> </section> </div> </div> Expected Behavior Since products.php executes before _main.php and contains region actions (pw-append) that should be processed in order, the final output should show: Products Intro Section Product Categories Section Actual Behavior The sections are rendered in reverse order: Product Categories Section Products Intro Section Technical Context According to the Markup Regions documentation: Since products.php is processed before _main.php (using $config->appendTemplateFile = '_main.php'), the region actions in products.php are technically output "before" the <html> tag and region definitions in _main.php. Therefore, the implementation follows the documentation correctly, but the output order is reversed. Current Workaround Changed first section from pw-append to pw-prepend to achieve desired order: <div class="bg productsintrobg" pw-prepend="maincontent"> <!-- Products Intro Section --> </div> <div class="bg productcatsbg" pw-append="maincontent"> <!-- Product Categories Section --> </div> MarkupRegions Debug Output (shows wrong order of processing): • APPEND #maincontent with <div class="bg productcatsbg" ... +24 bytes><div class="container"> <section class="productCats teasers row"> … 14986 bytes</div> • APPEND #maincontent with <div class="bg productsintrobg... +26 bytes><div class="container"> <article class='intro row'> … 1264 bytes</div> • 0.0014 seconds Environment ProcessWire version: .3.0.243 PHP version: 8.1 (same behavior with 8.2) Has anyone experienced this before? Couldn't find related forum posts or github issues