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.