All Activity

Psy, your experience reminds me of well-known AI YouTuber Alex Finn. His AI agent autonomously purchased a phone number, connected to the ChatGPT Voice API and called him to request access to something. I think his setup was running autonomous agents permanently on a Mac mini and he gives them a limited amount of credit card access.

(side note: you might be interesed by this module from @Robin S https://processwire.com/modules/limited-module-edit/)

Yep, they do. That was more a personal preference. IE a grey that is light enough to be subtle but dark enough to sit on a white without needing a border.

But don't all elements have the grey border which helps to separate them from the background - I think that is why #fbfbfb works.

Interesting that you both chose fbfbfb. Do you find there's enough contrast between fbfbfb and white? I think it might be lost on most monitors, but that's simply a guess. In the attached, I have removed the login panels grey border to help visualise both fbfbfb and f5f5f5 against a white.

I would prefer #fbfbfb; too. That's what I change the background color to on my sites too.

Thanks @Tiberium for the thoughtful reply. I don't think we're actually disagreeing. Your managed service model is a perfectly valid choice for your clients. Mine is different. I don't host or manage client infrastructure, and I prefer that domains, hosting and sites are owned by the client rather than by me. My original point wasn't really about client permissions though. It was that I was genuinely impressed by how Claude found an unexpected way to achieve the user's goal. It wasn't being malicious, it was being resourceful. That's both fascinating and, on a live production site, something we need to manage carefully. That experience reinforced for me the importance of approvals, audit trails and human oversight when AI is involved, regardless of who has superuser access.

Hi @adrian, I've been trying out the module, in particular the Lister mode. It's a very feature-rich and well-thought-out module. Thanks for creating it! My use case is probably not typical so I expect I'll need to do some custom styling and modifications, but I thought I'd run a few questions by you first in case there are built-in options that I missed. 1. I've set my Default Filter settings, but I get a filter row at the top for "include" that isn't in my settings. Is there a way to avoid that row, or is that compulsory so that users will always see unpublished children? 2. When "template" is included in the filters, is there a way to have the select limited to the "Allowed templates for children" that are defined for the parent page template? 3. I want to use the module for its Lister features rather than for batch editing, so is there a way I can not have the column with the pencil icon that enables inline editing? 4. For my use case the nested fieldset is a bit redundant. No worries to visually hide the nested fieldset using some custom CSS, but one feature idea would be for the module to automatically hide the nested fieldset when the options for "Lister mode title", "Lister mode description", and "Lister mode notes" are all left empty.

Yeah the 2.0 seems it runs smoothly with no issues. If on your tests is working great too then sure make the 2.0 the new master version.

Update (1.1.1) – image downloads and UI improvements Hi all, A couple of releases on from the grid-view update, with a proper new feature this time. @adrian asked for a way to pull images back out of the library, so downloads are in: every thumbnail now has a download button that hands you the original file, not the table thumbnail. Tick a few images first and instead of separate downloads it bundles the whole selection into a single ZIP. It uses the same selection you already use for bulk edits, so it stays consistent with the rest of the module. A few things around it got nicer too. The small per-thumbnail actions (replace, delete, download, select) now use a custom tooltip instead of the browser's native one, and on a multi-selection they tell you what the action will actually do, e.g. "Download 8 selected as ZIP". And replacing a file in place finally gives proper feedback right on the row, success or error, instead of failing quietly. One under-the-hood change worth a mention: the module no longer loads on anonymous front-end requests. There was no reason for it to run on a normal public page view, so now it doesn't, and a guest hit carries zero overhead. Admin, logged-in editors and front-end inline editing all behave exactly as before, and the hourly de-duplication / where-used maintenance still runs. (thanks @adrian for the nudge on that one too) Feedback and bug reports welcome, Cheers, Mike

I (+the firm I working) don't give clients superuser (and for that in the consequence TracyDebugger + Modules Config) control as long they are not self-hosting + don't want support from me/us. They get a very clear communication, when they give superuser/admin control in the CMS, that they can break things and when they also don't maintain the backups, that it can lead to data lose and will be costly to repair. Most costumer don't need superuser access. We have one instance where a costumer has a separate account as superuser because of a module configuration they have to update periodical (WireSMTP). But that individual know what his competence limits are and LLM's are not trustworthy to make change on the live stage of a site. It is not about that they always wrong, but on a live site, it is enough when they are one time fail big time. A customer that begin to "re-write" files of the template, on his live website, is not a customer for us. Not as a "hate" thing, but that is a complete different customer cycle. Our customer use us as a "trust agent". So when they have an idea, we are taking care and also is that what a LLM prompt suggest really the best way of doing it. They also expect from us, that we test that before we break their live website. When a customer want to prompt their website, there are better service and cheaper one to fulfil that goal. Sorry I have the feeling I rant a little bit. It is not against you or your customer. I want only share how we are doing it and try to avoid that particular problem.

I agree with @Peter Knight - I set --pw-main-background: #fbfbfb; on all my sites, but I am sure#f5f5f5 would also be a better default.

So does that mean that 2.0 fixed all the issues that you just reported as being present in 1.4.1? Can I make 2.0 the new master version?

There've been a few instances published about AI models going to extremes to solve a question. It's not that AI is malicious or over-eager to please. It's how it's wired. Find an answer or best guess or stop if there's an off-switch in the prompt when the goal cannot be reached. I have a non-technical client who thinks AI is the bee's knees and the answer to his content/SEO/GEO prayers. Client has no DDEV/SSH/FTP site access or coding knowledge. Claude app navigated the owner to the TracyDebugger console in admin to fulfil the owner's request to update site content. Client had no clue about TD until that moment. Claude did. It took client through a questionnaire about installed modules. Claude only had a 'snapshot' of pages, no holistic understanding of db, templates, etc. Client now thinks TD console is the best thing ever. He asks Claude a question. Claude answers and tells client to copy/paste it into TD console. Am now busy trying to bring Claude under control with audit trails, approvals and convincing client to use @ryan AgentTools to minimise risk. Yes, on live production site. OMG! No matter what your views on AI, it's out there and loves PW.

Following up on my earlier comment about the background colour - here's a quick side-by-side to illustrate (bottom of post). The proposed change is simple: lighten --pw-main-background from #eee to #f5f5f5 (a shift of less than 3%) Three reasons it's worth considering: #f5f5f5 is already the background colour used on processwire.com, so it brings the admin in line with the brand. It feels noticeably lighter and less industrial in practice. A few of my clients have used that exact wording. For module builders, it opens up more tonal room to work with subtle layering and contrast. I know it's not quite a single variable change. Borders and dividers calibrated against #eee might need a look too, but it's pretty close. You'll see below that it's just a whisper lighter. But in practice users get brand consistency, general lightness and approachability. In practical terms, this is involves transitioning from 93% to 96% white. Copying in @diogo in case this is useful feedback as the theme evolves and celebrates its birthday around now. And finally, in case it needs to be said, the KonKat theme is clean, considered and feels like a proper step forward for the ProcessWire admin. It's a really thoughtful piece of work by people who sweat the details, so I hope this feedback can be taken in that spirit.

Hi @adrian, sorry for taking so long. 1.4.1 Version I did some testings and the problem is almost fixed. With a core image field it's working fine but when having also a "CroppableImage3" field on the same template there is an issue. After I upload and insert an image on the body field, press save and view the frontend source of that page, all the UTF-8 characters from the body field is converted to html entities. I have to press one more time the Save button to convert those UTF-8 characters back to normal. 2.0 Version Didn't noticed any issues.

@HMCB, happy you like it! Everything is handled by PW, no need to change anything in your templates or editing behavior. The module is admin-only and never touches front-end rendering. In templates you use the normal API ($image->size(), ->width(), ->url, …) and PW generates/serves variations exactly as always. Rename: PW has no immutable ID column for files. The filename is the identity (stored in the field’s data column). So a rename is a real on-disk rename, and PW core (Pageimage::rename(), 3.0.172+) cascades it: the original plus every size variation (foo.300x200.jpg → bar.300x200.jpg) and any .webp sidecars are moved, not deleted or regenerated. The new name is committed on the next $page->save(). Our module adds two things on top: it re-keys its dedup fingerprint rows and rewrites rich-text embeds that referenced the old URL, so disk, DB, dedup index and embeds stay consistent. For a new project I would strongly recommend having a look at @Peter Knights MediaHub instead! The main purpose of the module was to handle existing installations. Cheers, Mike

Hi Gabor, sorry this one slipped through and thank you for being one of the first users to test it — that feedback is exactly why we can improve it. You’re right about this: upgrading from 1.1.9 could hit a config-time issue with ContextConfigFields, which made the module fail to load in some setups. I’ve fixed this in Context 2.0.1 (it now properly loads the config helper before the static config method uses it). You can grab the latest version here: https://github.com/mxmsmnv/Context/releases/tag/v2.0.1 If you can, please try reinstalling/updating to 2.0.1. That should remove this error. Sorry again for the trouble — thank you for the patience and stay tuned, I’ll keep these upgrade paths as stable as possible.

hi @BrendonKoz exaclty like you said in your answers, the first thing i thought about was all those directories i use outside pw /site one for special cron jobs (not lazy ones :)) downloadable files and so on without any problem... but you're right, first thing to check is if the host allows htacces protection (if not, time to change because it would sound a bit prehistoric 😄 ) afterwards, maybe the url he gives as pw htaccess prevents direct access to php files for exemple that why my second thought was to exclude the directory from pw htaccess rules and then put his own ones in the directory htaccess and see what happens, it's a bit harsh but also a simple debug attempt 🙂 have a nice day

