Requests get lost between blog and forum: configuring Tickets MODX
A guest leaves a question under a blog article, and a second one in a forum thread.
Both points live on the same site but in different sections of the MODX resource tree: the blog has its own output templates and moderation rules, while the forum has its own, with a separate set of subscribers. From the outside it looks like one site; inside, there are two independent feedback channels.
The Tickets component stores requests in its own tables and sends event notifications — when a comment is created and when a topic is created.
If the handler is linked to only one section and the email goes to a shared inbox, the second stream produces neither a notification nor a visible marker in the panel.
A comment awaiting review is not displayed on the page at all — it becomes known only after someone manually opens the section.
This is where lost requests come from: the responsible person sees half of the dialogue, replies in a thread the guest does not read, and duplicates an answer already given. The client leaves without waiting for a response.
This can be measured by the share of requests without a response within 24 hours and by the number of dialogues where the answer appeared in the wrong thread.
We'll look at how this is resolved: configuring Tickets for both loops, a single intake point for requests from comments, events for each container, processing statuses, and explicit assignment of a responsible person.
What a unified request feed provides: measurable effects of configuration
<cite>Tickets</cite> stores a request as a separate record linked to a parent — a blog post or a forum topic.
Therefore a comment under an article and a message in a thread end up in one request feed rather than two independent storages: one workplace, one selection, one set of moderation rules.
The status model — new, in progress, resolved, closed — plus assignment of a responsible person.
Until a request receives a response, it stays in the request processing queue and rises to the top by age; as soon as a moderator takes it into work, it leaves the common list and stops pressing on everyone else.
Time to first response is calculated as the time from publication to the first moderator message. For the forum, this metric used to be inflated: a topic would sink down and wait until someone found it manually.
A unified feed pulls such discussions into the common flow, and time to first response levels out between the blog and the forum.
The load on moderators is broken down by section and by the number of open requests per person — it is clear where a second duty moderator is needed and where a typical one can be closed with a template response.
The share of closed requests is calculated by transitions to the final status over a period; overdue and stalled requests remain separately in the report, which previously were simply lost in threads.
Options for displaying requests in the blog and on the forum: comparing approaches
The choice of how to display requests is determined by the amount of custom logic on top of the standard Tickets feed.
Ready-made snippets and templates for the blog and forum cover the typical scenario with almost no edits — but as soon as custom publishing rights, separate sorting, end-to-end moderation, or a connection to an external storage appear, template output is no longer enough.
Below are four schemes that are realistically chosen between at the start. They do not exclude each other: in practice, some discussions come directly from Tickets, while some are pulled in by synchronization.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made output snippets in blog and forum templates | Typical request feed, standard permissions, data already lives in Tickets | Custom logic is added via additional calls, increasing the number of queries per page |
| Custom output controller | You need your own access rules, output order, and pagination different from the standard ones | More expensive to maintain: when the core is updated, the logic is checked and migrated manually |
| Synchronizing requests with an external storage | Discussions are already collected outside the system — in a support service or on a separate platform | Requires matching authors, protection against duplicates, and a procedure for resolving discrepancies |
| Hybrid scheme: output from Tickets plus a mirror for search and reporting | You need fast page delivery and, at the same time, end-to-end data export | Two data streams — you need an explicit source of truth and control over mirror lag |
We fix the scheme after analysis: we count output points, request sources, and whether reverse writing is needed.
Implementation order: from template inventory to handover of procedures
We build from facts, not assumptions: first we look at what already exists in the project, then we design the connections, and only then do we touch the settings.
This implementation order removes the main risk — when the forum and blog start living their own lives, and editing one template breaks output in three places. Below is the sequence of steps as we go through it on real projects, including Tickets in MODX.
Work sequence
- Audit of templates and forms. We compile a list of all places where discussions are displayed: blog card, forum page, personal account. We note duplicate markup, inheritance, and places where logic is duplicated in code instead of a shared template.
- Section relationship diagram. We record in a diagram which section is responsible for what, where common branches are, how blog and forum topics are separated, and by what criteria permissions are granted. The diagram is agreed upon before configuration — rework at this stage is cheaper.
- Component configuration. We bring output to a single set of templates, configure group permissions, moderation, notifications, and spam protection. Instead of copies for each section — one set of parameters.
- Migration of existing discussions. We check the integrity of connections: threads, replies, attachments, authorship. We resolve discrepancies before publication so users do not see “broken” discussions.
- Testing response scenarios. We run the full cycle: reply to a comment, quote, edit, delete, report, subscribe, guest and authorized participant. Each scenario — with permission and notification checks.
- Testing edge cases. Deleting a parent message with replies, changing the author, restoring from trash, resubmitting the form. This surfaces errors that are not visible in a calm test.
- Project handover. We provide the template map, moderation procedure, and instructions for typical edits. The procedure describes what can be changed without a developer and what requires intervention.
After handover, editing an individual template does not affect the other sections, and new scenarios are added in a targeted way. Let's discuss your task — we'll come back with an estimate and a plan for these stages.
Handover contents: chunks, templates, moderation rules, and documentation
Project handover is not an archive with a database and files, but a working configuration that your team can edit independently. We collect everything related to comments, the forum, and requests into one package: settings, output templates, moderator permissions, and procedures. Below is what exactly remains with you after launch.
- Tickets MODX configuration: blog and forum sections, binding to resources, category tree, user group permissions — from guest to moderator.
- Comment output templates: chunks for the list, reply form, pagination, notifications, and emails; each with a comment — which parameter is responsible for what.
- Moderator access rules: roles and levels — pre-moderation, hiding, editing, deletion; separately for handling reports and moving topics.
- Anti-spam and notification settings: rate limiting for sending, filters by stop words and links, notifications about new requests by email and in the panel.
- Request documentation: how a moderator sees a comment and the history of actions on it, what is recorded, and where the log is stored.
- Processing procedure: response times to a report, the procedure for handling disputed situations, who makes the decision in a conflict.
- Relationship map and deployment instructions: which chunk is connected to which template, how to transfer settings between environments, and what to add when a new section appears.
The package covers typical tasks without us: a new section, permissions for a new moderator, changing the appearance of comments.
Case study: a blog with open comments and a large forum
Before discussions were migrated to MODX Tickets, the blog and forum lived in two disconnected loops: comments under articles were stored in one table, forum topics in another, and some questions came by email and direct messages altogether.
A moderator saw only the thread they manually entered, so requests were lost not because of a failure, but because there was no unified queue. One question out of five remained unanswered: it simply did not come into the duty moderator's field of view.
What we changed
All discussion points were moved to Tickets as a unified layer over materials.
Each article and each forum section became the owner of its own request section: a topic is automatically linked to the page, inherits its permissions, and appears in the queue of the required moderator group.
We introduced explicit statuses — new, in progress, awaiting author, closed — as well as a rule according to which a closed request remains publicly readable, but new messages in it are blocked.
Notifications about new topics and “stalled” requests go to the responsible person, not the whole team.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of requests without a response | ~20% | 3% |
| Median time to first response | 26 hours | 4 hours |
| Share of topics reaching closure | 45% | 88% |
| Requests requiring manual search | manually | 0 |
We separately configured the migration of old comments and topics while preserving authorship and dates — the history was not lost when the mechanics changed.
Moderation stopped being a manual walk through sections: the queue is built by status and deadline, so stalled requests surface on their own. Such a loop withstands forum growth without a proportional increase in the moderator team.
How does Tickets MODX differ from built-in comments?
Built-in comments are a message linked to a resource: one reply tree, author and date, permissions inherited from the page itself. Moderation comes down to deletion and pre-moderation, and there is nowhere to store a status, responsible person, or attachment in such a model.
<cite>Tickets</cite> MODX turns a discussion into a request model: a message becomes a separate entity with its own lifecycle — privacy, reply thread, files, status history.
The difference shows up in section permissions. In comments, access is determined by the resource: whoever sees the page also sees the discussion.
In tickets, the policy is set separately — a guest posts in the public forum, but their private ticket is read only by the author and the assigned responsible person.
Routing of responsible people is built on sections: a hosting request goes to one engineer, an integration question to another, and no ticket remains without an owner.
For comments under an article, the built-in mechanism is enough; when a discussion becomes a support channel with deadlines and obligations, the request queue takes over.
Common technical doubts before implementation
Before starting, people ask not about the module itself, but about how it will get along with an already working site. Let's go over engineering-level doubts: migration of old discussions, layout, behavior under load, moderation permissions, and notification delivery.
Are old comments migrated to Tickets?
Yes, we migrate them. We export messages from the previous tables and link them to the same materials by identifier, preserving dates, authors, and reply nesting. We recalculate counters after import so that the number of messages in lists matches the actual number.
Will this break the site's layout?
No, if the output is assembled using your templates: message markup, the reply form, and pagination inherit the existing classes and wrappers. We restrict allowed tags in the editor in advance so that inserts do not overflow the column width.
How does the system behave on an active thread?
Hundreds of views and dozens of replies per minute are handled by caching ready-made blocks and rate limiting submissions. Queries use indexes, so the speed of list delivery does not depend on how many messages have accumulated over the years.
Can moderation be distributed among different people?
Yes, permissions are granted to groups rather than individual accounts: thread editors, section moderators, administrator. We separately enable pre-moderation for new participants and hiding messages instead of deleting — the trace remains readable.
Notifications about new replies are not arriving. Why?
Most often, emails go to Spam during mass mailing through a server mailbox. We solve this with an external delivery service and correct sender domain settings, and we investigate disputed sends using the log — it shows who did not receive the email.
Let's discuss the task: we'll show the scheme and come back with an estimate and plan
To make the conversation concrete, at the start a minimum is enough: the address of the blog and forum, administrator access, the current structure of sections and user groups.
From these it is clear whether there are already accumulated discussions that need to be migrated, and how deeply the Tickets module integrates into existing templates — whether edits will remain only in output or will affect the logic of publishing materials.
In response, we send not general words but a working framework:
- solution scheme: which forum sections we create, how we link them to blog materials, where we leave comments on a post, and where a separate topic;
- list of work for migrating existing discussions while preserving authors, dates, and attachments;
- configuration of group permissions and moderation: who publishes, who hides messages, who receives reply notifications;
- estimate and work plan broken down by stages with explicit dependencies — what is required from you, what we do;
- implementation timelines with a margin for a test environment, acceptance, and transfer of settings to the production site;
- terms of transfer to support: procedure for updates, backups, and response to requests after launch.
Until the scheme and work order are agreed upon, we do not start edits on the production site — therefore changes remain predictable, and rollback is possible at any stage.
Describe the task: send access and briefly tell us how the discussion is organized now — we'll come back with an estimate and a plan.
