All Activity

Interestingly if I try to open the frontend in Chrome, Firefox, or Zen now, it's still blocked, but it opens in Safari.

Thanks for the suggestion, but after deleting the module files and reinstalling them, I have access again for now. But still having issues with the ban duration. I set it to 2 minutes but I am still blocked out (this time just on the frontend). Note that I am logged in, but my admin is not at /processwire or /admin (in case that has any impact on the previous issue where I was actually locked out of the backend).

Hint (temporary solution), open Chrome browser or Safari, add keywords: Brave and Firefox to Allowed User-Agents (Bots Whitelist) section

Brave

Quick question: you are use Firefox?

Even after 60 mins I still can't get in and now even my backend admin is blocked. I ended up having to remove the module folder to get access again. What am I doing wrong?

Big thanks for this @maximus A couple of feature suggestions if I may :) Could you change the "Return 404 silently (stealth mode)" option to really be a stealth 404 error because at the moment it still returns the styled black Wirewall page with all its branding - it's just a change to the wording. Any chance of an option to disable the AJAX protection completely? And a confusion - I am logged into my admin, but in the same browser window I have still managed to trigger the rate limit (intentionally), but your docs state "First, all logged-in ProcessWire users are automatically whitelisted." but I am blocked and actually don't seem to be able to remove the block even after deleting the files in /assets/cache/WireWall - what am I missing?

Given RepeaterMatrix is based on Repeater there are no differences performance wise. Actually I did it exactly this way for a project before I purchased ProFields so there’s nothing wrong with that. It’s (mostly) about convenience.

Hi @kongondo Hope you don't mind me resurrecting this thread after so long. Using a repeater, I'm making a kind of section builder for a porfolio site. Using a radio toggle, it displays relevant layout fields to upload to for each section type. However they all use the same repeater. I'm wondering if there are any downsides or performance issues to including fields in a repeater, if they are not populated. My example only includes about 6 or 7 fields, with a project page using up a repeater about 5 or 6 times. Profields is out of my budget for this project right now, but I'm curious about any performance impacts my alternative may have. I've included screenshots of my repeater in the thread below.

Media Hub update The Media Hub now has folders (asset-level tags already working) Folders can be renamed to Gallery or Assets or Media etc by the user Media assets can exist in one or more Folders Clicking a Folder name applies a Filter On an Asset detail view you can quickly add and remove an association to a folder Support for Folder nesting, renaming etc

