🇨🇭Switzerland @handkerchief

Workaround for specific cases:

/**
 * Implements hook_preprocess_HOOK().
 */
function THEME_preprocess_TEMPLATENAME(&$variables) {
  // Remove the <p>tags inside <dt> and <dd> tags.
  if ($text = $variables['items'][0]['content']['#text']??NULL) {
    if (str_contains($text, '<dt')) {
      $result = preg_replace(
        pattern: '#<(dt|dd)\s*>\s*<p>(.*?)</p>\s*</\1>#si',
        replacement: '<$1>$2</$1>',
        subject: $text
      );
      $variables['items'][0]['content']['#text'] = $result;
    }
  }
}

But be careful, for complex scenarios you go better with the DOM-API.

Some simila issues:
🐛 Prevent CKEdtior5 from wrapping blockquote elements with unneeded tags Closed: works as designed

https://github.com/ckeditor/ckeditor5/issues/1537

Same problem here. For example, if you add a dl-list:

<dl>
    <dt>Some text</dt>
    <dd>Some text too</dd>
</dl>

Will result in this after saving:

<dl>
    <dt><p>Some text</p></dt>
    <dd><p>Some text too</p></dd>
</dl>

I tried it with all format filter unchecked (/admin/config/content/formats/manage/full) , and with the filters like html corrector, newline
etc. on = same result.

@jurgenhaas I tested the new dev version of drd and drd_agent. Commit #16 of this issue is working, no more problems to add cores.

BUT your suggestion in #18 is not working. 🐛 OpenSSL" not found Active
The drd_agent update 8002 was successful, but a "drush drd-ping" from the main instance results in "Input is incomplete" (with drd_agent debug mode on). Reason: The $input variable at line 270 in /drd_agent/src/Agent/Action/Base.php has an empty $input['args'] parameter. I don't know why. So the only workaround right now is to re-register all remote sites so you get a new token with the correct values/parameters.

handkerchief → created an issue.

I don't know with more recommended, but in a hurry I can only do it for patches. The adjustment must also be done on the agent side.

This is how it works for me again. But I have to link the projects again.

So the final problem is the function \Drupal\drd\Crypt\Method\OpenSsl::getLabel():

  /**
   * {@inheritdoc}
   */
  public function getLabel(): string {
    return 'OpenSSL';
  }

Which is called in \Drupal\drd\Crypt\Base::getMethods():

  /**
   * {@inheritdoc}
   */
  public static function getMethods($instances = FALSE): array {
    $dir = __DIR__ . '/Method';
    $methods = [];
    foreach (['Mcrypt', 'OpenSsl', 'Tls'] as $item) {
      /* @noinspection PhpIncludeInspection */
      include_once $dir . '/' . $item . '.php';
      $classname = "\\Drupal\\drd\\Crypt\\Method\\$item";
      /** @var BaseMethodInterface $method */
      $method = new $classname(\Drupal::getContainer());
      if ($method instanceof BaseMethodInterface && $method->isAvailable()) {
        if ($instances) {
          $methods[$method->getLabel()] = $method;
        }
        else {
          $methods[$method->getLabel()] = [
            'classname' => $classname,
            'cipher' => $method->getCipherMethods(),
          ];
        }
      }
    }
    return $methods;
  }

Strictly speaking the part $methods[$method->getLabel()]

Solution: Change the getLabel() method of OpenSsl.php, Tls.php and Mcrypt.php or use the $item value.

Ok so the problem is, the drd module core add form is not correct, I don't know why. I run composer remove drupal/drd and after that composer require 'drupal/drd:^4.1', so I'm sure it's the current version 4.1.7.

New added cores are saved wrong in the database (table drd_domain):

name = NULL
crypt = OpenSSL

First of all, as a first crypt settings on loading the add-core-page is this (but MCrypt is greyed out if i click on the select list)

After changing to OpenSSL:

#10 helped not. Same issue.

In \Drupal\drd_agent\Agent\Action\Base::getCryptInstance(), the value of $authorised[$uuid]['crypt'] is always "OpenSSL". I have reinstalled everything several times, deleted and relinked core, with one exception, I have not uninstalled and reinstalled the drd module on the main instance.

