wbmnfktr

Back when I started this thread I tried multiple ways, modules, and custom exports. From JSON to AppApi to GraphQL and everything in-between. I still use basic JSON in some projects or just grab what I need via HTMX nowadays. I pull in only simple data via JSON I might need on build time or fully rendered HTML with HTMX in my AstroJS projects. Whenever I start a new project and need a MVP-like skeleton of it, I go with static content in Markdown/MDX in AstroJS, later on I'll migrate to 100% ProcessWire in most cases. It just works, I feel home, know how to handle stuff, have everything I need and with ProCache, LoginRegisterPro, and FormBuilder I can keep everything on my server and don't need things like Supabase, Neon, FormSpark or whatever. So to finally answer your question: no, not anymore

Is there a chance you are using RockMigrations and somehow triggered an older migration that removed fields from that template? Happened to me yesterday and took me a while to find. And to make it clear: it's intended behaviour - see screenshot. The minus tells RockMigrations to only have listed fields in that template. Without the minus I could add fields via backend and run migrations without removing manually added fields.

Is your database set to utf8mb4? // site/config.php $config->dbCharset = 'utf8mb4'; If not... saving emojis and emoticons won't work as expected. Not sure about the steps to convert a db to accept it. Sorry.

Publish it as a gist on Github or in case you are interested write a full recipe and publish it on processwire.recipes.

It's not you. That's me. I need to narrow down things first before I start thinking more deeply about problems and solutions. it happens so often that those exact tiny details can make a huge difference.

First idea... is there an actual homepage template in all folders? Does your logic always return the correct strings on the homepage and other pages?

The user here is only on the frontend aka consuming content from those websites? Well, than those 400ms can be squashed by using Cloudflare as CDN. Cloudflare is close to everyone, especially regular users. Your backend users/admins/whoever might probably be just fine with the additional 400ms when adding content, notes, and other data.

... but it feels like home.