Thanks @monollonom I feel silly now 😅 I thought I had tried using values. I had used a round about way of getting the text values to work like an OR statement by elimination. I've updated to use numbers instead. Still not entirely sure why "section_type<=5" didnt work though. I've included what worked below in case other PW newcomers find it useful: heading section_type!=single_image, section_type!=two_images, section_type!=three_images, section_type!=txt_image, section_type!=image_txt section_type=6|7 text_area section_type!=single_image, section_type!=two_images, section_type!=three_images section_type=4|5|6|7 project_image_1 section_type!=txt_heading, section_type!=heading_txt section_type<=5 (doesn't work) section_type=1|2|3|4|5 project_image_2 section_type!=single_image, section_type!=txt_image, section_type!=image_txt, section_type!=heading_txt, section_type!=txt_heading section_type=2|3 project_image_3 section_type!=single_image, section_type!=two_images, section_type!=txt_image, section_type!=image_txt, section_type!=heading_txt, section_type!=txt_heading section_type=3 By the way, do you think using a large repeater in this way (like a mini page builder) is bad practice or performant enough? I know ProFields exists but I'm not sure how different this is performance wise

Worked on this the last couple days: https://github.com/elabx/processwire-mcp just tested it yesterday, so not a lot of usage.

You mean something like this?? https://cursor.com/docs/agent/browser I started doing this with Claude and it does catch the error screens and fixes the bug.

Try to reference the ID instead: section_type=6|7

Screenshots:

Incidentally, when you mention you reached limits of performance, where and how did those limits manifest? I ran your query / issue through my AI Agent and had the following response. The Real Diagnosis Your friend likely experienced real slowness, but the cause is almost certainly inefficient query patterns (loading too many pages at once, N+1 queries, unindexed searches) rather than a fundamental limitation of pages-as-assets. These are the same problems any ORM-based system hits at scale, and they have well-known solutions. What MediaHub Would Need for 100K Assets Problem Fix Effort Crops filter loads all crop pages Direct SQL: SELECT DISTINCT master_id Small N+1 crop count per listing Batch query or denormalized count field Small LIKE search on title/desc Add FULLTEXT indexes Small Tag dropdown loads all tags Already paginated or use autocomplete Small No query caching Add WireCache for expensive queries Medium Standard pagination at scale PW handles this natively with start= + limit= Already done Streaming large exports Use $pages->findMany() (lazy loading) Small None of these require rethinking the data model. They're standard database optimization work. Summary The page-per-asset architecture is sound and scalable. ProcessWire's page model with proper indexing handles 100K+ pages without issue. The current MediaHub implementation has a handful of query patterns that would need optimization (mostly the crop filter and N+1 counts), but these are straightforward fixes. Switching to a JSON-in-field approach would solve the wrong problem while creating a bespoke data layer that loses most of PW's value and introduces its own harder-to-fix scaling issues. //END What do you think of above

Hey David Thanks for that. I am planning another sprint next week. Right now, I am approaching this from a traditional image-as-page approach. Each crop variation of a 'master' image is also a separate page. That's possibly not as good for scalability but better from the point of view of having a new page image field listing all my images and crops. I dont have any sites with 10K + images so I'm happy enough with this solution but I will certainly reconsider and you've given me some other ideas too which I'll tackle next week. Will DM you re. other items. Cheers

Thx @Peter Knight ! This is so crazy! I asked it to add an onboarding tour overnight. The first two page impressions led to exceptions, but after copying those error messages to cursor it worked: And it not only works it also looks great! There are some issues still, but it's amazing how fast you can try things out and get a real world experience and not just a pencil sketch. Is it somehow possible to give the AI access to a browser so that it can try to load the page and see and fix such exceptions on its own? Another thing I'd love to have is to make it PLAN upfront but then start building once that is done. It seems I have to always confirm the build step after the plan is done.

Sounds great. Any examples or screenshots for us?

Hi everyone, I’m excited to share a new module I’ve been working on: GrokImagine. It integrates the x.ai (Grok) API directly into the admin interface, allowing you to generate AI images on the fly for your Pageimage fields. Instead of leaving the CMS to generate assets, you can now do it right where you need them. Key Features: Progressive Loading: Unlike many AI modules that make you wait for the whole batch, this one loads images one-by-one as soon as they are ready. Batch & Variety: Generate up to 4 variations. The module intelligently tweaks prompts for batch requests to ensure you get different angles and compositions rather than duplicates. Aspect Ratio Control: Built-in selector for 16:9, 1:1, 9:16, and 4:3. Model/Resolution Settings: Support for both grok-imagine-image-pro and standard models, plus 1k/2k resolution toggles. Seamless Integration: Enable it only for specific image fields via the module settings. How it works: Enter your API Key from console.x.ai in the module config. Go to any page with an enabled image field. Type a prompt, hit "Generate," and watch the "skeletons" fill up with images. Click the ones you like (blue checkmark) and save the page—the module handles the WireHttp download and adds them to your field automatically. GitHub Repository: https://github.com/mxmsmnv/GrokImagine Installation: Download or clone into /site/modules/GrokImagine. Install via the Admin Modules dashboard. I’d love to hear your feedback or any suggestions for future features! 🍀

Thanks @virtualgadjo. The contentTypes tip looks interesting, though I'm not yet advanced enough yet to fully understand it, but I'll get there eventually! 😄 Ah yes @psy, I forgot about the <region> tags - good idea. I was just going to try something like <script pw-id='js' ...... pw-optional></script> but I'm not sure if that would work with prepending, before, after, etc and if the tags don't match. The region approach looks cleaner. Thanks!

So I'm trying to create a little page builder of sorts for the project section of a porfolio site using a section repeater. The repeater includes fields for creating various section options to build out a page (1xfull-width screen image, image+txt, txt+image, 2ximages, triptych, etc.). I added a "section-type" radio field with layout options so I can use if statements in the code to change what markup will be created in the template. The screenshot below shows my repeater as it is now, but I'd like to use field dependencies to hide fields that are not required for the chosen layout type. The problem is - I just can't manage to get the "Show this field only if..." to work for partial text matches or OR statements. Taking the heading field as an example -- I only managed to hide the heading field with the following, and only for that one case: section_type%=heading_txt I tried using OR statements, but this didnt work either: section_type%=heading_txt|txt_heading Partial matching like this doesnt seem to work: section_type%=heading Am I missing something obvious? Would really appreciate any help. 1=single_image 2=two_images 3=three_images 4=txt_image 5=image_txt 6=heading_txt 7=txt_heading

ProcessWire and photo-heavy sites go hand-in-hand. But these sites can also present development challenges, especially when cloning a large site. This post goes into detail about techniques you can use to keep lightweight development sites without all the photo/image overhead. https://processwire.com/blog/posts/developing-photo-heavy-sites/

I though you were talking about THIS, now I just furiously started prompting all the bugs meanwhile I go reviewing and doing stuff on my own. Now just boostrapping ddev somwhere (gihub codespaces?) , some E2E testing, feedback loop till acceptance and out of work lol

Anyone tried OpenClaw yet on a local machine? I see lots of tweets about Mac minis and OC and people running much cheaper agents etc