Thank you. No blocking issues and I have updated the plugin.
now, I get 2x ‘Price’ variations and no ‘Ticket Price’ variation but that’s the one I see in the admin.
Replies for tickets on suppota
Thank you. No blocking issues and I have updated the plugin.
now, I get 2x ‘Price’ variations and no ‘Ticket Price’ variation but that’s the one I see in the admin.
It appears that the upgrade I did today – as there was a new one in my email – has fixed the issue.
I have downgraded the plugin to version 4.5.4 and the problem persists. What do I do?
Hello again,
I have updated to version 4.5.7 to test and the same thing happens to me as in the previous ticket, when I try to change to the next month it does not work. I’m going back to version 4.5.4 and waiting for a quick solution.
Thank you
Ah, here is new information: with EventOn Main Version (ver 4.5.7) i am now forced to use Use UTC offset time globally = OFF. Then it displays 1. January as Monday correctly. If i use UTC offset time globally = ON, then even with the old working DailyView 2.1, it will now wrongly display 1. January as Sunday too.

Please see attached snip below.
David Gutierrez
dgutierrez@ocde.us
How do i downgrade without starting again? Do i just upload this version?
It worked, but now it isnt working anymore. Even if “Datenschutzhinweis akzeptieren” is accepted, it says that you have to accept it. Do you know whats wrong?
Our code: https://codeshare.io/KWrrjE
// actionUser integration
add_action(‘evoau_frontform_evotest’, ‘evoautest_fields’, 10, 6);
// Frontend showing fields and saving values
function evoautest_fields($field, $event_id, $default_val, $EPMV, $opt2, $lang){
$helper = new evo_helper();
echo “<div class=’row evotest req’><p>”;
$evoau_test_value = ($EPMV && !empty($EPMV[‘evoau_test_value’]) && $EPMV[‘evoau_test_value’][0]==’yes’)? true: false;
echo $helper->html_yesnobtn(array(
‘id’=>’evoau_test_value’,
‘input’=>true,
‘label’=>evo_lang_get(‘evoAULtest_1’, ‘<a href=”https://www.schachtermine.com/datenschutzhinweis-fuer-das-einreichen-von-veranstaltungen/” target=”_blank” data-type=”link”>Datenschutzhinweis akzeptieren</a>’, $lang, $opt2),
‘var’=> ($evoau_test_value?’Yes’:’No’),
‘lang’=>$lang,
‘required’=> ‘yes’,
‘afterstatement’=>’evoau_test_value_section’
));
echo “</p></div>”;
}
// save the values to event post meta
add_action(‘evoau_save_formfields’, ‘evoautest_save_values’, 10, 3);
function evoautest_save_values($field, $fn, $created_event_id){
if( $field ==’evotest’){
// for each above fields
foreach(array(
‘evoau_test_value’,
) as $field){
if(!empty($_POST[$field]))
add_post_meta($created_event_id, $field, $_POST[$field]);
}
}
}
add_filter(‘evoau_form_fields’, ‘evoautest_fields_to_form’, 10, 1);
function evoautest_fields_to_form($array){
$array[‘evotest’]=array(‘Datenschutzhinweis’, ‘evotest’, ‘evotest’,’custom’,”);
return $array;
}

I also tried the new EventOn Main Version (ver 4.5.7). This does not make a change to the wrongly calculated Day in DailyView 2.1.1 and 2.1.2
(Luckily ver 4.5.7 fixed the other timezone problem during daylight-saving-time in all calenders in all events from 31.03. to 27. 10. 2024 (Germany), the Times are now displayed correctly, i am not opening another new ticket)

I enabled “EventON > Time Settings > enable Use UTC offset time globally on calendars” and i made sure that Default-Timezone is set correctly.
This did not make a change on the wrong Day-Calculation of 1. January. It would still say it was a Sunday. It should say Monday.
I also tried with the new version 2.1.2, both with Use UTC offset time globally ON or OFF does not make a change: 1. January keeps beeing displayed wrongly as a Sunday.
On a sidenote: the display of Date and Time is heavily degraded with Version 2.1.1 and 2.1.2 in contrast to the better DailyView 2.1. See Comparison Screenshot attached. The HTML-structure of version 2.1 was fine:
I downgraded back to dailyView Version 2.1 again for the time beeing.
(We also suddenly have other Timezone-related problems in all Calenders, seemingly to do with germany Summer/winter-Timezone changes. I open a new ticket for this different problem.)
Please help get DailyView corrected. We rely heavily on it on two sites.