🇨🇦Canada @sdsheridan

sdsheridan → created an issue.

Patch worked for me. Thanks!

This seems to have reverted somewhere along the way, as it's not in 8.x-2.5. Might also want to include $ex->getTraceAsString() -

throw new EncryptException($ex->getMessage() . " \n" . $ex->getTraceAsString());

shawn

Looks right to me.

I checked my entire project directory, and found that indeed one of my own custom modules had a space before the opening '<?php' tag. Use the following to find them:

$ pcregrep -Mlr --buffer-size=1048576 "^\s+<\?php" .

There were a number of items that showed up under ./vendor, and then my module.

I now seem to be no longer getting "something went wrong" errors, and fields are adding correctly now.

If it helps, I observed this behaviour on both an updated site from 10.1.7, and on a fresh install of 10.2.0.

Nothing appears in the PHP error log, or in the watchdog log when these errors occur now. The only thing that appeared in the watchdog was around trying to add a user reference field "Project manager" to a "Project" content type, as follows:

Type 	php
Date 	Tuesday, December 19, 2023 - 19:48
User 	admin
Location 	http://rp10.local/admin/structure/types/manage/project/add-field/node/field_project_manager?_wrapper_format=drupal_ajax&destinations%5B0%5D%5Broute_name%5D=entity.node.field_ui_fields&destinations%5B0%5D%5Broute_parameters%5D%5Bentity_type%5D=node&destinations%5B0%5D%5Broute_parameters%5D%5Bfield_name%5D=field_project_manager&destinations%5B0%5D%5Broute_parameters%5D%5Bnode_type%5D=project&destinations%5B1%5D=%2Fadmin%2Fstructure%2Ftypes%2Fmanage%2Fproject%2Ffields%2Fadd-field
Referrer 	http://rp10.local/admin/structure/types/manage/project/add-field/node/field_project_manager?destinations%5B0%5D%5Broute_name%5D=entity.node.field_ui_fields&destinations%5B0%5D%5Broute_parameters%5D%5Bentity_type%5D=node&destinations%5B0%5D%5Broute_parameters%5D%5Bfield_name%5D=field_project_manager&destinations%5B0%5D%5Broute_parameters%5D%5Bnode_type%5D=project&destinations%5B1%5D=/admin/structure/types/manage/project/fields/add-field
Message 	InvalidArgumentException: Field field_project_manager is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField() (line 616 of D:\var\www\rp10.local\web\core\lib\Drupal\Core\Entity\ContentEntityBase.php).
Severity 	Error
Hostname 	127.0.0.1
Operations 	
Backtrace 	