@jurgenhaas Do you have any idea what's going on?

I deleted the core of the project on the main instance, and reconnected it again with the agent. After that, I checked the variable "$method" at \Drupal\drd_agent\Crypt\Base::getInstance():
OpenSSL

So in the method \Drupal\drd_agent\Agent\Action\Base::getCryptInstance() the value $authorised[$uuid]['crypt'] is indeed "OpenSSL". I guess something went wrong with all the instances with the update of drd_agent including “drush updb” which was shown as successful.

To avoid investing even more time, it is probably best to uninstall the agent everywhere, reinstall it and then link all the projects again.

So I have switched on the debug mode in the drd_agent project, I get this message:
"Input is incomplete"

The variable "$input" at line 270 in \Drupal\drd_agent\Agent\Action\Base::run() in /drd_agent/src/Agent/Action/Base.php:

Array
(
    [uuid] => string 36 characters
    [args] => 
    [iv] => string 24 characters
)

So no $args variable is available, which causes the message "Input is incomplete"

The request from the module drd on the main instance:

Array
(
    [0] => post
    [1] => https://example.com/drd-agent
    [2] => Array
        (
            [body] => string 120 charaters
            [headers] => Array
                (
                    [X-Drd-Version] => 1.7.0
                )

            [cookies] => GuzzleHttp\Cookie\CookieJar Object
                (
                    [cookies:GuzzleHttp\Cookie\CookieJar:private] => Array
                        (
                        )

                    [strictMode:GuzzleHttp\Cookie\CookieJar:private] => 
                )

        )
)

@jurgenhaas does that give you a clue as to what might be wrong? I have only updated the modules and updated the database.

It gets even stranger, in \Drupal\drd\Crypt\Base::getInstance() I've logged the variable $method, and what does the log say?
'OpenSsl'

So at this point, the correct string is used.

Thank you, I've checked the database from the main instance already:
SELECT crypt FROM `drd_domain`;
result OpenSsl

I've run cron multiple times, also run "drush cr", nothing helped... strange.

Thanks for the fast response. The database update has already been carried out immediately after the update, on the main instance as well as on the projects. All updates were successful, so this must be a bug, right?

handkerchief → created an issue.

Any news on that?

Ok I've just seen this issue 🐛 Rename ActionPlugin Generator Active

handkerchief → created an issue.

Same problem here, #2 fixed it! thx

This patch should help.

Core: 10.4.0
Module: 1.1.1

Error on /admin/structure/block/list-inline-block:

Warning: Attempt to read property "entity" on null in Drupal\list_inline_block\Controller\ListBlock->getBlock() (line 103 of /modules/contrib/list_inline_block/src/Controller/ListBlock.php)

Error: Call to a member function label() on null in Drupal\list_inline_block\Controller\ListBlock->getBlock() (line 103 in /modules/contrib/list_inline_block/src/Controller/ListBlock.php).

In my case it was the installation of the Webform libraries: https://www.drupal.org/node/3003140 →
... which caused the error

#19 composer dump-autoload -o was also the solution. Hope there is no downside to this.

Same problem here.

Core: 10.3.10
calendar_view: 2.1.x-dev updated 18 Aug 2024 at 19:46 UTC

• calendar_view_w52-2024.png → : This week is correct, there are no events and all the dates are correct.
• calendar_view_w01-2025.png → : This week is wrong, events should be visble in this week and the dates (month, year, days) are wrong.
• calendar_view_w02-2025.png → : This week is correct again, events are visble and the dates (month, year, days) are also correct.

I'm using this css (copied from bootstrap 5):

.field--name-field-media-oembed-video {
  position: relative;
  width: 100%;
  &:before {
    display: block;
    padding-top: 56.25%; // 16x9
    content: "";
  }
  iframe {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
  }
}

handkerchief → created an issue.

Simple workaround, uninstall all slick and blazy modules, instead using vanilla "swiper JS": https://swiperjs.com/
Of course there is a bit of work todo, because other classes and so on, but after all, I'm no longer dependent on this module.

handkerchief → created an issue.

@walkingdexter You tested another scenario, our scenario is:

1. New Drupal installation in English
2. Add another language, e.g. German. But English still is the default language.
3. Add nodes directly in the German language, no translations
4. Generate the sitemap

Then you will get the effects described in #3.

I thinks the problem is, the site default language is English, but only nodes in German exist without translations. Again the reason for this site configuration are effects like 🐛 Configuration language being overwritten during module install Needs work or 🐛 Installing a module causes translations to be overwritten Fixed . So to avoid such translation problems if you have another default or installation language as English, we use English as default language, although only German is used without translations.

@anybody see here: https://www.drupal.org/project/photoswipe/issues/3024243#comment-15804453 ✨ Enable media fields in custom captions Fixed

@peterhebert I had the same issue, I was able to solve this with the peprocess hook:

function HOOK_preprocess_photoswipe_image_formatter(&$variables) {
  // Get correct caption for the image.
  $imageDTO = ImageDTO::createFromVariables($variables);
  $media = $imageDTO->getItem()->getParent()->getEntity();
  $media_title = $media->label();
  $example_text = $media->field_example_text->value;

  $final_caption = $media_title . '<br>' . $example_text;
  $variables['attributes']['data-overlay-title'] = $final_caption;
}

The code is just an example. Hope this helps someone.

Ok i found the infos: https://www.drupal.org/docs/8/modules/drupal-remote-dashboard/configurat... →

As described in #70, the patch in #57 works for us with Drupal 10.3.5, it would be great if this issue is going further in progress.

I wanted to report the same for the Gin theme.

The layout seems off especially on these pages:

