EventON Action User - WordPress Plugin

A Practical Guide to Configuring EventON Action User for Frontend Event Submissions

EventON Action User is useful when your EventON calendar needs to accept event submissions from users who should not have access to the WordPress admin area. This guide is not a product overview. It walks through a working setup: how to prepare the site, where to place the form, which permissions to allow, how to enable moderation, where users can manage their own events, and how to verify that a submitted event actually makes it into the calendar.

The real value of this plugin is not the form itself, but the connection between the submission form - user permissions - event status - published calendar. If that chain is set up incorrectly, a visitor may appear to submit an event successfully, but the administrator will not see the right data, the event may go live immediately without review, or it may fail to appear on the site even after approval.

Below you will find a detailed walkthrough covering the initial setup, field configuration, roles, Event Manager, a practical example for a local events website, troubleshooting, and comparisons with similar solutions. Where the exact settings depend on your version of EventON or your addon stack, I point you to a safe verification method instead of making overly confident claims.

What frontend event submission is meant to solve

A standard EventON setup works well when events are created by an administrator, an editor, or a small internal team. But event websites, clubs, educational portals, nonprofits, and local communities often need something different: they need outside contributors to be able to submit events without giving them access to wp-admin.

That is exactly the scenario EventON Action User is built for. A visitor or registered user sees a submission page and fills in the title, description, date, time, location, organizer, image, and other allowed fields. After submission, the event is created inside EventON, and from there it can remain pending review, be published immediately, or be assigned to the user for ongoing management.

For the site owner, that means the calendar becomes more than just a schedule. It becomes an intake channel for submissions. A neighborhood events site can accept listings for lectures and concerts, a fitness center can collect event ideas from trainers, a university community can publish department activities, and a webinar directory can accept submissions from guest speakers.

At the same time, this plugin does not turn WordPress into a full author management system with broad permissions over all content. It stays inside the EventON ecosystem: the form creates events, Event Manager helps the author manage those events, and permissions and restrictions need to be configured around the calendar itself. That boundary matters because it helps you choose the right site architecture.

Where EventON Action User is especially useful

This plugin makes the most sense if your site already runs on EventON and you need controlled user event submissions. The most natural use cases include:

• A local events calendar where organizers submit concerts, meetups, exhibits, and community activities on their own.
• A nonprofit site where volunteers or partners suggest events and an editor reviews them before publication.
• An education platform where instructors add lectures, workshops, clubs, and webinars.
• A professional community where members publish meetups, seminars, and industry events.
• A directory of venues or organizers where it matters to display events by author or assigned user.

If all you need is a contact form, a simple inquiry form, or a basic way to add blog posts, EventON Action User is probably unnecessary. Its strength is working specifically with EventON events, their dates, types, locations, organizers, statuses, and calendar output.

Who this plugin is a good fit for, and when another route may be better

Before installing it, it helps to answer one question honestly: who will be creating events, and who will be responsible for content quality. A frontend form lowers the barrier for users, but it also creates editorial work. The more people you allow to submit events, the more important moderation, anti-spam protection, clear fields, and notification checks become.

Teams and roles that fit this setup well

EventON Action User works best on sites that have a calendar administrator and several external or internal contributors. The administrator prepares the form, sets the default status for new events, chooses which fields are available, and reviews submissions. The user fills in only the information needed for the calendar and does not receive broad WordPress permissions.

For small editorial teams, this is a useful middle ground: contributors do not need to learn the admin dashboard, and the editor does not have to manually retype every submission from email. For an agency or developer, the plugin is helpful because it gives the client a clear workflow: a submission page, a management page, and a published calendar result.

When this may not be the best product choice

There are also cases where another solution may be a better fit. If EventON is not already in use on the site and the calendar workflow is still being planned, it may be simpler to choose a system where frontend submission is part of the core workflow. If you need a more advanced organizer portal with payments, tickets, reporting, participation requests, and communication with attendees, Action User alone may not be enough. You may need a broader addon stack or a different events platform.

Another limitation is filtering and sorting in Event Manager. Support discussions have included requests for more flexible filtering by category and date inside the event manager. For some use cases, the developer suggested relying on the main calendar with search and date controls instead of expecting Event Manager to behave like a full administrative table for all events. So if you expect many authors and each of them will manage hundreds of events, check in advance whether the current interface will still feel practical.

Practical takeaway: EventON Action User is especially strong when the site is already built around EventON and users need to submit and edit events without access to the admin area. If you are building a separate organizer marketplace with payments, tickets, and reporting, evaluate the requirements more broadly than just a submission form.