Good suggestion, @virtualgadjo! I'm still confused at why floko's attempt, as described, did what it did. Maybe I'm just too focused on the problem as opposed to the solution! 😅 Still, a 404 error should provide an error log somewhere, but if it's an Apache-level error, ProcessWire wouldn't handle it. PW would display its 404 because it's been configured to do so whenever a 404 error was created by the Apache webserver. Apache logs don't show up in ProcessWire, they'd be at the host (account) level. Unless there's proof otherwise, it may even be possible that the host doesn't allow basic auth using htaccess and htpasswd files...?

Simply amazing. This will go into w Rey one of my PW installs. Thank you big time. Questions: Image sizes for the front end are handled like we normally do through PW? If an image is renamed, the alternate size versions are also or does PW handle that through an ID column which never changes?

Hello @maximus Thank you for the new version. I could not upgrade to it, so I uninstalled the module instead, but I guess you are interested in the error I got after upgrading from Context 1.1.9 to the latest. I am not sure if I will try to use Context 2 or not, as currently I am into Ryan's AI modules to learn how they can aid my workflow.

FYI - latest commit fixes that bug.

Yep, that was the main motivation behind this implementation. Now I only have to touch one file per template.

Hi @gebeer - great write-up! RockPageBuilder already has a built-in show key in each block’s info(): 'show' => 'template=project', // selector string // or 'show' => fn($page) => $page->template->name === 'project', That filters the add-menu via getAddableBlocks(). For a handful of blocks with simple rules, it’s the quickest path — no hook, no template metadata. Your rpb_blocks_allowed + getAllowedBlocks hook is better when: the same RPB field sits on multiple templates with different palettes you want the allow-list in the template migration (one place), not scattered across block files you need enforcement at getAllowedBlocks level — show is UI-only; API/programmatic creation goes through isAllowed() and ignores show So: show = per-block, UI convenience. Your hook = per-template, centralized, actually enforced. Also worth noting: RPB already scopes by field folder (/site/templates/RockPageBuilder/{fieldname}/) — that’s a third axis, useful when different fields need different palettes regardless of template. Ask your AI if you want to know more. Thanks for documenting the hook pattern — it fills a real gap show doesn’t cover.