#0 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Entity\ContentEntityBase.php(597): Drupal\Core\Entity\ContentEntityBase->getTranslatedField('field_project_m...', 'x-default')
#1 D:\var\www\rp10.local\web\core\modules\field_ui\src\Form\FieldStorageConfigEditForm.php(116): Drupal\Core\Entity\ContentEntityBase->get('field_project_m...')
#2 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Entity\EntityForm.php(107): Drupal\field_ui\Form\FieldStorageConfigEditForm->form(Array, Object(Drupal\Core\Form\SubformState))
#3 D:\var\www\rp10.local\web\core\modules\field_ui\src\Form\FieldStorageConfigEditForm.php(85): Drupal\Core\Entity\EntityForm->buildForm(Array, Object(Drupal\Core\Form\SubformState))
#4 D:\var\www\rp10.local\web\core\modules\field_ui\src\Form\FieldConfigEditForm.php(199): Drupal\field_ui\Form\FieldStorageConfigEditForm->buildForm(Array, Object(Drupal\Core\Form\SubformState), Object(Drupal\field\Entity\FieldConfig))
#5 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Entity\EntityForm.php(107): Drupal\field_ui\Form\FieldConfigEditForm->form(Array, Object(Drupal\Core\Form\FormState))
#6 [internal function]: Drupal\Core\Entity\EntityForm->buildForm(Array, Object(Drupal\Core\Form\FormState))
#7 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Form\FormBuilder.php(536): call_user_func_array(Array, Array)
#8 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Form\FormBuilder.php(375): Drupal\Core\Form\FormBuilder->retrieveForm('field_config_ed...', Object(Drupal\Core\Form\FormState))
#9 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Form\FormBuilder.php(633): Drupal\Core\Form\FormBuilder->rebuildForm('field_config_ed...', Object(Drupal\Core\Form\FormState), Array)
#10 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Form\FormBuilder.php(325): Drupal\Core\Form\FormBuilder->processForm('field_config_ed...', Array, Object(Drupal\Core\Form\FormState))
#11 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Entity\EntityFormBuilder.php(48): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\field_ui\Form\FieldConfigEditForm), Object(Drupal\Core\Form\FormState))
#12 D:\var\www\rp10.local\web\core\modules\field_ui\src\Controller\FieldConfigAddController.php(62): Drupal\Core\Entity\EntityFormBuilder->getForm(Object(Drupal\field\Entity\FieldConfig), 'default', Array)
#13 [internal function]: Drupal\field_ui\Controller\FieldConfigAddController->fieldConfigAddConfigureForm('node', 'field_project_m...')
#14 D:\var\www\rp10.local\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#15 D:\var\www\rp10.local\web\core\lib\Drupal\Core\Render\Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#16 D:\var\www\rp10.local\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(121): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#17 D:\var\www\rp10.local\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#18 D:\var\www\rp10.local\vendor\symfony\http-kernel\HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#19 D:\var\www\rp10.local\vendor\symfony\http-kernel\HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#20 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 D:\var\www\rp10.local\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 D:\var\www\rp10.local\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 D:\var\www\rp10.local\web\core\lib\Drupal\Core\StackMiddleware\StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 D:\var\www\rp10.local\web\core\lib\Drupal\Core\DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 D:\var\www\rp10.local\web\index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#30 {main}

I wish there were, but no, that's about it. The only other thing I've not indicated is the contrib modules I've got, which are:

1. address
2. address_display
3. admin_toolbar
4. better_exposed_filters
5. ckeditor5_findandreplace
6. ckeditor5_font
7. color
8. computed_field
9. conditional_fields
10. config_filter
11. config_split
12. ctools
13. devel
14. devel_php
15. encrypt
16. entity_clone
17. entity_reference_revisions
18. environment_indicator
19. feeds
20. field_group
21. field_permissions
22. filefield_paths
23. genpass
24. jquery_ui
25. jquery_ui_datepicker
26. jquery_ui_slider
27. jquery_ui_touch_punch
28. key
29. libraries
30. linkit
31. mail_login
32. menu_block
33. name
34. paragraphs
35. paragraphs_table
36. patchinfo
37. pathauto
38. realname
39. real_aes
40. role_delegation
41. scroll_top_button
42. smart_trim
43. structure_sync
44. subpathauto
45. symfony_mailer
46. taxonomy_manager
47. telephone_validation
48. tfa
49. token

sdsheridan → created an issue. See original summary → .

I'm running into the same issue, and the ob_clean() call of #7 above at least now generated the captcha image, although the fonts are still not previewing properly.

• Drupal 10.1.6
• PHP 8.1.13 and 8.1.26
• GD 2.1.0 and 2.3.3
• Captcha 2.0.5

Sorry, realised this had been open too late. Please seee https://www.drupal.org/project/calendar_view/issues/3339333#comment-1528... 🐛 Date range - offset one day Needs review . Solution is there.

It would seem we're not quite there yet. Just downloaded the latest release, and we have an offset problem in the bubble. There's an error in the logic in CalendarViewBase::getRowValues(). In particular, this bit of code:

    // Get offset to fix start/end datetime values.
    $timezone = $this->getTimezone($field);
    $same_tz = date_default_timezone_get() == $timezone;
    $offset = $same_tz ? 0 : $this->getTimezoneOffset('now', $timezone);
    $values['value'] += $offset;
    $values['end_value'] += $offset;

If the site's timezone is anything other than UTC, and the field's timezone is the same as the site's timezone (which will often be the case), then the offset will be zero, and the start and end values will not be modified. However, the start and end values are in UTC (that's how they're stored in the DB), not in the site's or the field's timezones (unless they're UTC), and so the start and end values remain UTC, not those of the site or field's timezones.