What to verify before installing it on a WordPress site

Preparation should not be treated as a formality. Action User depends on the core EventON plugin, the health of your WordPress setup, the theme, the site scripts, mail delivery, and the way user roles are structured. The earlier you check those pieces, the fewer misleading errors you will run into after publishing the form.

The EventON technical foundation

First, make sure the main EventON plugin is already installed, activated, and successfully displaying a standard calendar on a test page. If the base calendar is not working, there is no point in starting with Action User. Fix the main output, caching, theme conflicts, and script issues first.

EventON's official system requirements for sites using addons assume a current WordPress version, up-to-date PHP, enabled permalinks, sufficient memory, working WP-Cron, and HTTPS for workflows that process user data. You do not need to surface all of that to readers, but the site owner should verify it before launching the form, especially if the site is already running a heavy plugin stack.

Permissions, roles, and moderation policy

Before installation, decide who should be allowed to submit events: only registered users or any visitor. An open form collects submissions faster, but it requires protection against junk submissions and more careful moderation. A members-only form is usually a better fit for clubs, schools, internal communities, and organizer directories.

The second question is the default status of new events. For most public-facing websites, it is safer to begin with draft or pending review rather than instant publication. Immediate publishing only makes sense for closed teams where the submitters are already trusted and understand the content guidelines.

Email and notifications

Action User can send notifications for new events, but actual email delivery still depends on WordPress wp_mail() and your hosting environment. If the site has had mail issues before, set up an SMTP plugin before launching the form and send a test email through EventON's diagnostic area. Otherwise, an administrator may miss a new submission even though the event itself was created successfully.

Caching, theme behavior, and interactive elements

The submission form, lightbox, image picker, new location or organizer creation, and Event Manager buttons all depend on JavaScript. After installation, temporarily disable aggressive script optimization, file combining, and deferred loading for the form page. Then re-enable those optimizations one setting at a time and test the form again.

If your theme overrides styles for forms, buttons, popups, or tables, Action User may look different from the official demo. That is not always a plugin bug. Sometimes the theme styles are simply more specific. In those cases, EventON recommends using browser developer tools to identify the conflict and then adding a more targeted CSS rule in EventON > Styles or in your child theme stylesheet.

Installation and the first post-activation check

Installing Action User is technically similar to installing any standard WordPress plugin: upload the ZIP file through Plugins > Add New > Upload Plugin, install it, and activate it. But with EventON addons, the sequence matters: the main EventON plugin should already be working first, then the addon is installed, and only after that should you review the settings inside EventON itself.

Basic sequence

1. Confirm that the main EventON plugin is active and that a standard calendar is displaying on a dedicated page.
2. Upload the Action User ZIP file through the standard WordPress uploader.
3. Activate the plugin and go to the EventON settings.
4. Open the Action User section and review the tabs for general settings, form fields, and permissions.
5. Create a draft page for the event submission form without adding it to the site menu yet.
6. Submit a test event using a user account with the same permissions your real contributors will have.

The first check is best done from a non-admin account. Administrators often see more than regular users, so testing as an admin can hide permission errors. Create a separate user with the target role, open the form page in another browser or private window, and walk through the submission flow as an actual event author would.

What counts as a successful installation

The installation has gone well if the form opens on a public page, the fields match your settings, the submission does not return an error, the event appears in the EventON event list with the expected status, and the admin email arrives or at least it is diagnostically clear why it did not.

Quick post-installation check: create an event with a test title, save it through the form, find it in the EventON admin area, and verify the status, author, event type, location, organizer, and image. Then open the calendar as a regular visitor and confirm that the event appears only when that behavior is allowed by your publication status workflow.

Configuring the submission form: fields, statuses, and post-submit behavior

The submission form is the central screen in Action User. This is where you decide what data the user can enter, which fields are effectively required, how guest submissions should be handled, what should happen after a successful submission, and who can see the event before review. A well-configured form reduces incomplete submissions and protects the calendar from chaos.

General form settings

In EventON documentation for user event submission workflows, the recommended path starts in EventON > Settings > Action User > General Settings. Important options there include assigning the logged-in user to the created event and restricting submissions to logged-in users only, if that is the model you have chosen for the site.

For a typical public-facing site, a safe workflow looks like this: a user submits an event, the event receives a status that does not publish it automatically, the administrator gets notified, and then an editor reviews the content and publishes the event. A closed community can allow a faster flow, but only after testing it with a normal user role.

