Never mind, I figured it out.
Because drush uses /usr/bin/env php you need to create a symlink named "php" to the php version you wish to use, and then include it in the shell PATH.
I´m actually not using shared hosting but a virtual private server using ispconfig.
However I need to have multiple PHP versions installed with the default being 7.4.
I have the shell setup with PHP 8.1 for my Drupal 10 sites, and php -v shows 8.1. drush st also shows php 8.1.
But running drush updb will always use the system wide default, which is php 7.4. Most other drush commands work fine.
Did anyone ever figure out a way to do this without hacking Drush?
Sadly no, but it should be possible with a custom dropdown menu and some javascript that sends the user to an url when a month/year is picked.
It should then translate the picked date to a timestamp and send the user to url arguments that calendar view understands, like "calendar_timestamp=1675206000"
I made something similar for the fullcalendar module, but I don´t have the time now.
same problem for me. All day events using date range are offset by 2 hours.
@gge totally agree, but with out the patch a lot of events are not shown and with the patch site crashes, so until there is a proper solution, this hack works for us (we dont use many multiday events).
thanks @gge - commenting out that line makes everything work.
Events still seem to be sorted correctly.
Error with dev applied:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO "cache_discovery" ("cid", "expire", "created", "tags", "checksum", "data", "serialized") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE "cid" = VALUES("cid"), "expire" = VALUES("expire"), "created" = VALUES("created"), "tags" = VALUES("tags"), "checksum" = VALUES("checksum"), "data" = VALUES("data"), "serialized" = VALUES("serialized"); Array ( [:db_insert_placeholder_0] => views:exposed_form [:db_insert_placeholder_1] => -1 [:db_insert_placeholder_2] => 1684320047.775 [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => a:4:{s:3:"bef";a:9:{s:6:"parent";s:6:"parent";s:11:"plugin_type";s:12:"exposed_form";s:14:"register_theme";b:1;s:5:"title";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:22:"Better Exposed Filters";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:11:"short_title";s:0:"";s:4:"help";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:54:"Provides additional options for exposed form elements.";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:2:"id";s:3:"bef";s:5:"class";s:76:"Drupal\better_exposed_filters\Plugin\views\exposed_form\BetterExposedFilters";s:8:"provider";s:22:"better_exposed_filters";}s:10:"vefl_basic";a:9:{s:6:"parent";s:6:"parent";s:11:"plugin_type";s:12:"exposed_form";s:14:"register_theme";b:1;s:5:"title";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:19:"Basic (with layout)";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:11:"short_title";s:0:"";s:4:"help";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:37:"Adds layout settings for Exposed form";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:2:"id";s:10:"vefl_basic";s:5:"class";s:47:"Drupal\vefl\Plugin\views\exposed_form\VeflBasic";s:8:"provider";s:4:"vefl";}s:14:"input_required";a:9:{s:6:"parent";s:6:"parent";s:11:"plugin_type";s:12:"exposed_form";s:14:"register_theme";b:1;s:5:"title";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:14:"Input required";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:11:"short_title";s:0:"";s:4:"help";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:73:"An exposed form that only renders a view if the form contains user input.";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:2:"id";s:14:"input_required";s:5:"class";s:52:"Drupal\views\Plugin\views\exposed_form\InputRequired";s:8:"provider";s:5:"views";}s:5:"basic";a:9:{s:6:"parent";s:6:"parent";s:11:"plugin_type";s:12:"exposed_form";s:14:"register_theme";b:1;s:5:"title";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:5:"Basic";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:11:"short_title";s:0:"";s:4:"help";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:18:"Basic exposed form";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:2:"id";s:5:"basic";s:5:"class";s:44:"Drupal\views\Plugin\views\exposed_form\Basic";s:8:"provider";s:5:"views";}} [:db_insert_placeholder_6] => 1 ) i Drupal\Core\Cache\DatabaseBackend->doSetMultiple() (linje 273 af /var/www/clients/client2/web15/web/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php).
I can confirm this problem.
The dev version breaks the calendar for us (we get a white page with half a calendar and no styling), but I dont know if that is a problem on our side.
It wasn´t easy, but this comment helped me at the time.
The patch in this issue as well as the steps outlined in comment 31 helped me at the time, but I think the patch needs to be rerolled:
https://www.drupal.org/project/drupal/issues/2871486#comment-13894528
🐛
field.storage YAML and FieldType plugin cannot coexist in same module because of FieldUninstallValidator constraint
Needs work
I have used it on several sites, but imho it is very unstable and has led to much pain and frustration. Worst thing is that it is almost impossible to get rid after you have installed it :-/
While I appreciate all the work that went into the module, I would recommend to proceed with care and make sure you have an "exit plan" :) :)
@matthieuscarset - thank you so much - new version seems to work perfectly with our many events :)
I´m not sure I understand the current solution - but it doesn´t work for us.
We can´t set an offset for for instance "-1 year", because our users have to be able to see events from 5 years ago in the calendar.
But the calendar as it is now is far too slow because it has to load thousands of events.
So a "dynamic" page-filter - one that loads each month´s event every time you change to a new month - would be ideal.
robotjox → created an issue.
Thanks, that makes total sense, as I am in UTC+1 (Denmark).
So, @jurgenhaas - I guess it is not necessary to use the MR in that case? Or would you still like me to do that? Happy to help :)