🇩🇪Germany @osopolar

@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.

Worked for me too by adding the issue fork to the composer.json repositories:

"repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": [
                "drupal/form_mode_manager"
            ]
        },
        {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/form_mode_manager-3297262.git"
        },

and requiring the latest commit from PR via:

composer require "drupal/form_mode_manager:dev-3297262-automated-drupal-10#2c564b3b047dfc5002349c45ef6eec9aa98f8968"

I have updated the sandbox module Content Access Lite → to work with Drupal 10. In case there is some interest I could promote it a a real module.

"Reset to defaults" and submitting the defaults again sets the right grants. Could it be related to caches?

Current dev version is compatible with D10, see https://git.drupalcode.org/project/disable_user_view/-/commits/2.0.x

But 2.x branch does not include 🐛 All links to user page are broken now Fixed .

We had run into this issue too and since then we just did sub-request to get additional data. Today I had the need to add such a "forbidden" include and surprisingly it worked. I remember, that in past it also worked and suddenly it stopped working. I am not sure about the conditions triggering the failure, but I found issue #3005274: [PP-1] Support for Paragraphs' ability to negate the entity reference selection → . From that it seems that the issue may appear if the allowed entity reference bundles are negated (exclude allowed paragraphs from specific field). I tested it, inverted the paragraph selection and negated it and the error appeared. So would it be at least a workaround to not negate the entity reference bundles? Would be nice if people having this issue may check if they negate the allowed paragraphs selection and if the issue happens only then.

osopolar → created an issue.

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

Copy of patch from https://git.drupalcode.org/project/bridtv/-/merge_requests/11.diff 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 am still using the patch from #2, but run into an issue with Computed Field → and Metatag → module resulting in the following error (with parts of backtrace) as metatag module expects a serialized array in MetatagManager::getFieldTags():

