markus-th

I can't say much about it at the moment, as the module I'm currently developing is tailored specifically to a customer's needs. However, I plan to release a slightly different version later on, which will work in a similar way to the WordPress Media Manager.

Thanks for merging @elabx! That is awesome news. My main goal with these changes was to be able to list this module as a dependency ('requires') for my other current and upcoming modules. Now I can rely on a central Alpine.js source instead of bundling/implementing it separately in every single module. That makes maintenance much easier. Thanks again for the collaboration!

Oh sorry, i missunderstood this. Go to "Releases" > "Draft a new release".

You can click "Refresh". I increased the version from 005 to 006, this shoud do the job.

Hi @elabx, First of all, thank you for the AlpineJS module! I have been working on a fork to modernize the module and make it more flexible for my projects. Instead of shipping a static (and potentially outdated) JS file, I implemented a downloader mechanism. Here is a summary of the new features I added: Local Hosting & Updater: The module can now download the latest Alpine.js core and plugins directly from unpkg.com to the server. This allows for 1-Click Updates via the module config without needing a module update. Plugin Support: Added checkboxes to easily enable official plugins (Mask, Intersect, Persist, Focus, Collapse, Morph, History). You can review the changes in my fork here: https://github.com/markusthomas/AlpineJS I think these changes would be a good addition to the your repository. Would you be interested in a Pull Request? Best regards, Markus

Hi @patricus, everyone is welcome here. 😉

Have some swiss customersites by cyon.ch and everything works fine.

Hi @Stefanowitsch I can integrate as option a base CSS with semantic class names, similar to how I handled it in my WireMagnet module. This way, the styling can be done independently of Tailwind. I plan to release the module on GitHub in the next 2–3 weeks, once I've successfully completed some final tests.

You can test to set the visibility to "Closed + Loaded only when opened (AJAX)"

Hi everyone! I am currently developing a new module for a client project and wanted to quickly reach out to see if there is broader interest in the community for a solution like this. The Use Case My client needed an appointment booking system similar to "Calendly". However, they had specific requirements: Zero external dependencies: No third-party SaaS for GDPR/DSGVO compliance and to avoid monthly fees. Full Design Control: It had to fit seamlessly into their custom design. Lightweight: No heavy bloat. The Solution: WireBooking is a native ProcessWire module that handles appointment slots and bookings using standard ProcessWire pages. Current Features: Frontend Wizard: An interactive, step-by-step booking process built with AlpineJS and Tailwind CSS. Native Storage: Bookings are saved as standard ProcessWire pages (booking-entry), allowing you to use the full power of PW selectors and hooks. Backend Management: Simple interface using the native ProcessWire Admin Theme (UIkit) to view bookings. Notifications: Sends confirmation emails to the customer and admin, including generated .ics calendar files for Outlook/Apple/Google Calendar. Availability Management: Manually block specific time slots or entire date ranges via the module settings. AJAX Driven: Dynamically loads available slots via JSON to keep the initial page load light. The "Catch" (Requirements) To keep the module lightweight and modern, it is opinionated regarding the frontend stack. It assumes you are already using (or are willing to include): Tailwind CSS (Utility classes) for the styling. Usage Example: Using it in a template is extremely simple: <?php echo $modules->get('WireBooking')->renderWizard(); ?> I need your feedback! The module is currently functional for this specific use case (Consultants/Service Providers). Before I invest time into generalizing it for a public release on the modules directory, I have two questions for you: Is this something you would use? Is there a need for a native "Calendly" alternative? Is the dependency on Tailwind a dealbreaker? Since the markup relies on Tailwind utility classes, it might be hard to style if you use Bootstrap or custom CSS. Looking forward to your thoughts and suggestions! Cheers, Markus

