diogo

This is independent of the backend, just add the root domain like on my example.

To quickly test many of your websites to know if they are affected by this, you can use this cURL in the terminal, just edit the urls: urls=( "https://example1.com/" "https://example2.com/" "https://example3.com/" ) printf "%-45s %-12s %-12s\n" "URL" "page_name" "pg_name" for url in "${urls[@]}"; do a=$(curl -s -o /dev/null -w "%{http_code}" -X POST -d "page_name=test" "$url") b=$(curl -s -o /dev/null -w "%{http_code}" -X POST -d "pg_name=test" "$url") printf "%-45s %-12s %-12s\n" "$url" "$a" "$b" done

most probably something with wordpress 🙄

Hey everyone, If you suddenly find yourself unable to create new pages or edit the name of an existing page on certain hosting providers, this is not a ProcessWire core bug. Recently, major hosting providers (specifically confirmed on IONOS and Mittwald in Germany) seem to have rolled out a Web Application Firewall (WAF) rule update. This security baseline aggressively blocks any incoming POST requests containing the string "page_name". Because PW uses "_pw_page_name" when you create a new page or edit the name on an existing page, the host's firewall drops the request entirely before it even reaches PW, throwing a 403 error. Cloning pages works completely fine because it executes programmatically via the internal API, which bypasses the form submission block. I came up with a temporary workaround for my own websites. Just add this to your ready.php. It does something very simple and non destructive, using hooks, we modify the input name on the form to something that doesn't trigger the firewall, and after we receive it via POST request, we change it again to the variable that PW is expecting: /** * Temporary WAF bypass hack for 'page_name' parameter. * Renames the page name input on render to avoid WAF rules blocking the * '_pw_page_name' parameter name, then restores the value under the * expected key before ProcessWire processes the form input. */ // 1. Rename the input on render (output) $wire->addHookAfter('InputfieldPageName::render', function(HookEvent $event) { $event->return = preg_replace( '/(<input\b[^>]*\bname=)("|\')_pw_page_name\2/', '$1$2_pw_bypass_waf_pg_name$2', $event->return, 1 ); }); // 2. Inject the bypassed value back under the expected name before processing $wire->addHookBefore('Inputfield::processInput', function(HookEvent $event) { $input = $event->arguments(0); // Only act if our bypass parameter exists and the original doesn't $bypass = $input->_pw_bypass_waf_pg_name ?? null; if ($bypass !== null && !$input->_pw_page_name) { $input->_pw_page_name = $bypass; } $event->arguments(0, $input); }); I opened an issue here https://github.com/processwire/processwire-issues/issues/2351 EDIT: I can't reproduce this anymore on Mittwald, so I'll assume it only affects IONOS.

I also read it all, and I'm struggling to keep in mind all I want to say, so I won't say much at all. Just a couple of notes from the top of my head: 1. As Ryan mentioned, I've been with processwire since the very beginning. I'm talking about when the forum had 30-40 people, from those, I don't think many are still active. During all these years I've seen a bunch of users in the forum come in with a lot of ideas for processwire, many times aggressively wanting to impose them and even trying to create dissent groups. These groups had, sometimes, completely opposite ideas – some wanted processwire to be more friendly to non developers, some wanted it to be more of a complete framework only for experienced developers. Some wanted processwire to be smaller, some wanted it to be larger – you get the point. Ryan was always incredibly gracious with everyone, and every time explained calmly his reasoning to keep processwire in the path he was taking it to. Most of these more imposing users just left, or faded away from the forum with time. I personally don't agree with every single decision taken by Ryan, and I never stopped checking and trying other tools (I even started a thread where people can post interesting alternatives to processwire. You can still find it somewhere here), but, overall, processwire suits me better than any other tools I've tried, so I stick around. 2. I don't know the exact goal in Ryan's mind for processwire. I'm not sure if he has it 100% clear himself, since it seems to come a lot from belief and intuition. Honestly, I think it has worked until now, mostly due to how intellectualy honest he is. 3. Concerning the governance of processwire, and the comparison to other, bigger, projects. Laravel seems to be governed in a very similar way to processwire, or am I looking at it wrongly? Can you guys clarify that? Other projects are for profit, and hire a team of developers, I think Kirby falls into this category. Big open source projects, like Drupal, function by voting, but have a complex system of authority splitting, and a board of directors, conflict resolution group, etc. We are free to question Ryan's method, and here he is, asking openly for everyone's opinion, but I don't think it's fair to question his intentions. 4. About the Konkat theme. The possibility to design the new theme came to life while discussing the redesign of the website. Jan and I would have never done it, if it was in the open, and Ryan respected this. Again, and as we explained before, this was never supposed to be the "definitive theme", but simply a "skin" for the uikit theme (and this means, uikit, jqueryui, some custom jquery modules, three different types of overlays, etc...). The theme is only CSS on top of the original one, and still manages to introduce a new kind of theming that doesn't require compilation, to conciliate stuff that was incoherent, introduce a dark mode and sticky header. At Ryan and Jan's suggestion, I looked carefully at Bernhard's Uikit admin, but concluded that taking it as base and asking for Bernhard's collaboration wouldn't advantageous to our work. Many hours went into this theme, and they would have been exponential if the work was open for collaboration, opinions, voting, etc. When the theme was completed we told Ryan that we were fine with it not being the default theme, if that didn't suit the project's best interest, and were always open about it. We think Ryan made the right decision to still do it. We also think the weak points of the admin are not in the theme, but the old base (jquery, jquery ui, even uikit), but that's a huge mountain to climb, and the truth is that those tools, despite being old fashioned, aren't going anywhere. 5. Because I use processwire as a tool for client work (and I know that was always Ryan's intention for himself also), I don't feel the need to make a profit of processwire itself. I understand that some people invested work on exactly that thought. What made you guys invest those hours on the modules, was it a genuine thought that the processwire ecosystem was already ready to yeld that return, or was it a bet that processwire would sooner or later be ready for it? Either way, I don't think it's fair either to put the responsibility of not being able to make that profit on Ryan's shoulders, if that's what I'm hearing in some of the comments from this and other threads. 6. Careful with MoR like Lemmon Squeezy and Paddle. They are effectively between you and the customer, in practice, they are your client, and the customer is theirs. They also keep complete control of the store, if they flag one module they can cancel the whole thing. They do make tax much easier, since you don't need to take care of anything. Ok... the few notes turned out to be longer after all. I'm too tired to review them, so I'll hit submit, trusting that I'm among friends who'll forgive the rambling 🙂

@elabx This is a change Ryan did because he added a bunch of new stuff to the documents. We understand the need to organize the long content in an accordion, so we already discussed a bit how we can improve it. For now, Ryan already added an "Expand all" button and an anchor link to the API reference that you find on the bottom of each page. In my opinion this was already a great improvement 🙂

If you want to try cheaper models, while having the same experience as Claude Code, check out Deepseek TUI or, for multi providers, check Openecode or Aider.

Aider has an interesting “architect mode”, where you can define a “strong” and a “week” models for reasoning and acting. This can keep costs much lower https://aider.chat/2024/09/26/architect.html

Oh wow, Soma, glad to have you back here! My mind just went way back now 😄

Thanks for reporting @monollonom! It seems like our small animation on the logo, breaks the page in Firefox. While we don't figure this out, I removed it from firefox with @-moz-document url-prefix() Not as nice, but at least the page works. Edit: the animation works for Firefox now 👍

Chris Ferdinandi has a valuable opinion on the subject. I would love to agree with him, but I honestly don't know if I can afford to https://gomakethings.com/training-your-replacement/ While you're at it, check his others posts and subscribe to the newsletter, he is a very insightful guy 🙂

@AndZyk just sent a fix for this to Ryan.

@markus-th In my view there's no reason to be confused, there's a disagreement on the strategy, that's all. Your position doesn't confuse me, I understand it perfectly, I just don't necessarily agree that it's the best path. Also notice that I carefully worded that sentence to convey that this is only one of the aspects that we discussed. It doesn't mean that it was the most important one and it doesn't mean we discarded other targets. We still think the site will convince developers to go deeper and discover PW. What we did, in that aspect, is not much different from what greatly successful tools aimed at developers are doing. From the top of my mind, see Next, Astro and Svelte

Thanks you for your opinions and suggestions, they are very welcome! We can always count on this community for engagement 👍 One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center. Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂 That could be a fun animation to make 😆 Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

@markus-th I had this on my list, but somehow didn't get to doing it. Yes, it should be an easy fix.