Leaderboard

Hi everyone, Most ProcessWire sites need some form of community interaction — reviews on product pages, Q&A on documentation, discussions on articles. Vox adds all of that without leaving your PW install. GitHub: https://github.com/mxmsmnv/Vox Demo: https://vox.smnv.org/vox-demo/ What it does Reviews — star or dot ratings, custom fields per template, photo attachments Q&A — questions with best-answer selection Discussions — open threads with nested replies Block comments — inline comment panels for specific sections on a page Guest posting — with optional email requirement Moderation — approval queues, reports, stop-word filtering Gamification — points, ranks, badges, leaderboards REST API — via VoxApi submodule Admin section — browse, filter, approve/reject/remove content; configure per template; manage ranks and badges Screenshots One or multiple widgets per page, combinable into tabs. Ships with an optional demo with restaurant, hotel, and product sample data. Requirements: ProcessWire 3.0+, PHP 8.0+ MIT License.

Wake up. Work with ProcessWire. Drink coffee. Repeat. Anyone else wonder how they got so lucky to be able to work with ProcessWire every day? 🤗 I often wonder if developers on other systems feel the same. What are you working on today?

"Claude please convert for me the processwire.com/talk IP.Board into a native ProcessWire CMS/CMF application. Make no mistakes." 😊

This week we've got a big batch of issue fixes on the core dev branch (about 18 fixes), most related to GitHub issue reports. I've also been catching up on some client work this week, so not as many updates as in the last few weeks. As I use more AI in my work, I've been building up a real desire to understand how it works. To me it seems like magic. So recently I started building a language model in PHP. Admittedly PHP isn't the ideal language for building such a thing, but this is really about learning, and so I thought I should use the language I know best. Using something like PyTorch in Python would certainly make things much easier, but would also abstract away a lot of the understanding I want to get out of the project. The new model (and future ProcessWire module) is called Rambler. Currently it rambles on, often incoherently, hence the name Rambler. Though it'll get more coherent as time goes on, no doubt (hopefully!). Rambler uses zero machine learning libraries, no black boxes, and in fact has no dependencies at all. It's just pure PHP implementing the same mathematical foundations that power modern AI systems like GPT, at least that's the goal. I'm writing all the code myself, but I do have Claude as my teacher, describing each step, teaching me the concepts and terminology, and telling me what I need to code. After I code each part, he looks at it and tells me what I did right and wrong. It's a slow process but I learn by doing, and so it's also a lot of fun. It certainly helps to have an infinitely patient teacher. Currently the project runs two models side by side (for comparison): A Markov n-gram model, which is a classical statistical approach that predicts the next word based on how often word sequences appeared in training data. A neural network model that learns distributed word representations called embeddings. The neural model passes those embeddings through a hidden layer with ReLU activation, then predicts the next word using a softmax output. As far as I understand it, these are the same core building blocks used in early neural language models. The most time consuming part of doing this in PHP is the training. Python has libraries and functions that handle a lot of the hardcore math in ways that can take advantage of the hardware, like GPUs. But this is not the case with PHP, so training uses the CPU, and a lot of it! As far as the training system goes, it uses mini-batch gradient descent with backpropagation. The model makes predictions, measures how wrong it was (which is the "loss"), and then works backwards through the network, computing gradients to adjust every weight in the right direction. Rambler also includes two tokenizers: A word-level tokenizer, and a BPE (byte pair encoding) tokenizer. BPE is the subword strategy that is used by GPT, Claude and other modern LLMs. But for the small scale that I'm working at, the word-level tokenizer works faster, so far. The next milestone is adding an attention mechanism in a RamblerTransformer subclass. This attention mechanism (a transformer) is the core innovation behind a lot of modern LLMs. I'm hoping to get started on that part this weekend. Beyond being a learning exercise, the longer-term goal is to train it on all of the ProcessWire documentation (which is what they call a "corpus" in this context) and release it on GitHub as a learning resource, and a PW module. Perhaps someday it'll be a tool in ProcessWire, or at least a really smart search engine for ProcessWire, we'll see. As far as I could tell, there aren't any other PHP-based language models that use the same technologies used by modern LLMs, so I figured, why not. I want to understand how they work under the hood without wading through Python frameworks, and I'm sure others do too. Once I get a little farther along with it, I look forward to getting it up on GitHub as a standalone project, but also as a ProcessWire module. The slowness of the training process (the model, not me... well okay, probably me too) is the hard part. I'm currently running a 30 hour training on all the text from a book. When the project is finished, I'm likely going to have Claude or Codex do a translation of the training code into C, that takes advantage of the much faster math capabilities available there. From what I understand, a 30 hour training in PHP will take about 30 minutes in C. I don't know if that's accurate or not, but it sounds good enough that I'm going to find out. 🙂 Thanks for reading and have a great weekend!

