We have a series of recurring events, and our visitors can register for any future date.
When a visitor registers for an event on (as an example May 20 2024) event the "Learn More" button is displayed on the earliest visible event in the list view, instead of the date of the event they selected to register.
We have customized our settings to change the "Learn More" text to "You are Registered"
Since the button change is related to the event type and not the event date the visitor has registered for this can confuse.
My understanding from this behaviour is:
The button change appears to be related to the event type and not the visitor event registration date/time . Leading to the visitor thinking they are registered for the wrong time.
Can you offer a solution to have the event button change from "Learn More" to "Register" include the event date.
If you need any further details please let me know.
It appears the amelia_events table.parentId is used to determine the register status of the user for an event. I think it would make more sense to use the amelia_events.id instead.
I'm looking for a proper way to identify this further and then adjust as such. I might be completely wrong here. I've just started my search.
I'll keep you posted.
I would appreciate any input from the developers, for example: where is the request and response code located for this button on event list view.
My apologies for the additional question, as there is a lot of different information in this ticket, and to be honest, I tried to understand everything before asking developers, but can you please summarize this issue and I will assist you with this?
The customize view for lists allows you to define the "register" buttons style. The button styles can alternate based on the registration status of the visitor. If you apply a different style to help indicate to the user they are already registered for a recurring event you will experience an unexpected result.
Detail:
If a user has registered for a future date for a recurring event the alternate button should be displayed based on the date the user registered and not the event's first date visible in the list. (sure they are registered for this event, but the date the user registered for could be days, weeks or even months later.).
Currently, in the event list view if a user registers for a recurring event at a future date the list will indicate they are registered for the first occurrence of the matching event in the list.
Example:
Recurring Event Starts at say: Jan 10th 2024, the event happens every Monday for the next 2 years.
User views events list and registers for June 17th 2024
- If the user returns to the event list on June 13th 2024 the list will indicate to the user they are registered for the event on the June 10th 2024 date (past date).
- If the user opens a past date say May 16th 20204, the list will show them as registered for the event on May 13th 20204.
Now the user is confused and thinks they made a mistake and tries to register again on the correct date they plan to attend.
See how this can be confusing for the end user.
I reviewed the related code and provided details on my debug process, but this looks to require core changes and not something I can slip in with filters, hooks etc. And should be addressed.
Anyway just checking in. I noticed this ticket was closed without an update.
Thank you for bringing this to our attention. We apologize for the delay in our response. It appears that, for some reason, our initial response was not sent, and the ticket was subsequently closed after several days of inactivity.
We appreciate your detailed explanation of the issue with the "register" buttons in the customize view for lists. We understand that when a user registers for a future date of a recurring event, the button should reflect the specific date they registered for, not the first occurrence of the event in the list. This discrepancy can indeed cause confusion, as users may mistakenly believe they are registered for the wrong date and attempt to register again.
We have noted this issue and recognize its importance. It is on our radar, and we are planning to address it in a future update. Unfortunately, as you correctly pointed out, this fix requires changes to the core system, which cannot be implemented through simple filters or hooks. Rest assured, our development team is aware of the problem and will work towards a resolution.
We appreciate your patience and understanding. If you have any further questions or need additional assistance, please do not hesitate to reach out.
We have a series of recurring events, and our visitors can register for any future date.
When a visitor registers for an event on (as an example May 20 2024) event the "Learn More" button is displayed on the earliest visible event in the list view, instead of the date of the event they selected to register.
We have customized our settings to change the "Learn More" text to "You are Registered"
Since the button change is related to the event type and not the event date the visitor has registered for this can confuse.
My understanding from this behaviour is:
The button change appears to be related to the event type and not the visitor event registration date/time . Leading to the visitor thinking they are registered for the wrong time.
Can you offer a solution to have the event button change from "Learn More" to "Register" include the event date.
If you need any further details please let me know.
Thank you
Doing some digging
It appears the amelia_events table.parentId is used to determine the register status of the user for an event. I think it would make more sense to use the amelia_events.id instead.
I'm looking for a proper way to identify this further and then adjust as such. I might be completely wrong here. I've just started my search.
I'll keep you posted.
I would appreciate any input from the developers, for example: where is the request and response code located for this button on event list view.
Note this also allows me to repeatedly register for the same event for the same day adding to the confusion of the user.
It appears this is likey the script that handles the button visibility on the v3 events list:
/plugins/ameliabooking/v3/public/assets/EventsListForm.0ee19ef9.js
LINE 244 (unminified)
p(
"div",
{ key: 1, class: M(["am-ec__actions", [{ "am-vertical-center": !e(a).customizedOptions.price.visibility }, e(v)]]) },
[
e(a).customizedOptions.price.visibility ? (s(), p("div", { key: 0, class: M(["am-ec__actions-price", e(v)]) }, [n("p", null, k(e(x)), 1)], 2)) : T("", !0),
e(a).btnVisibility
? (s(),
p("p", ga, [
O(
Re,
{
size: e(g) > 500 ? "small" : "medium",
type: e(m) !== "open" ? e(a).customizedOptions.infoBtn.buttonType : e(a).customizedOptions.bookingBtn.buttonType,
onClick: i[0] || (i[0] = (r) => F(e(a).event.id)),
},
{ default: q(() => [$e(k(e(m) !== "open" ? e(a).labels.event_learn_more : e(a).labels.event_read_more), 1)]), _: 1 },
8,
["size", "type"]
),
]))
: T("", !0),
],
2
))
As we can see e(a).labels.event_learn_more : e(a).labels.event_read_more)
This looks like the function that determines the button version displayed.
This is the spot I'm after.
Now I just have to find the function that looks up and sets the vars so I can modify to be based on the date registered and not the parentid.
I think it makes sense we base from live_amelia_events.id and not live_amelia_events.parentid (at least in our use case).
Anyway, again if the devs want to step in and correct me and send me in the right direction I'd appreciate it.
Code seems overly obscured, I need to see inside e(a) I can think of a million better names to use for this lol.
Do you guys have a variable and function reference guide/translator :-D
Where is e() constructed and where is (a) populated?
Hard to do a search on these. I'm not using an IDE for debug yet, was hoping I didn't have too.
Am I at least on track for what I want to accomplish?
I'm tracing my ideas here:
Line 1399 seems to start the customer data.
variable yo is assigned as the reference object....
Its not in the customer object - I don't think...
Can't find how e(a).labels.event_read_more becomes true yet based on the current user that has registered for a particular recurring event.
Simplified question:
How to make the value contained in e(a).labels.event_read_more true for the current event matching the date the customer registered for.
Sorry for the ongoing stream of posts. I'm simply taking notes.
welp I give up for now. I have other problems to solve.
Hopefully the devs can offer some insights.
Where and how is e(a).labels.event_read_more set to resolve as true. ("I'd like to adjust what makes it true)
Hmmmm, I think I am wrong.
Is there a getter used to match who is registered for an event?
Hello Robert,
Thank you for reaching out to us.
My apologies for the additional question, as there is a lot of different information in this ticket, and to be honest, I tried to understand everything before asking developers, but can you please summarize this issue and I will assist you with this?
Looking forward to your reply.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
On the events list view the Button to register is switched to a "Learn More" when a visitor has already registered.
When the event is a recurring event the button changes for the first visible date of the event and not the date the person registered for.
This can confuse leading to the visitor thinking they registered on the wrong date.
Hello Robert,
Thank you for the update on this.
I will have this checked out and provide you with an update on it.
I appreciate your patience.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Anything on this glitch?
The customize view for lists allows you to define the "register" buttons style. The button styles can alternate based on the registration status of the visitor. If you apply a different style to help indicate to the user they are already registered for a recurring event you will experience an unexpected result.
Detail:
If a user has registered for a future date for a recurring event the alternate button should be displayed based on the date the user registered and not the event's first date visible in the list. (sure they are registered for this event, but the date the user registered for could be days, weeks or even months later.).
Currently, in the event list view if a user registers for a recurring event at a future date the list will indicate they are registered for the first occurrence of the matching event in the list.
Example:
Recurring Event Starts at say: Jan 10th 2024, the event happens every Monday for the next 2 years.
User views events list and registers for June 17th 2024
- If the user returns to the event list on June 13th 2024 the list will indicate to the user they are registered for the event on the June 10th 2024 date (past date).
- If the user opens a past date say May 16th 20204, the list will show them as registered for the event on May 13th 20204.
Now the user is confused and thinks they made a mistake and tries to register again on the correct date they plan to attend.
See how this can be confusing for the end user.
I reviewed the related code and provided details on my debug process, but this looks to require core changes and not something I can slip in with filters, hooks etc. And should be addressed.
Anyway just checking in. I noticed this ticket was closed without an update.
Hello Robert,
Thank you for bringing this to our attention. We apologize for the delay in our response. It appears that, for some reason, our initial response was not sent, and the ticket was subsequently closed after several days of inactivity.
We appreciate your detailed explanation of the issue with the "register" buttons in the customize view for lists. We understand that when a user registers for a future date of a recurring event, the button should reflect the specific date they registered for, not the first occurrence of the event in the list. This discrepancy can indeed cause confusion, as users may mistakenly believe they are registered for the wrong date and attempt to register again.
We have noted this issue and recognize its importance. It is on our radar, and we are planning to address it in a future update. Unfortunately, as you correctly pointed out, this fix requires changes to the core system, which cannot be implemented through simple filters or hooks. Rest assured, our development team is aware of the problem and will work towards a resolution.
We appreciate your patience and understanding. If you have any further questions or need additional assistance, please do not hesitate to reach out.
Kind Regards,
Uros Jovanovic
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables