Mikel

Update: Improved "Link Module" UX We had an internal discussion about the "Link Module" interface and optimized how the different states are handled: Match found – The repo is resolved and ready to link. The green link opens the repository on GitHub so you can verify it's the right one before linking. This appears instantly when the module declares its GitHub URL in getModuleInfo() or has been resolved before (cached), otherwise after a quick GitHub search. No repo found – ProModules like RepeaterMatrix have no public GitHub repo. GitSync shows a clear "No repositories found." instead of false matches. Multiple repos – When a module exists in several repos (forks, different maintainers), you get a list to pick from. Selected, with "change" – After picking one, a "change" link lets you switch. It only appears when there are actually alternatives. Other improvements: single results are now auto-selected (no unnecessary click), the GitHub search uses Code Search API for exact .module.php filename matching (works even when repo name ≠ class name), and results are cached client-side so re-selecting a module is instant. Cheers, Mike

Hey folks, we at frameless Media often develop across multiple devices – laptop, tablet, sometimes even from a phone with an AI coding assistant. Git is our single source of truth, but getting those changes onto a staging or production server has always been annoying. Especially on shared hosting where there's no SSH, no git, and git-based FTP via YAML configs is more hassle than it's worth. We also frequently need to test new modules directly on shared hosting environments where the server setup differs from our local machines. Manually uploading files after every push? No thanks. So we built GitSync. 🎯 TL;DR: ✅ Link any installed module to its GitHub repo ✅ See all branches and their latest commits ✅ One-click sync – only changed files are downloaded ✅ GitHub Webhook support – auto-sync on every push ✅ Works on shared hosting – no git, no SSH, no cron ✅ Private repo support via GitHub Token What's the difference to ProcessUpgrade? ProcessUpgrade is great for updating published modules from the PW modules directory. But it tracks releases, not branches. During development, when you're pushing to `develop` or `feature/xyz` ten times a day, you need something different. That's where GitSync comes in. 🚀 How it works Install the module, add your GitHub Token (optional for public repos) Go to GitSync > Add Module, pick any installed module from the dropdown GitSync searches GitHub for matching repositories automatically Link the module to a repo + branch – done From now on, you can sync with one click. GitSync compares file hashes locally and remotely (using the same SHA1 blob hashing that git uses internally) and only downloads what actually changed. No full re-downloads, minimal API usage. Want it fully automatic? Set up a GitHub Webhook – enter a secret in the module config, point the webhook to `https://yoursite.com/gitsync-webhook/`, and every push triggers an automatic sync. The module overview shows a ⚡ webhook badge on auto-synced modules so you always know what's wired up. The real power: remote development with AI 📱 You're on the train, phone in hand, chatting with Claude via the Claude app. Claude writes code, commits to a feature branch on GitHub. GitSync picks up the webhook and syncs the module to your dev server. Automatically. You open the edited webpage on your phone, check the result, give feedback, iterate. The entire development loop without ever opening a laptop. 🤯 This works just as well for teams: multiple developers push to GitHub from different machines, and the staging server always reflects the latest state – no manual deploys, no SSH sessions, no FTP. We've been using a prototype internally for a few weeks now and it's become part of our daily workflow – especially the webhook auto-sync is something we don't want to miss anymore. As proof of concept we built the public release entirely as described above 😃 Technical details for the curious The differential sync works like GIT itself: every file's content is hashed as `sha1("blob {size}\0{content}")`. GitHub's Trees API returns these hashes for the entire branch in a single request. GitSync computes the same hash locally. Matching hash = identical file = skip. Requirements ProcessWire >= 3.0 and PHP >= 7.4 with cURL Module and Docs 👉 GitHub: https://github.com/frameless-at/GitSync 👉 Module Directory: https://processwire.com/modules/git-sync/ Would love to hear your thoughts, ideas, and edge cases we might not have considered! Cheers, Mike

