🇨🇦Canada @chrisck

@maxilein Your suggestion may not work for everyone. In our case we are needing flexibility around AND/OR logic around the contextual filter from fields of the current entity.

Patch #17 is working for me too. Thanks.

It seems that a patch for this is not necessary. There is a hook_file_download that we can use:

This hook allows modules to enforce permissions on file downloads whenever Drupal is handling file download, as opposed to the web server bypassing Drupal and returning the file from a public directory. Modules can also provide headers to specify information like the file's name or MIME type.

/**
 * Implements hook_file_download().
 */
function hook_file_download($uri) {
  $filename = \Drupal::service('file_system')->basename($uri);
  $disposition = 'attachment; filename="' . $filename . '"';
  return [
    'Content-disposition' => $disposition,
  ];
}

Replace the hook in your function with your custom module name.

chrisck → created an issue.

chrisck → created an issue.

chrisck → created an issue.

Sorry for the multiple MRs, I'm trying to get a handle on GitLab and the failing pipeline test. I'm unable to delete the branches that I made.

chrisck → changed the visibility of the branch 3389509-drag-handle-multiple-file-widget to hidden.

chrisck → changed the visibility of the branch 3389509-for-multiple-image to hidden.

chrisck → changed the visibility of the branch gin-3389509 to hidden.

chrisck → changed the visibility of the branch 8.x-3.x to hidden.

The MR needs a rebase or a re-roll. Patch could not apply.

The Select All or None buttons have been extremely useful in our project and we've been using it for some time now with no issues. Is it possible to consider making it part of the chosen module?

chrisck → created an issue.

I managed to get around this error by doing two things, though I’m not sure which has fixed the issue for me.

• Upgraded mglaman/drupal-check to ^1.4
• Upgraded weitzman/drupal-test-traits to ^2.1

In “require-dev” of composer.json

Same issue

We first installed Smart Date 3.5.0, and then four weeks ago upgraded to 4.1.0-beta1. We've been keeping up with regular updates.

@TolstoyDoyCom Thanks for your MR in the other issue. I'm confirming the MR fixes my issue, as reported here.

This looks to be a general problem in core and perhaps not specific to views_conditional.

Just reporting that we're seeing the same error in the Status page. Not 100% sure when exactly this happened, but could be due to an update.

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.

Content
The node.field_event_datetime field needs to be updated.

+1 to new D10 release please

Just reporting here that contextual_range_filter does work with Smart Date range field type. Make sure your contextual filters are enabled at /admin/config/content/contextual-range-filter

Configure your smart date range field contextual filter as follows:
When the filter value is NOT available

• Provide default value
• Type: PHP code

if (isset($entity['node'])) {
  // Get the date range
  $start_date = $entity['node']->field_smartdate_range->value;
  $end_date = $entity['node']->field_smartdate_range->end_value;
  $range = $start_date . '--' . $end_date;
  return $range;
}

For lower limit range only:

if (isset($entity['node'])) {
  // Get the date range
  $start_date = $entity['node']->field_smartdate->value;
  $range = $start_date . '--';
  return $range;
}

Hope this helps someone.

@asherry Thanks for spotting this. Sorry I missed this in the original MR. As this issue is closed (fixed) I created a new follow up issue with a new MR and tagged you there.

chrisck → created an issue.

There seems to be a mix up of the date functions used getHours(), getMinutes(), getSeconds() with local and UTC time.

The if() statement is not getting triggered because end constant is not 00:00:00 in local time. It is 00:00:00 in UTC time. I'm uploading a patch that takes this into account, which I've tested to be working in my setup.

I've just tested this issue with FCV and Drupal core's date range field type and the issue still exists.

Steps to reproduce issue:

1. Create Event content type with date range field type, with field settings Date Only.
2. Create FullCalendar view with date range field. In the Format: Full Calendar Display, settings select Start Date field and End Date field to be the same date range field (be sure when adding the field, select the first option and not the one that says [fieldname] - Duration, [fieldname] - End etc.)
3. Create Event with a date only date range.
4. On the FullCalendar view, drag and drop the event. Refresh the page. The event is saved as one day longer than intended.

