All Activity

Here's a handy FAQ with the types of issues I needed to solve and are built into SEO Neo. FAQ (quick answers) 1. Can meta descriptions be filled automatically from existing page fields? Yes. Smart field mapping and per-template defaults pull from fields like summary or body when the SEO description is left blank. Auto-resolved text is truncated to a configurable length at a word boundary. 2. Can page titles get a consistent suffix (e.g. “About us | My Company”)? Yes. That is built into module config: site name, title format, and separator — no custom code needed for the usual pattern. 3. Can I override or extend resolution logic with hooks? Yes. Individual resolvers (title, description, OG image, etc.) are hookable, so sites with non-standard rules can plug in custom logic without forking the module. 4. Does the admin SERP preview reflect auto-resolved values? Mostly. On load it uses the same resolver chain as the frontend. If SEO fields are empty, the preview shows the computed title and description. If an editor types into the SEO fields, those values take precedence. 5. I am on MarkupSEO or Seo Maestro — can I migrate gradually? Yes. Both legacy fieldsets can stay on the same template while you copy values across. The SeoNeo tab can show a small NEO badge so it stays distinct when both tabs are labelled “SEO”. Migration helper planned. FAQ Longer versions 1. Automatic descriptions from content fields A common requirement is that staff and blog pages should not need a separate meta description when summary or body already exists. SeoNeo handles this in module config, not by asking editors to duplicate content: Smart field mapping defines fallbacks when seoneo_description is empty — for example, try summary, then body. Per-template defaults go further: a [blog-post] or [person] block can set description={summary|body} so only those templates use that chain. Truncation applies to auto-resolved values only. Values typed directly into the SEO description field are left as-is. The max length is set once in module config. There is also an ancestor walk prefix (*fieldname) if a section landing page should supply a default description for child pages. For edge cases — inheriting a homepage description site-wide, template-specific truncation rules, or pulling from a custom settings page — hooks on the description resolver are the extension point. 2. Title suffixes and branded <title> patterns Another frequent ask is a predictable title pattern: Page name | company.com That is a first-class feature via site name, title format, and title separator in module config. Per-template defaults can influence the source part of the title (e.g. {long_title|title} on blog posts) while the suffix still comes from the global format. Homepages that already store a fully branded title in the SEO field can use a hook on the title formatter to skip the automatic suffix on that one page. 3. Hooks for custom SEO logic Sites with existing custom SEO logic often need to tweak titles, descriptions, or OG images based on template, page ID, or external settings. SeoNeo splits resolution into hookable steps — reading and resolving individual values, formatting the final title, resolving OG image, hreflang, and so on — rather than one monolithic hook. Render methods are hookable too if you need to append tags rather than change resolved values. 4. What the SERP preview in the admin actually shows The bundled SERP preview calls the same PHP resolvers the frontend uses on initial render. While editing, typed SEO values take precedence; empty SEO fields fall back to server-resolved values from page load. One limitation: the live preview watches the SEO input fields, not every source field in the fallback chain. Editing summary will not update the preview until save/reload if the description comes from smart-map. A richer fallback-chain visualisation in the editor is on the PRO roadmap. 5. Multilingual sites Multilingual support is a common question for any SEO module, especially when hreflang and locale tags need to stay in sync with ProcessWire’s language tabs. SeoNeo is built around native PW language-aware fields, not a separate storage layer. Each seoneo_* field behaves like any other translatable field — editors fill in SEO values per language tab, and the resolver chain returns the value for the currently active language on the frontend (or whichever language you switch $user->language to in PHP). Configuration for multilingual output: Per-language site name — override the global site name per language (e.g. de=Mein Beispiel). Used in title formatting, template defaults, and og:site_name. Locale map — map PW language names to BCP47 codes (default=en-GB, de=de-AT, etc.). Powers og:locale, og:locale:alternate, and hreflang codes. Hreflang alternates — emitted per language with correct URLs, including x-default pointing at the default-language URL. Segment and pagination handling matches the canonical URL policies. In the page editor: The SERP preview includes a language switcher (on multilingual sites) so editors can preview each language’s title and description without leaving the current PW language tab. Resolved values in the preview use the same per-language fallback chain as the live site, including the localised URL in the breadcrumb. Desktop/mobile toggle and character counters apply per surface regardless of language. Smart-map and template defaults respect language context too — a German summary field resolves when the German language is active, not a mixed default. For sites with unusual language setups (custom domain-per-language, non-standard hreflang codes, or locale rules that differ from PW’s language names), the hreflang and locale resolvers are hookable. 6. Migrating from MarkupSEO or Seo Maestro Both legacy modules can stay installed while you move page by page: Install SeoNeo (InputfieldSeoNeoPreview installs with it). Add seoneo_tab to templates — remaining SEO fields insert automatically on save. Copy legacy values at your own pace. Switch templates from $page->seo to $page->seoneo when ready. Uninstall the legacy module when frontend output is fully on SeoNeo. Watch for doubled <head> output if both modules auto-inject meta tags.

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've been doing some testing with Agent Tools. My setup is MAMP Pro (PHP 8.3.30), using OpenAI (GPT-5). While I can see responses in the Conversation History, every request initially results in an Error 500. Only after reloading the page, I can return to Engineer tab and then see the response in the Conversation History. I can't figure out why this is happening as there are no errors logged at all, neither in the PHP / Apache logs. The only error I saw logged was this from the installation: files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/failed/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/failed/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/done/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/done/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/running/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/running/ files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools filePutContents: Unable to write: [redacted]/site/assets/at/jobs/pending/.htaccess files‑errors 2026‑06‑10 14:53:21 admin https://mysite.local/admin/module/edit?name=AgentTools mkdir: Unable to mkdir [redacted]/site/assets/at/jobs/pending/ ...but these folders have in fact been created: PW Debug mode is on, and so is Tracy. Any suggestions as to how to get beyond this point?