For example (i.e., how to replicate this), my php.ini timezone is America/Toronto, as is my site's timezone, and the calendar and field use the default timezone (i.e., no timezone specified, to they fall back to the site's timezone). So date_default_timezone_get() will return "America/Toronto", as will $this->getTimezone($field), resulting in a zero offset, and leaving the bubble/title start and end times in GMT, even though they should be adjusted for the offset to Toronto time.

So, I think the test for same timezone should be removed, and the offset should simply be computed. Thus, the above code should be:

    // Get offset to fix start/end datetime values.
    $timezone = $this->getTimezone($field);
    $offset = $this->getTimezoneOffset('now', $timezone);
    $values['value'] += $offset;
    $values['end_value'] += $offset;

What's interesting is that the text of the displayed calendar item does have the correct date/time value(s), including after this change. I've not taken the time to hunt down why that is, but I assume the rendering of the item is handling the timezone offset properly (views and some other module rendering the "When" field independent of this function call), and not using the values from this function call.

shawn

sdsheridan → created an issue.

+1 here too.

Also just ran into this. Changed the parser to RSS and saved and then back to CSV, and the error was gone.

Whoops! Yes, that should have been "...are now showing correctly...".

I'll try to generate a diff, but in the meantime, here's what I did (both in src/Plugin/views/style/CalendarViewBase.php):
1. Created a new helper function getTImeZone that i placed right before getRowValues:

  /**
   * Helper function to determine what timezone to use if formatting and start-
   * and end-date rendering determination.
   *
   * @param EntityField $field The date field being used.
   * @return string The timezone string.
   */
  public function getTimeZone(EntityField $field) {
    $timezone = 'UTC';
    if ( !empty($field->options['settings']['timezone_override']) ) {
      $timezone = $field->options['settings']['timezone_override'];
    }
    elseif ( ( $user_timezone = \Drupal::currentUser()->getTimeZone() ) && !empty($user_timezone) ) {
      $timezone = $user_timezone;
    }
    elseif ( ( $system_timezone = \Drupal::config('system.date')->get('timezone')['default'] ) && !empty($system_timezone) ) {
      $timezone = $system_timezone;
    }
    $tz = new \DateTimeZone($timezone);
    $time_now = new \DateTime('now', $tz);
    $offset = $tz->getOffset($time_now);

    return ['timezone' => $timezone, 'offset' => $offset];
  }

2. Modified the getRowValues function to use the new timezone function as follows:

  /**
   * Get the value out of a view Result for a given date field.
   *
   * @param \Drupal\views\ResultRow $result
   *   A given view result.
   * @param \Drupal\views\Plugin\views\field\EntityField $field
   *   A given date field.
   *
   * @return array
   *   Either the timestamp or nothing.
   */
  public function getRowValues(ResultRow $row, EntityField $field) {
    $delta = 0;
    if ($delta_field = $field->aliases['delta'] ?? NULL) {
      $delta = $row->{$delta_field} ?? 0;
    }

    // Get the result we need from the entity.
    $this->view->row_index = $row->index ?? 0;
    $items = $field->getItems($row) ?? [];
    $item = $items[$delta]['raw'] ?? $items[0]['raw'] ?? NULL;
    $values = $item instanceof FieldItemInterface ? $item->getValue() : [];
    unset($this->view->row_index);

    // Skip empty fields.
    if (empty($values) || empty($values['value'])) {
      return [];
    }

    $timezone = $this->getTimeZone($field); // PATCHED to adjust timezone.

    // Make sure values are timestamps.
    $values['value'] = $this->ensureTimestampValue($values['value']) + $timezone['offset'];  // PATCHED to add timezone offset to UTC value.
    $values['end_value'] = ( $this->ensureTimestampValue($values['end_value'] ?? $values['value']) ) + $timezone['offset'];  // PATCHED to add timezone offset to UTC value.

    // Get first item value to reorder multiday events in cells.
    $all_values = $field->getValue($row);
    $all_values = \is_array($all_values) ? $all_values : [$all_values];
    $values['first_instance'] = reset($all_values);

    // Expose the date field if other modules need it in preprocess.
    $config = $field->configuration ?? [];
    $field_id = $config['field_name'] ?? $config['entity field'] ?? $config['id'] ?? NULL;
    $values['field'] = $field_id;

    // Get a unique identifier for this event.
    /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
    $entity = $field->getEntity($row);
    $key = $entity->getEntityTypeId() . ':' . $entity->id() . ':' . $field_id;
    $values['hash'] = md5($key . $delta);

    // Prepare a title by default (e.g. on hover).
    $start = $values['value'];
    $end = $values['end_value'] ?? $start;
    $title_string = $start && ($start !== $end) ? '@title from @start to @end' : '@field: @title @date';
    $values['title'] = $this->t($title_string, [
      '@field' => $field->label(),
      '@title' => $entity->label(),
      '@date' => $this->dateFormatter->format($start, 'long', '', $timezone['timezone']),    // PATCHED - even though passed the timezone to dateFormatter,
      '@start' => $this->dateFormatter->format($start, 'short', '', $timezone['timezone']),  // seemed to make no diff until adjusted for the offset above, 
      '@end' => $this->dateFormatter->format($end, 'short', '', $timezone['timezone']),      // so these could probably return to the way they were.
    ]);

    return $values;
  }

