Recently Updated Topics

Update – Auto-Sync for third party modules – v0.2.0 Hi, folks, a new feature for the GitSync module: for public third-party modules where you can't add a webhook on the source repo, GitSync can now check for upstream updates automatically. How it works Every linked module has a new per-row "Auto-Sync" setting in the GitSync overview: off – manual sync only (default) notify – on the first admin page load per session, GitSync queries GitHub for the tracked branch. If a newer commit exists, a warning notice appears with a direct link to the branches view: auto-sync – same check, but performs the sync immediately without confirmation. Once a remote update has been detected, an orange "update available" badge stays on the GitSync overview next to the affected module – so the info is still there after dismissing the notice. Throttling and scope Checks run once per session (right after admin login), not on every page load. Webhook-active mappings are skipped entirely. GitSync itself is excluded from auto-sync – self-updates remain manual. Why we built it Webhooks are the cleanest path for repos you own. For public modules from other authors you don't control, you'd previously have to remember to check for updates manually. Now the module nudges you on login (or syncs straight away if you trust the upstream). Feedback welcome, Cheers, Mike

Version 2.0.3 https://github.com/matjazpotocnik/ProcessFileEdit I can not add "overflow:hidden" in a css file. Also "include" is not possible in a php file… probably because of security reasons…

I just did, but still waiting for approval. Cheers R

Some additional thoughts on using AI for PAGEGRID development: https://page-grid.com/blog/ai-as-a-tool-not-a-replacement/

@AndZyk I think the issue is that the Jumplinks module is in the root namespace (rather than ProcessWire namespace), so the module has to be compiled. The dev branch recently moved ModuleConfig from being part of the bootup loader to loading on-demand. I've reversed that so that ModuleConfig is now loaded at boot, which should fix that issue. Though let me know if not. Thanks.

StripePaymentLinks 1.2.0 — Electronic withdrawal for B2C distance contracts Hi all, just shipped new version of StripePaymentLinks, which adds a complete electronic right-of-withdrawal flow for online merchants. Why now EU Directive 2023/2673 (amending the Consumer Rights Directive 2011/83/EU) requires every online trader selling to EU consumers — goods, services, or digital products — to provide an easily accessible "withdrawal button" by 19 June 2026. Member states had to transpose the directive into national law by 19 December 2025; Austria's FAGG amendment is one of the implementations now landing. The guiding principle: withdrawing from a contract must not be more burdensome than concluding it. This module ships an electronic withdrawal flow that satisfies that principle, with all legal wording editable per site so it works under any national transposition. What's new Withdrawal modal on every frontend page — Bootstrap 5 modal with form → confirmation → success steps. Renders only when invoked (link or ?withdraw=1 URL parameter); zero overhead otherwise. Per-user withdrawal log — every submission is stored in a repeater on the user template (spl_withdrawals) with timestamp, products affected, salted HMAC-SHA256 IP hash, and a status field that the merchant can update from the backend. Two-mail flow — the customer gets a confirmation of the withdrawal, the merchant gets an internal notification with a direct link to the user profile. Both go through the existing universal mail layout. Order-confirmation mail now includes a consumer-rights block — auto-injected for every purchase, with two outcomes depending on the product: Right of withdrawal applies → withdrawal instructions are rendered. Right has been waived (e.g. immediate digital delivery with explicit consent) → waiver acknowledgement is rendered. Site-editable legal text — two TinyMCE config fields (mailWithdrawalText, mailWaiverText) let each site operator write the exact legal wording their jurisdiction requires. Placeholder system including {products}, {provider}, {contact_email}, {order_id}, {order_date}, {name}, {email}, {today} and — for the TinyMCE editor — anchor-pair placeholders that survive the editor's href-stripping: {withdrawal_mail}TEXT{withdrawal_mail_end} → expands to a prefilled mailto: link (subject + body from translatable defaults) {withdrawal_online}TEXT{withdrawal_online_end} → expands to a ?withdraw=1 deeplink that auto-opens the modal Built-in protection — honeypot field, per-IP rate-limit, server-side CSRF, deliverability headers (Auto-Submitted, X-Auto-Response-Suppress, proper Reply-To). Setup is a few field saves ... In the module config there's a new Withdrawal fieldset with five fields: Internal notification email (falls back to $config->adminEmail) Contact email shown in the form (falls back to sender email) Privacy policy page (page-select) Withdrawal text — right of withdrawal applies (TinyMCE) Waiver text — right of withdrawal does not apply (TinyMCE) The module creates all required fields, the spl_withdrawals repeater and status options on first save / module upgrade — fully idempotent. ... and adding the trigger link to your templates The withdrawal modal is auto-injected on every frontend page — you only need to render a link to open it. The module ships a helper for that: echo $modules->get('StripePaymentLinks')->renderWithdrawalLink(); That gives you the legally required, always-visible withdrawal entry point. Typical place: site footer or account menu. The helper takes two optional arguments — a CSS class and a custom label — so it adapts to whatever markup your theme uses: echo $modules->get('StripePaymentLinks')->renderWithdrawalLink('nav-link fw-bold'); echo $modules->get('StripePaymentLinks')->renderWithdrawalLink('', 'WITHDRAW'); Anything that links to your site root with ?withdraw=1 also auto-opens the modal — useful for putting a direct withdrawal link inside order-confirmation mails, transactional notifications, or PDF receipts. That's the whole frontend integration — one helper call, no JavaScript wiring, no modal HTML in your templates. Translatable All UI strings (modal labels, mail subjects/bodies, status names) are PW-translatable. Happy to hear feedback, edge cases, or implementation experiences from other EU jurisdictions. Cheers, Mike