Looking good, Mike. It's great to see image options. And thanks for the MediaHub mention too 🙂

@ryan Thank you for your continued progress on the Agent Tools module. It is amazing to see how well ProcessWire is capable to work with AI already. 🙂 Here are some thoughts/suggestions I had while using the Page Engineer module: After submitting a prompt you get the answer two times: As notification and in the page engineer field. Wouldn't it be better to just get the answer one time? After submitting a prompt you cannot see the prompt anymore. Maybe it would be nice to have the prompt above the answer, f.e. for screenshots or context. Field visibility: Currently the field is either at the beginning/between/end of the other fields or as tab. Maybe it would be nice to have a fixed field visibility (in the corner) that you can toggle via icon. But I know that would be a new general field visibility. Prompt animation: The new prompt animation is cool, but maybe a little too much for my taste. It feels like entering the matrix after submitting a prompt. But that is just my taste and this is really subjective. 😅 Would it be possible for the Page Engineer to display results that don't change the page without reloading the page editor via Ajax? I guess that will be hard to manage, which result changes the page or not, but right now the page gets saved even without changes. I mentioned this a while back and this would be a general suggestion for the Agent Tools module: It would be cool, if the engineer would have a file field to directly give the engineer files. For example "Create a new image element in the content field with this image." The new tab navigation is nice to switch between the categories. In the Migrations tab a little space for the button would be nice, if you have no migrations. I am exited about the future of the Agent Tools module. 😀

