CSV Import: Enddate doesn't get set correct

[Oliver]

Hi,

I want to import events via the CSV import.
The import itself works fine, but unfortunately the enddate doesn’t get imported correct.

When using your example files from here https://theeventscalendar.com/knowledgebase/csv-files-options-and-examples/ the enddate e.g. for “Rock Concert” is set to 08/31/2015 instead of 09/01/2015.
The enddate is always set to startdate – 1 day for all imported data.

Can you provide any help on this?

Best regards,
Oliver

[Nico]

Hi Oliver,

Thanks for reaching out to us! I’ll help you out on this 🙂

I’ve tried to re-create this locally -with Berlin timezone also- but it working fine for me. Are you sure you correctly mapped the columns to the fields on the csv file?

In case you are sure the error is not coming from that end, Can you try to change your site timezone to UTC -WP-Admin > General > Timezone- and re import those?

I see you marked this was tested with default theme and no other plugin active, Can you confirm this? Any difference in the import with this settings?

Please let me know about those,
Best,
Nico

[Oliver]

Hi Nico,

I deactivated all plugins except the Events Calendar Plugins.
I also changed the timezone to UTC-0.
I double-checked the field mapping.

Unfortunately there is no difference, the enddate is always set to startdate – 1 day.

Do you have any other ideas, where the problem could be?

Best regards,
Oliver

[Nico]

Hey Oliver,

Thanks for the follow-up! Sorry to hear nothing of what I suggested worked for you 🙁

Are you testing this locally? – I can’t access the website you linked –

I’ll have someone else on the team to test this for me. Also do you think you can manage to create a fresh WordPress install in a different environment to test this?

Please let me know if that’s possible,
Thanks for your patience on this,
Nico

[Oliver]

Ok, I will setup a clean test environment this week and will check it there!

Thanks!
Oliver

[Nico]

Hey Oliver,

Thanks for doing so, at this point we are not able to reproduce this. But please let me know about your findings as this might be a bug!

Best,
Nico

[Oliver]

Hi Nico,

wow, this is weird: In the clean test environment it work flawless, but in the productive system and the test system not. Looks like I need some more deep dives to figure out the reason for this behavior.

I’ll keep you updated!

Regards,
Oliver

[Nico]

Hi Oliver,

Thanks for the feedback on this! It sounds like a pretty random issue so far…

Are all of those instances -clean, test and production- in the same server with the same settings?

Thanks for keeping me updated, I appreciate it!

Best,
Nico

[Oliver]

Yes, they are on the same server and have the same settings.

Today I did some more testing on the test system:
– I deactivated again all other plugins except the TEC plugins.
– I removed completely the W3 Total Cache plugin
– I changed again the theme to Twenty Fitheen.
– I played around with the UTC setting.

But there is no difference, the enddate is always set to startdate – 1 day.

Interesting enough to mention: In the overview the date is displayed correct:
https://www.dropbox.com/s/ur18341h4wbrh4z/Screenshot%202015-08-30%2013.36.41.png?dl=0

But not in the detail view:
https://www.dropbox.com/s/sq8yjgzjtp66q4j/Screenshot%202015-08-30%2013.38.17.png?dl=0

Apart from that I found another weird behavior: when uploading the same events several times several events are created instead of being updated. In the clean environment this works fine.

Any idea where I can have another look?

Best,
Oliver

• This reply was modified 10 years, 7 months ago by Oliver.
• This reply was modified 10 years, 7 months ago by Oliver.

[Nico]

Hey Oliver,

Thanks for following up on this once again!

This still looks pretty random 🙁 Are all the sites in German? Also do all of them have the same datepicker date format -WP-Admin > Events > Settings > Display > Datepicker date format ?

I’m still puzzled with this issue I must say, sorry for not having a definitive solution to it!

Best,
Nico

[Oliver]

Hi Nico,

the sites are all in German.

I checked if the datepicker format is the same. It wasn’t but I changed it to the clean environment, but unfortunately they was no positive result.

If you like I can give you access to the test environment, where you can have a direct look at it.

Best regards,
Oliver

[Nico]

Hey Oliver,

Can you access the server error log maybe we can find a clue in there? This still seems to be pretty random!

Another thing that might be interesting to take a look is the plain data on the data base, because it’s showing different dates in the backend events list and in the backend details. I see two options, maybe the information is not getting correctly saved or this is just a display issue.

Let me know if you can take a look at this, if not I can craft a little snippet to print this out,
Best,
Nico

[Oliver]

Hi Nico!

direct hit! 🙂

The date in the database is correct:
https://www.dropbox.com/s/0kw6vn24uai8x73/Screenshot%202015-09-03%2021.18.19.png?dl=0

It is also correct on the frontend (I never tested this because it’s not logic …):
https://www.dropbox.com/s/zc8gby767od7saz/Screenshot%202015-09-03%2021.19.22.png?dl=0

But even after publishing the event it gets displayed wrongly in the event details in the backend:
https://www.dropbox.com/s/3w9g9otae8xn6qz/Screenshot%202015-09-03%2021.20.42.png?dl=0

I see now two options:

A) If I replace the events calendar files (php, etc.) in the productive environment from the clean environment will this harm or manipulate the data? Is there stored any information, configuration, etc. inside the php-files?
(I would guess the logic resides in the php-files, but the data resides in the myQSL-DB)

I could give this a try, because I think there is just something wrong within the php.

B) Looks like there is a new TEC version coming very soon. Will it replace ALL php-files or only the ones which changed? If it replaces all maybe it correct the problem “automatically”.

What do you recommend to do?

Best regards,
Oliver

[Nico]

Oliver,

Super stocked to see where finally getting down to the solution for this 🙂

I think waiting for the update is good idea, hopefully it will get things fixed. It will replace all the files so if the plugin installation was corrupt in same way this will most probably fix it. We are expecting version 3.12 to be out next week, so if you could hold on that would be great.

We can keep this thread open until you have a chance to update the plugins and confirm this fixes your issue.

Cheers,
Nico

[Oliver]

Ok, let’s do it like this – I’ll wait for the update!

Cheers,
Oliver

[Author]

Posts