Hi @Nomak Just a query. I'm not pitching for the work as I am busy. But when you say... Do you have distinct mockups for each of these from the agency?

@maximus The ProcessWire Upgrade module currently suggests your module as an update for existing Pages2Pdf installations. Some of my clients have "just clicked update," which immediately broke their PDF generation. To prevent further broken production sites and support overhead for other developers, could you please consider renaming your module to something unique (e.g., MaxWirePDF or PdfEngine)?

Hey everyone I'm pleased to report that MediaHub 1.16.0 has been released. Here's a breakdown of the changes. The next release will optimise bulk upload and crops. I will also add integrated focus points cropping. 1.16.0 Changelog Admin navigation Optional MediaHub link in the admin top bar. A new module setting (Show MediaHub link in main navigation) adds Media Hub to the admin top bar. Custom label for the top-bar link. When the top-nav option is on, a new Custom label field lets you override what appears in the top bar. Useful when the localised "Media Hub" string is verbose or when your team prefers a different term (Media, Assets, Library, DAM). Leave blank to keep the localised default. Setup → Media Hub label is unaffected. Library and inputfield Drag-to-reorder thumbnails in MediaHub fields. Just like the native InputField, you can reorder thumbnails to take advantage of first() and last() etc. Works across any view mode (grid, proportional, detail). Master "select all visible" checkbox in the table view header. Tick the column header to select every row currently rendered; untick to clear. "Add more" button now matches stock InputfieldFile Font, colour, hover state, and icon spacing across AdminThemeUikit, Reno, and Default are more consistent Bug fixes Library search now covers Alt/Description, Labels, and Collections. Previously search only matched the asset title and filename. Searching by exact ID is also now reliable. Renamed filename and title in the upload queue are now applied on upload. Editing the filename stem or title in the upload queue rows had no effect; the values were not transmitted to the server. Both fields are now picked up and saved with the new asset. Duplicating an asset preserves its Collections and Labels. Cloned assets were losing the page-reference fields. Both are now copied explicitly to the new asset. The duplicate confirmation message also clarifies that crops are not copied (they can be re-generated on the duplicate). Cleaned up a stray PHP warning in the library view left over from the v1.15.0 Tags → Labels rename. PHP 8.5 deprecation notice in the MediaHub inputfield resolved (explicit nullable parameter typing). Defensive changes Server-side upload batch limit now matches the configured browser-side limit. Previously the server hard-capped to 50 files per request even if Maximum upload batch had been raised higher; both ends now read the same setting. Bulk-import requests are now capped at 500 selections per request. Selecting thousands of existing site images at once was holding a single PHP request open for many minutes with no progress feedback and no resume path on failure. Larger jobs now surface a clear message asking you to import in batches. Upload temp-file cleanup window extended from 60 seconds to 5 minutes, to avoid deleting an in-flight temp file mid-write on slow connections. Container pages at the site root reinforced as hidden + system on upgrade, so the data-tree containers (Media Hub, Labels, Collections, Assets, Crops) cannot accidentally appear in front-end navigation. Security Import-by-URL is now safer on shared and self-hosted servers. Imports from external URLs are now hard-capped at 5 MB per file and refuse URLs that resolve to private or reserved IP ranges (mitigating server-side request forgery), and reject any non-HTTP(S) protocol on the initial request and on any redirect. Cheers Peter

Hi all, Does anybody notice this with 3.0.260? It happens when wire folder in the root installation folder is a symlink to other folder. Gideon