Will try the dev version when i get a chance. Pushing to get this project to beta right now, so hopefully after that.

shawn

So as a follow up to my follow-up, I tried the above, and for some reason the dateFormatter->format(...) is ignoring the timezone / not making an adjustment for the timezone offset; not sure why. So I hacked this temporarily to add the offset to the timestamps in getRowValues(). The title and rendering are not showing correctly in the calendar with this hack.

shawn

Just following up, looks like there might be three places that need adjustments:

1. You might want to create a method in class CalendarViewBase that established the timezone to use as per the above.
2. Use that method in function getRowValues when setting the $values{'title'] at the end of the function to pass to the $this->dateFormatter->format(...) calls.
3. Looks like the last spot might be the populateCalendar method, where the computation of $start_day and $end_day would need to be adjusted for the same timezone offset as above.

Hope that helps!

shawn

This may be related. I'm using date range field, and it would appear that the calendar is using the underlying UTC times (as stored in the database for date range values), and not converting them to the timezone selected for the calendar (specifically set to Toronto), not to the site's time (also Toronto) in the absence of the calendar's timezone, nor the user's timezone (also set to Toronto). So looks to me like the module is missing some time-zone adjustment for the start and end time values.

Not sure where this is best remedied, as it seems to be affecting both how the span box is drawn, as well as the title attribute of the node title link (both using the UTC dates).

However, the hierarchy should probably be something like:

if ( calendar timezone is set ) {
  adjust dates based on calendar timezone offset;
}
elseif ( user timezone is set ) {
  adjust dates based on user's timezone offset;
}
elseif ( site timezone is set ) {
  adjust dates based on site's timezone offset;
}

shawn

Tested here as well. Seems to be working fine.

sdsheridan → created an issue.

See https://www.drupal.org/project/hammerjs/issues/3354336#comment-15011950 💬 Practical example of how to use hammer.js Active for a way to do this pretty easily using hammer.js.

OK, i think i figured out why it wasn't working - i appear to have pulled the wrong hammer.js version from github. After pulling the 2.0.8 version, everything started working.

sdsheridan → created an issue.

That worked! Thank you!

sdsheridan → created an issue.

OK, just realised that the documentation needs to be updated for this to not happen. The settings.php (or settings.local.php) adjustments must be made first, and for D10, the variable is $settings, not $config. That said, it probably shouldn't catastrophically fail if those changes are not yet made, but rather should show instructions to that effect on the configuration page.

Also, not seeing any changes now despite being able to access the configuration page. Will open separate issue for that.

sdsheridan → created an issue.

Would be great to get this included in the production version of the module. I've implemented the patch in #23 and it's working great for me.

shawn

OK, so i've narrowed this down to an issue with granularity. The duration is making it through to the DurationService::getHumanReadableStringFromDateInterval (dpm is showing that), but the granularity array being passed is all false. Where do I need to set the granularity string for a computed field plugin so that it gets passed to the method properly?

sdsheridan → created an issue.