TypeError: unserialize(): Argument #1 ($data) must be of type string, array given in /app/docroot/modules/contrib/metatag/src/MetatagManager.php on line 414 #0 /app/docroot/modules/contrib/metatag/src/MetatagManager.php(414): unserialize(Array)
#1 /app/docroot/modules/contrib/metatag/src/MetatagManager.php(169): Drupal\metatag\MetatagManager->getFieldTags(Object(Drupal\node\Entity\Node), 'field_meta_tags')
#2 /app/docroot/modules/contrib/metatag/src/MetatagManager.php(179): Drupal\metatag\MetatagManager->tagsFromEntity(Object(Drupal\node\Entity\Node))
#3 /app/docroot/modules/contrib/metatag/src/Plugin/Field/FieldType/MetatagNormalizedFieldItemList.php(41): Drupal\metatag\MetatagManager->tagsFromEntityWithDefaults(Object(Drupal\node\Entity\Node))
#4 /app/docroot/modules/contrib/metatag/src/TypedData/ComputedItemListTrait.php(32): Drupal\metatag\Plugin\Field\FieldType\MetatagNormalizedFieldItemList->computeValue()
#5 /app/docroot/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php(43): Drupal\metatag\Plugin\Field\FieldType\MetatagNormalizedFieldItemList->ensureComputedValue()
#6 /app/docroot/core/lib/Drupal/Core/Entity/ContentEntityBase.php(694): Drupal\metatag\Plugin\Field\FieldType\MetatagNormalizedFieldItemList->getValue()
#7 /app/docroot/modules/contrib/computed_field/src/ComputedFieldHelpers.php(55): Drupal\Core\Entity\ContentEntityBase->toArray()
#8 /app/docroot/modules/contrib/computed_field/src/Plugin/Field/FieldType/ComputedFieldItemTrait.php(58): Drupal\computed_field\ComputedFieldHelpers->executeCode('field_title_com...', Object(Drupal\node\Entity\Node), 0)
#9 /app/docroot/modules/contrib/computed_field/src/Plugin/Field/FieldType/ComputedFieldStronglyTypedItemTrait.php(19): Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItemBase->executeCode()
#10 /app/docroot/modules/contrib/computed_field/src/Plugin/Field/FieldType/ComputedFieldItemTrait.php(22): Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItem->getRawResult()
#11 /app/docroot/core/lib/Drupal/Core/Field/FieldItemList.php(93): Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItemBase->isEmpty()
#12 [internal function]: Drupal\Core\Field\FieldItemList->Drupal\Core\Field\{closure}(Object(Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItem))
#13 /app/docroot/core/lib/Drupal/Core/TypedData/Plugin/DataType/ItemList.php(275): call_user_func(Object(Closure), Object(Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItem))
#14 [internal function]: Drupal\Core\TypedData\Plugin\DataType\ItemList->Drupal\Core\TypedData\Plugin\DataType\{closure}(Object(Drupal\computed_field\Plugin\Field\FieldType\ComputedStringItem))
#15 /app/docroot/core/lib/Drupal/Core/TypedData/Plugin/DataType/ItemList.php(281): array_filter(Array, Object(Closure))
#16 /app/docroot/core/lib/Drupal/Core/Field/FieldItemList.php(94): Drupal\Core\TypedData\Plugin\DataType\ItemList->filter(Object(Closure))
#17 /app/docroot/core/lib/Drupal/Core/Entity/ContentEntityBase.php(1459): Drupal\Core\Field\FieldItemList->filterEmptyItems()
#18 /app/docroot/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/ChangedItem.php(49): Drupal\Core\Entity\ContentEntityBase->hasTranslationChanges()
#19 /app/docroot/core/lib/Drupal/Core/Field/FieldItemList.php(233): Drupal\Core\Field\Plugin\Field\FieldType\ChangedItem->preSave()
#20 /app/docroot/core/lib/Drupal/Core/Field/FieldItemList.php(191): Drupal\Core\Field\FieldItemList->delegateMethod('preSave')
#21 /app/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(938): Drupal\Core\Field\FieldItemList->preSave()
#22 /app/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(888): Drupal\Core\Entity\ContentEntityStorageBase->invokeFieldMethod('preSave', Object(Drupal\node\Entity\Node))
#23 /app/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(563): Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('presave', Object(Drupal\node\Entity\Node))
#24 /app/docroot/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(753): Drupal\Core\Entity\EntityStorageBase->doPreSave(Object(Drupal\node\Entity\Node))
#25 /app/docroot/core/lib/Drupal/Core/Entity/EntityStorageBase.php(517): Drupal\Core\Entity\ContentEntityStorageBase->doPreSave(Object(Drupal\node\Entity\Node))
#26 /app/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(804): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\node\Entity\Node))
#27 /app/docroot/core/lib/Drupal/Core/Entity/EntityBase.php(339): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\node\Entity\Node))
#28 /app/docroot/core/modules/migrate/src/Plugin/migrate/destination/EntityContentBase.php(240): Drupal\Core\Entity\EntityBase->save()
#29 /app/docroot/core/modules/migrate/src/Plugin/migrate/destination/EntityContentBase.php(179): Drupal\migrate\Plugin\migrate\destination\EntityContentBase->save(Object(Drupal\node\Entity\Node), Array)

As said, I still use this patch, but had to serialize the metatag value like:

  field_meta_tags/0/value:
    - plugin: single_value
      source: field_meta_tags/0/value
    - plugin: callback
      callable: serialize

FWIW: Patch won't apply using together with 🐛 Not all fields are being mapped Needs work . In case anybody needs both check this one.

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

@juanl Did you resolve the issue? What was the cause of the problem?

This was fixed with 🐛 ISBN in certain cases null when using Pivot Fixed , see https://git.drupalcode.org/project/schema_metatag/-/commit/f9a27356d8f7f.... The only difference is that this MR would have added more details to the description:

-      // Clean out any empty values that might have been added by explode().
+      // Clean out any empty values that might have been added by explode() and
+      // reindex array as otherwise json_encode outputs array keys leading to
+      // invalid schema markup.

@DamienMcKenna Do you think that this might still be useful? If not, please close this issue as outdated.

