Search the Community

Hi everyone, I am releasing Tickets, a ProcessWire module for private customer-support conversations, staff workflows and reusable support forms. The practical problem it solves is simple: support requests often begin in a generic inbox, lose their context, and become difficult for both the customer and the team to follow. Tickets keeps that workflow inside ProcessWire, next to the accounts and content it supports, without turning private conversations into public comments. How it is used on LQRS Tickets is running on LQRS.com and its development site. The public flow shows the main value of the module: A visitor can open a private request without creating an account. The guest receives a secure access link and continues the same conversation from the website. Messages, status changes and private attachments stay together instead of being scattered across email threads. Signed-in members get a single view of their active and resolved requests. The support team works from a ProcessWire queue with assignment, priorities, internal notes, SLA state and reporting. After resolution, the customer can rate the support experience or reopen the request. For LQRS this means the Help Center remains the first place for immediate answers, while issues that require account context, a data correction, moderation review or a private file move into a trackable support workflow. What Tickets includes Authenticated and guest tickets with threaded replies. Hashed guest-access links and private attachment delivery. Statuses, priorities, assignment, routing rules, SLA targets and bulk actions. Staff-only notes, related tickets, merging and an audit trail. Reusable intake forms with validation, previews and shortcode embeds. One-way import of FormBuilder definitions into independent Tickets form drafts. Editable transactional mail templates through a selectable ProcessWire WireMail provider. Reports, CSV export, ratings, automation and retention tools. Bundled admin translations for Dutch, French, German, Italian and Spanish. Site-owned frontend Tickets owns the support domain, storage, permissions and public API. It deliberately does not overwrite the site's design. The consuming site supplies site/templates/tickets.php, controls routing below the configured support page, and composes the module output into its own frontend. A reusable form can be embedded in otherwise cacheable content: <?php namespace ProcessWire; if($modules->isInstalled('Tickets')) { /** @var Tickets $tickets */ $tickets = $modules->get('Tickets'); echo $tickets->renderFormEmbed('report-incorrect-data'); } Editors can also use: [[tickets-form:report-incorrect-data]] The API covers ticket creation, account and guest access, replies, ratings, attachments, custom forms, staff operations, reports and optional integrations. Exact signatures and authorization boundaries are documented in API.md. Privacy and operational boundaries Customer conversations and files are private; internal notes never belong in customer output. Browser writes require ProcessWire CSRF validation. Guest tokens are stored as hashes, and support routes should use private/no-store/noindex responses. Attachment access is authorized before a private filesystem path is used. Transactional delivery, inbound email, AI assistance and retention are all explicit opt-ins. Uninstall keeps ticket data by default rather than silently deleting customer records. Optional integrations Core ticketing works without additional modules. Optional integrations include WireMail providers for delivery, Resend for authenticated inbound replies, Mailbox for bounded email ingestion and SMTP reply threading, and staff-requested Squad drafts grounded by Atlas or Knowledge Base. AI drafts never send automatically. Requirements and installation ProcessWire 3.0.200 or newer. PHP 8.1 or newer. Download or clone Tickets into /site/modules/Tickets/. Refresh modules and install Tickets. Review the public path, legal links, recipients, attachment rules and optional integrations. Add the site-owned site/templates/tickets.php frontend. Grant tickets-manage and tickets-admin only to the appropriate support roles. Enable transactional delivery only after the selected mail provider has been tested. Links GitHub repository Download ZIP README Integration documentation Public API reference Live support portal on LQRS Issues and feedback I would especially appreciate feedback on the public route contract, permission boundaries and support workflows used on real ProcessWire sites.

Dear PW Community Let me shout out my question here, I really don't know where to start and hope someone can give me a hint or tell me to resign and go home and cry. I want to create a subpage that is only accessible to people with unique access codes. It's gonna be an online concert streaming page (thanks Corona!). People who buy tickets through a local ticketing service should be able to access and stream the show with their individual access code. These codes should work only for this person and show. If someone in the «audience» closes and reopens the page, they should get in again, but not their friends who were given the code of course, basically just like in a club with a ticket and a stamp on the wrist. Now, is there a possibility to achieve that with more or less basic Processwire skills? In my imagination I have a field where I list the given access codes, another two to add start and ending date/time of the show, maybe one for a unique ID/title of the show. Is there an existing module for something like that? Should I get into the module development field and create that? How?? Haha. Any comments are welcome here. Thanks, Nuél

I’m building a simple ticket booking system for our events. I’m considering two different solutions: The first approach is creating one page per ticket and a reference to a booking page with the contact info. This should be faster when checking for ticket availability by using $pages->count(). The other one is a one page per booking with an integer field holding the ticket quantity. Downside is having to use $pages->find() but only having to create one page per booking with the API. My biggest concern is listing the events and the ticket availability for each event, loading all bookings. At the most one event has 300 bookings. Any ideas are welcome.