• /drd/domains/domain/*
• /drd/cores/core/*
• /drd/hosts/add
• /drd
  • Some buttons are not readable

handkerchief → created an issue.

handkerchief → created an issue.

Reason: I've not enabled domain_access because we work only with the field "field_domain_source". So maybe you can set a dependency in the info file. FYI: The module works exactly the same with the field "field_domain_source", so maybe it's possible to expand the module for this field with another views filter.

handkerchief → created an issue.

For us the items are leftsided out of view.
3.0.0-rc13
DC: 10.3.2

Same problem for us as in #7 described.

Same issue here, #5 is fixing the problem. thx.

handkerchief → created an issue.

Same issue for me as with #33: https://www.drupal.org/project/redirect/issues/3447718#comment-15736214 🐛 Cannot redirect to an empty URL Needs review

Ok forget my posts, I found the reason: https://www.drupal.org/project/drupal/issues/2972344#comment-15408830 🐛 InvalidArgumentException: Cannot redirect to an empty URL. in Symfony Active
It was the exact same situation in my scenario. All good.

After this error, I had do uninstall the whole module, because when I'm going to the frontpage, this error appears again and again, although I've deleted all redirects, rebuild cache etc.

Redirect to the frontpage seems impossible. I tried with "", with "/node/some-id", it always give me this error:

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (Zeile 68 in /webroot/vendor/symfony/http-foundation/RedirectResponse.php).

#0 /webroot/web/core/lib/Drupal/Component/HttpFoundation/SecuredRedirectResponse.php(60): Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl('')
#1 /webroot/vendor/symfony/http-foundation/RedirectResponse.php(39): Drupal\Component\HttpFoundation\SecuredRedirectResponse->setTargetUrl('')
#2 /webroot/web/core/lib/Drupal/Core/Routing/TrustedRedirectResponse.php(26): Symfony\Component\HttpFoundation\RedirectResponse->__construct('', 301, Array)
#3 /webroot/web/modules/contrib/redirect/src/EventSubscriber/RedirectRequestSubscriber.php(170): Drupal\Core\Routing\TrustedRedirectResponse->__construct('', '301', Array)
#4 [internal function]: Drupal\redirect\EventSubscriber\RedirectRequestSubscriber->onKernelRequestCheckRedirect(Object(Symfony\Component\HttpKernel\Event\RequestEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#5 /webroot/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\RequestEvent), 'kernel.request', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#6 /webroot/vendor/symfony/http-kernel/HttpKernel.php(157): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\RequestEvent), 'kernel.request')
#7 /webroot/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#8 /webroot/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#9 /webroot/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#10 /webroot/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#11 /webroot/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#12 /webroot/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#13 /webroot/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#14 /webroot/web/modules/contrib/shield/src/ShieldMiddleware.php(263): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#15 /webroot/web/modules/contrib/shield/src/ShieldMiddleware.php(130): Drupal\shield\ShieldMiddleware->bypass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#16 /webroot/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\shield\ShieldMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /webroot/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /webroot/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /webroot/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /webroot/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /webroot/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#22 {main}

Redirect to another node, which is not defined as frontpage in "/admin/config/system/site-information" is working. It seems that one problem is, that will trigger empty url error.

Core: 10.3.2
Redirect: 8.x-1.10

Had the exact same issue, Same as #8, the Security Review module was the problem. Thanks!

Tried with full backup, it's working again now.

Can anyone tell me if this is specific to Shield or a general phenomenon or what could be the cause? Depending on that, this issue can be treated further or analyzed somewhere else.

Hi arti.singh, thank you very much.

I had the same error:
Error: Call to undefined function Drupal\twilio\Controller\twilio_command() in Drupal\twilio\Controller\TwilioController->receiveMessage() (Zeile 65 in /modules/contrib/twilio/src/Controller/TwilioController.php).

Your patch in #2 has fixed the error, the hook is working.

It would be great if someone could confirm or integrate this.

Strangely enough, importing a DB backup doesn't help either...

@samit.310@gmail.com But not logging out does not automatically mean that users should continue to use the website despite maintenance.

Example from practice:
Website is briefly switched to maintenance mode several times a day because automatic backups are performed. However, it is correct that during backups, no user administers the website and therefore should not have the permission “Use the site in maintenance mode”. But the users should not all be logged out just because maintenance mode was switched on briefly. If you have a website with a community where many users are logged in, then they are automatically logged out several times a day.

I have the exact same problem. Caught the eye in 💬 Undefined constant "Drupal\node\Entity\DRUPAL_OPTIONAL" Active
https://www.drupal.org/project/shield/issues/3304657#comment-15694393 💬 Undefined constant "Drupal\node\Entity\DRUPAL_OPTIONAL" Active

Can confirm that there is no shield.setting entry in the config table after uninstalling, but there is still the described error which discards the whole instance and makes it unusable. As soon as the module is reactivated “drush en shield”, the page works again. In the logs it simply says Access denied for each path you have selected, otherwise no error or message.

Only affects the Shield module, other modules can be installed and uninstalled without any problems. But it only happened to me after I had installed a patch (but not anymore), see link. any ideas?

A strange phenomenon. After testing the patch, I can no longer uninstall the Shield module, otherwise it will discard the entire website. The design no longer works correctly and on every page it says (access denied), if I install the shield module again, the site works correctly again. I have now updated to shield 1.8.0, and it runs without a patch. But still the same. Only applies to the shield module. I didn't do anything except apply the patch once, tested it and then I wanted to uninstall shield again. Any idea what's going on?

Hi Aporie, thank you very much for your information and your efforts.
I have tested the patch, rebuilt caches etc. Unfortunately still the same error as in #15. Maybe someone else can test this, it didn't work for me.

I deactivated shield (not uninstalled), but error show up again if I want to grab some data from the instance.

Error: Undefined constant "Drupal\node\Entity\DRUPAL_OPTIONAL" in Drupal\Core\Entity\EntityStorageBase->mapFromStorageRecords() (Zeile 418 in /core/lib/Drupal/Core/Entity/EntityStorageBase.php)

#0 /core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(186): Drupal\Core\Entity\EntityStorageBase->mapFromStorageRecords(Array)
#1 /core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): Drupal\Core\Config\Entity\ConfigEntityStorage->doLoadMultiple(NULL)
#2 /core/lib/Drupal/Core/Entity/EntityTypeBundleInfo.php(99): Drupal\Core\Entity\EntityStorageBase->loadMultiple()
#3 /core/lib/Drupal/Core/Entity/EntityTypeBundleInfo.php(80): Drupal\Core\Entity\EntityTypeBundleInfo->getAllBundleInfo()
#4 /core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(200): Drupal\Core\Entity\EntityTypeBundleInfo->getBundleInfo('user')
#5 /core/lib/Drupal/Core/Entity/EntityFieldManager.php(384): Drupal\Core\Entity\ContentEntityStorageBase->getEntityClass('user')
#6 /core/lib/Drupal/Core/Entity/EntityFieldManager.php(353): Drupal\Core\Entity\EntityFieldManager->buildBundleFieldDefinitions('user', 'user', Array)
#7 /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(1219): Drupal\Core\Entity\EntityFieldManager->getFieldDefinitions('user', 'user')
#8 /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(503): Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables(Array, false)
#9 /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(428): Drupal\Core\Entity\Sql\SqlContentEntityStorage->mapFromStorageRecords(Array)
#10 /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(394): Drupal\Core\Entity\Sql\SqlContentEntityStorage->getFromStorage(Array)
#11 /core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array)
#12 /core/lib/Drupal/Core/Entity/EntityStorageBase.php(608): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#13 /core/modules/basic_auth/src/Authentication/Provider/BasicAuth.php(93): Drupal\Core\Entity\EntityStorageBase->loadByProperties(Array)
#14 /modules/contrib/shield/src/ShieldMiddleware.php(343): Drupal\basic_auth\Authentication\Provider\BasicAuth->authenticate(Object(Symfony\Component\HttpFoundation\Request))
#15 /modules/contrib/shield/src/ShieldMiddleware.php(263): Drupal\shield\ShieldMiddleware->basicAuthRequestAuthenticate(Object(Symfony\Component\HttpFoundation\Request))
#16 /modules/contrib/shield/src/ShieldMiddleware.php(137): Drupal\shield\ShieldMiddleware->bypass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 /core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\shield\ShieldMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /core/lib/Drupal/Core/DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#23 {main}

Same problem here.
Drupal 10.2.6

basic_auth enabled.
shield (8.x-1.7) enabled.

I edited a media entity and this error appears.
No core update happened.

I needed to disable shield, and it worked again.

Adjusting the passwords is very time-consuming as this has to be done on many instances. And what guarantees that it won't happen again? Is there a possibility of a bugfix on the Shield module?

Workaround:

/**
 * Implements hook_simple_sitemap_links_alter().
 */