Today I wanted to implement the feedback and found that everything was already done. Thank you kim.pepper for the finishing.

@kim.pepper: I added aws/aws-sdk-php to composer suggests. The requirements check for the sdk in the sub-module .install file is there:

if (!class_exists(Credentials::class)) { ...

Merge request !35 is ready for review 😇.

To clarify: I just needed to fix my old implementation, but the sub-module approach is the way to go.

I have a similar issue but my problem is with title. On a migration I only set the link uri but not the link title, therefore the link title is NULL (not empty string). Looking at the link fields table in the database suggest says that NULL is allowed for uri, title and options. Should we modify the schema respectively? At least for title?

  public function getOutputJsonSchema() {
    return [
      'type' => 'object',
      'properties' => [
        'uri' => ['type' => 'string'],
        'title' => [
          'anyOf' => [
            ['type' => 'null'],
            ['type' => 'string'],
          ],
        ],
        'options' => [
          'anyOf' => [
            ['type' => 'array'],
            ['type' => 'object'],
          ],
        ],
        'url' => ['type' => 'string'],
      ],
    ];
  }

My current workaround is to set title to empty string in migration.

Thank you @jonathan1055 for working on this.

What about caching? I saw the issue: Paragraph does not invalidate parent cache tags if it wasn't published yet 🐛 Paragraph does not invalidate parent cache tags if it wasn't published yet Needs work . Did you experience the same? If so, maybe the issue summary should point to that issue.

What about the update hook? See also #13 and #21

I guess it would be fine to set the published_at to NULL where it currently is 2147483647:

update node_field_revision set published_at=NULL where published_at = 2147483647;
update node_field_data set published_at=NULL where published_at = 2147483647;

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

Implemented in ✨ Add support for block_content and taxonomy_term name fields (core) Needs review to avoid merge conflicts. Not yet implemented for 3.x as the plugin system is not yet defined.

osopolar → created an issue.

Patch #22 also works for migration development where drush migrate:rollback {migration-name} failed with the message "Drush command terminated abnormally" due to redirect response.

I found that updating after patching the module did not update the riddle_marketplace.api_url

Documentation for hook_post_update_NAME says:

Drupal also ensures to not execute the same hook_post_update_NAME() function twice.

Therefore I assume a new hook_post_update_NAME function needs to be added to riddle_marketplace.post_update.php and implement the changes.

As workaround I just edited the exported riddle_marketplace.settings.yml file and imported it again.

Patch from #21 with following modification no not set pager like page=0:

- $element = $pager_manager->getUpdatedParameters([], $pager->getPagerId(), $current - 1);
+ $element = $current > 1 ? $pager_manager->getUpdatedParameters([], $pager->getPagerId(), $current - 1) : [];


I am wondering if the entity lookup could be done providing the subfield like value_key: field_media_document.target_id. I had a similar issue where the lookup was successful but then I experienced an "unknown field" error, see #3354308 for more details and workaround.

osopolar → created an issue.

@sayco: Please see https://git.drupalcode.org/project/thunder/-/commit/cb3b2794ed3eed56b09e... and then you may check if your code-base contains that changes.

Path in #2 works for me too. Thank you Stefan.

Copy of patch from https://git.drupalcode.org/project/migrate_drupal_d8/-/merge_requests/3.... 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.

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

osopolar → created an issue.

This seems to fix also 🐛 Fix bundle logic to select fields correctly Needs work in the same way it was done there. Therefore I suggest to mark the other issue as duplicate.

The fix of this issue looks very similar to the one of 🐛 Not all fields are being mapped Needs work . To me it looks like a duplicate of that issue, where it seems that another aspect also got addressed.

Works for me. As of #3 it still needs tests.

Thank you dejan0, your patch from #12 worked for me also to be able to access text format pages like admin/config/content/formats/manage/basic_html

Copy of re-rolled patch from https://git.drupalcode.org/project/consumer_image_styles/-/merge_request... (#8) attached, to be used with composer, see "Patches from drupal.org merge request URLs are dangerous".