New version (v 0.55.0) – This changes everything Barely a week on from the public beta release here's where Image Library went next. Short version: it grew a brain for duplicates, and that quietly changed what the module is for. How it continued. Barely a week after the first post, a different client site handed us the next problem – and this time it wasn't missing metadata, it was duplication, and a lot of it. ~10,000+ images on the site, of which only ~3,500 were actually unique – meaning roughly 6,500 exact-or-near-duplicate copies of the same pictures scattered across lead_image, body_images, galleries, repeaters, you name it. Years of "just re-upload it on this page too." So we went looking for a way to make duplicates stop mattering – without migrating anything. The full rationale is in the repo (docs/deduplication-design.md); the gist: Give every image a content identity – a byte hash (xxh128, md5 fallback), computed lazily and cached by path+size+mtime, with a cheap size/dimension pre-filter so we only hash real candidates. Group identical images into clusters = "this picture, in these K places." Then duplicates become manageable, not just visible: a Duplicates filter, a copy-count badge per image, an expandable cluster in the table (a cluster modal in the gallery), where-used per cluster, and the big one – edit-once-propagate: caption/tag a cluster once, written to all copies. Pure DB writes, fully reversible, zero filesystem risk. Optional, opt-in, reversible disk reclaim: byte-identical copies get hardlinked onto one inode, so 6,500 copies stop costing 6,500× the bytes. Lossless, runs in the background (on save + hourly), with Scan / Re-measure / Revert tools and a live "disk reclaimed" readout. (We tried perceptual near-dup detection too – dHash/pHash — and pulled it: it grouped unrelated photos that merely share a tonal layout. Detection-only, never destructive, and still not trustworthy enough to ship.) And then it clicked. What we'd built, almost by accident, was a DAM without the DAM. Strip a digital-asset manager down to what it actually gives you: one logical asset instead of scattered copies, metadata edited once as a single source of truth, a "where is this used," a central place to browse and pick – and storage that doesn't pay for the same file twice. Every one of those falls straight out of the content-identity + cluster technique. The difference: we get it over the images already sitting in native FieldtypeImage fields – the asset layer is synthesised from what's there, not a store you migrate into. No central library, no new page type, no migration, and crucially no template changes. That last part is the whole point: on some of these projects, re-wiring every template and every chunk of content onto a new media model would be a multi-week job and a regression-test nightmare. We just… didn't have to – and the editors get the DAM experience anyway. A word on MediaHub. If you are starting a fresh project and want a proper central media model from day one, MediaHub is – in our opinion – the best option out there. Huge thanks to @Peter Knight for letting us test it; we're genuinely impressed, it's a lovely piece of work. Different tool, different job: new site → MediaHub. Existing site full of scattered images → this. Image Library isn't trying to change the way PW image handling works; it's a layer over the files, pages, templates, methods and structures you already have. Which is exactly the rule we build by: must work with existing installations, as-is; plug & play – install, open, done; no rebuild, no migration, no new fields, no template surgery; no new workflow for editors; and – new – front-end-editor capable. BAM. 💥 That last one is the other big addition: two optional, off-by-default picker add-ons: Choose from library – a button on every image field to assign an existing library image without re-uploading (version-aware: inside a page version it lands in that version's folder, and it's deduped on the spot). Insert from library – a button in TinyMCE and CKEditor that drops a library image straight into rich text… and it works in the front-end inline editor (PageFrontEdit) too. Editor live on the page, click, pick, done. Plus, while we were in there: Collections – a hand-picked set of images no filter could reproduce (tick the ones you want, save them as a named tab). Recalled by a tiny ?coll=<id> link – the image list lives in your user profile, not the URL, so a 100-image collection is still a ~12-character link. Add/remove just by clicking a collection's tab while images are selected (the cursor tells you which way it goes), and collections are themselves filterable. Masonry gallery view – height-balanced (shortest-column) packing, natural aspect ratios, hover-revealed selection checkboxes – the same selection that drives bulk edits and collections. Status. v0.55.0 – public beta on top of the original. Module + docs (EN + DE concept, plus the dedup design doc) on GitHub / the Modules Directory. As before: feedback very welcome – especially duplication in the wild, odd Fieldtype combos in custom-field templates, ProFields, deep Repeater/RepeaterMatrix nesting, and anything the front-end picker trips over. Cheers, Mike

Hi @ukyo, thanks for this great module! It's a real time saver 👍 According to the README, this module supports focus and position mapping, but the focal point is ignored when rendering the image. It simply performs a center crop. Focus and zoom applied in Image field: Rendered output via $image->render("landscape"):

Hi @maximus I am using SEOMestro at the moment but saw that this module has a convenient migration feature for that case. Really nice! Is it possible to automatically add a "suffix" to the meta_title? What I like to to is created titles like: "Home | my-company.com" or "Our Services | my-company.com" Where the first part is the actual page title and the second part is my suffix text. Is it somehow possible to define this pattern in the global configuration of the module inside this global defaults JSON? { "meta_title": "field:title", "meta_description": "field:summary|truncate:160" }