Hello everyone, I’m happy to share a new module I’ve been working on: WireMagnet. We often face the requirement to offer "gated content" (like Whitepapers, PDFs, or Zip files) where users need to provide their email address to receive a download link. While there are external services for this, I wanted a native, privacy-friendly, and lightweight ProcessWire solution. What does WireMagnet do? WireMagnet handles the entire flow of capturing leads and delivering files securely. It intercepts form submissions, logs the lead, and sends an email with a unique, temporary download token. It prevents direct access to the files (assets are not just sitting in a public folder). Key Features: Secure Delivery: Generates unique download tokens (valid for 24 hours) and serves files via wireSendFile(). Double Opt-In (DOI): Optional support for DOI to verify email addresses before sending the file. Automated Emails: Automatically sends the download link (or attaches the file directly if preferred). AJAX Ready: Comes with built-in Alpine.js support for seamless, reload-free form submissions. Lead Management: Logs all subscribers (Email, IP, Timestamp) to a custom database table (leads_archive). Admin Interface: View leads and export them to CSV directly from the ProcessWire backend. Easy Integration: Render the form with a single line of code. How to use: Install the module. Create a page (e.g., using a lead-magnet template) and upload your file to a file field. Output the form in your template: // Render the subscription form (default field: 'lead_file') // The module automatically handles success/error messages and styling. echo $modules->get('WireMagnet')->renderForm($page); // OR: Render for a specific field (e.g., if you have multiple magnets or custom field names) echo $modules->get('WireMagnet')->renderForm($page, 'my_custom_file_field'); // OR: Override the button text manually echo $modules->get('WireMagnet')->renderForm($page, 'lead_file', 'Send me the PDF!'); Configuration: You can configure the sender address, email subject, DOI settings, and styling preferences (like button text) in the module settings. Download & Source: GitHub: https://github.com/markusthomas/WireMagnet Modules Directory: https://processwire.com/modules/wire-magnet/ I'm looking forward to your feedback and suggestions! Cheers, Markus

@ukyo Thanks for the suggestion! I considered that approach, but there is a significant technical blocker: Class Name Collision. The legacy Pages2Pdf module already defines a global class named WirePDF internally. The module you referenced also uses the global class WirePDF. If I were to build a wrapper or if a user tries to migrate from the old module to the new one, PHP would throw a Fatal Error: Cannot redeclare class WirePDF immediately if both files happen to be loaded (which can happen easily during uninstall/install processes or if site caches aren't perfectly cleared). My goal with Wire2Pdf is to cleanly separate the logic using Namespaces (e.g., ProcessWire\Wire2Pdf). This ensures: Zero conflicts: It can theoretically exist alongside the old module during migration/testing without crashing the site. Full Control: I can ensure the mPDF library is updated and configured specifically for ProcessWire's needs without depending on a third-party wrapper that relies on global class names. So, while extending would be "dryer", a fresh, namespaced module is the safer and more robust path forward.

Maybe I have a few little goodies that you might like 😉 Wire2PDF (first Alpha) What's new? Custom fonts You can upload and use own fonts Set PDF metadata (defined with variables or custom by a specific templatefield title, subject, keywords, author and creator Create PDF/A-1b for font embedding Now i have to test before it is ready to publish.

Thanks for sharing. I’ve actually looked into that repository. The main issue I see is that it uses the class name WirePDF, which causes a naming collision because the original Pages2Pdf module already defines/uses a WirePDF class internally. This makes migration difficult and would crash the site if both are present. My goal with Wire2Pdf is to use proper Namespaces (e.g. ProcessWire\Wire2Pdf) to ensure PHP 8 compatibility without risking these kinds of class name conflicts.

Hi everyone, For those of you running into compatibility issues with PHP 8 or needing a newer version of the underlying mPDF library, I wanted to let you know that I am working on a modernized successor to this module. To avoid clogging up this thread, I have started a separate discussion about the new project (currently named Wire2Pdf) here: If you are interested in a maintained version with PHP 8 support and new features, please join the conversation over there. Thanks!