Leaderboard

Most important to me is that I understand everything that goes into the core, and that means that AI is used for ideas and suggestions, but the code is still written by hand. And even then, the suggestions and ideas only end up in the core if they produce a measurable improvement. After testing and benchmarking, sometimes the ideas/suggestions result in an improvement, and just as often they do not. I do the same with pull requests. Coding and re-coding something is how I feel comfortable that I understand it. Perhaps too old-school but I don't think that will ever change. So long as I'm in charge of the core, I need that level of understanding with it. On another project I'm working on with a client (an add-on to their website), we're letting Claude handle the code entirely, with lots of instructions from us, but zero code from us. It's kind of a test and a learning experience, and the client initiated it. We don't know the details of the code, but we do know that the code works quite well. Though I had a peek at its code and found it to be quite solid. What's funny is that in this case, Claude is having me build web services it can pull data from. So I'm giving it instructions, but it's also giving me instructions. 🙂

Still using Seomaestro. Discovered a scenario where it missed pages in the sitemap that used urlsegments. In my case, it was the blog module authors page. It should also handle paginated pages but untested. Hope this helps.

The toughest challenge so far? Being our own client. Actually, the website we launched back then was just a placeholder, and the plan was to quickly replace it with a proper portfolio website. But as is often the case, it ended up taking a little longer than expected. A year later, we’ve finally done it: Our new website is live! https://konkat.studio/ The goal of the new website is to showcase our work and better communicate our services. The site is bilingual and was built using ProcessWire and PageGrid. More on that later. In addition to the website, we’ve also evolved our visual identity and logo. KONKAT (from concatenation) stands for linking individual elements into a functional whole. Our new branding makes this connection visible. In our case, we combine strategy, design, and technology into a unified process. The logo mark communicates this as well; as most of you probably know, the += operator in JavaScript joins elements and assigns the result. It took us some iterations to get the design right, but once the design was done, development was pretty straightforward. Most of the time was spent preparing the content for the projects, and that is also where PageGrid was super useful since it allowed us to design the layout and content of each project individually. Backend view: Managing project content and layouts with PageGrid. PageGrid also significantly sped up development, as we built all other pages using only its core blocks. For the projects overview, for instance, we used the datalist block to automatically generate the listing from our project pages, working perfectly out of the box without any custom logic. We also added some custom code where it made sense, e.g. the scroll animation on the homepage was just a bit easier to achieve with custom code (it uses native CSS sticky). Backend view: Using Pagegrid's inline editing to update some text on the english version auf our services page. Another great thing is that PageGrid takes care of lazy loading images and videos (using the famous lazysizes js plugin) and is caching its content automatically. As a result, we got a 100 on the Google Lighthouse test on desktop and 99 on mobile without any extra optimizations (we are not using Markup Cache or ProCache for this site). Backend view: Editing a thumbnail on the homepage If you have any further questions regarding our workflow or process, feel free to ask. I will do my best to answer them. Also, please let us know if you find any bugs, since the website is brand new, there are probably some we haven't caught yet! We also welcome any feedback you may have. Best, Jan & Diogo (KONKAT)

@jploch @diogo Awesome work, I love the new website!