Hi Mikel and SEO specialist Thanks for taking so much time to list your thoughts. I completely agree, and it's a testament to both SEO Modules and ProcessWire itself that they have worked together for so long. I hope my original post doesn't come across as a criticism of either Module or the developers. Life moves on, and understandably, the developers have new priorities. Yes, agree too. And I don't intend to recreate existing Modules simply for the sake of it. But I also want SEO Neo to rely on other modules as little as possible. So it's likely that SEO Neo will act as an umbrella/coordinating layer for companion Modules. All working together. It's an ambitious task, but I would prefer to build from the ground up with modular components (sub-modules) that can work together rather than end up with a Module which relies on various "3rd party" modules. I realise this somewhat contradicts my earlier statement. But to answer your specific points: SEO health (missing descriptions, duplicate titles, noindex flags) as a Lister-based audit view – this genuinely doesn't exist in the ecosystem yet Yes, this is on the roadmap and has been on my mind for some time. The module should have an SEO health dashboard that can display the basic rolled-up audit of your site. I use SEM Rush extensively (alongside several other SEO tools). SEO Neo won't try to replace them, but will surface critical issues within PW itself. I see this as a big benefit to SEO specialists, developers and editors, even if it serves as a launch pad for deeper investigation via more powerful SEO tools. 404 hotspots from the logger with a "create redirect" action wired into ProcessRedirects Yes, this is being developed currently with a focus on 404 logging. AI crawler activity from Wire Request Blocker Have added to the roadmap. SeoMaestro field status across templates SEO Neo will have a field status overview if that's what you mean? It won't report on other SEO modules' gaps. Native urlSegments support – as psy mentioned earlier in the thread, currently needs a hook in SeoMaestro urlSegments is done and working since my last post. I am stress testing on a larger site shortly. Canonical, og:url, twitter:url and hreflang all preserve $input->urlSegmentStr() natively. I also have a config setting for sites that want segments collapsed instead. The hook needed for SeoMaestro isn't required in SEO Neo. Yoast-style content analysis with traffic-light scoring – tends to produce text optimized for the algorithm rather than the reader. I am keen for SEO Neo not to become a Yoast copy. Schema.org helpers with documented hooks – ready-made generators for the common types (Article, FAQPage, Person, Organization, BreadcrumbList) that developers can call from templates. Not auto-detection (that doesn't work without explicit mapping), but a clean API. Noted. Finally, the rollout of SEO Neo's core module and individual components will likely be phases. The Neo in SEO Neo is more a nod to a new approach rather than Nearly Everything at Once. P

Honestly, you’ve got everything you need with just the files and a database dump. I’ve done this exact migration a few times, and ProcessWire is actually one of the easiest CMSs to move because it doesn’t hardcode paths in the DB. Just upload your files to the Ubuntu server, import the SQL via phpMyAdmin or CLI, and update your /site/config.php with the new database credentials. The only real "gotcha" is usually file permissions or missing .htaccess—make sure mod_rewrite is enabled on the new Ubuntu box and double-check that your /assets/ folders are writable by the server, otherwise your images won't render. You definitely don't need a fresh install first; just "drop and swap" works fine.

Honestly, for a local dev environment, it’s mostly just an annoyance. The main "risk" is that your timestamps for things like page edits, logs, or scheduled tasks will be an hour off. If you’re just building and testing layout or logic, you can safely ignore the warning. However, if you're testing anything time-sensitive (like countdowns, expiring links, or publishing schedules), that one-hour gap will definitely trip you up. Instead of changing your whole system, you can usually just sync them in your config.php as the error suggests: PHP $config->timezone = 'Europe/Paris'; Since it's just your local install, it won't affect your physical clock, and it makes the warning vanish. If the time difference bothers you while looking at the "Last Modified" dates, just keep it as is—nothing is going to "break" the database.

Hey! Yeah, that's a classic snag with ProcessWire's Repeater Matrix. The ->type property actually returns the "name" (slug) of the type, but ->label isn't a direct property of the item itself. To grab the human-readable label, you have to pull it from the field's definition. You can do it like this: PHP $label = $item->getRepeaterMatrixType()->label; echo $label; Essentially, $item->getRepeaterMatrixType() returns the actual type object, which contains all those extra details like the label, icon, and description. Super handy if you're building out a custom page builder and want the UI to match the backend!

Hi all, SYMPTOM When creating or editing a page with Chinese characters in the page name (e.g., 關於我們) while $config->pageNameCharset = "UTF8" and $config->pageNameWhitelist = "" (empty), a fatal error occurs: Fatal Error: Uncaught ValueError: idn_to_ascii(): Argument #1 ($domain) must not be empty in Sanitizer.php:1138 Environment PHP 8.4 ProcessWire 2.6.260 I create an bug report in github https://github.com/processwire/processwire-issues/issues/2215 By the help of AI, I found the root cause. 1. The pageNameHasConflict() method in PagesNames.php calls $sanitizer->pageName($name, Sanitizer::toAscii) to convert the UTF-8 name to ASCII for duplicate name checking. 2. Sanitizer::pageName() triggers punyEncodeName() to encode the Chinese characters using Punycode. 3. Inside punyEncodeName() (line 1085), when $version > 1, each character of the name is checked against $config->pageNameWhitelist. 4. When pageNameWhitelist is empty (""), every Chinese character fails the whitelist check and gets replaced with "-" (hyphen). 5. After collapsing consecutive hyphens and trimming leading/trailing hyphens, the result is an EMPTY STRING "". 6. The empty string is then passed to PHP's idn_to_ascii() function (line 1158), which throws ValueError because it requires a non-empty $domain argument. Gideon

