|
Mylor
|
September 5, 2024 at 3:48 am
Hello,
We’ve encountered a bug on the plugin wherein inactive events seem to save automatically when entering backend editing. When inactive events are opened, redirecting away from it without saving, still assigns it a date in the future and will show up on the calendar.
|
|
Tony
|
September 5, 2024 at 4:48 am
Hi there,
I can’t reproduce this, editing inactive events leaves them inactive even if I make changes and updating (other than setting a datetime/new date).
Are you using the Legacy editor or Advanced?
https://eventespresso.com/wiki/new-advanced-event-editor/
You your just clicking to edit and then if you open the event in a new tab its active?
Can you add any details, screenshots, loom video? Anything show how to reproduce?
|
|
Mylor
|
September 5, 2024 at 8:50 am
Here is the loom video replicating the issue. Sorry it’s so long (4 min) but it shows it in detail 🙂
https://www.loom.com/share/06e00bdbc7cb4248a15fee24eb36a753
|
|
Tony
|
September 5, 2024 at 12:15 pm
Hmm, ok. So I can see it happeing on the site…. BUT… there’s more going on for this here.
What stands out for me is this: https://monosnap.com/file/kozMxNtK0JvNAAxCknNkyXCaQPP2EQ
Your events don’t have a datetime assigned to them, even expired events have datetimes. So what is likely happening when you open up the event is the default datetime is being created because you don’t have one already (The video didn’t show the event editor tickets/datetimes so I can’t say for sure but that’s what appears to be happening).
Has this site moved servers, any kind of data migration been run?
In short, what your seeing isn’t just from ‘expired’ events…. those 2 events you edited in the video look like previously broken events (how they broke I don’t know) and now when opening them EE is generating a default datetime/ticket in the background becuase all events should have at least one… those appear not to.
|
|
Mylor
|
September 6, 2024 at 12:53 am
Hi Tony,
I think I got what you mean. Indeed, it seems that EE is configured to have a default date even if set to draft. I’ll look deeper as to why the old inactive events don’t have one but moving forward, is there a way we could retain the old inactive events without triggering a publish action when opening them? For now, the only way to retain them is to open them one by one and set them to draft together with the auto-assigned default date. This, or is there a configuration where we could deactivate the auto-assigning of default dates and tickets for events?
Thanks!
|
|
Tony
|
September 6, 2024 at 3:45 am
We don’t have a way to disable the default datetime/ticket creation on an event as that should happen when the event is initially saved (with whatever status it had/has).
For now, the only way to retain them is to open them one by one and set them to draft together with the auto-assigned default date.
That’s correct, although I would recommend adjusting the datetime date so that it’s expired rather than just a draft event.
I’ve opened an internal discussion on this to confirm I’m not missing something and will let you know if there’s another option.
|
|
Tony
|
September 6, 2024 at 3:55 am
I went back and rewatched your video a couple of times and noticed that the events in question are published beforehand, which means originally that must have had a datetime assigned to them which is now missing.
What’s the history of this site?
Right now the only way I can think of the above happening is the site has been moved or the DB tables altered and not all of the DB tables were migrated, so you have the ‘old’ EE event posts sitting in the database (wp_posts table) but the related datetimes aren’t there (should be within wp_esp_datetime). So when you open up the old EE posts that’s why EE generates a datetime and why the event automatically shows up.
|