Hi @Mingsong there is a bug with the event dragging as previously reported by @mandclu. The bug is in the eventDrop callback function in fullcalendar_view/js/fullcalendar_view.js on line 221:

 // Event drop call back function.
  function eventDrop(info) {
    const end = info.event.end;
    const start = info.event.start;
    let strEnd = '';
    let strStart = '';
    let viewIndex = parseInt(this.el.getAttribute("calendar-view-index"));
    let viewSettings = drupalSettings.fullCalendarView[viewIndex];
    const formatSettings = {
        month: '2-digit',
        year: 'numeric',
        day: '2-digit',
        hour: '2-digit',
        minute: '2-digit',
        second: '2-digit',
        timeZone: 'UTC',
        locale: 'sv-SE'
      };
    // define the end date string in 'YYYY-MM-DD' format.
    if (end) {
      // The end date of an all-day event is exclusive.
      // For example, the end of 2018-09-03
      // will appear to 2018-09-02 in the calendar.
      // So we need one day subtract
      // to ensure the day stored in Drupal
      // is the same as when it appears in
      // the calendar.
      if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
        end.setDate(end.getDate() - 1);
      }
      // String of the end date.
      strEnd = FullCalendar.formatDate(end, formatSettings);
    }

I've read through your comments and I understand why we need to subtract one day from the end date, however the following if() statement isn't triggering. So I printed the end date value to an alert and found the issue:

    // define the end date string in 'YYYY-MM-DD' format.
    if (end) {
      // The end date of an all-day event is exclusive.
      // For example, the end of 2018-09-03
      // will appear to 2018-09-02 in the calendar.
      // So we need one day subtract
      // to ensure the day stored in Drupal
      // is the same as when it appears in
      // the calendar.
      alert(end);
      if (end.getHours() == 0 && end.getMinutes() == 0 && end.getSeconds() == 0) {
        end.setDate(end.getDate() - 1);
      }

The end date alert is showing as:

17:00:00 GMT-0700 (Pacific Daylight Time)

This is why the if() statement isn't getting triggered, because the hours don't match up. So I updated the if() statement and the end date is now getting subtracted by one day as originally intended.

if (end.getHours() == 17 && end.getMinutes() == 0 && end.getSeconds() == 0) {

I'm not sure if this is the ideal solution, but definitely highlights some work needed here. I'm not sure where the 17:00:00 GMT is coming from, is this just a default value if the date value is null?

Lastly, the same issue is present in the eventResize() callback on line 84.

Ran into the same issue after upgrading from Drupal 9.4.x to 9.5.x. MR!3 is working for me on Drupal 9.5.9.

chrisck → created an issue.

@saschaeggi confirming that the maintenance mode message is now displayed on the user login form as a warning message.

Changing the issue title to better reflect the work being done

chrisck → made their first commit to this issue’s fork.

While the original issue summary does not mention using smart_date for all day functionality, smart_date is mentioned quite a few times in the comments. I'm reporting that smart_date 4.0.2 is working out of the box with fullcalendar_view 5.1.12 with all day functionality, without requiring any patches.

Perhaps what some are missing is that the field type has to be "Smart date range" and not, the core "Date range" with Smart date widget.

Download and enable the Smart Date Calendar Kit → on a new Drupal install and look at how it's configured.

chrisck → created an issue.

chrisck → created an issue.

I think a module maintainer has to create the dev release first from the link provided by @Pasqualle.

@Vinayak.Ambig looks like you're using the node bulk operations field. You need to swap node bulk operations (core) with views bulk operations field (VBO module) in your view.

+1 for this much needed feature!

chrisck → created an issue.

@BramDriesen this does not happen on the 2.2.x version

I've been able to replace and rename files in Drupal 9 without any custom code by using the File (Field) Paths module → . Following this awesome blog post, Better File Management for Drupal 8 and Drupal 9 – Part 1 I was able to give content editors the power to rename media files with normal sentence case and spacing, but have ideally managed filenames renamed by File Field Paths:

Media name:
Product Handbook 2023

Filename:
product-handbook-2023.pdf

In addition, if this were a media entity type Document and had a taxonomy term attached to this e.g. onboarding, I was able to get FFP to automatically place these in a structured location for easy file management:

/sites/default/files/documents/onboarding/product-handbook-2023.pdf

The only difference between what I did and what you'll find in the blog post is I have unchecked "Create Redirect" and "Retroactive update" and only have checked "Active updating" under the FFP settings in the file field settings. Retroactive update is useful if you have existing files that you want to update, and you'll only have to check this box once, and after it runs it unchecks itself. I've also used this to change file systems from private > public or public > private and update the file paths for my media files.

I am also using the Media file delete module → so that users are managing media entities rather than Files themselves. If the media entity is deleted, so is the file. I set the default value to be checked:

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function MYMODULE_form_media_confirm_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // Set confirm delete default value for media files.
  $form['also_delete_file']['#default_value'] = 1;
}

Finally, I have the following in my settings.php file, so that if I want to make sure orphaned files are removed, I can either wait for the next cron run or trigger a manual cron job.

/**
 * File settings (Custom).
 *
 * This will remove orphaned (deleted) files from the file system on the
 * next cron run.
 */
$config['file.settings']['make_unused_managed_files_temporary'] = TRUE;
$config['system.file']['temporary_maximum_age'] = 1;

Adjusted the line spacings to two before the ## heading and one after :)

I can confirm number 3 is already fixed. I checked for line endings and they are all unix style LF.

MR in #7 addresses all of the phpcs errors found.

In addition to the amswap.module errors found, there are more errors found in /src/Render/Element/Amswap.php:

------------------------------------------------------------
FOUND 7 ERRORS AND 1 WARNING AFFECTING 7 LINES
------------------------------------------------------------
 42 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 50 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 67 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 74 | WARNING | [ ] Line exceeds 80 characters; contains 84 characters
 74 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 78 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 83 | ERROR   | [x] Inline comments must end in full-stops, exclamation marks, question marks, colons, or closing parentheses
 90 | ERROR   | [x] Expected 1 space after "="; 2 found
------------------------------------------------------------

This change looks good. I can confirm the change to American English spelling.

This change looks good. I can confirm the change to American English spelling.

These are very small nits from the README.me template guide → :

1. ## Introduction
   A Drupal module that allows you to provide a customized administration menu for each role. For example, you can create an "Editor" menu, then assign that menu to to the "Content editor" role.
   

   Two lines before ## headings. Suggest we add an additional line space or remove Introduction heading and keep single line space.
    

2. ## Requirements
   Two lines before ## headings.
    
3. ## Installation
   Two lines before ## headings.
4. ## Configuration
   Two lines before ## headings.
    
5. ## Troubleshooting
   Two lines before ## headings.
    
6. ## FAQ
   Two lines before ## headings.

7. 1. **Q**: Is this the same as the "Administration Menu Source" module?
   **A**: No, AMSwap was built from scratch for Drupal 8 by a separate developer,
   but it was inspired by Administration Menu Source.

   Remove ordered list. Insert new line break for "A: ..." portion.
    

8. ## Maintainers
   Two lines before ## headings.

Closing as duplicate of #3338445 🐛 [VBO] Action form breaks alignment Needs review

The MR in #2 fixes the alignment by reordering the flex items (detail is first, select all toggle is second, everything else stays the same) and increasing the flex-basis for these two items to wrap to a new row. The alignment has been tested and working in different browser sizes. I've also tested the toggle to enable/disable the "Always show selection info" in views.

chrisck → created an issue.

If this is a challenge to build into the module, how can this be done programmatically via local tasks? Something like this?

mymodule.links.task.yml
mymodule.view_mode_page_name:
  route_name: view_mode_page.display_entity
  title: 'View Mode Name'
  route_parameters:
    view_mode: 'view_mode_machine_name'
    entity_type: 'node'
  base_route: entity.node.canonical

mymodule.routing.yml
mymodule.view_mode_page_name:
  path: '/node/{node}/view-mode-pattern'
  defaults:
    _controller: '\Drupal\view_mode_page\Controller\MainController::displayEntity'
  requirements:
    _permission: 'access content'

@sam452 I'm experiencing the same problem with nginx. Can you please share where you added that into the location block?