Hi all, a small confession from the frameless corner of the PW universe: in the last 15 years we've spent way too many evenings doing the same FTP-shuffle on shared hosting. Delete everything in site/, drop the DB via phpMyAdmin, re-upload, run install.php, log back in, find out the bug we were chasing only reproduces after a reset, sigh, repeat. The reason we do this on real hosting at all is that the gnarly bugs in modules-under-development never show up locally — AllowOverride, mixed file ownership, mod_security, you know the drill. But "let's test cleanly on the real server" and "no SSH access" don't combine well. So we built ProcessWireReset: a module that wipes a PW install back to clean profile state from inside the admin. No SSH, no FTP, no phpMyAdmin. Click the button, log back in, you're at a freshly installed PW with your superuser intact and any modules you marked as keep re-installed automatically. A few things worth knowing, since destructive modules deserve some care: Modules to keep + Directories to keep. Two fields in the config: one picks which modules survive (transitive dependencies included), the other is a free-form list of paths under site/ that should be spared by the cleanup — handy for things like templates/RockIcons or assets/backups that live outside the module directories. Custom tables go into a snapshot. After the reset you can pick which module-specific tables to restore. Auto-restoring everything turned out to fight with re-installed schemas more often than we liked. The reset can crash mid-way — a kept module's install() can fatal in surprising ways. The confirmation modal hands you a one-time recovery URL with a 256-bit token. If the worst happens, that URL gives you a clean reinstall with your original credentials. Belt, braces, and one extra strap. It's interactive only. No cron triggers, no CI hooks. The destructive button has a real human in front of it, on purpose. Pairs nicely with GitSync: If you're already using our GitSync module, ProcessWireReset is the missing other half. GitSync pulls a fresh module version from your GitHub repo into the live install at the click of a button — but it doesn't touch the DB or re-run install(). After a GitSync pull that changed schemas, fields, or admin pages, the previous install state and the new code drift apart. Hit Reset, the module is removed and re-installed cleanly from the freshly pulled code, and you're testing what you actually shipped instead of a frankenstein of old DB state and new files. That GitSync → Reset → test loop is what we use daily on shared-hosting test installs where SSH isn't an option. Repo (MIT): https://github.com/frameless-at/ProcessWireReset Modules Directory: https://processwire.com/modules/process-wire-reset Caveat the obvious: this thing is for development, not for production. Treat it accordingly. Curious to hear what you build/break with it. Bug reports and pull requests welcome. Cheers, Mike

I will most definitely be watching this progress. Thank you!

I might repeat myself here but: 🤯 The idea and concept of collections in addition to the interface. That's a great one!

I feel that! But it became way better than it was a few years back when the world was going nuts. The things I changed in the last 12-18 months: getting all the regular vitamins and supplements for someone my age getting additional supplements that help my brain to keep working checking in on gut health and eating less/none heavily processed foods checking calories and protein in-take - fixing both and removing empty carbs and calories getting back to the gym - first only cardio, now additional strength training All the above helped me to not being stressed out everytime and all the time. I couldn't care less about things thrown at me these days. A full day with meetings, a workshop, and a coffee with friend somewhere in-between, and of course the usual time at the desk don't affect me in a negative way anymore. I don't know how the math works here, but these days I have enough hours each day to have plenty of time, even time to balance everything out. PLUS the weekends for side-projects, fun, friends, family, and just things.

I'm blown away by this. 🤯

Thanks Adrian, once again.

Sounds just about right to me, yes. At least for my use cases that would be a big leap forward; it would put me/us to control of when and where scheduled tasks run 🙂 I do like the database approach of WP cron because it gives me clear view of the landscape, so to speak, but honestly that may not be necessary at all. And perhaps something very similar can already be achieved.

I think today represents an important milestone in running a good model locally. See what Antirez (creator of Redis) has released. Tweet embedded below. Does anyone have an Apple M3 with 128gb RAM? I'd be interested to hear how it goes if you run it.

ProcessWire is more alive than ever.

Fix is confirmed. Installed the latest version from Github and it's working as before. 🎉 GLM is pretty nice. Feel free to test it a bit more using that key.