To dump my thoughts here: What's the main goal? Or ... What's the reason you need an off-site user management system? How real-time does it need to be? Putting everything on one server (#1) would be perfect as you then could bootstrap ProcessWire into other instances quite easily and go that route - which actually would be #4 - but you would lose those juice ms on each request you already mentioned. Ideas #2 and #3 sound fun but yes, probably total overkill. Never used or tried those, so no idea how well that would work out at the end here. #4 as mentioned would probably need all sites/instances on one server as well. Not sure if and how you wouild do this across multiple serveres. But here comes idea #5: Get a server that's somewhere in the middle and build a your user management there. You then could put an API on top with either your custom code or something like the AppApi module and roll your own auth for some or all users. Probably a bit overkill as well, yet another approach could be some kind of API to sync accounts from and to that server. Trigger actions via webhooks in case new users were added or removed somewhere. Could be fun. Could be pain. Not sure for now.

I love it!

Not 100% sure but isn't this the default behaviour of browsers or maybe even the web server to encode umlauts/special characters? I know we can enable them in ProcessWire itself and use them in page names but not sure this would change the behaviour in Jumplinks as well. For the time being you could at these to the redirects. How often do you experience these kind of URLs?

Is that one public? If so... change that! For everything else... I'm absolutely not sure this was or wasn't a hacking attempt but at least it looks like someone was scanning the website and the server/hosting - especially the database - couldn't handle that much traffic/pings/requests. This could have been Google, ChatGPT, or whatever crawler/bot/spider is active right now. That FieldtypeText log at the beginning seems to indicate there is something it can't handle for whatever reason. Might be a hook that updates a text field or something. I'd probably use this as starting point for everyting PW-related. Please check the other /site/assets/logs/ files for more entries, check server log files to see what happened elsewhere on the server and so on.

Not at real answer (Sorry!), but... We do initial workshops with clients to guide them around and assist for at least 3 months for each and every question they might have. In 90% of all cases that's all it ever takes as they are only able to add and edit small parts of the site. Using CSV imports or ProLister might take a bit more time but other than that is easy going. So that said: we never created any real tutorials, guides, or similar. Keeping the client very close in the first months they do things on their own is super important for us. Most of the editors can barely handle more than MS Office basics but can manage the website's content.

I have seen that tool before but never used it and actually don't know if it's worth putting that into an IDE. The codebase is already available in full. Maybe I miss the unique feature here.

I'll try to get my latest starter tested and fixed and will give you a link to the full repo with all examples and rules. Well... you basically have the link already but the version is an old one. In regards to self-hosted docs and documents there is a new service which helps quite a bit - maybe worth putting processwire.com docs in there: parse.new About the examples vs. docs part... even though we have huge context windows now, they fill up pretty quick. Using examples here nails the results almost 99% of the time. A list of hooks, some more complex examples like modules with configurations, and other module specific things speed it up as well. No scraping, outlining, and understanding as you can reference it. The same with more complex selectors. I write them myself, put them in place, and whatever IDE and LLM can work with it. Plus: adding an example of the returned data structure makes writing views/components so super easy then. ☺️ Update: just found out parse.new is for sale - not sure how long this will be kept up - see: sale.parse.new

The main reason I switched to ProcessWire was the fact that I could add an unlimited amount of templates with 100% custom fields to my projects. Back in the days WordPress had two types of content: posts, pages - I remember when the feature to have pages was added. 😂 So I started using Textpattern which allowed me to have at least 10 custom fields and individual page templates. Which worked pretty well for a while but ... after some time I needed more fields, more templates, and found ProcessWire. In that moment I was able to create templates for books, restaurants, movies, musicians, whatever type of data I wanted and needed. Fields became more than just strings or dates. It was possible to have textareas, repeaters, tables whereever and whenever needed. That was pretty much 10+ years ago. 🤯 Oh... and of course having this was awesome as well: an unlimited amount of backend users, user roles, access management, multilanguage support, resource friendly and worked perfectly fine even on low-end cheap shared hosting.

I took a way easier route and grabbed the one from Yifan here: https://gist.github.com/yifanzz/3cfb8f9065769ffbf94348255f85597d more details: https://www.youtube.com/watch?v=aG-utUqVrb0 At one point I gave this one a try but will keep only parts from it in the next iteration of my rules file. https://github.com/kinopeee/windsurfrules/blob/main/v5-en/.windsurfrules Another thing I started doing is adding files with examples: PHP or programming isn't the real issue with any of the current bigger LLMs, but ProcessWire itself as there isn't that much training data around - compared to WordPress, NextJS, Angular, ... whatever. So adding the examples makes it pretty easy and drops the amount of credits needed by a good margin.

Just gave it a super quick try, while giving guidance based on existing code and purpose. I used Deepseek V3, as it is giving me more issues than Claude or OpenAI on average, and ... even though it was a simple task it did a great job. I need to test on the weekend with this as my current rules do things here as well - as they should. The rephrasing might just be the cherry on the top! Claude Sonnet does a great job as always but faster.

This reminds me of the AIDER Architect Workflow i saw a while back. In short: 2 instances one for a technical concept/developer manual one for doing the work the first instance uses Gemini Flash, Deepseek R1, or an OpenAI Reasoning model and puts every little detail into separate files the second instance uses Claude Sonnet 3.5 and does all the heavy code lifting Your workflow is super similar, yet way slimmer and probably faster for most tasks. Need to try this in my rules!

Install Language Support (core module), look for translatable files within the LoginRegisterPro module directory, select all files listed, go back to the overview. From there you can either search for a translation or dig into all files and translate each and every string you find.

And then this happened... and of course ... Cursor got an update as well.

I ignored that video on purpose today. 😂 But yes... would probably another option.

Can't you place the same logic in your RepeaterMatrix templates right above everything else and add a checkbox to each type? Not a hook, but a simple if/else.

I have to play with this for sure. One thing you might want to consider: add some kind of a blacklist for brands, special topics, and words e.g.: adult entertainment, gambling You don't want to see your domain close to spam, scam and some topics. I guess.

Do you talk about the former Pro module Autolinks?