🇵🇭Philippines @bryanmanalo

Added a patch to store the default date and view before any ajax call. Then reload those values on calendar rebuild/ajax complete.

Visually speaking, the redraw is not noticeable.

Sorry I misunderstood the issue.

In my case, the problem was the ds setting "layout_suggestion_bc". If this is set to TRUE, layout--onecol--node-video.html is not recognized, and it looks for layout-onecol--node-video. However, this is flagged by Drupal as invalid.

<!-- INVALID FILE NAME SUGGESTIONS:
   See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter
   layout_onecol__node__200526
   layout_onecol__node_video_teaser
   layout_onecol__node_video
   layout_onecol__node_teaser
   layout_onecol__node
-->

It might be helpful for others, this is the setting. Disable this if you are facing the same issue.

On a side note, why is there a hook_update_N to turn this ON by default?

Should this be re-opened?

https://git.drupalcode.org/project/ds/-/commit/833693cd386bd111eff81c008...

This particular commit still contains a single hyphen.

https://www.drupal.org/project/drupal/issues/3343198 🐛 Improve documentation of hook_theme_suggestions_HOOK_alter() Fixed will mark suggestions with a single hyphen as invalid.

#3 works indeed. However, shouldn't the module define its own hook_file_download for private files?

When using <= 10.2, excludes 10.2.9.

Shouldn't the composer.json version be:

core_version_requirement: "^10.2"

instead of

core_version_requirement: "<=10.2"

Patch updated. #2 patch causes class not found on LanguageInterface.php.

@marcus_johansson thanks! Latest is indeed working.

@netv mine was also exiting, can't remember how I resolved it with lando. But this is was the last working lando.yml:

name: bryanmanalo-d9
recipe: drupal9
config:
  composer_version: '2.2.0'
proxy:
  mailhog:
    - mail.bryanmanalo-d9.lndo.site
services:
  appserver:
    via: apache:2.4
    type: php:8.2
    webroot: ./docroot
    config:
      php: ./lando-config/php.ini
    build_as_root:
      - a2enmod headers
      - service apache2 reload
  database:
    type: mysql:5.7
    creds:
      database: drupal
  mailhog:
    type: mailhog
    hogfrom:
      - appserver
  etcd:
    type: lando
    services:
      image: quay.io/coreos/etcd:v3.5.0
      environment:
        - ETCD_AUTO_COMPACTION_MODE=revision
        - ETCD_AUTO_COMPACTION_RETENTION=1000
        - ETCD_QUOTA_BACKEND_BYTES=4294967296
      volumes:
        - ./etcd:/etcd
      command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
  minio:
    type: lando
    services:
      image: minio/minio:RELEASE.2020-12-03T00-03-10Z
      environment:
        MINIO_ACCESS_KEY: minioadmin
        MINIO_SECRET_KEY: minioadmin
      volumes:
        - ./minio-data:/minio_data
      command: minio server /minio_data
      healthcheck:
        test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
        interval: 30s
        timeout: 20s
        retries: 3
  milvus:
    type: lando
    services:
      image: milvusdb/milvus:v2.4.8
      command: ["milvus", "run", "standalone"]
      environment:
        ETCD_ENDPOINTS: etcd:2379
        MINIO_ADDRESS: minio:9000
      ports:
        - 19530:19530
        - 19121:19121
      volumes:
        - ./milvus-data:/var/lib/milvus/db
      depends_on:
      - "etcd"
      - "minio"

I ended up removing lando and switched with plain docker-compose here https://github.com/bryanmanalo/milvus-chatbot .

https://bryanmanalo.com/creating-chatbot-using-drupal-ai-module

Also experienced the same issue. I used the MR here in this issue. And the MR here https://www.drupal.org/project/drupal/issues/3047022#comment-15487162 🐛 Layout builder fails to assign inline block access dependencies for the overrides section storage on entities with pending revisions Needs work as per #13 and #11.

2 patches in total.

Thanks for the guidance!

Also experienced this, I tried using this script to install the path_alias update entity. However, not so sure if this is correct.

This will make the update db successful.

You can add this on hook_update_N or drush scr.