Default status for a new event

The event status setting determines whether visitors can see the event right away. If the calendar should not allow accidental, promotional, or incomplete events to go live, choose a review-based workflow. If the calendar is maintained by a small team of trusted contributors, immediate publication can work, but you should still review events and email notifications from time to time.

Guest submissions and submitter data

The official Action User product page notes that it can collect the name and email address of users who are not logged in. That is useful for an open events calendar, but it requires stricter review. In that setup, the administrator needs clear contact fields to follow up on event details, along with protection against automated submissions.

Single-submission limitation

The one-submission-per-user feature is useful when each submission should be unique, such as an event contest, a single organizer profile, or one event registration per participant. Do not enable it by default for event calendars and directories where one organizer may run many events. Define the business rule first, then enable the limitation if it truly fits.

Form fields and the order users complete them

The form fields tab is not just about appearance. If you show too many fields, users may abandon the form or fill it out randomly. If you hide important fields, the administrator will have to chase down every submitter for missing details. Start with a minimum set: title, description, date, time, location, organizer, image, and event type if event types are used in your calendar filters.

For an open form, it is usually a good idea not to let users create too many new entities without review. If new locations and organizers are allowed, clean up duplicates regularly: the same venue may appear as Main Hall, Main hall, and Grand Hall. For a controlled directory, it is often better to let users choose from existing locations and leave the creation of new ones to the administrator.

Redirects, repeat submissions, and the success message

Action User supports post-submission redirects and the option to prompt users to submit another event. Those settings should be used intentionally. For a form where submissions go into moderation, a good confirmation page explains that the event will not appear immediately, who reviews it, and roughly when the submitter can expect a response. For an organizer directory, a repeat-submission button can be useful, but only if authors really do add event series or multiple listings.

User permissions and Event Manager without admin access

The submission form solves only the first half of the problem. The second half is managing events after they have been created. For that, Action User includes a frontend Event Manager that can be added to a page through the shortcode generator and is available to logged-in users. The official documentation emphasizes one important point: the event manager is intended for logged-in users.

Roles and capabilities

Permissions are configured in EventON > Action User > User Capabilities. There, you choose a user role and then check the allowed actions. Capabilities can also be reviewed at the individual user level through Users > All Users, where EventON capabilities can be configured for a specific account.

For the initial launch, do not open up too much. If an author only needs to submit and edit their own events, do not give them access to extra EventON settings. The principle is simple: the role should have exactly the actions needed for the working scenario, and nothing more. That reduces the risk of accidental changes, conflicts, and questionable access to other users' events.

The minimum role for an event author

For a closed community, a Subscriber role or a dedicated organizer role with permission to manage only its own events is usually enough. If your site has several participant types, it is better to create a separate role through a reliable role management plugin instead of mixing event contributors with blog editors.

Testing permissions with a real user account

After saving the capabilities, sign in with a test account. The user should be able to see the Event Manager page, see their own events, use the allowed buttons, and not see the actions you deliberately restricted. If you test as an administrator, you will miss permission problems.

The Event Manager page

The documentation recommends creating a new page or using an existing one, inserting Event Manager through the shortcode generator, saving it, and publishing it. The result is a frontend interface where users can browse, search, edit, and delete events within the limits of their permissions.

This page should not be buried. If users add events regularly, include a link to it in the account area, community menu, or the email that follows a successful submission. The page title should be clear: "My Events," "Manage Events," or "Organizer Dashboard." A technical label like Event Manager may make sense to an administrator, but not always to a typical contributor.

Assigning users to events

Action User can associate users with events. The documentation describes a manual path: open the event edit page, find the Action User block in the sidebar, click Manage Assigned Users, and select users in the popup window. There is also a workflow where the logged-in user is automatically assigned to the event after a successful form submission.

This feature matters most for calendars where each event belongs to an organizer. If an event is not assigned to a user, it may not appear in their personal manager or in a calendar filtered to the current user. That is why, after every test submission, you should verify not only that the event was created, but also that the user assignment is correct.

The current user calendar and author-based event output

One of the most useful Action User scenarios is showing a user only their own events. The documentation describes two approaches: dynamic PHP code using the current user ID, and the shortcode [add_eventon currentuser="yes"]. For most site owners, the second option is the easier place to start because it does not require editing a template.

When current-user output makes sense

This setup is useful for an organizer dashboard, a private community, and profile pages. The user opens the page and sees a calendar containing only the events associated with them. That reduces noise because the author does not have to search through the full calendar to find their own submissions.