I'm trying out this module at the moment. It's looking really good so far except that my top page and top landing and exit pages are all /pwna-track/ Am I missing a step to exclude pwna-track ? Thanks for all your effort though - it's a great looking module and something I'm sure I'm going to find really useful.

@zilli this is such a great progress review you gave us here. From "not knowing where to start/anything" to trying and exploring, finding solutions and new options, and even noticing that nothing is perfect on first try but iterating on it can you bring you quite far. 3 months ago I had to ton of ProcessWire skills in my projects to be able to get things done in a proper and clean way, but since Ryan started to explore and use AI more and brought us AgentTools, I skipped my skill files in projects that use AgentTools. It's working perfectly fine so far. Modules are sometimes edge-cases but at the end everything started to work as intended. I love to explore more tools, guidelines, agents, harnesses, models, and whatever the latest hype is. But at the end of the day I mostly only use OpenCode with Z.AI and the OpenCode Go plan to get things done. Sometimes for really huge tasks I try the Opus models through Windsurf/Devin ($10 legacy plan ftw!). What I learned with trends and hype cycles... wait a week or two. If people still talk about it, try it. Otherwise don't even care. Gastown? Beads? OpenClaw? Ralph Loop? Karpathy XYZ? SpecKit? [...] - meh. Not really. Looks nice, may work for some, but not for me.

@cb2004 There was a lot of FA data that didn't need to be there. I've deleted it, so we should be down to ~1.6 MB now. @jploch The problem I ran into is that it's just too many icons to display at once, it made the whole window lag. We could always add a link to a page with all the icons on this site, or at the font awesome site?

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.

Update: Withdrawals tab + Stripe custom fields (v 1.1.0) Hi all, a quick update on StripePlAdmin, the companion admin module for StripePaymentLinks. Two new things in this release: Withdrawals tab Surfaces the right-of-withdrawal (cancellation) requests that the main module stores per user (spl_withdrawals repeater). Same architecture as the other tabs — configurable columns, status/date/search filters, CSV export — plus inline-editable status and admin notes that save immediately via a small CSRF-protected AJAX endpoint. Consumer name/email link straight to the user account. The tab only shows up when the main module actually provides the feature. Custom Fields column Stripe checkout custom fields (the ones you define on a Payment Link) are now read out of the stored stripe_session meta and shown as Label: Value pairs — text, numeric and dropdown fields (dropdowns mapped back to their option label). It's a configurable column on the Purchases tab, flows into the CSV export, shows up in the purchase-details modal, and is included in the search. As always, feedback welcome, Cheers, Mike

Yeah, this definitely needs to load from CDN.

This is now a massive download with the Font Awesome changes.

Hey, just a follow up here 🙂 Following the advice in this thread, I’ve been pretty happy with Codex CLI so far. I also tried Claude, but I ended up using Codex more. From what I’ve seen, both can do the job well. Most of the time, when something goes wrong, the problem is on my side 🫣 Usually weak planning, a vague prompt, or both. I’m still very much at the beginning, so there’s a lot to learn. But these are a few things that have been working for me: I treat AI like a very competent junior developer. Most of the time, I plan the task first and then ask him to execute. I might promote him to associate if things keep going well 🤣 I’m using the $20 Codex plan. You can actually get quite a lot done with it if you spend some time planning before asking it to code. I’ve just started using RTK to save tokens. I’m not sure yet whether it’s worth it, but I’m giving it a try. I’m comfortable with the CLI, so my setup is pretty simple: Arch Linux, Codex CLI, phmate, sqmate, and gog. I don't use MCP. Reading the model documentation and best practices has helped a lot too. It gives you a better understanding of how the model works. From there, it’s much easier to build your own workflow instead of just throwing prompts at it and hoping for the best. One of the most important things for me has been mindset, and I had to work on that quite a bit 😅 Before AI, building a new feature or even fixing bugs could take days, weeks, or months. Today, you can sometimes get something working in minutes. That’s incredibly powerful, but it can also be dangerous, especially for newer developers. The temptation to expect everything to be done in minutes or hours is huge, but reality is often more complicated. Maybe things will be different in the future, but for now, I’m perfectly happy spending a few days on something that would have taken me months before. That still feels like a big win. Finally, I wanted to ask @ryan and the others: are you using any additional guidelines, like the Karpathy Guidelines?