$update_manager = \Drupal::service('entity.definition_update_manager');
$path_alias = \Drupal::entityTypeManager()->getDefinition('path_alias');

// 1. Install the missing schema.
$update_manager->installEntityType($path_alias);


// 2.  Manually remove the index, because the update does nothing since we
// don't have a copy of the schema prior.
$schema = \Drupal::database()->schema();
$table = 'path_alias';

if ($schema->indexExists($table, 'path_alias__status')) {
  $schema->dropIndex($table, 'path_alias__status');
  \Drupal::messenger()->addStatus(t('The index "path_alias__status" has been removed from the table.'));
}
else {
  \Drupal::messenger()->addWarning(t('The index "path_alias__status" does not exist on the table.'));
}

Thanks @marcus_johansson.

Reporting that the patch is needed when adding a new one. However, you have to remove the patch in order to edit an existing one.

Patch added to fix the issue.

bryanmanalo → created an issue.

Yes, I experienced the issue in another part of the codebase. However, it could just be a combination of using this and menu_token module.

I was able to replicate this issue.

This is the error that I am getting.

Deprecated function: preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\token_or\Token->scan() (line 35 of modules/contrib/token_or/src/Token.php).

Adding a patch.

I do not know how to do MRs yet.

Attempting a fix.

bryanmanalo → created an issue.

bryanmanalo → created an issue.

For us the issue was from this particular patch from core: https://www.drupal.org/node/2898635 → . When this patch was removed, the filters were back.

A colleague was able to discover this issue for us.

This regex saved us a lot of time. Thanks!

bryanmanalo → created an issue.

bryanmanalo → created an issue.

Also experiencing this issue. I am surprised that this has not gained a lot of traction. Seems like a big issue for existing sites with lots of views with exposed filters.

Patch added to beta7

The patch fails on my end.

Adding another patch, with minimal changes.

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

Quickest patch I can come up with. However, this patch needs a lot of improvement.

https://www.drupal.org/files/issues/2023-08-31/3384443-plain_text-3_0.patch →

bryanmanalo → created an issue.

Hoping this is available soon.

Update patch.

Update patch with latest

Also needing this feature.

The information says though:

The pages can be served from the location in the public or private files
directory or from an alias set on the parent entity (where the field is attached
to).

However, when I looked at the code, the asset is served by whatever is the drupal default scheme which is usually public.

Found a work around on the above.

Enable 'view all revision' to the roles that need it. And use ' https://www.drupal.org/project/config_perms → ' contrib to block off access to 'entity.node.revision' and 'entity.node.version_history' . You can specificy other routes here to be able to pick which roles has access to which entity routes.

Just a heads up that we experienced an issue surrounding this if you are using this patch with filefield_paths with replace option enabled on a field.

This is becaue filefield_paths replace will allow 2 different fids with the same uri. There will be an instance where the file reference retreived will be on a older revision.

This patch checks that if the entity is not the latest revision, it will require the 'view all revision' permission.

#2 patch works! Thanks @Ludo.R!

But I have to modify slightly to make it compatible with another patch from https://www.drupal.org/project/profile/issues/3232335 🐛 User Profile form does not load latest revision when it is not the default one Needs review .

This was really helpful @colorfield. Thank you very much!

I also need the patch from @Ludo.R , with slight modification, as this is incompatible with that patch created there.

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

I am having an issue with this if used together with the patch from:
https://git.drupalcode.org/project/feeds_http_auth_fetcher/-/merge_reque...

I had to replace:

$response = $this->get($feed->getSource(), $sink, $cache_key,$feed->getConfigurationFor($this)['token']);

with this

$response = $this->get($feed->getSource(), $sink, $this->getCacheKey($feed), $feed->getConfigurationFor($this)['token']);

Not sure how to update MRs as of this point.

If anyone is interested, the default core behavior for private files is:

If you can view the content, you will have access to the private files attached to the content.

Some scenarios:

1. If you are an anonymous user and can't view the content because it is unpublished, you won't have access to the private files attached to it.
2. If you are an anonymous user but can view the content because it is published, you will also be able to see the private files attached to it.

This is true for paragraphs and even for webforms.

https://bryanmanalo.com/drupal-private-file-mystery-who-has-access