Leaderboard

Hi everyone I've started a new module called SEO NEO It's a new SEO module built for today's SEO, on today's ProcessWire. I hadn’t planned another module, but I keep returning to the same niggling thought: SEO is too important to our clients' sites (and businesses) to depend on modules that are not being actively developed keeping pace with how SEO works today. So that's pretty much it. SEO NEO will be free. An Ultra/Pro version will follow and include genuinely useful additions for industry professionals. I'll have more soon, but if you have any SEO requests, my DMs are open. Cheers Peter

There is nothing good about imperial 😜

I use VSCode and have been a subscriber to GitHub Copilot for a few years. I didn't pay much attention to the plan I was on until I started using agentic coding in ~October 2025. I then realized what made GitHub Copilot a ridiculously good value, as others discovered as well, was that it works on a "per-request" billing model. In short, if you knew what you were doing (I didn't realize this fully at the time), you could use a high-end model like Opus 4.5, which costs 3 credits, and if just have it rip for HOURS on a task and it would only cost 3 requests (lower end models would be 1 request). With the cheapest plan on GitHub Copilot, it is (well, now WAS), $10/month which gave you 300 requests. A lot of people took advantage of this... imagine paying $10/month and getting like $5000/$10,000 worth of value (ie, what would be the real cost of per-token billing) out of it per month! Absolutely insane. Microsoft understandably put an end to that last week because they were losing their shirts: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ In short, they are one of the first to go per-token/per-usage billing and I suspect others like Anthropic and OpenAI will eventually follow suit. It's only a matter of time given the economics of it all. However as you may know, the Chinese AI labs are extremely competitive with their AI offerings and have both monthly plans and token-based plans (generally 90% less cost) and of course, they release the models outright. Because of what Microsoft did, I've been experimenting with the various Chinese models via OpenRouter (and still using VSCode GitHub Copilot "Bring Your Own Key" which they support), so it's basically the same experience. However there seems to be a lot of advancements in high density, low parameter models (Qwen3.6 27B, Deepseek V4 Flash) which can be run on consumer hardware at good speeds and output that is not far behind something like Sonnet or Opus, or at least catching up quickly. I haven't owned a discreet GPU in many many years (I don't game), but I believe with a RTX 5090 and 64-128GB of RAM, it can be done. Don't quote me on any that however... I haven't dived into this world yet and don't yet have an understanding of all the settings that determine how well an LLM runs and how it affects its intelligence. I'd be interested to hear anyone who is playing with this idea: What models are you using? What hardware? What software are you using to run it?

Ditto. One thing missing in SEOMaestro is support for urlSegments. Fix is via a hook. Be great if SEO NEO supported urlSegments natively. Looking forward to seeing the new module 🙂

Hi everyone, I made a small fieldtype module for storing product dimensions: https://github.com/mxmsmnv/FieldtypeDimensions FieldtypeDimensions lets you store length, width, height and optionally weight in a single field. It’s mainly useful for product/catalog/e-commerce pages where dimensions are needed for display, shipping or filtering. Supports different units (mm, cm, m, in, etc. for length and g, kg, lb, etc. for weight) and stores values internally in mm/grams. The module also supports multilingual setups — admin field labels are available in 20+ languages and can be configured globally. Basic usage example: $dim = $page->dimensions; echo $dim; // 120 × 80 × 50 mm, 1.5 kg echo $dim->lengthIn('cm'); echo $dim->weightIn('kg'); Selectors: $pages->find("template=product, dimensions.length>100"); $pages->find("template=product, dimensions.weight>500"); More details in the README. Feedback and suggestions are very welcome.

Hi @maximus - thanks as always! Would you mind giving us a basic list of differences compared to: https://processwire.com/modules/fieldtype-object-dimensions/ so we can make an informed decision about which might be better for our needs? Is it basically just the additional weight subfield? Thanks.

Very impressive work and nice PW integration too. Im guessing the images have text embedded in them and that’s why you want mobile portrait versions? TBH I normally find centering + object-fit: cover handles a lot of situations gracefully. I saw some nice work recently by @Stefanowitsch where he had specific mobile crops for hero images. He might be a good person to ask.

I'm back from the future lol. I studied some php in the mean time and I understand what use and & do now haha. https://www.johnfarrell.fr Eventually got round to implementing things. There are still a few things to fix overall. Your suggestions work well, I used slideshow image tags and it pulls in images into my home page slider from a WireArray based on that. Only thing is, it would be nice if I could change the images for mobile portrait layouts, based on the user-agent. Some of my designs don't really suit portrait viewing. I thought about using MobileDetect, and make the slider pull images with another tag, say slidermobile. It looks like that doesn't play nicely with ProCache though... I don't want to change the url for mobile either...as I've printed qr codes for the site already 😅 Any suggestions? A PHP solution would be nice but maybe JS is needed. I may make a seperate post in case others find this useful. The last topics on this are old:

@Peter Knight sounds great. I am still using SeoMaestro on every Project but I am interested in every module that covers this topic.

I actually came across the need for this as well. @ryan - could we perhaps have: $page->isUrlHook In my case I have url segments enabled on the homepage and some logic to process them, but that logic can't tell if it's a urlsegment or a path created by a URL hook. I ended up with this for now: $urlHookSegments = []; $pathHooks = $wire->hooks->pathHooks ?? (new \ReflectionProperty($wire->hooks, 'pathHooks'))->getValue($wire->hooks); foreach ((array) $pathHooks as $hook) { $match = $hook['match'] ?? ''; if (preg_match('#^/([^/{(]+)#', $match, $m)) { $urlHookSegments[$m[1]] = true; } } if ($input->urlSegment1 && !isset($urlHookSegments[$input->urlSegment1])) {

Hi @adrian, great question — happy to clarify. Both modules store L×W×H, but the focus is different: FieldtypeObjectDimensions (juergen) — geometry-oriented: auto-calculates and stores area and volume, useful when you need spatial calculations. FieldtypeDimensions (mine) — shipping/e-commerce-oriented. The reason it exists: I've been building a package forwarding platform (think Qwintry-style — customers ship packages to a US warehouse, we consolidate and forward internationally). That platform, AltaPost, never launched at scale, but the logistics logic stuck with me. When I needed a dimensions field for product catalogs in ProcessWire, the obvious missing piece was weight — you can't quote a shipping rate without it. A lot of our shipments went to Europe, so we constantly needed to show the same package in both metric and imperial at once — 120 × 80 × 50 mm / 4.7 × 3.1 × 1.9 in, 1.5 kg / 3.3 lb. That's why the conversion API exists: no manual math in templates. Main differences: Weight field — fourth subfield alongside L×W×H, optional per-field Unit conversion API — $dim->lengthIn('in'), $dim->weightIn('lb') for passing values directly to shipping APIs (GoShippo, EasyPost, FedEx rates) or displaying both metric and imperial simultaneously Normalized storage — always saves in mm/grams internally; changing display unit never requires data migration 28 admin languages — useful when ProcessWire itself is configured with multiple languages and you want field labels to appear natively for each editor If you need area/volume stored and searchable — @Juergen module is the better fit. If you need weight + unit conversion for shipping integrations — this one covers that case.

Hi, everyone! While working on a client project we were looking for a way to let editors apply CSS classes to individual images in rich text fields — quickly, visually, and also in the frontend editor. ProcessWire already has several ways to get CSS classes onto images, so it's worth being precise about what this module does differently: TextformatterFluidImages adds one class to all images automatically — great for img-fluid across the board, but there's no per-image choice. TextformatterImageInterceptor is more powerful: editors tag images in the image field, and the Textformatter applies the corresponding classes at render time. The logic is developer-defined and centralized, which is exactly right when you want consistent, rule-based image treatment. But the class is invisible in the editor, applied only in the frontend output, and editors have to set the tag in a completely separate place from where they're actually working. TinyMCE's built-in styleFormatsCSS is the closest thing to what we wanted. You write CSS, ProcessWire turns it into a Styles dropdown. It works, but the dropdown is generic — it shows all defined styles regardless of what's selected — and there's a known accumulation issue where nothing prevents float-left float-right ending up on the same image. And it doesn't work in the frontend editor. What we needed was simpler: editor clicks an image, picks a style, sees immediately which styles are active, can combine them or remove them individually. No dialogs, no separate fields, no render-time magic — the class goes directly into the <img> tag in the saved HTML, visible and editable right there in the editor. That's what this module does: It registers a context toolbar in TinyMCE that appears as a floating "Image Style" button when an image is selected. For CKEditor the same options show up in the right-click context menu. The class list is defined once in the module settings and works across both editors — no separate configuration per editor type. Each entry shows a checkmark when active, clicking it again removes it, multiple classes can be combined freely. Works in the admin and in the frontend editor. Complete Readme on GitHub: https://github.com/frameless-at/ProcessImageClasses and the module directory. Any thoughts on further improvements welcome! Cheers, Mike

I tested on a site with ~12000 URLs, it seems to work fine 🙂 Right now, every user with page-edit permission can use the module, but there might be good reasons to restrict it to certain roles. Maybe you could add a "sitemap" permission to make this more granular?