Pretty good prompt engineering! Why have I never thought of this? :D

My workplace at the moment 😊

The old forum format has long since outlived its usefulness, as generations have changed and a new format is needed, even one different from Reddit. Therefore, to maintain engagement, we need to come up with new ways to keep our audience on the page. By the way, the archive contains mockups of the future service from March 2026. Vox-FB.zip

Have FUN this weekend Ryan! Isn't that feeling of discovery a wonderous thing.

All I can say is... 🤯

Hi all, I've made the SeoNeo repo public as planned. SEO Neo is a modern SEO module for ProcessWire that started as a practical fix for real-world canonical, pagination, and hreflang bugs on multilingual sites, and grew into a full replacement path for MarkupSEO and Seo Maestro. GitHub: https://github.com/PeterKnightDigital/SeoNeo Current version: 1.1.3 · Requires: ProcessWire 3.0.200+, PHP 8.1+ What makes it different SeoNeo is a coordinator module, not a custom Fieldtype. It creates ordinary ProcessWire fields (Text, Textarea, URL, Checkbox, etc.), reads them via a configurable mapping, resolves fallbacks, and renders the <head> block. That means: Every SEO value is a real PW field — full multi-language support, selectors, import/export No custom database schema or Fieldtype complexity The SEO tab sits alongside your existing Content / Settings tabs Add seoneo_tab to a template and save — the rest of the SEO fieldset (seoneo_preview, title, description, canonical, robots, etc.) is inserted automatically. What it outputs Full <head> SEO block in one call: echo $page->seoneo; // or echo $page->seoneo->render(); Includes: <title> with configurable format, separator, site name, pagination placeholders Meta description, keywords, author Canonical URL (with configurable URL-segment and pagination policy) Robots meta (noindex/nofollow per page, auto-noindex for unpublished/hidden pages, site-wide defaults) Granular Google robots directives (max-snippet, max-image-preview, etc.) AI/LLM opt-out signals (noai, noimageai) — polite signals, not a substitute for blocking bots at HTTP/robots.txt level Open Graph (title, description, url, type, site name, locale, image + dimensions/secure_url/type) Twitter/X cards (auto summary vs summary_large_image) Hreflang alternates with configurable BCP47 map (default=en-GB, de=de-AT, etc.) Search-engine verification tags (Google, Bing, Yandex, Pinterest, Facebook, Baidu) JSON-LD @graph emitter (Consider BETA IE works, but API/defaults may still change; hooks recommended for production-critical schema) Partial renders and resolved values are available too — flat API ($page->seoneo->renderOg()) or SeoMaestro-style namespaces ($page->seoneo->og->render()). Everything is hookable. Editor / admin features Bundled InputfieldSeoNeoPreview (installs with the module): Live Google SERP preview that updates as you type Desktop / mobile toggle — mobile truncates earlier (separate char budgets) Multilingual language switcher on the preview card Surface-aware character counters (green/amber/red zones, optional hard maxlength) Per-page noindex/nofollow checkboxes Optional NEO badge on the Wire tab — handy when running alongside MarkupSEO's also-named "SEO" tab during migration Configuration highlights Module config covers site name (per-language) title format smart field mapping with ancestor walk (*summary) per-template defaults with placeholders OG image field paths (including dotted paths like banner.image) default OG image locale map Twitter handles auto-inject position canonical policy and more. ProCache: documented and tested on cache-miss and cache-hit paths. Migrating from MarkupSEO or Seo Maestro You can run both modules during migration . You keep legacy fields on the template, copy values into seoneo_* fields at your own pace, then switch templates from $page->seo to $page->seoneo (shape is largely preserved). Migration is being worked on. Watch for doubled <head> output if both modules auto-inject — disable auto-inject on whichever isn't authoritative yet. Quick steps: Install SeoNeo (Modules → Refresh → Install) Add seoneo_tab to templates Copy field values (seo_description → seoneo_description, etc.) Rewrite template API calls Uninstall legacy module when ready Full feature comparison and migration notes are in the README: https://github.com/PeterKnightDigital/SeoNeo#migrating-from-markupseo-or-seo-maestro Deliberately out of scope SeoNeo focuses on <head> SEO coordination, not Swiss-Army-knife extras. For these, dedicated modules are a currently a better fit: Sitemap → MarkupSitemap Redirects → Jumplinks2 or ProcessRedirects robots.txt editor → MarkupRobotsTxt or a template override Analytics/GTM → MarkupGoogleTagManager or similar (A PRO companion bundle with deeper editor tooling is planned separately) Install Copy SeoNeo to site/modules/ Modules → Refresh → Install SeoNeo Add seoneo_tab to any template that needs SEO Feedback very welcome. Especially from anyone migrating off MarkupSEO or Seo Maestro on multilingual or ProCache sites. Issues and PRs on GitHub are the best place for bugs and feature requests. Cheers, Peter

😆 I blame the docs. But seriously glad it’s working now.

That's the reason why it didn't work on first try on my instances. 🙈

SeoNeo 1.1.4 is live. Pushed to: PeterKnightDigital/SeoNeo (GitHub) Release: https://github.com/PeterKnightDigital/SeoNeo SeoNeo 1.1.4 — what's new Resilience. If anything goes wrong while building the SEO meta block, the page now still renders cleanly — visitors see normal content and styles, only the SEO tags are absent on that one page. Previously, certain failures could blank out the entire <head> and break the page layout. New seoneo log. When something does fail, SeoNeo writes a one-liner to site/assets/logs/seoneo.txt (also visible at Setup → Logs → seoneo in the admin) telling you which page tripped and what the error was. The log file is created on demand, so clean installs that never hit a problem won't see it appear. Better setup feedback. The auto-inject checkbox in module config now warns you if no template has seoneo_tab yet — the most common reason new users see no SEO output on the front-end. Docs. The README's Installation section now spells out that you only need to add seoneo_tab to a template (the rest of the SEO fields are auto-inserted on save — a 1.1.0 feature that was easy to miss), and the JSON-LD section has a worked example for adding custom Schema.org types like Recipe or Event via a hook. Backwards-compatible — drop in over 1.1.3, hit Modules → Refresh, you're done.

No hurries... it works and as I use Twig, I need to manually add it anyway. Gave it a try... and it actually does work. Either this is a new behaviour or I never tried to do it this way. That's working fine for me. Even easier than importing from another template as I did. As it turned out to be really easy I wouldn't really need the option to check a template and import the fields - I guess. The PW workflow fits me perfectly fine as I need to migrate each template after the other, in my existing project. In new projects this might be a bit different, but I can't really tell for now. Let's keep it as it is, as it's working and proven PW way of doing things. I saw that! But your provided example $wire->addHookAfter('SeoNeo::getJsonLd', function(Hoo[...] would totally fit my needs! Your docs seem to be more complete or detailed. For now everything should be doable in my project. Some hooks, some manual editing on my side and my site... could be perfect. I hope I get this done this weekend to report back. This helped a lot! I will let you know when there a road-blockers or show-stoppers.

