ssvtom

After investigating this a bit further, it turns out, that the ORM all() and first() functions for venues do NOT return decorated post objects as there is no format_item function in the venues repository implementation; i.e. all() and first() return raw WP_Post objects (as returned from get_post()).

Potential solutions:

• add a format_item function to the current venue repository implementation
• use the undocumented filter tribe_repository_venues_format_item to provide a custom format_item function

For the first solution pls have a look at the Pull Request https://github.com/the-events-calendar/the-events-calendar/pull/4870, which includes fixes for two issues we encountered.

Wrt. the second solution

add_filter('tribe_repository_venues_format_item', function($formatted, $id) {
    return tribe_get_venue_object($id);
}, 10, 2);

did the trick for me.

Any update on this issue you can share?

—
Tom

Did the TEC 6.0.2 upgrade on my staging system.

Still, events created via REST API get “old style” look. Interesting to see, that the description field is left empty during the creation. As previously said, if I just open the generated event in the Editor, it immediately gets “updated” to the new style. Afterwards the description field contains some (HTML) content.

BTW, I’m using httpie.io as REST client for testing:

http –verify no –auth user:pass https://ssv-volleyball.de/wp-json/tribe/events/v1/events title=”Testevent” start_date=”2022-10-23 16:00:00″ end_date=”2022-10-23 18:00:00″ status=publish categories:='[12]’ venue:=76

resulting in the following JSON being sent to WP

{
    "categories": [
        12
    ],
    "end_date": "2022-10-23 18:00:00",
    "start_date": "2022-10-23 16:00:00",
    "status": "publish",
    "title": "Testevent",
    "venue": 76
}

Any pointers welcome.

Oh, thanks.

Will test the upgrade on my staging system and see how events, that are created via REST look like afterwards.

I’ll keep you posted…

Yes, can confirm, solved the issue for me as well

Thanks!

@geoffbel Your fix does not solve it at our site.

Tom

Just for documentation purposes:

After an investigation with Tobias it turned out, that the error message was misleading and the root cause was a limitation in the PHP settings for posting form data, namely the setting of ‘max_input_vars’. In my install it was set to 1000, increasing it to 3000 solved my issue.

Thanks Tobias for your excellent support!

Rgds,
Tom

Hi Tabias,

yes, I’m using the “Save Auto Import Configuration” button on the Import tab underneath the list of tables.

The CSV files are owned by root, but have read perm for all. As said, I can run the CSV import manually without any issues.

Rgds,
Tom

Ok, found the issue. It was a misconfiguration on the host OS. Problem was, that /usr/share/timezone/UTC was identical to /usr/share/timezone/Europe/Berlin, which meant, that the system had UTC = Europe/Berlin.

The fix was to re-install Linux package tzdata, which fixed the issue.

Same here.

Add’l info:
The Events Calendar 5.1.6
Wordpress timezone (Settings => General => Timezone) is set to Europe/Berlin
timedatectl status (host OS: CentOS) is also saying Europe/Berlin
[root:~] ls -l /etc/localtime
lrwxrwxrwx 1 root root 35 6. Sep 22:14 /etc/localtime -> ../usr/share/zoneinfo/Europe/Berlin

I created an event for next sunday, Sep 13, 10 to 17h

Strangely in backend database I find for that particular event:

MariaDB > select * from wp_postmeta where post_id=9094 and meta_key like “_Event%”;
+———+———+————————+———————+
| meta_id | post_id | meta_key | meta_value |
+———+———+————————+———————+
| 54669 | 9094 | _EventOrigin | events-calendar |
| 54689 | 9094 | _EventShowMapLink | 1 |
| 54690 | 9094 | _EventShowMap | 1 |
| 54691 | 9094 | _EventStartDate | 2020-09-13 10:00:00 |
| 54692 | 9094 | _EventEndDate | 2020-09-13 17:00:00 |
| 54693 | 9094 | _EventStartDateUTC | 2020-09-13 10:00:00 |
| 54694 | 9094 | _EventEndDateUTC | 2020-09-13 17:00:00 |
| 54695 | 9094 | _EventDuration | 25200 |
| 54696 | 9094 | _EventCurrencySymbol | |
| 54697 | 9094 | _EventCurrencyPosition | prefix |
| 54698 | 9094 | _EventCost | |
| 54699 | 9094 | _EventURL | |
| 54700 | 9094 | _EventTimezone | Europe/Berlin |
| 54701 | 9094 | _EventTimezoneAbbr | CEST |
+———+———+————————+———————+
14 rows in set (0.001 sec)

This seems to say, that the event starts at both 10h UTC and Europe/Berlin (CEST), which is wrong.

If I preview the above event its from 8h to 15h. If I output timezone, it adds CEST.

I’m running a bit of an unusual combi with Solaris 11.4 as OS. So far I was still on PHP 5.6.38 / Apache 2.4.34, which led to the behavior described above. When I switched to PHP 7.1.22, the issue was solved.

Was able to fix it: root cause was an outdated PHP version.

Same here. Any fixes / updates?

Thanks,
Thomas

Hi @jaimemarchwinski,

thanks for pointing me to the doc urls. I was well aware of them. It appears strange to me, that via the REST API you can create tags, organizers and venues and assign them to events, but you can only create categories, but NOT assign them to an event.

So I understand that correctly: this is not just a doc bug, but a general restriction with the current version of the REST API design, right? And if so, any idea if/when this might be addded to the POST /events/{id} service?

Thanks,
Tom