function HOOK_simple_sitemap_links_alter(array &$links, $sitemap_variant) {
  $sitemap_id = $sitemap_variant->id();
  $node_storage = \Drupal::entityTypeManager()->getStorage('node');
  if ($sitemap_id === 'default') {
    foreach ($links as $key => $link) {
      $nid = $link['meta']['entity_info']['id'];
      $node = $node_storage->load($nid);
      if (str_contains($link['url'], '/node/')) {
        $links[$key]['url'] = $node->toUrl()->setAbsolute()->toString();
      }
    }
  }
}

+1, similar case with me.

Default language is English.
Second language is German.

But the Site uses only German without prefixes and so on. Reason for that setting are problems with module translations if you don't install drupal with english as default languge.

So aliases only exist in German, but the sitemap will always create the English-Version wich is node/1, node/2 etc.

ps: I had to delete this code from my version in #2, otherwise it was not working.

else {
  throw new \InvalidArgumentException('Either device token or topic must be provided.');
}

I've seen that you've made a lot of adjustments, just in case that still needs to be taken into account somewhere, possibly already obsolete anyway.

Because it is not yet merged, a patch may still be needed for many, which is integrated with updates, here it is.

+1 please merge, thank you all.

+1 for this excellent feature! It's really needed. Is there any status update on this?

Thank you very much. So I am curious to see how the development of the module progresses.
To your question: Personally, I would like the module to provide a service API for the most frequently required things. Whether this should be outsourced to a submodule is up to you.

I switched to the project firebase_php → . It has validation features as well as the modern way of API as google is discontinuing the old one soon.

handkerchief → created an issue.

A related question to this topic: What do you recommend for regularly checking whether the tokens already saved are still valid?

Would a good option be, for example, a cronjob that tests all stored tokens with this service every week/month and deletes them from the database if they are negative?

@see https://firebase.google.com/docs/cloud-messaging/manage-tokens#update-to...

A related question to this topic: What do you recommend for regularly checking whether the tokens already saved are still valid?

Would a good option be, for example, a cronjob that tests all stored tokens with this validation handler every week/month and deletes them from the database if they are negative?