Hey everyone, on a recent client project we had to deal with a large number of Markdown files that needed to end up as regular HTML content on ProcessWire pages. Converting them manually or piping them through external tools wasn't an option – too many files, too tedious, and the content had to be stored as actual HTML in rich textfields, not just formatted at runtime. So we built a small module that handles this directly inside ProcessWire. How it works The module creates a file upload field (md_import_files) and a Repeater field (md_import_items) with a standard title field and a richtext body field (md_import_body) inside. The body field automatically uses TinyMCE if installed, otherwise CKEditor. You add both fields (md_import_files,md_import_items) to any template, upload your .md files, hit save – each file gets converted to HTML via PW's core TextformatterMarkdownExtra and stored as a separate Repeater item. The source filename goes into the items title, processed files are removed from the upload automatically. Template output The Repeater items are regular PW pages, so output is straightforward: foreach ($page->md_import_items as $item) { echo "<section>"; echo "<h2>{$item->title}</h2>"; echo "<div>{$item->md_import_body}</div>"; echo "</section>"; } Tag mappings One thing we needed right away: control over how certain Markdown elements end up in HTML. For example, #headings in Markdown become <h1> – but on most websites <h1> is reserved for the page title. The module has a simple config (Modules → Configure → Markdown Importer) where you define tag mappings, one per line: h1:h2 h2:h3 strong:b blockquote:aside hr:br This performs a simple 1:1 tag replacement after conversion, preserving all attributes. Works well for standalone or equivalent elements like headings, inline formatting, blockquotes, or void elements like hr:br. Note that it doesn't handle nested structures – mapping table:ul for example would only replace the outer <table> tag while leaving thead, tr, td etc. untouched. Requirements ProcessWire 3.0.0+ FieldtypeRepeater (core) TextformatterMarkdownExtra (core) GitHub: github.com/frameless-at/MarkdownImporter Modules Directory: https://processwire.com/modules/markdown-importer/ Happy to hear if anyone finds this useful or has suggestions for improvements. Cheers, Mike

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

[Update] v1.0.25 – Multi-Email Account Merge A small but handy addition for real-world scenarios: customers sometimes purchase with different email addresses and end up with split accounts. The new Merge User Accounts tool in the module config lets you consolidate them in seconds. You enter the source email (the old/unwanted account) and the target email (the one the customer wants to keep). The module transfers all purchases from the source to the target and permanently deletes the source account. Before committing, you can run it in test mode to see exactly what would be transferred – no changes are written. Once you're confident, check "Merge now", save, and the merge report confirms what happened. One thing worth noting: the source account is permanently deleted after the merge – so double-check in test mode first. 🙂 Feedback welcome!

Hi Thomas, @chuckymendoza, thanks for thinking this through so carefully — and yes, the bottle analogy is growing on me. 😄 That said, I'd still recommend not rewriting the module for this use case — not because it's technically impossible, but because the wheel has already been invented, and quite well: Option 1 — FormBuilder + Stripe Processor (by @ryan) Ryan's Stripe Processor Action for FormBuilder supports customizable line items via ProcessWire hooks out of the box. You could build a font-family selector form, populate the line items dynamically, and send the whole bundle to Stripe Checkout in one session — exactly what you described. It's not a cart system, but for a single-family "pick your styles" page it could be a very clean fit. Option 2 — RockCommerce (by @bernhard) Released in late 2024, RockCommerce is a modern, lightweight e-commerce module built "the ProcessWire way." It supports cart, checkout, product variations, coupons, payment webhooks, and pluggable payment providers — without the bloat of a full enterprise shop system. Option 3 — Padloper / ProcessWire Commerce (by @kongondo) If you need the most mature, battle-tested solution with a long track record, ProcessWire Commerce is the established open-source choice. Full cart, order management, variants, webhooks — all there. Rolling your own Stripe Checkout Session integration inside this module would mean maintaining webhook handling, session state, download token security, order persistence — all things that are already solved in the tools above. The maintenance burden alone usually kills these side projects. My honest take: for your font-family use case, RockCommerce or FormBuilder + Stripe Processor are the most promising starting points. For anything larger in scope, ProcessWire Commerce has you covered. Cheers, Mike

[Update] Free Access Display Support (v0.1.7) Hi everyone! Following the latest release of StripePaymentLinksv1.0.23, we've updated this module to match the new free product access — so manually granted product access now shows up properly in all portal views. When a user has products assigned via spl_free_access, those products appear in the portal almost like purchased ones: Grid view: Free-access products render as full active cards instead of grayed-out "not yet purchased" ones. Table view: Free-access rows get a cyan "Free access" badge in the status column. The date column shows a dash (—) since there's no purchase timestamp involved. This makes it immediately clear which products came through Stripe and which were granted manually. Cheers, Mike

[Update] New Feature: Free Product Access (v 1.0.23) Hi, everyone! We just released v1.0.23 with a new feature based on a real client use case: A client using StripePaymentLinks wanted to grant certain high-value customers bonus access to additional products — no Stripe transaction involved, just a manual override. The solution: a new spl_free_access field (AsmSelect, multi-page) on the user template. Pages selectable in the dropdown are automatically restricted to the configured product templates, so editors only see relevant products — every user in the backend gets a "Free Product Access" field where additional products can be assigned directly. Access granted this way is recognized by hasActiveAccess() — the same internal check SPL uses for all content gating — so it integrates transparently with the existing module logic. The field is created and updated automatically by ensureUserFields(), including template restriction syncing when the product template config changes. Thanks for the request and feedback that led to this improvement! Cheers, Mike