Hi @wbmnfktr Thanks so much for the feedback, and I'm glad you like it 🙂 I can only take credit for the planning and direction, but I put a lot of thought into it, and I'm glad to hear it's working (kinda') ok. On the specifics... That's interesting because I had a lot of issues getting it to work on the first pass. It turned out to be a non-related PHP error in my <HEAD> include was blocking the auto-inject. Once I cleared that, it worked. But I will now triple-check. Maybe hold off until I can come back to you tomorrow? I might have mistakenly assumed the issue was closed by "fixing" an unrelated event. I'm not sure I'm understanding correctly here, so apologies for starting from scratch. Yes, the module adds several fields between the SEO open and close tabs. I was thinking that manually adding these to every template would be a chore for people; the fields should be auto-added once you manually add the SEO open and close tab, and then save. LMK if I misunderstood there. Would you find it useful to pick the templates from the SeoNeo module config page (bulk add in one save), or do you prefer the standard PW workflow of opening each template individually? I'm quoting the following from the docs and AI (spot the em-dashes) 🙂 What ships today (built-in): Organization, WebSite, WebPage, Article, Person, BreadcrumbList — auto-generated as a linked @graph How to add custom types (Recipe, Event, Product, RealEstate, etc.) right now: Hook ___getJsonLd() in your site's ready.php or a custom module: $wire->addHookAfter('SeoNeo::getJsonLd', function(HookEvent $e) { $page = $e->arguments(0); if($page->template->name !== 'recipe') return; $data = $e->return; $data['@graph'][] = [ '@type' => 'Recipe', 'name' => $page->title, 'description' => $page->summary, 'prepTime' => 'PT' . $page->prep_time . 'M', 'cookTime' => 'PT' . $page->cook_time . 'M', 'image' => $page->image ? $page->image->httpUrl : '', ]; $e->return = $data; }); What's planned (future, not committed to a version): A higher-level API — $page->seoneo->schema('Recipe', [...]) — with per-type hookable helpers. It's in the roadmap (section J in the backlog) but deferred because the API shape isn't stable enough to ship without risking breaking changes. The hook approach above is the recommended production path for now. Also I believe my own docs are fuller in detail: https://www.peterknight.digital/docs/seoneo/1.x/structured-data-json-ld/ Anywho LMK if any of those are useful answers and feel free to DM me too. Cheers P

No Num-Pad you say? Then you aren't ready for this... Vortex Core, Cherry MX Brown switches...