But the documentation also notes an important limitation: if the user is not logged in, the shortcode [add_eventon currentuser="yes"] may display all events. For that reason, pages using this kind of calendar should be protected from guests through WordPress access controls, a membership plugin, or template logic. Do not rely on the shortcode alone as a privacy mechanism.

Showing events for specific users

For public organizer pages, you can use the users parameter in the shortcode [add_eventon users="3,5"]. That allows you to build a calendar that displays events from specific users. This approach is useful for sections like "Partner Events" or "Organizer Calendar," but it requires careful handling of user IDs and event assignment checks.

If you need a page that groups events across all authors, the documentation shows an approach using a page template, a user loop, and a call to add_eventon for each user ID. That is already a developer or advanced admin task: the code should live in a child theme, be tested on a staging copy, and never be added by editing plugin files directly.

Practical scenario: an "Add Event" page for a local events site

Let us look at a concrete example. Imagine a WordPress-powered local events website. The editor wants to accept event submissions from organizers, review them, and publish them to the main calendar. Organizers should not have access to the admin dashboard, but they should be able to submit an event and later update the description or image.

Goal

The target setup includes three pages: a public or restricted event submission page, a "My Events" page for logged-in organizers, and a main calendar where only approved events appear. After submission, the editor receives a notification and reviews the entry before publishing it.

Preparation

Before configuration, create a test role or user called "Organizer," verify that the main EventON calendar works, configure mail delivery, and decide which fields are required for editorial review. For a local events site, that usually means title, description, date, time, location, organizer, image, event type, and submitter contact information.

Setup steps

1. In EventON > Settings > Action User > General Settings, enable automatic assignment of the logged-in user to the event after successful submission if the site works with registered organizers.
2. Choose a default status for new events so the editor reviews the submission before publication.
3. On the fields tab, keep only the fields the editor needs to make a decision and arrange them in a logical order.
4. Create an "Add Event" page and insert the form using the EventON block or shortcode generator.
5. Create a "My Events" page and add Event Manager for logged-in users.
6. Configure the "Organizer" role in User Capabilities so the user can submit and edit their own events without managing other people's calendar settings.
7. Create a test event as the organizer and verify that it appears in the admin area with the correct status and user assignment.
8. Publish the event as an editor and open the main calendar in a private window.

How to verify the result

The workflow is ready if the organizer can see the form, submit an event, receive a clear confirmation message, find the event under "My Events," and the visitor sees it in the main calendar only after the editor publishes it. Also verify separately that one organizer cannot edit another organizer's event.

What can go wrong

The most common failures in this scenario are not caused by a single setting, but by a break somewhere in the chain. For example, the event is created but no user is assigned to it; the email never arrives because of wp_mail(); the lightbox opens but the image uploader is hidden by theme styles; or the event is published but never appears in the calendar because of an event type filter. So test the entire path, not just the submit button in isolation.

Practical implementation ideas for different types of sites

Action User does not have to serve only one submission page. It can fit into several editorial workflows as long as you keep publication status, permissions, and data quality in mind. Below are a few scenarios built on confirmed capabilities: the frontend form, configurable fields, event types, user assignment, Event Manager, notifications, and calendar output.

Local community events calendar

For a neighborhood events site, the form can be open to the public, but only with mandatory moderation. A user submits an event, adds the location, date, description, and contact information, and an editor verifies that the event is actually relevant to the community, cleans up the writing if needed, and publishes it. In this case, CAPTCHA, submitter data, and a draft status are important because the form is accessible to a broad audience.

Organizer dashboard on a private site

For a club, school, or professional community, it is usually better to require login. Each organizer can then access Event Manager and a calendar containing their own events. This is more convenient for repeat contributors because they can revise descriptions, change the image, update the location, and avoid sending every small edit to an editor by email.

Partner or instructor directory

If the site displays events by author, you can assign events to users and then output a specific user's calendar through the users parameter or the current-user mode. That makes it possible to build pages such as "Instructor Events," "Venue Calendar," or "Partner Events." It is important to decide in advance who is responsible for duplicate locations and organizers, otherwise the directory will quickly become inconsistent.

An event showcase with paid submission workflows

If you need to charge users for event submissions, the base Action User addon should not be described as a complete payment solution on its own. EventON provides a separate addon for that: ActionUser Plus, which integrates with WooCommerce. In the context of this guide, that matters as a decision boundary: first build a free or moderated event submission workflow, then evaluate the paid scenario separately based on payment requirements and submission tiers.

Safe enhancements: CSS, Event Manager template overrides, and extra fields

Action User does offer confirmed ways to extend its behavior, but they should be handled carefully. Do not edit plugin files directly or paste in large code fragments without understanding them. Start with settings, then move to CSS in an approved location, and only then consider a template override or documented hooks if the task truly requires development work.

Minor visual tweaks through EventON Styles

In one support case, the official EventON team recommended adding CSS in EventON > Styles to hide individual form rows or change button styling. The example below is not a universal recipe for every site, but it shows a safe approach: CSS is easy to remove, does not alter data, and does not modify plugin files.

#eventon_form .evoau_submission_form .formBtnS {
  background: #1f7a5b !important;
  color: #ffffff !important;
}

#eventon_form .evoau_table .row.evoau_repeating {
  display: none !important;
}

Before adding it, inspect the classes on your own form using browser developer tools. If the markup differs in your version, the rule may do nothing or affect the wrong element. Rolling it back is simple: remove the CSS from EventON > Styles, clear the cache, and reload the form page.

Overriding the Event Manager template through a child theme

The Action User documentation describes a template override for the frontend manager: templates from ../wp-content/plugins/eventon-actionuser/templates/ can be copied to ../wp-content/themes/your-theme-directory/eventon/actionuser/. This is no longer a beginner-level setting. It is development work. Do it in a child theme or a custom theme, track the changes in version control, and retest after plugin updates.

This kind of override is useful if you need to change the structure of the event list, add a custom guidance block, or adapt the interface to the design of an organizer dashboard. If your task only involves colors, spacing, or the visibility of a few elements, start with CSS instead of copying templates.

Adding custom fields through hooks

The official documentation shows how to extend the form through the evoau_form_fields filter, the evoau_frontform_... action, and saving logic via evoau_save_formfields. This is a good path when the standard fields are not enough, for example if you need an extra consent checkbox, an internal marker, or a file field. But that code should be written by someone who understands WordPress hooks, input validation, and event metadata storage.

For a typical site owner, the safer first question is whether the requirement can be solved with an existing EventON field, event type, location, organizer, or private note. If not, the developer brief should describe the full workflow rather than simply saying "add a field": where the field appears, who fills it out, where it is stored, who sees it in the admin area, whether it appears on the public page, and how it can be removed without damaging the event record.

How to validate the setup after configuration

Validation should follow the actual user workflow rather than stop at "the form opened." A good verification pass catches problems with status handling, permissions, notifications, the lightbox, caching, image upload, user assignments, and calendar output.

First-test checklist

1. Open the form page as a user with the real target role, not as an administrator.
2. Submit an event with a title, description, date, time, location, organizer, image, and event type.
3. Verify that a clear success message appears or that the expected redirect happens.
4. Find the event in the EventON admin area and check its publication status.
5. Verify the assigned user and the event editing permissions inside the frontend manager.
6. Open the calendar as a regular visitor and confirm that the event becomes visible only after publication.
7. Check the admin notification email and, if needed, send a test message through EventON Settings > Diagnose.
8. Clear both site cache and browser cache, then repeat the submission after re-enabling script optimization.

What to test on mobile

The official product page highlights a responsive lightbox form, but the real outcome still depends on your theme and caching setup. On a phone, test scrolling through a long form, choosing date and time, uploading an image, closing the popup, tapping the submit button, and reading the success message. If the form is long, a standard page is often more usable than a lightbox.

What to test after updates

The ActionUser changelog shows that newer versions have fixed issues involving Event Manager, form messages, image uploads, statuses, and nonce validation. So after an update, do not stop at a quick glance at the calendar. Submit a test event, verify the image upload, editing inside Event Manager, notifications, and user assignment. If you are updating a client site, record the verification result in a short internal checklist.

When EventON Action User is the right choice

EventON Action User is a good fit if you already use an EventON calendar and want to turn it into a controlled user submission system. The plugin solves an important practical problem: users can submit events from a public page, the administrator controls status and quality, and authors can work with their own events through the frontend manager.

Before launch, do not rush to open the form to every visitor. First build and verify a complete test workflow: user role, form, status, notification, author assignment, Event Manager, final calendar output, and a retest after clearing cache. Only then should you add the page to the site menu and invite real organizers to use it.

If the tested workflow matches your site's needs, you can download the ZIP archive and try it on a clone or staging site. The best starting point is not the maximum number of settings, but a short, clear form, a safe publication status, and one fully verified path from event submission to the event appearing in the calendar.