Reply to: tickets(337727)

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.

Reply to: tickets(337833)

It appears that the upgrade I did today – as there was a new one in my email – has fixed the issue.

Reply to: tickets(337875)

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

Reply to: tickets(337119)

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.

Reply to: tickets(332704)

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;
}

 

 

 

Reply to: tickets(337119)

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)

Reply to: tickets(337119)

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:

  • evoet_dayblock evcal_cblock
    • evo_start
      • day
      • date
      • month
      • time
    • evo_end
      • day
      • date
      • time
This changed to a simple and uninformative:
  • evoet_dayblock evcal_cblock
    • evodv_time

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.