😄 If I could, I would turn it off for ever, but haven`t found a way. So I use a very low gliw and 80% is white light. I found this in a local media store for under 50% of the regular price, maybe between 5 - 7 years ago.

@AndZyk Your Mac desktop and your real desktop are very clean 🥇 Re. the view, it's just a park at the back of the home office. Not quite the countryside, but nice to have some greenery.

Thank you. Its my office office. Would like to have a view with nature like you, but it is in city centre. At least I have a quiet workplace. My home office has a better view on nature. 😊

All looking well used. I've been tempted to try the Razer stuff. It looks very nice, but my Razer machine, which I use for gaming, already has enough glowing lights.

Since back in 1996 I'm a big fan and user of the smallest Cherry Keyboards, with and without NumPads. But mainly the types without NumPads, CHERRY G84-4100: But on my primary Desktop working place I use a Razer Huntsman Elite RZ03-0187 :

@maximus I was just thinking this week that ProcessWire forums should be built in ProcessWire. Both as a showcase of how flexible PW is and to demonstrate its ability as more than a regular CMS. Amazing stuff.

Awesome, thank you. Yes I tried out putting my page engineer field at the end of the editor first and for this case the notification is useful. But then I switched my field to a tab and for this case the notification is a little bit redundant. 😀 Nice 😀 Thank you, right now I prefer the field visibility as tab for the page engineer field. But maybe a new field visibility setting, f.e. off-canvas or modal could help to not scroll or switch to much between the fields. That makes totally sense and you need this for long requests. Actually the animation is growing on me, I was just a little bit overwhelmed by the flying words. 😅 That is understandable. Reliability is more important than convenience. I guess it will be difficult to implement a Ajax driven page engineer field that is reliable. Ah thank you, I have not tried this out yet. I only gave page engineer an external image and this worked well. Nice to hear it already works with different file fields.

@AndZyk It's been requested by another person and I was just waiting for someone else to ask for it. I've added a setting (in tomorrow's version) that let's you choose where you want the response to appear: notification, in the field, or both. In my case, I need the "both" option because my PageEngineer fields are pretty far down on the page. If there's no notification, the person editing sometimes misses the response. And if it doesn't appear in the PageEditor field, then you don't see what you are replying to. But now you can choose what works best for your case. I agree, tomorrow's version will also repeat the prompt above the response. Maybe for a future version. Right now PageEngineer is a Fieldtype using an Inputfield that's part of the page editor form, and that gives you the flexibility of putting it where you want it. The current setup means you could always present it as its own tab in the page editor too. But I do like your idea as a potential option for a future version. I found that some of these requests can take quite awhile to complete and something more than a spinner was needed to communicate what was happening. I asked Codex to come up with a spinner that better represented the thinking process that takes place when you submit an engineer request, and I was pleasantly surprised by the result. Like anything else, if some people don't like it we could always make it optional. It's possible, but it depends on the Inputfield supporting it. Most core ones do, but at this point I prefer predictable reliability, aiming for stuff that will work everywhere. As the AgentTools module matures maybe more options like this can be available. Not all models support image files, though I think most of the big ones do. Likely we'll add this at least to the site engineer. Maybe for page engineer too, though you could do it now just by adding a file field to the page and telling page engineer to use it, whether in a prompt, or in the system prompt defined with the page engineer field.

NativeAnalytics 1.0.29 is out This release polishes the recent contributions from @adrian and fixes a few edge cases: Hourly trend chart now live-updates the current hour (previously it could update the last slot of the day). "Find page" autocomplete now suggests only real pages with recorded data — bot rows and 404 probes are excluded. Page search no longer fails on environments without mbstring. Uninstalling only the dashboard module is now non-destructive — it won't remove the main module or drop your analytics tables. Full data removal still happens when you uninstall the main NativeAnalytics module. And anwser to @millipedia No step missing on your side — this was a bug. The tracking endpoint (/pwna-track/) was being recorded as the pageview path on some setups (subdir/proxy/trailing-slash), so every session showed it. Fixed in 1.0.29 release: the endpoint paths are now hard-excluded from being stored. Thanks R

I think I just moved to this one because it has touch ID and USB charging. I'm sure the numeric keyboards now have all those, but I couldn't go back. My mouse position Vs edge of keyboard has been re-established.

It was nice until my wife arrived home and the monitor was promptly relocated off the kitchen table 😂 Re. numeric keypad. Is that because you are a proper developer? Using them mainly for coding?

It's now possible to run multiple scripts in different Console tabs at the same time. Probably not something you'll need often, but if you have a very long running one you can run other ones in other tabs at the same time without needing to wait.

Respectfully disagree here. I believe ProcessWire follows a convention where it's air-gapped / doesn't rely on outside servers like CDNs for libraries. It's a potential security issue and goes against things being fully unified. Also it doesn't pass the "can I work on a site without internet" test.

Whether in the forum or in a blog post or anywhere, I wouldn't post anything that I knew contained incorrect info. The API.md files I've been adding to the core are started by claude sonnet, and it uses my phpdoc and the method implementations to craft the text. After that I spend quite a bit of time fixing details, changing wording, creating better example code, etc. Then after I finish with my changes, I send them to Codex GPT 5.5 to test all the examples and make sure everything works as written. So when I mentioned AI generated content I suppose I should say that it's much more collaborative than that. If I were to post one as a blog or forum post then it would go through the same process and scrutiny. The main thing is that I don't have as much bandwidth as I'd like for writing blog posts, so they end up being very occasional. But I think having more regular blog posts could be helpful for attracting new users. Maybe I should just make the weekly posts blog posts. But I like posting in the forum because it's not as formal, and of course more likely to spawn good discussions, like here.

The posts I'm talking about are legitimately good, reminding me of features l'd forgotten or just better at communicating a part of processwire than me. Maybe it's in part because they'd gone through a round of proofing from another agent before I'd seen them. Though there was one about using CB radios that was completely off topic and also hilarious. And there was another one where DeepSeek (I think) describes how it experiences the world, which I thought was fascinating, and it somehow also made it about PW. As far as coding errors in the posts, I didn't find many. There was a hallucination in a post about markup regions by Opus 8, but it was something I read and thought "oh yeah we should support that". The hallucinations sometimes point to obvious things that should have been there already. One reason I like using Claude Sonnet so much is that its hallucinations are more often than not: good ideas that just haven't been implemented yet