|
Daniel
|
November 23, 2019 at 1:57 pm
I don’t have complete repro of this, but I wanted to bring it to your attention to see if this was a known issue.
The Event API seems to ignore some preference/settings when creating events via the API.
Specifically, we have seen wp_user_integration_settings auto_create_user set to 1 when the default in the system was 0. And, events created through the API seem to get RPP by default rather than the chosen system default RAP.
Please let me know if we have discovered a bug or if we should be setting these values explicitly and not relying on event defaults set in the WP UI to affect API calls.
Thanks!
|
|
Josh
|
November 25, 2019 at 7:45 am
Hi,
The API doesn’t use any setting values set within the site, so you will need to set those option values in the API requests.
|
|
Daniel
|
November 25, 2019 at 9:23 am
Ok. Thanks for the clarifications.
Maybe a note with API docs could say
“The API will not use the defaults configured in the Admin area – it will apply the global Database default values when a parameter is not sent.”
Cheers!
|
|
Josh
|
November 25, 2019 at 10:10 am
Hi,
The API doesn’t apply the global database default values either. You need to specify the options in the request.
|
|
Daniel
|
November 25, 2019 at 10:14 am
What values get stored to the db tables when they are not passed via the API then?
I’m thinking maybe it was a bug in the API then because my db rows were all switched to RPP when I had definitely set most or all to RAP already modifying them in the Admin UI.
Is it possible that the Event API would set all values of existing rows to RPP when it is not passed a value? I don’t know how every db row could get set to RPP otherwise.
Thanks! let me know.
|
|
Josh
|
November 25, 2019 at 10:28 am
The API will not set the values, but the database models could fill those in if needed. In any case, if you need an option value set and you’re using the API to write to the database, you need to specify the option value in your write request.
|
|
Daniel
|
November 25, 2019 at 10:54 am
Thanks Josh!
So, I’m still wondering how all the rows got set to RPP after I used the Event API. I think there’s a bug in there somewhere.
Did: Wrote events to Events API without specifying some values of Event meta.
Expected: All event metas in the rest of the db table to stay the same.
Got: All EVT_default_registration_status set to RPP.
Something like this might be involved:
https://github.com/eventespresso/event-espresso-core/blob/2d2f8f3d4afe8dea408ac53c9d03cf9fd9ce9741/core/db_models/EEM_Event.model.php#L93
|
|
Josh
|
November 25, 2019 at 11:03 am
If you want a default reg. status for the event to be something other than RPP, you need to specify that. Are you expecting the default reg status to not be set if you don’t set it?
|
|
Daniel
|
November 25, 2019 at 11:15 am
Hi Josh,
No, I understand that there may be defaults that are set when data values are not passed to the API – this is expected behavior.
What I am suspecting is that something in the API code is causing a kind of update all SQL query to be run on the event metas that causes all default registrations statuses for every event to be set to RPP.
This is what happened at some point to my event metas db. It was very surprising to see this. I think it would be easy to repro… I just can’t do it right now because I would have to set up a system that could be borked on purpose :-). So, I am submitting it as a possible major bug for your consideration and pondering.
Thanks!
|
|
Josh
|
November 25, 2019 at 11:22 am
Feel free to open an issue on GitHub and please include the specific steps to replicate the issue.
https://github.com/eventespresso/event-espresso-core
|
