Subject: Critical Bug: EventON Action User Frontend Manager shows stale data after AJAX edit (Caching Issue)
Plugin: EventON Action User
Version: 2.4.9
EventON Version: 4.9.1
WordPress Version: 6.7.2 de_DE
PHP Version: 8.2.28
All other Plugin are disabled (except EventOn and ActionUser).
Standart-Theme ist activated. (No function.php stuff…)
Verified that no Server-Side Caching is involved (No NGINX or MemCache)
Request:
Please review the data retrieval logic for the frontend manager’s AJAX operations, specifically:
The pagination/refresh logic in the get_paged_events AJAX handler. The method used to populate date/time fields in the edit form (form-type-datetime.php), ensuring fresh data is used instead of potentially cached data from the main EVO_Event object during AJAX form loads.
Problem Description:
After successfully editing and saving an event using the Action User frontend manager (via AJAX), both the event list view and the date/time fields within the editor itself consistently display stale/outdated data when refreshed via AJAX. The correct, updated event data only appears after a manual full page refresh (F5). This affects usability critically as users cannot verify their changes immediately.
Steps to Reproduce:
Open the frontend page containing the [evo_event_manager] shortcode.
Click “Edit” on an existing event.
Modify the event’s date and/or time using the specific Date/Time “[EDIT]” sub-editor.
Click “Update Event”. The event saves successfully (verified in backend).
Return to the event manager list.
Observed Behavior 1: The event list shows the old date/time for the edited event.
Click “Edit” on the same event again.
Click “[EDIT]” next to “Event Date & Time” to open the sub-editor.
Observed Behavior 2: The date/time picker fields in the sub-editor are pre-filled with the old date/time values, not the ones just saved.
Manually refresh the entire browser page (F5).
Observation after F5: Both the event list and the date/time sub-editor now correctly display the updated data.
Troubleshooting Performed (Excluding External Factors):
Tested with a default WordPress theme (Twenty Twenty-X): Problem persists.
Tested with all plugins disabled except EventON and EventON Action User: Problem persists.
Confirmed no server-side persistent object caching (Redis, Memcached) is active on the server. Nginx caching for AJAX was also ruled out.
Cleared browser cache multiple times: No effect.
Verified that event data is correctly updated in the WordPress database and visible immediately in the WP Admin backend after saving from the frontend manager. The issue is strictly related to data retrieval for frontend AJAX displays.
Root Cause Analysis:
We tracked down two distinct issues in the Action User code causing this behavior:
Event List Refresh (includes/ajax.php -> get_paged_events function):
The AJAX call to refresh the list (triggered by load_manager_events with direction=none) was prematurely terminated by an exit; statement around line 73.
The condition if($next_page == (int)$_POST[‘page’]) was met when direction=none, causing the script to exit before fetching and rendering the updated event data via $FNC->get_paged_events(). The check should likely only exit if direction is not none.
Date/Time Sub-Editor Fields (includes/form/form-type-datetime.php):
This file populates the date/time picker fields based on data derived from $this->EVENT->start_unix and $this->EVENT->end_unix.
The $this->EVENT object itself is populated earlier in includes/form/class-form.php (within get_content()) using $this->EVENT->get_data().
During the AJAX request that loads the edit form, $this->EVENT->get_data() appears to retrieve stale/cached data (likely from EventON’s internal caching or the non-persistent WP Object Cache interaction during AJAX), leading to the sub-editor being filled with outdated values.
Workaround Applied (Confirming Internal Issue):
We were able to resolve the issue locally with the following modifications, confirming the problem lies within Action User’s data handling during AJAX:
Modified the if condition in includes/ajax.php (around line 73) to: if( $atts[‘direction’] !== ‘none’ && $next_page == (int)$_POST[‘page’]).
Added direct get_post_meta() calls within includes/form/form-type-datetime.php (before lines ~44 and ~125) to fetch fresh evcal_srow and evcal_erow values, bypassing the potentially stale data from $this->EVENT->start_unix / end_unix when populating the date/time pickers.
Impact:
This bug prevents users from reliably editing event dates and times via the frontend manager, causing confusion and potential data errors as they don’t see their changes reflected immediately. It significantly hinders the core functionality of the Action User addon.
These are the tempory fixes in /eventon-action-user/ we use locally to resolve the bug:
assets/js/au_script_f.js
if(data.status==’good’){
form.find(‘.inner’).html(”);
// show success msg
form.find(‘.evoau_form_messages’).html( data.success_message_html );
formp.addClass(‘successForm’);
// — START OF ADDED CODE —
// Reload the event list in the manager
var MANAGER = $form.closest(‘.evoau_manager’); // Get the manager container relative to the form
if( MANAGER.length > 0 && typeof load_manager_events === ‘function’ ){ // Check if manager exists and function is defined
load_manager_events( MANAGER, ‘none’);
}
// — END OF ADDED CODE —
// redirect page after success form submission
if(form.attr(‘data-redirect’)!=’nehe’){…
includes/ajax.php
and eventon-action-user/includes/class-functions.php
Hello,
Thank you for your messages, I am going to assign this ticket to Ashan and he will be able to take it from here and find you a solution. Please allow some time for him to get back to you, we greatly appreciate your patience and thank you for being a eventon customer! Also please disable any IP blocking on your site if there are any.
Wow Thank you Andrea for sharing this amazing workaround code.
Your intention is to load updated event data on the event list for the event manager once an event has been edited. However, what you tried to do is a bit of a roundabout way. We will implement a straight forward solution to load updated events list after event is updated in the next version which should be available later today 🙂
Cool, thank you, i was hoping you would find a solution on a higher level, regarding your recent refactoring of the date and time handling. But do have a look at the event manger list. …
Event List Refresh (includes/ajax.php -> get_paged_events function):
The AJAX call to refresh the list (triggered by load_manager_events with direction=none) was prematurely terminated by an exit; statement around line 73.The condition if($next_page == (int)$_POST[‘page’]) was met when direction=none, causing the script to exit before fetching and rendering the updated event data via $FNC->get_paged_events(). The check should likely only exit if direction is not none.