🇩🇪Germany @osopolar

@dieterholvoet Any reason why you did not integrate the fix for status (see #14)?

@makkus183 Can you (x)debug and check why it returns false? Which StreamWrapper do you use? I assume it's a different issue. This one is about figuring out if it's a local file or not. In your case it's about wrong behavior of $this->streamWrapperManager->getViaScheme(StreamWrapperManager::getScheme($uri), which of cause will make the detection fail but for different reasons. May you open a new issue and also link it here?

@johnny5th you where right, see 🐛 Follow-Up: Default public scheme is wrongly not considered as a local filesystem Active

Patch from MR!27 for composer.

osopolar → created an issue.

Patch from MR!26 for composer.

Thank you @ahmad-alyasaki, the issue was introduced by 🐛 Follow-up: Very slow JSON:API responses when images are stored on AWS bucket Needs review , recently committed and hopefully fixed soon.

@saschaeggi Do you mean it will break the forms or it will just disable the sticky action in many places?

For now I am fine with disabling sticky action. I would have disabled it completely, also for content forms, but there is no option for that. We use the thunder distribution, which pins the gin theme to 3.0.0-rc11, as "The update to current version of gin is quite complicated". I tried to use RC14, but I was not able to save the content form, as the content moderation select field (container) was moved to more actions and from there it did not work. I tried some related patches with no luck and decided to downgrade again, as resources for working on that are very limited.

For now I implemented hook_gin_content_form_routes_alter() to disable gin content form layout for ajax requests:

function thunder_gin_content_form_routes_alter(array &$routes) {
  // Do not use gin content edit form layout in ajax context (overlays).
  if (\Drupal::request()->isXmlHttpRequest()) {
    $routes = [];
  }
}

See also issue for thunder distribution: 🐛 Current Gin version does not work with media_library_edit Active .

This issue should not have been closed as fixed, as nothing was fixed. Therefore I created a new/duplicate one with a workaround, which might be used until gin theme got updated: 🐛 Current Gin version does not work with media_library_edit Active

osopolar → created an issue.

Patch in #32 can be removed as issue 🐛 Performance Degraded after update to twig 3.14.2 Active was fixed and released with Drupal 11.0.9, 10.3.10 and 10.2.12. Until that it can be ignored via composer .json extra.patches-ignore like that:

"extra": {
"patches-ignore": {
"thunder/thunder-distribution": {
"drupal/core": {
"Issue #3487031: Performance Degraded after update to twig 3.14.2": " https://www.drupal.org/files/issues/2024-11-20/3487031-33.patch → "
}
}
}
}

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

@daniel.bosen

Could you elaborate a bit more on why it's complicated to update to the current version of Gin? What issues are you encountering?

Follow-up for Drupal > 7: ✨ Add an option to only collapse the fieldset when no filters are active Active

osopolar → created an issue.

Thank you chrisla for helping. At the end it was my fault. The fieldset I want to make collapsed by default and open it only if filters are set come from Views Exposed Form Fieldset → and not from BEF.

osopolar → created an issue.

osopolar → created an issue.

Fixed issue "Warning: Undefined array key 3 in _menu_translate() (line 788 of /app/includes/menu.inc)." when field_ui is disabled.

Patch for MR!5 to be used with composer.

osopolar → created an issue.

Supporting Media Library would be awesome.

I have found how it might work: Add the media_library_add form to source info using hook_media_source_info_alter():

/**
 * Implements hook_media_source_info_alter().
 */
function custom_module_media_source_info_alter(array &$sources) {
  if (empty($sources['podcast']['forms']['media_library_add'])) {
    $sources['podcast']['forms']['media_library_add'] = MediaNameForm::class;
  }
}

And then implement the form, see for example docroot/core/modules/media_library/src/Form/OEmbedForm.php

osopolar → created an issue. See original summary → .

I already found a hint to my issue, see hook_media_source_info_alter() in media_library.module (media_library_media_source_info_alter()): the form to create media entities got added there for some types. For the slideshow plugin (docroot/modules/contrib/media_entity_slideshow/src/Plugin/media/Source/Slideshow.php) the media_library_add is not defined. Therefore \Drupal\media_library\MediaLibraryUiBuilder::buildMediaTypeAddForm() returns an empty array:

if (empty($plugin_definition['forms']['media_library_add'])) {
  return [];
}

Therefore the next step would be to add "add forms" for the other media plugins.

osopolar → created an issue.

Not much activity here. I suggest to close this ticket in favor of 📌 Fix INI directive track_errors PHP 8.0 compatibility errors Needs review as having multiple php compatibility tickets might be confusing and is harder to maintain.

Patch from #17 + compatibility fix for 🐛 PHP Fatal error: Uncaught TypeError: fclose(): Argument #1 ($stream) must be of type resource, bool given in /var/www/html/sites/all/modules/contrib/httprl/httprl.module:1885 Needs work + compatibility fix for 🐛 PHP 8.1 compatibility Active .

There is one difference to patch from #17, because if value was not provided (= NULL) it would behave like FALSE:

-function httprl_print_empty(&$data, $level = 0, $output_plain_text = TRUE) {
+function httprl_print_empty(&$data, $level = 0, $output_plain_text = FALSE) {

Fix link to related issue.

It seems that the fix got committed with the related issue 🐛 [AdminToolbarSettingsForm] Fix Fatal Error: Call to undefined method Drupal\Core\Menu\MenuLinkManager::invalidateAll() Fixed , see also https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/94/diffs

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

@alexpott Sorry, but currently I do not have budget to work on this.

Copy of patch from https://git.drupalcode.org/project/field_permissions/-/merge_requests/34... (Merge request !34) attached, to be used safely with composer".

The reason why #55 worked for me and some others seems to be that we still didn't upgrade to Drupal 10 🙈. Upgrading to Drupal 10 I found the note in upgrade status that all permissions in a user role must be defined in a module.permissions.yml file or a permissions callback, linking to the CR Permissions must exist → .

Re-roll patch from #2 so it works after applying Merge request !1 patch from 📌 Automated Drupal 10 compatibility fixes Needs review #8 ( 3289392-8.patch → )

Setting this drom RTBC to "Needs review".

@mostepaniukvm are you still using riddle and this patch in Drupal 10+?

Copy of patch from https://git.drupalcode.org/project/riddle_marketplace/-/merge_requests/1... attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

I am also wondering about the future of this module. We use it too.

@Alex, I saw your comment in ✨ Use Riddle API v2 Needs work did you already upgrade to API v3? If so, do you mind to share the patch (maybe in a separate issue)?

For me the error happened on test environment after importing a fresh database dump from production. So it's not a big deal.

In \Drupal\vgwort\Plugin\AdvancedQueue\JobType\RegistrationNotification::process() $response = $this->httpClient->send($request); is called without try-catch-block, at least while sending the message via drush vgwort:send node 1. We should interception the error there.

Might be related to 💬 How to render message text if node view is disabled for anonymous user? Active .

Might be related to 💬 How to render message text if node view is disabled for anonymous user? Active .

@alexpott What do you think about the solution? Search API also switches the theme. I think that might be considered as well to ensure that correct theme is used for rendering. For example, I set roles for rendering to "authenticated user", which does not have the right to use the admin theme. Calling /node/{nid}/vgwort now showed up as default theme instead of admin theme. I assume the default theme was used for generating the message text and drupal didn't switch back to admin theme later. If the role "authenticated user" has the right to use the admin theme, everything works as expected. That made me think that different themes might be used to render the content which may leads to different results. Ensuring that i.e. the default theme is always uses makes it more consistent. Any thoughts on this?

I now want to use cron to send the registration messages to vg wort, but do not want to mess with cron, ie. to run the complete cron job as admin. I looked how search api renders the content for "rendered_item" field. It allows to define a role to be used for that field, see \Drupal\search_api\Plugin\search_api\processor\RenderedItem::addFieldValues(). There it uses the account switcher:

// Change the current user to our dummy implementation to ensure we are
// using the configured roles.
$this->getAccountSwitcher()
  ->switchTo(new UserSession(['roles' => array_values($roles)]));

// ... render content ...

// Restore the original user.
$this->getAccountSwitcher()->switchBack();

Could we implement similar logic for vg wort?

osopolar → created an issue.

@mhx I did not understand the following code in \Drupal\bridtv\Plugin\QueueWorker\BridSyncWorker::processRemoteList(), therefore I did not touch it. Maybe something fundamental also changed regarding this code. May you check? $pagination['nextPage'] seems to be boolean and $pagination['page'] integer:

    // In case we are not on the last page yet, throw the next
    // item into the queue to continue processing.
    if (!empty($data['q_next']) && !(empty($pagination['nextPage']) || ($pagination['nextPage'] == $pagination['page']))) {
        $sync->queueRemoteListItem($pagination['nextPage'], TRUE);
    }

Copy of patch from !MR13 attached, for save use with composer.

@mxh The changes where not as trivial as thought as it was not only about modifying the endpoints but also implementing functionality of the new api, as legacy functions from and older api got removed. May you be so kind and review the changes? Or maybe ping others to review, in case you know somebody who is using the module. The syncing must have stopped for them too.

There was once a command for drupal console: #2920030: Add a Drupal Console command for clearing a queue →

For me it still seems to be relevant. I just edited the default content view (under /admin/structure/views/view/content) to reproduce the issue. There I added an new field with html in the label. The html of the label gets escaped. Switching to a different display style (i.e. unformatted list) has the same result.

I got feedback from BridTV why the API stopped working for us:

… the legacy functions have been cut. We announced the deprecation of APIv2 to APIv3. After APIv3 came out live, the endpoint "videos" led towards legacy functions, which were enabled for some time after the release. After we ensured we gave enough time, the endpoint "videos" was cut as a legacy function and now a new endpoint "video" must be used. This endpoint is leading to the APIv3. (bearbeitet)

I also asked what happened to endpoint: https://api.brid.tv/apiv3/players/catalog/{partner_id}.json

The mentioned endpoint was also deprecated with APIv2. Now on the APIv3, please be sure to use the following endpoint:
https://api.brid.tv/apiv3/player/list/{partner_id}.json

You can also find it in our documentation here:
https://developer.brid.tv/reference/listplayer

@mxh If you want I can minimally maintain the module, as long as we are using it, otherwise I won't be able to test.

I am wondering the same, because for us it also worked before. To me it looks like that BridTV updated it's API. Maybe they just turned off legacy functionality as otherwise a new api version should have been introduced. I will try to figure out what happened and also check what happened to the /players/catalog/{id}.json endpoint.

Copy of patch from https://git.drupalcode.org/project/bridtv/-/merge_requests/13.diff attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

osopolar → created an issue.

This patch is the fixed version of patch from #47 (with \Drupal\field\FieldStorageConfigInterface instead of \Drupal\Core\Field\FieldConfigInterface)

@gcb is patch in #47 actually working for you? Looking at field_permissions_entity_field_access():

-  if (!$field_definition->isDisplayConfigurable($context) || empty($items) || !is_a($field_definition->getFieldStorageDefinition(), '\Drupal\field\FieldStorageConfigInterface')) {
+  if (!$field_definition->isDisplayConfigurable($context) || empty($items) || !is_a($field_definition->getFieldStorageDefinition(), '\Drupal\Core\Field\FieldConfigInterface') || !$field_definition->getTargetBundle()) {

I don't understand how $field_definition->getFieldStorageDefinition() will return \Drupal\Core\Field\FieldConfigInterface.

Add patch for 2.x branch, as since 2.2.2 patch from #7 (3.x for 3.x and 2.x <= 2.1.1) does not work anymore for 2.x branch and development currently takes place in 2.x branch, but not 3.x, see 🌱 Roadmap for 3.x Active .

osopolar → created an issue.

Currently we are using the Thunder Admin Theme → , which is based on seven. After upgrading from 1.x to 2.x our Paragraphs Features stopped working due to this issue. As fisherman90 pointed out, it might not be necessary to limit the widget features to claro and gin (based) themes – or at least provide a way to enable the widget also for other themes.

Copy of patch from MR12 attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

Copy of patch from MR13 attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

osopolar → created an issue.

osopolar → created an issue.

I had an issue running drush simple-sitemap:rebuild-queue (drush ssr) for a eck entity related sitemap, resulting in the following error, which was hard to understand:

In Tables.php line 369:

'status' not found

In my case it was not the 'title' but the 'status' field (published => status).

Copy of patch from MR !29 attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

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

osopolar → created an issue.

@alexpott Do you have an idea how to fix it? Should there be a configuration where the user id for rendering might be set?

Is that a VG Wort specification to not report content to VG Wort? I haven't seen it in the Integration Manual. We have a headless setup consuming the Drupal backend by JSON:API. The pixel gets rendered in the frontend and if not required would avoid implementing a check for vg wort test-mode.

For now we did not implemented it as suggested but use a workaround in our custom helper module as suggested under https://drupal.stackexchange.com/questions/312612/how-can-i-run-the-inbu...

namespace Drupal\custom_helper\Commands;

use Consolidation\AnnotatedCommand\CommandData;
use Drupal\Core\Session\AccountSwitcherInterface;
use Drupal\Core\Session\UserSession;
use Drush\Commands\DrushCommands;

/**
 * A Drush commandfile.
 */
class VgwortRunAsAdmin extends DrushCommands {

  /**
   * The account switcher service.
   *
   * @var \Drupal\Core\Session\AccountSwitcherInterface
   */
  protected $accountSwitcher;

  /**
   * @param \Drupal\Core\Session\AccountSwitcherInterface $account_switcher
   *   The account switching service.
   */
  public function __construct(AccountSwitcherInterface $account_switcher) {
    $this->accountSwitcher = $account_switcher;
  }

  /**
   * @hook pre-command vgwort:send
   */
  public function preCommand(CommandData $commandData) {
    $this->accountSwitcher->switchTo(new UserSession(['uid' => 1]));
  }

  /**
   * @hook post-command vgwort:send
   */
  public function postCommand($result, CommandData $commandData) {
    $this->accountSwitcher->switchBack();
  }

}

And add the @account_switcher service to the custom helper modules drush.services.yml file:

services:
  custom_helper.commands:
    class: \Drupal\custom_helper\Commands\VgwortRunAsAdmin
    arguments: ['@account_switcher']
    tags:
      - { name: drush.command }

osopolar → created an issue.

osopolar → created an issue.

The vgwort_counter_suffix is already there. The button to increment the suffix still needs to be implemented, right. So currently re-authoring is still not possible, is it?

Patch from MR https://git.drupalcode.org/project/vgwort/-/merge_requests/38.diff to be safely used with composer.

osopolar → created an issue.

Copy of patch from https://git.drupalcode.org/project/facets/-/merge_requests/129.diff (#12) attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

Note that it is not yet possible to install this theme via composer. This should be possible when #3084063: Use information in info.yml files to determine project requirements → is completed.

Copy of patch from https://git.drupalcode.org/project/views_slideshow/-/merge_requests/8.diff attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous?".

I experienced the same is issue, due to an outdated globally installed drush. After removing that (https://www.drush.org/12.x/install/), it worked well.

💬 Conflicts with drupal/core-recommended 10.1.x-dev requires egulias/email-validator ~4.0.1 Active

osopolar → created an issue.

The question in #5 from @almaudoh was not answered. AFAICS It's not necessary to copy the complete default.services.yml to services.yml but it might be necessary to copy/set all options for a parameter and not just the one which should get overridden.

Example:

Set cookie_lifetime: 0 with following services.yml:

parameters:
  session.storage.options:
    cookie_lifetime: 0

After setting above code in services.yml and rebuilding cache the output of drush php:eval "var_export(\Drupal::getContainer()->getParameter('session.storage.options')) is:

array (
  'cookie_lifetime' => 0,
)

Which is different to the output with no services.yml which is:

array (
  'gc_probability' => 1,
  'gc_divisor' => 100,
  'gc_maxlifetime' => 200000,
  'cookie_lifetime' => 2000000,
  'cookie_samesite' => 'Lax',
  'sid_length' => 48,
  'sid_bits_per_character' => 6,
)

Therefore I assume that it might be necessary to define all options below for one parameter, at least if no defaults are defined by the corresponding service:

parameters:
  session.storage.options:
    gc_probability: 1
    gc_divisor: 100
    gc_maxlifetime: 200000
    cookie_lifetime: 0
    cookie_samesite: Lax
    sid_length: 48
    sid_bits_per_character: 6

Is that assumption right?

Anyway, looking at \Drupal\Core\Session\SessionConfiguration::__construct() shows that defaults are defined, so at least in this case the missing options shouldn't be problematic.