Hi everyone, Accessibility overlays have a bad reputation — mostly because they're sold as SaaS, phone home to third-party servers, and charge monthly fees for something that should be built-in. Ally is different: self-hosted, MIT, no external requests at runtime. GitHub: https://github.com/mxmsmnv/Ally What it does Adds an accessibility panel to your site's frontend, powered by Sienna (MIT). The JS bundle and OpenDyslexic font ship with the module and are served from your own server — nothing loads from external CDNs at runtime. Font size adjustment Dark, light, and high contrast modes High/low saturation, monochrome Dyslexia-friendly font (OpenDyslexic, bundled locally) Highlight links and headings Letter spacing, line height, bold text Reading guide, stop animations, big cursor 53 languages with auto-detection from html[lang] or browser settings Full ProcessWire multi-language support — maps $user->language to the correct locale automatically Configurable position, offset, button size, and accent color Skips admin pages and Chrome Lighthouse by default No build step — prebuilt JS bundle included. One caveat: the widget is injected via Page::render hook. If you serve pages through ProCache static HTML, the hook doesn't run on cached pages — exclude those pages from ProCache if you need the widget there. Overlay widgets supplement, but do not replace, accessible markup. Use Ally alongside good semantic HTML, not instead of it. Requirements: ProcessWire 3.0.200+, PHP 8.1+ MIT License.

Hi @ukyo, when this module is installed, attempting to crop an image using the 'Crop' function results in an error, which prevents the image from being cropped: Given filename is not a file or link: /../site/assets/cache/WireTempDir/.PFM0.80307900T1780994336Rbdli4W6dXi/0/abc.713x276.jpg-tmp.jpg

@AndZyk I know I can look them up, but it would ne nicer to have them in the backend directly without opening a new page. Since we use them so much in the backend, I think it's worth it.

@jploch You could search the icon on Font Awesome (https://fontawesome.com/search?s=solid&ic=free-collection), but yes it would be more convenient to have a grid view. 🙂

@ryan Great update! I really love the updated icons in the backend! One issue I have with the current implementation is that we’re missing the grid view from before. I know there are a lot more icons now, but the grid view would still be helpful. With the new update, you always have to type something into the search bar first, but often I am browsing for a specific icon visually, before knowing the name. Another option would be a custom seletct that shows the icons before the text.

I'll take a look in the near future, I think it's possible to automate this somehow.

There are still a few modules left to do...

So... to keep up with your awesome modules, I decided to up my caffeine-intake to 1,200mg per day now. I love it! 🤯

Thx for the loveletter @gebeer and others. I thought I've already replied, but it seems that post got lost. I'm getting a lot of 500 errors these days in the forum. I wouldn't say I've quit the community. What I've stepped away from is making significant investments in the ecosystem and trying to build a business around it. That didn't work out for me, so I had to move on. As for RockMigrations: I understand and even share some of the concerns raised here (even though I find terms like "bloated nature" a bit harsh). It started as a somewhat experimental proof of concept, and yes, I built it with my other modules in mind. At the same time, it has always been completely free because I felt it was too important to put behind a paywall, and it has always been open to PRs. 😉 Nevertheless, over time it turned out to be very reliable and became an essential tool for my work. Considering that all my ProcessWire projects from the last decade rely on it, I expect it will remain supported for quite some time. That's the status quo. What I did find a little surprising, though, was seeing migrations become part of the core years later, seemingly almost overnight, while RockMigrations and the other migration modules weren't much of a reference point in that process. Unfortunately, it's not the first time I've seen that happen. What I learned from that experience is that it's not something I can build a business on. So I really haven't quit on the community — I've simply moved on from trying to build a business around my ProcessWire contributions, and my reduced forum activity is just a consequence of that. But I check in from time to time to see what's going on and I try my best to be available and helpful if anybody needs anything related to my modules. 🙂