All Activity

Hi Nomak, thanks for posting — this sounds like an interesting project. I'm Robert, a web developer based in Düsseldorf, Germany, doing both frontend and backend development. My frontend stack normally includes HTML, CSS (SASS/PostCSS), JavaScript (Alpine.js, htmx or Vue if needed), focusing on fully responsive (fluid) and accessible results. You can get a first impression of my work at robertweiss.de. I'm located in Germany and hold a valid EU VAT ID, so there would be no issues on the tax and legal side. I'd be happy to hear more about the project scope — for instance the size and complexity of the design, the number of templates/elements involved, and any specific interactions or animations expected. Knowing the budget you have in mind would also help me figure out if this could be a good fit for both of us. Looking forward to hearing from you! Best regards, Robert

Hi @Peter Knight Thanks for your reply! I have distinct mockups for the desktop version as well as for mobile - the tablet version must be derived from these mockups.

I remember that there were some attempts to create courses on PW, but none of them really stuck in my memory. I think it is better to make one's way through tutorials and read through the docs. There are some videos that can be useful. These come to mind: https://www.youtube.com/watch?v=IHqnLQy9R1A - a really dated walkthrough I have once started with; everything looks different but the essence is the same) https://www.youtube.com/playlist?list=PLOrdUWNK38ibz8U_5Vq4zSPZfvFKzUuiT - a comparaison to WP

Thanks for the fast response. Unfortunatelly the sync screw up the TracyDebugger (Error: Failed opening required 'C:\inetpub\wwwroot\site\modules\TracyDebugger/tracy-2.12.x/src/tracy.php') and I had to restore it form the GH repo. In the logs: 2026-05-13 09:28:15 admin http://localhost/processwire/setup/gitsync/sync/ [manual] Sync "TracyDebugger" branch "master": 1121 remote, 987 local, 980 to update, 980 to delete (134 preserved via .gitignore/.gitattributes) 2026-05-13 09:28:23 admin http://localhost/processwire/setup/gitsync/sync/ Using ZIP archive for 980 file update(s) (>50 threshold) ... 980 files updated ... 2026-05-13 09:28:27 admin http://localhost/processwire/setup/gitsync/sync/ [manual] Synced "TracyDebugger" to branch "master" (commit 068bbd9) – 980 updated, 980 deleted Not sure what happened, but when the site failed with the exception, the TracyDebugger folder only had 6 files on the root. Other folders, like assets, panels, includes were all missing. It's odd since the log shows: 2026-05-10 18:25:51 admin http://localhost/processwire/setup/gitsync/sync/ Updated: panels/AdminToolsPanel.php (8396 bytes) ... 2026-05-10 18:25:47 admin http://localhost/processwire/setup/gitsync/sync/ Updated: includes/post_processors/AdminToolsPost.php (4138 bytes) Will try to debug later, I'm at work now 🙂