Hi, @chuckymendoza aka Thomas 😉 Sorry for the delay, we´ve been busy and I did not get to read the forum in the past weeks. To put it short: For your use case I would definitely NOT use the module. What you need is some kind of shop system because you want your customers to be able to buy MORE than 1 font at once, don´t you? This is something the module explicitly is NOT made for. So yeah, maybe you can hang a picture with a nail and a bottle, but I'd still recommend the hammer. 😉 Cheers, Mike

We use the StripePaymentLinks module for all projects where a few products or services are sold on landing pages. Typically, these are NOT shops, and do not require a shopping basket. Cross-selling can be implemented directly with Stripe, and the module also covers this. For shop functionality, when needed, we use whatever fits best. RockCommerce, for example, is elegant and can be set up in no time. So you just need to ask yourself: Do I want my customers to be able to buy more than ONE product at the SAME TIME? Cheers, Mike

RockCommerce from @bernhardcould also be a choice: https://www.baumrock.com/en/processwire/modules/rockcommerce/ It's open source meanwhile and has all features of a shop including cart and checkout by external payment provider. Out of the box it’s Mollie, but since it’s an interface class, you can add any other easily. We tested this module a while ago and it was really nice working with it 👍 Also open source since a while is the well known ProcessWire Commerce (formerly “Padloper”) by @kongondo Because it was mentioned: StripePaymentLinks is not recommended when you need cart functionality. Cheers, Mike

Hi, @Pavel Radvan, thanks for reporting, that was just because of a wrong version number in the modules info.json file. We fixed it, so when you do the update now, it shows the correct version number. cheers, Mike

Hi, @eelkenet, thanks for the findings! We updated the module to version 1.1.2 that addresses all 4 points: Specific error messages for upload_max_filesize, UPLOAD_ERR_PARTIAL, etc. TheMappingEngine now has multiple fallback strategies title field selection via Dropdown in UI for manual selection All parsers now use max_rows for data limiting Good luck with WP import, that one can be a bit tricky 😉 due to WPs "unique" structure. Cheers, Mike

Thanks, Ivan. Screenshots are included in the Readme file on Github and the module directory (when module is approved). Regarding Repeater (Matrix) Fields: As the module handles external (non ProcessWire) data structures, what exactly do you mean by „handled“? It is not possible to map data to an existing template/field structure, if that´s what you are asking for.

Hey, everyone, here at frameless we frequently work with clients who already have a website but aren't happy with it and want us to rebuild it from scratch. Whenever possible, we use ProcessWire for new web projects – no surprise there, given the flexibility and clean API we all love. For smaller sites, migrating content is usually straightforward – a bit of copy/paste and you're done. But for larger projects with hundreds or thousands of records across multiple database tables, this quickly becomes tedious and error-prone. Over the years, we've written various import scripts and parsers to handle these migrations. We finally decided to clean them up and package everything into a proper module that we'd like to share with the community. Introducing: Data Migrator Data Migrator is a Process module that imports external data (SQL dumps, CSV, JSON, XML) directly into ProcessWire's page structure – including automatic creation of templates, fields, and even PHP template files. Key Features Multi-format support – Import from .sql, .csv, .json, and .xml files Automatic type detection – Recognizes emails, URLs, dates, booleans, integers, etc. and maps them to appropriate ProcessWire fieldtypes SQL schema parsing – Extracts column types from CREATE TABLE statements for better field mapping Foreign Key handling – Detects FK relationships and sorts tables by dependency order Dry Run mode – Preview exactly what will be created before committing anything Full Rollback – Undo an entire migration with one click (removes all created pages, templates, and fields) Template file generation – Automatically creates ready-to-use .php template files in /site/templates/ How it works Upload your data file (SQL dump, CSV, JSON, or XML) Review the analysis – the module shows detected tables, columns, suggested fieldtypes, and sample values Fine-tune if needed – override fieldtypes via dropdown, configure FK relationships Run a Dry Run to preview all changes Execute the migration – templates, fields, parent pages, and data pages are created automatically If something's wrong – hit Rollback to cleanly undo everything Requirements ProcessWire 3.0.0+ PHP 7.4+ Links GitHub: github.com/frameless-at/ProcessDataMigrator Modules Directory: /modules/process-data-migrator/ We've been using the methods and classes bundled in this module internally for a while now and it has saved us a lot of time on migration projects. We hope it's useful for others facing similar challenges. Feedback, bug reports, and feature requests are welcome! Cheers, Mike