@see https://firebase.google.com/docs/cloud-messaging/manage-tokens#update-to...

This commit fixed the problem (after cache clear)
https://git.drupalcode.org/project/drupal/-/commit/61bc6f8e8cda4f708038c...

I have 10.2.4 and the same problem:

1. go to /admin/config/regional/content-language
2. Check Content checkbox
3. Check contenttype page and some different fields you wish to translate
4. click on save
5. Now all the fields of the contenttype page are hidden and the main checkbox of that type checked

it is impossible to translate the website, the settings are not saved.
No error in the logs, what the hell is going on?

handkerchief → created an issue.

handkerchief → created an issue.

It took me a while because I had to study the module and chose the colorbox approach first. But it's much easier, here's the patch.

This allows you to select the GLightbox formatting from the media reference field within the paragraph entity type. The settings remain the same as in your screenshots. But I do not use ept_image_gallery.

It works for me now. It would be great if you could also test or optimize it. If I can also maintain the module, just add me.

Hi @joekers,
Thank you very much. I have tested it, it now works with the dev version, the saving as well as the output.

Hi @levmyshkin

Thank you very much for your fast reponse.

Colorbox, yes that's the case. I have already initiated this for Juicebox, where it now works correctly:
https://www.drupal.org/project/juicebox/issues/2996745 →

In your showcase gif: As far as I can see, you have 2 images per gallery. And if you click on an image in a gallery and then switch the images back and forth in the lightbox, the same image is always displayed. But it would be correct if it switched between the 2 images in the gallery, correct? Is this currently possible without an additional code?

handkerchief → created an issue.

handkerchief → created an issue.

The patch #2 does not fix the problem for me. It is still the same error.

handkerchief → created an issue.

handkerchief → created an issue.

@jurgenhaas Thank you very much for answering all the questions. You have helped me a lot and the answers are conclusive :)
Perhaps the one or other question & answer can still be included in the documentation, if it isn't already and I just haven't seen it.
Thanks again

handkerchief → created an issue.

There was no real README file with content committed yet. It was only used for the initial commit. Correct readme file is now committed.

Merged the changes.

@mortona2k Thank you for your message. No, I have not missed the latest work on the Refreshness module. But unfortunately not much has happened for far too long, which is why I programmed a different type of integration for myself some time ago. But I hadn't gotten around to publishing it on drupal.org yet.

In addition, Refreshless was a bit too extensive for me and I wanted a simpler method. This would probably offer fewer options, but perhaps enough for many people.

Also with Turbodrop I almost took a complicated path, because there are many extensive methods to integrate this. Like "Symfony UX Turbo" and NPM composer methods where users have to make customizations. That's why I find the local method the easiest. I will extend it with more TURBO versions, test and then release a stable realease.

@jaydenpearly Thank you for your feedback. That was exactly the point, to offer as simple an integration as possible. I had developed Turbodrop for TURBO version 7, now it's version 8, so I still have to do some testing. Feel free to give me feedback if you have any suggestions for improvement or if something doesn't work.

Ok my bad, patch #15 is working, but something was wrong with the import.

I'm on Drupal 10.2.4
The patch doesn't work, new code base.

@sascha_meissner thank you very much, it's working now.
When hidden and when reloading, the page jumps because the toolbar is displayed first. This is due to the nature of the thing when the script is executed, so probably not much can be changed. In any case, a big step forward, thanks again.

Thank you very much for your work. But I am a bit confused. The toolbar on the left disappears, but:
- The padding on the left remains
- The toolbar at the top of the screen remains

Just the icons of the toolbar on the left are gone. I currently have zero benefit. The goal would be to be able to hide the admin areas in the frontend as if you were viewing the website anonymously. But the admin bars still disrupt the whole layout.

Same issue, same solution, patch #6 works for me for Drupal 10.2.2.

Great! Until now, we have always had to solve this by creating a new role especially for this scenario, which is an unnecessary effort.

+1 for this feature! I've wanted that for a long time for the same reason as the author of this issue.

Same with the module "domain" enabled:

Drupal\Core\Entity\EntityStorageException: 'field_config' entity with ID 'node.example.field_domain_source' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 519 of /web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).