This week on the dev branch we've got several commits with various core improvements and fixes. @adrian has been using Claude Code to suggest core optimizations (focused mostly on the PageFinder) and so he sent the suggestions to me. (PageFinder is the brains behind the $pages->find() method, and many others). I took the suggestions and coded them into our PageFinder, but didn't want to mess with what was already working well, so put them in a new class named PageFinder2, at least temporarily. If running the latest dev branch, you can enable PageFinder2 by adding the following to your /site/config.php: $config->PageFinder('version', 2); The most significant changes are: using subqueries for subselectors rather than separate independent queries; Reusing PageFinder instances (keeping a pool of typically 1-3 PageFinders rather than creating a new one for each $pages->find() operation); and lots of in_array() calls have been converted to isset() lookups, which should technically be faster (still the case in PHP8?, I'm not sure). There were some other changes as well. Theoretically these changes should make PageFinder even faster than it already is. I did quite a bit of testing and found that for the most part it performs the same as PageFinder v1. But then I came across a rather complex selector that translated to a much faster PageFinder operation, nearly twice as fast, and that convinced me it was worthwhile. While PageFinder v2 is not consistently faster than v1, there are some situations where it can be a lot faster. I'm not totally clear on what those situations are just yet, but I'll be doing more testing. In other situations it also can use a lot fewer queries, though that doesn't necessarily translate to a performance difference. But on the whole, all of Claude's suggestions were quite good, regardless of performance improvements. I was pretty impressed with what Claude Code had suggested, so decided to install it on my computer too. I've found it's particularly good at finding bugs. I'll ask it to do a code review on a core file, and it always has good suggestions. It uses ProcessWire terminology too. For instance it pointed me to an object that wasn't properly "wired to the ProcessWire instance", and that's something you'd only ever hear in ProcessWire land. Claude code also helped with improvements to our DatabaseQuery* classes, PagesVersions module, Wire base class, NullPage class, and minor updates to the PagesLoader* classes. I'm not having it write any code just yet, but am having it suggest where improvements can be made. I like to code. I asked it how it knew so much about ProcessWire, and it said that it stays up-to-date with the forums, the website, API docs, and GitHub repo. Thanks to @adrian and @Jan V. for recommending it to me (Jan V. uses it to manage this webserver), I can see how it's going to be a big help to ProcessWire with its suggestions and ideas, I'm already learning a lot from it. And if you get a chance to try the updated PageFinder, please let me know how it works for you. Thanks for reading and have a great weekend!

@Peter Knight Thanks for the work on this, Peter. Gemini AI actually helped me realize that it should work seamlessly with my PhpStorm + Cline + z.ai setup as well. Since your module includes the local Node.js MCP script, I should just be able to point my local Cline instance to that file via its MCP settings, and it will handle the sync workflow right inside PhpStorm. Looking forward to the release!

Hi everyone – very infrequent poster here, and also a long-time PW user in my web development career, for which I am deeply appreciative. Like @Ex-user, I have a lot of intense skepticism about AI, not only because of the environmental consequences being referred to, but also the invisibilized human costs in training these algorithms, as well as the risk of impacting critical thinking skills. I bristle at the way it's being coercively marketed as the inevitable answer to every human problem. That being said, I, like everyone else, recognize I have a career because of the many visible and hidden costs of digital technologies. That neither means I am "pure" or exempt from the hidden costs, nor does it mean I accept everything without pause. I think we all are attempting to make the best decisions for ourselves and consideration for others, and this may be expressed in differing ways when it comes to AI usage. For me, the primary issue with using AI is the matter of trust and accountability – what person is bearing responsibility for the work it produces or choices it makes? If PW's codebase adopts any changes suggested by AI, my hope would be that it undergoes the same level of testing and scrutiny as any other code revision, and it seems like Ryan is doing just that. If I have any say as a PW user in how AI is adopted into the main codebase, my hope would be that it's a transparent, auditable process, and (somewhat idealistically, from my own personal, ethical position) continues to be opt-in.

Hey @gebeer Yes, it's pretty wild and fun to watch sites being built by AI. Frightening too obviously ! I created an entire blog last week without touching the admin. Templates, fields, test content, pages etc created in about 5 mins. And 4 minutes of that were typing my instructions. But you could always save it as a 'recipe' and reuse it. No worries. I don't mind questions. 🙂 Yep, the JSON schema approach is a wrapper around the PW fields and templates API. It can create/update fields (type, label, description, inputfield settings) and templates (fields, family settings like allowChildren, urlSegments, etc.). Re. roles/permissions or module install/uninstall, I didn't need those. My workflow is quite simple, thankfully and doesn't involve clients updating their sites. I haven't used RockMigrations, but knowing Bernard's reputation, I imagine RockMigrations is significantly more comprehensive in that regard. Regarding the question about AppAPI Vs HTTP API, I had to ask the robots about that one and the reply is comprehensive but possibly not what you were asking. See below, but you're probably already familiar with the AppAPI stuff. BTW the Module isn't commercial, and anyone can try it. I want to clean up the repo before opening it up for wider use. Is the above any help to you? Did it answer your questions?

Hi folks, I just released version 1.1.1 which fixes the PHP 8.1 related errors from this issue: https://github.com/wanze/SeoMaestro/issues/41 These issues have been fixed by merging a pull request. I appreciate if the community can help me out, as I am quite disconnected from the ProcessWire world (as you might have noticed). However, I still want to support this module with bugfix releases. Cheers