Hi, @maximus, since we do not use OpenAI products (company policy) I haven´t tried Codex at all. But nevertheless, that workflow works — GitSync reacts to any git push, regardless of whether the commit comes from a human, CI, or an agent like Codex Cloud. @matjazp: Thanks for the detailed log — that pinpointed the problem clearly. Three fixes are now in main: PHP execution timeout lifted during sync (set_time_limit(0)). The 500 you hit was almost certainly PHP killing the script at 30–60 s, not GitHub timing out. Large diffs now use the ZIP archive endpoint. When more than 50 files need updating, GitSync fetches a single ZIP of the branch via /zipball/{ref} and copies from the extracted archive instead of hitting /git/blobs/{sha} once per file. Your 1115-file diff turns from ~1115 sequential HTTPS requests into 1 download plus local copies. GitSync now respects two sources at once: .gitignore (which spares Tracy's runtime files like logs/, dumps/, bluescreen/) and .gitattributes export-ignore (which keeps maintainer-excluded files like docs/ and .gitattributes itself off the live install). Both apply bidirectionally — files matching either are never added by the sync and never deleted from local. End result for TracyDebugger: install + first sync = "up to date" with zero unnecessary churn. Please switch to the GitSync branch refactor-install-from-Github in GitSync and give it another try — the log line for the sync should now show N to update, M to delete (P preserved via .gitignore/.gitattributes) – both N and M considerably lower than your original 1115/4430, and you'll also see Using ZIP archive for N file update(s) whenever the update count is above the 50-file threshold. We will merge the branch into main after some internal testing, so feedback is welcome 😉 Cheers, Mike

Hi Are there any online learning courses for processwire available? many thanks.

@Mikel, thanks for the clarification. Just for info, I've forked the ProcessWireUpgrade module and modified it so it can upgrade modules (and dev core) to the latest commit, even if there is no version bump. For the issues I have: the main issue is that the request timeout and I get http error 500 making the download incomplete. I have GH api key. 2026-05-13 05:12:16 admin http://localhost/processwire/setup/gitsync/sync/ [manual] Sync "TracyDebugger" branch "master": 1121 remote, 4437 local, 1115 to update, 4430 to delete 2026-05-13 05:12:17 admin http://localhost/processwire/setup/gitsync/sync/ Updated: .gitattributes (48 bytes) ... 2026-05-13 05:13:55 admin http://localhost/processwire/setup/gitsync/sync/ Updated: scripts/ace-editor/mode-batchfile.js (5187 bytes) All together it managed to fetch 268 files in ~100 seconds.

LoginPassKey has undergone some changes. Latest version is 0.3.1 available at https://github.com/clipmagic/LoginPassKey As well as some 'under the hood' security upgrades, you can now login without entering a username/email. Simply click the 'Login with PassKey' button and if all the checks pass, you're automatically logged into either the admin area, or the frontend via LoginRegisterPro depending on your config/setup. A full list of the changes available at https://github.com/clipmagic/LoginPassKey/blob/main/CHANGELOG.md

Another heads up for folks. It's not a PW bug but maybe could be considered a deprecation. I started getting this error: # ProcessWire\\WireException: Unknown column name(s) for findRaw: date_format.id in /wire/core/Pages/PagesRaw/PagesRaw.php:1816 ```php 1813 | protected function unknownFieldsException(array $fieldNames, $context = '') { 1814 | if($context) $context = " $context"; 1815 | $s = "Unknown$context name(s) for findRaw: " . implode(', ', $fieldNames); ► 1816 | throw new WireException($s); 1817 | } 1818 | } ``` The issue is that I had a table field (date_format) and a findRaw() that tried to load this array of fields: ['id','format','countries'] However table fields have no "id" field. In previous versions of PW this was silently ignored, but now the refactor of PagesRaw into wire/core/Pages/PagesRaw/ added strict column validation in findCustomField(), resulting in that exception. Hope that helps someone!

I think if you connect repositories to Codex Cloud, then configure GitSync on the server, it should work in auto-deployment mode. But I haven't checked. @Mikel you are try this chain?

Had a bit of fun with the latest DEV version and AgentTools version... yet ran into some issues. 1. I asked the Engineer to get a good grasp of the project, explained what it was for and what the Engineer should look at. Got this response: Refreshed the page, waited a bit and got what I was looking for. The result was on point and the next task was executed without issues, it wrote a migration and what i was looking for. 2. A bit later I asked the Engineer to answer a question I found here in the forums and got: Every request was using GLM 5.1 which can run long tasks and has tons of tools calls it can process. Just some findings I wanted to report.

Hi, @matjazp thanks for the report! We fixed it by removing the 3 calls. Just upgrade the module to 0.2.1 They solve different problems. ProcessWireUpgrade is for stable releases, GitSync is for branch-based development workflows. ProcessWireUpgrade pulls from the official modules.processwire.com directory and compares semantic version numbers. It can upgrade the ProcessWire core itself (master or dev branch) and existing installed modules, but it cannot install new modules that aren't already present, doesn't support private repositories, doesn't support arbitrary branches per module, and uses a pull model (no webhook / no auto-sync on push). Each upgrade is a full download. GitSync pulls from any GitHub repository — public or private (using a fine-grained Personal Access Token for the latter). It works at the branch and commit level rather than the release level, lets you switch any linked module to any branch, and detects changes by comparing git blob SHAs file-by-file, so only modified files are downloaded. It can install brand-new modules from a GitHub URL (even ones not listed in the official directory), supports private repos, and offers GitHub webhook integration for automatic sync on every push. It does not upgrade the ProcessWire core. When to use ProcessWireUpgrade: Production servers that should only move to officially released versions Upgrading the ProcessWire core itself Mostly relying on modules from the official directory When to use GitSync: Test/staging servers that should track a development branch (e.g. develop, feature-x) live Deploying your own modules from private repositories without FTP Installing GitHub-hosted modules that aren't (yet) in the official directory Auto-deploy on every git push via webhook They can be combined: use ProcessWireUpgrade for the core, and GitSync for modules that you develop yourself or that aren´t in the PW directory. To narrow this down — could you share: Which action failed? Install from GitHub, Link Module, or Sync/Upgrade of an already-linked TracyDebugger? The error or behavior you saw — blank page, timeout, rate-limit message, partial sync, etc. The last lines of the gitsync log under Setup > Logs > gitsync. Whether you have a GitHub Personal Access Token configured (without one you're capped at 60 API requests/hour). The file count alone (~1,250) shouldn't be a problem for a normal upgrade — only changed files are downloaded. But it would be a problem for a fresh Install from GitHub, where every file is fetched in its own API call. The log will tell us which case you hit. We just tested and ran into zero problems: We installed Tracy via the Modules page added it to GitSync via the dropdown synced master branch One known gotcha worth checking: TracyDebugger writes runtime files (logs, bluescreens, dumps) into its own module directory. GitSync deletes local files that don't exist in the remote repo, so a large toDelete list with permission-protected files could also cause the upgrade to fail mid-way. Cheers, Mike

@mikel, would you mind fixing the issue I reported? How your module compare to ProcessWireUpgrade module form Ryan? Just to let you know, I couldn't upgrade TracyDebugger. I guess to many files? I also successfuly upgraded NativeAnalytics, but the module didn't worked well, like something was missing, maybe incomplete download or something? Not sure how to debug...

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.

Thank you very much for adressing this, @Roych! Would it be possible that you release the module either here in the Modules Section and/or on Github? Either way it would simplify the upgrade process of your wonderful module to a one-click action (ProcessUpgrades) or fully automatic (GitSync). Cheers, Mike

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?

Dear Community, I am currently looking for a web developer to implement a website based on a fully completed and professionally designed layout provided by a design agency. The scope of work is limited to HTML, CSS, and JavaScript development. All other components, such as PHP integration, CMS setup, cookie banner, and backend functionality, will be handled by me. The website must be fully responsive and optimized for desktop, tablet, and mobile devices. For tax and legal reasons, the developer must be based in the European Union and able to provide a valid EU VAT ID. I look forward to hearing from interested developers. Best regards Nomak

@ryan I reproduced it on a fresh install this way: Install PW 3.0.260 or earlier Install module Jumplinks Upgrade to PW 3.0.261 Refresh modules Delete compiled files Error: Class "ModuleConfig" not found I only tested it with this module. Hope this helps to reproduce it.

NativeAnalytics v1.0.19 – update This release mainly focuses on privacy/consent handling and admin UI polishing. Added / improved: Added optional cookie-less visitor/session mode for sites that want to avoid browser visitor/session cookies. Added PrivacyWire localStorage consent helper support. Added helper methods for custom consent integrations: window.PWNA.trackIfConsented() window.PWNA.setConsent() window.PWNA.clearConsent() window.PWNA.syncPrivacyWireConsent() Improved consent-based tracking flow, so tracking can start correctly after consent is granted. Tracking-related settings are now hidden/disabled when global tracking is turned off, to avoid confusing combinations like “tracking off + event tracking on”. Added a module settings shortcut button in the analytics dashboard header. Improved AdminTheme compatibility and tab spacing across ProcessWire admin themes. Polished the flat admin UI and removed rounded corners. Fixed panel alignment issues in dashboard grid layouts, especially where side-by-side panels appeared vertically offset. Note: Multi-site analytics is not included yet. It is planned as a possible future improvement because it needs proper per-site separation in stored analytics data. Download is updated in first post!

@AndZyk @Gideon So I'm trying to duplicate here but so far not seeing that issue. I located a module that uses ModuleConfig, which is the ProcessWireUpgrade module... it uses ModuleConfig for its ProcessWireUpgradeCheck module that comes with it. I did try the ProcessJumplinks module also, though am not positive that's the same one you are talking about. Though it does use ModuleConfig and is in the root namespace, so ProcessWire has to compile it. I did also try clearing compiled files like you mentioned, but haven't been able to trigger any errors yet. Is there a particular way to do it? Can you confirm your version number is ProcessWire 3.0.261?