🇺🇸United States @sidgrafix

I did have a similar situation even tho my install is not using media_thumbnails_video when trying to update drupal from 10.3.x to 10.4.0 failed because it was blocked by php-ffmpeg/php-ffmpeg that uses a symfony/cache version that is not compatible with the version of symfony/http-foundation drupa 10.4 requires.

Not sure if this will cause issue but I worked around it by updating symfony/cache with
composer update symfony/cache when it completed I then ran:
composer update "drupal/core-*" --with-all-dependencies then drush updb and yes to run the update.

So far everything seems fine, but I have yet to test the modules I use that require ffmpeg yet.

Wanted to add the note regarding user accounts with empty emails will also trigger the notice and the mysql query will return no results if that is the case. Had just this exact situation on a site that had several test user accounts without emails used for testing new development on a production site when it is updated. The email requirement for those account has been overridden essentially making email not required.

@catch, I'm a little confused! Was a fix not implemented and committed (#54) for Drupal 10.3.x?
I just updated to 10.3.9 and removed the patch from #24 and the issue still persists with WSOD! Had to put patch back in. Patch #24 is the only one that works without issues as well. If I use the patch for more info from #29 there is no WSOD however I get the same error repeated like 70+ times filling pages of logs with User warning: Class "1" does not exist. if I drush cr or drush updb.

sidgrafix → created an issue.

+1 Can confirm this fixes drush warning after latest private_message update 3.0.3:

[warning] Undefined array key "name" Command.php:26
[warning] Undefined array key "name" Command.php:27

Thank You..

@alexpott, nope it isn't set anywhere and I can honestly say I never set it for any reason on either of the installs with this issue. Both of which had been in development since Drupal 9.x

I'll try to dig into things deeper by looking back thru every Drupal release prior to see when the setting was original introduced into Drupal and see if I can figure out how a setting I've never used and likely others was set as a Boolean when clearly it should not be. My best guess is somewhere in Drupal release history the setting was used as a Boolean then changed and not properly removed or changed on installation of an update.

@alexpott Appears to show up only in default expected locations and inactive!
grep -R yaml_parser_class ./ returns:

./web/sites/default/default.settings.php:# $settings['yaml_parser_class'] = NULL;
./web/sites/default/settings.php: # $settings['yaml_parser_class'] = NULL;
./web/core/assets/scaffold/files/default.settings.php:# $settings['yaml_parser_class'] = NULL;
./web/core/lib/Drupal/Core/Serialization/Yaml.php:    if ($class = Settings::get('yaml_parser_class')) {
./web/core/lib/Drupal/Core/Site/Settings.php:    'yaml_parser_class' => [
./web/core/lib/Drupal/Core/Site/Settings.php:      'message' => 'The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.',
./web/core/.deprecation-ignore.txt:# In Drupal 10, skip deprecations for the "yaml_parser_class" setting.
./web/core/.deprecation-ignore.txt:%The "yaml_parser_class" setting is deprecated in drupal:10.3.0. This setting should be removed from the settings file, since its usage has been removed. See https://www.drupal.org/node/3415489.%

@atomi, No this isn't just the case of admin vs user field. Writing to the fields/updating field values. is not the issue. It is the fact that even with value, unless a user either has a published or unpublished node of any type the view blocks will not display the fields values. The only work around I could come up with was to create a dummy content type as the user set to unpublished programmatically on new user registration so the blocks would display with their default value when they or an admin view the user account page. I used event dispatching and event subscribers to handle the heavy lifting.

@catch I don't use Acquia and just checked all custom theme and module files for any hooks that may be setting yaml_parser_class and cannot find anything injecting it. I also don't have any env's or includes and nothing in php ini configs.

Is it possible the setting was a default set by core on install back in Drupal 9.x somewhere and it wasn't updated/changed properly on existing installs during an update.

@alexpott I don't have it set anywhere! I've never set it, other than seeing it available in settings.php where else would it be possible to set it?

@alexpott and @bradjones1

With the patch from #29 I now get an error when navigating admin pages.

User warning: Class "1" does not exist. in Drupal\Core\Serialization\Yaml::decode() (line 20 of /var/www/html/web/core/lib/Drupal/Core/Serialization/Yaml.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(166): _drupal_error_handler_real(512, 'Class "1" does ...', '/var/www/html/w...', 20)
#1 [internal function]: _drupal_error_handler(512, 'Class "1" does ...', '/var/www/html/w...', 20)
#2 /var/www/html/web/core/lib/Drupal/Core/Serialization/Yaml.php(20): trigger_error('Class "1" does ...', 512)
#3 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php(396): Drupal\Core\Serialization\Yaml::decode('drupal.dblog:\n ...')
#4 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php(157): Drupal\Core\Asset\LibraryDiscoveryParser->parseLibraryInfo('dblog', 'core/modules/db...')
#5 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryCollector.php(87): Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension('dblog')
#6 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscoveryCollector.php(66): Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryDefinitions('dblog')
#7 /var/www/html/web/core/lib/Drupal/Core/Cache/CacheCollector.php(149): Drupal\Core\Asset\LibraryDiscoveryCollector->resolveCacheMiss('dblog')
#8 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscovery.php(44): Drupal\Core\Cache\CacheCollector->get('dblog')
#9 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDiscovery.php(58): Drupal\Core\Asset\LibraryDiscovery->getLibrariesByExtension('dblog')
#10 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(68): Drupal\Core\Asset\LibraryDiscovery->getLibraryByName('dblog', 'drupal.dblog')
#11 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(41): Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array)
#12 /var/www/html/web/core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(87): Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies(Array)
#13 /var/www/html/web/core/lib/Drupal/Core/Asset/AssetResolver.php(113): Drupal\Core\Asset\LibraryDependencyResolver->getMinimalRepresentativeSubset(Array)
#14 /var/www/html/web/core/lib/Drupal/Core/Asset/AssetResolver.php(128): Drupal\Core\Asset\AssetResolver->getLibrariesToLoad(Object(Drupal\Core\Asset\AttachedAssets))
#15 /var/www/html/web/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(323): Drupal\Core\Asset\AssetResolver->getCssAssets(Object(Drupal\Core\Asset\AttachedAssets), false, Object(Drupal\Core\Language\Language))
#16 /var/www/html/web/core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php(167): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object(Drupal\Core\Asset\AttachedAssets), Array)
#17 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/HtmlResponseSubscriber.php(45): Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object(Drupal\Core\Render\HtmlResponse))
#18 [internal function]: Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#19 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#20 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(214): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ResponseEvent), 'kernel.response')
#21 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(202): Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object(Drupal\Core\Render\HtmlResponse), Object(Symfony\Component\HttpFoundation\Request), 1)
#22 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#23 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/modules/contrib/advban/src/AdvbanMiddleware.php(57): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\advban\AdvbanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#37 {main}

Not sure if that helps any..

@alexpott running drush ev "var_dump(\Drupal\Core\Site\Settings::get('yaml_parser_class'));" returns: bool(true)

@longwave No none of my installs are on Acquia Cloud.

@longwave I tried completely removing line: # $settings['yaml_parser_class'] = NULL; from settings.php and it still WSOD, only until applying patch now from #24 do any of my sites work with 10.3.8, otherwise I have to pin to 10.3.7 or use the patch

I'm also a little confused? If # comments the option out, I would assume that meant it was inactive (as I have never changed or used this setting) I think it's finding the class from somewhere else as of 10.3.8 since 10.3.7? I also note that in the latest default has a message regarding it being deprecated in 10.3 and removed in 11. So if I wasn't using and also removed it after updating to 10.3.8 and still get the WSOD for the class. Shouldn't whatever the change was (from 10.3.7 to 10.3.8) account for that? I see this being a big problem for a lot of installs out there. If not what should that be set to to prevent a WSOD; yaml_parser_class = ?

The patch in #24 is the only thing that worked for me.

I also ran into this on 1 of 2 sites: (also shown above in comment #21) You have requested a non-existent service "cache.backend.null". Did you mean one of these: "cache.backend.memory", "cache.backend.apcu", "cache.backend.php
- Which was fixed after removing a $settings[] in the settings.php

$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

- should anyone wonder where they originate; likely any cache setting configured that used cache.backend.null service (which I'm guessing that service was removed in 10.3.7 as I had that issue when I initial pinned to 10.3.7 when initially getting WSOD's) not 100% sure on that, just appears that way.

@emptyvoid thank you patched from #21 worked

Had same issue WSOD with pretty much identical stack trace.

sidgrafix → created an issue.

+1 (used patch #15) Drupal 10.3.2 and inline_entity_form 8.x-1.0-rc17

Saved me after days of trying to get a field that should NOT be required when the field is part of a media entity using the inline entity form as an option on the content type edit/add form. Specifically when media entity type reference field "video" is used if a video wasn't uploaded a name shouldn't be required. Which cause other issues (as a workaround even tried) including a name when no video file was uploaded which then caused the media entity to be created and it shouldn't have been.

...Frustrating to say the least and the cause of a wicked headache until I finally realized inline_entity_form was causing the overall issue and finally stumbled onto this thread.
(but this is definitely needed) - thought I was going to have to dive into declaring an inline entity form controller for media to get it to work right after having tried every conceivable hook and callback to try and alter the fields #required state to FALSE (almost went with disabling default validation) for the entire node form on submit and validate it all in a callback - so glad I found this instead!

Also tried inline_media_form but that made things worse plus had to download it and add drupal 10 in it's info file just to try it.

OK.. I think I've got things sorted and should someone find themselves in the same boat...

This issue appears related to these issue:
https://www.drupal.org/project/drupal/issues/2978521 🐛 Remove orphaned (dangling) entity references when an entity is deleted Active
https://www.drupal.org/project/drupal/issues/2723323 →

Apparently Drupal currently does not cleanup dangling entity references and a slew of contributed modules are out there to handle some aspects of it depending on exactly what you want to do. There appears to be a few different views on why orphaned and dangling entity references should be removed and then others with why they shouldn't be (worth reading those issues for details).

But because they don't just get removed (or at least in my case some didn't) which is depended on several variables it has caused the notice of pending entities remain to be initialized by this module.

I was able to use a contrib module "node_revision_delete" https://www.drupal.org/project/node_revision_delete → by adding the option to delete revisions after 0 exist prior and letting it queue all older revisions (queue manager and queue ui help to see what was going on), then running cron. After cron ran I checked the status page and there is no-longer a warning listing 110 entities still needing to be initialized.

For the site in question even though some entities use workflow to utilize moderation state, revisions aren't required and aren't actually used - so purging any revisions (which probably exist from initial testing and content configuration testing) were all deleted.

I think even though this module listed 110 entity references to be initialized they were attached to 35 deleted nodes because the queue listed 35 entries total to be deleted, but I'm not entirely sure how node_revision_delete sets the ID for the queue item only about half of them matched up to the list of 110 IDs.

So in all I guess this technically isn't a bug with this module. Perhaps this info can help create a method for were this module could filter out orphaned or dangling revisions. At the very least I can't imagine I'll be the last for this to happen to in the future and this information will help!

My thoughts were actually headed towards this being related to revisions. Was just about to update this issue asking if it could be somehow revision related. So I did a quick check on my existing content and any of my current nodes when checking loadedRevisionID viewing the devel tab for some nodes that use content moderation and they aren't in the list of 110 (so again everything looks to be working properly) so I'm going to guess maybe somehow there are dangling revisions. Because I'm not getting any errors or problems for anything and all hooks seam to be firing fine no issues as well. Plus the only thing I really use for hooks for right now is to launch events I have subscribers too (when you mentioned a hook could be preventing your module from updating entities I checked through everything custom on my end, nothing interferes nor should it with cached_moderation_state when running the batch initialize.

I'll have to run through the database first thing next week to see if I can find dangling revisions with ID from the list returned. I'll post what I find. Feels like the most logical explanation.
- Thanks on that..

@clayfreeman

Well...interesting! Something definitely isn't right.

After running your code an array of 110 nodes are returned (as per the status page suggests) "however" the nodes it lists do not exist!
No entities either (media, paragraphs, comments, etc.) none have matching ID's to the node ID's returned which they shouldn't be considering no other entities besides 2 content types are using content moderation.

And out of the 2 content types (using content moderation) all nodes have been initialized and none are listed in the returned array accept for the first 5 - but I'm pretty sure that is just a coincidence. The next node I create would make it the 6th ID listed..

Here is what was returned:

array:1 [▼
  "node" => array:110 [▼
    0 => "node:170"
    1 => "node:171"
    2 => "node:172"
    3 => "node:173"
    4 => "node:174"
    5 => "node:175"
    6 => "node:176"
    7 => "node:177"
    8 => "node:178"
    9 => "node:179"
    10 => "node:180"
    11 => "node:181"
    12 => "node:182"
    13 => "node:183"
    14 => "node:184"
    15 => "node:185"
    16 => "node:187"
    17 => "node:191"
    18 => "node:192"
    19 => "node:193"
    20 => "node:194"
    21 => "node:195"
    22 => "node:196"
    23 => "node:197"
    24 => "node:198"
    25 => "node:199"
    26 => "node:200"
    27 => "node:201"
    28 => "node:202"
    29 => "node:203"
    30 => "node:210"
    31 => "node:211"
    32 => "node:212"
    33 => "node:213"
    34 => "node:214"
    35 => "node:215"
    36 => "node:217"
    37 => "node:218"
    38 => "node:220"
    39 => "node:223"
    40 => "node:225"
    41 => "node:226"
    42 => "node:232"
    43 => "node:233"
    44 => "node:234"
    45 => "node:235"
    46 => "node:236"
    47 => "node:237"
    48 => "node:238"
    49 => "node:239"
    50 => "node:240"
    51 => "node:242"
    52 => "node:243"
    53 => "node:244"
    54 => "node:245"
    55 => "node:246"
    56 => "node:247"
    57 => "node:248"
    58 => "node:249"
    59 => "node:250"
    60 => "node:251"
    61 => "node:252"
    62 => "node:253"
    63 => "node:265"
    64 => "node:271"
    65 => "node:274"
    66 => "node:276"
    67 => "node:277"
    68 => "node:278"
    69 => "node:279"
    70 => "node:280"
    71 => "node:281"
    72 => "node:304"
    73 => "node:305"
    74 => "node:309"
    75 => "node:310"
    76 => "node:311"
    77 => "node:312"
    78 => "node:313"
    79 => "node:314"
    80 => "node:315"
    81 => "node:316"
    82 => "node:317"
    83 => "node:318"
    84 => "node:319"
    85 => "node:321"
    86 => "node:322"
    87 => "node:323"
    88 => "node:324"
    89 => "node:325"
    90 => "node:326"
    91 => "node:327"
    92 => "node:328"
    93 => "node:329"
    94 => "node:330"
    95 => "node:331"
    96 => "node:335"
    97 => "node:339"
    98 => "node:340"
    99 => "node:341"
    100 => "node:343"
    101 => "node:345"
    102 => "node:347"
    103 => "node:349"
    104 => "node:351"
    105 => "node:353"
    106 => "node:355"
    107 => "node:358"
    108 => "node:360"
    109 => "node:363"
  ]
]

Currently I only have nodes with ID's up to 175, next node that will get created will be 176, Node 175 was created yesterday after submitting this issue so it didn't even exist yet and status page listed 110 entries. Nodes 170, 172-174 are for a content type that isn't using content moderation and node 171 was the last node created before installing this module that uses content moderation.

So, like I been saying the whole time everything seems to have initialized because if I take node 171 and change its moderation state and query with cached_moderation_state I get the correct result same for 175 and any node that uses content moderation that was created before installing cached_content_moderation it always returns the correct results. This list of 110 nodes were I have no nodes with ID's starting after 175 is definitely weird and doesn't make any sense.

Any thoughts? Something else to try perhaps?

@clayfreeman

Thanks, I will try that when I'm in the office tomorrow, I'm almost certain everything has been initialized it's just not seeing that they are, but I could be wrong on that. Anytime I query cached_moderation_state I get the correct results I'm looking for!

I'll post what I find after running the code..

sidgrafix → created an issue.

Just ran into this..

+1 for patch 6, I agree with dbouman.

+1 Absolutely needed this..

Couldn't believe this wasn't already an available permission. Running merge as patch on 10.3.1

~Thank you

+1 for patch 11 and @rupertj 100% agree with you

The decision to remove those permissions has already been made. The fact that they're still assigned to a role is an error

@ahmed.raza try this patch https://www.drupal.org/files/issues/2023-12-26/3089151-51.patch (it's the one I've been using) it's a core patch and solves most if not all field group display issues especially when field groups are nested.

- Here is the main issue thread for that patch:
https://www.drupal.org/project/drupal/issues/3089151 🐛 TableDrag JS :first-of-type issues Needs work

Hoping someday it gets merged into core as it not only affects field groups, but pretty much anything using table drag to adjust layout.

If anyone else falls victim to this the problem is caused by the typed_data module required by rules. If you uninstall rules and don't uninstall typed_data as well deleting rules causes the listed error.

Not sure if this is on rules as a bug (but it sure seems like it is)...

All configuration entities created by Rules are removed when Rules is uninstalled

If rules removes all configuration entities it appears to be missing any related configuration with typed_data.
- If I'm understanding correctly typed_data (the function and features behind it that was part of rules for Drupal 7 was taken out of rules and made a requirement for rules because other modules could benefit from/use the typed_data module.

@wilblakefcpl

I Just updated the feature issue with a new patch addressing the errors I previously noted. So should be good to go at least for now..

Adding updated patch version to add streaming_transcode_queue module to streaming (made against 2.x-dev should also patch on 2.x-alpha1), I think my initial git push of the module is why patching fails if trying to patch from the merge request url, at the time my version of git was outdated and i think it caused issues, when I can I'll redo all of that and push everything fresh.

- Just fixed a couple small issues in the event a fatal error occurs, or an error thought to be fatal and was not occurs.

When I can in the future I plan to rework a lot of this module, by adding a second queue to handle transcoding verification and implementing some events and event subscribers to handle things more efficiently. I've learned a considerable amount in other areas of Drupal after my initial creation of this which should drastically improve things.

@wilblakefcpl

In regards to the security advisory, I think it is planned as the dev version of streaming was updated with that intent to use git cli, If I remember correctly - but I can't say for sure! I'm not the developer for the module I just submitted the streaming_transcode_queue sub module as a new feature. I actually need to post an update for that feature (as is, it should work just fine, but I ran into a rare event that could cause some confusion if a video fails to transcode completely or a fatal error interrupts the transcoding process.) I should be able to get that done sometime this week, hopefully within the next day or two!

If you do try the streaming module, post any questions to the feature request issue thread and I'd be happy to help get you setup and rolling with it... https://www.drupal.org/project/streaming/issues/3393523#comment-15384408 ✨ Feature: streaming_transcode_queue Active

@TR, don't really care if you don't want to help - someone else might, closing a ticket for no reason is childish like your throwing a tantrum .. good luck with that!

sidgrafix → created an issue.

Just to add to the issue:

I just found that deleting a users node if they only had one - also produces the same issue and the account fields are not rendered in the view block. Guess it's time for a workaround...

Just ran into this myself latest version of Drupal 10.2.6

It occured because a field I created (as a test) on user account views and set the view own permission for a role then later deleted the field. The field was a default core number field added to account settings at /admin/config/people/accounts/fields.
- I was under the impression if you delete a field any configuration and or permissions wherever they are used would be removed as well, but I guess that is not the case. Like others have listed here updating any permissions after the fact causes a Runtime Exception: Adding non-existent permission to a role is not allowed.

I'm adding this info to this thread for those that fall victim to this and DO NOT have a sites/default/files/config_.. directory containing the configuration file (user.role.[role].yml) - like me.

Go to: /admin/config/development/configuration/single/export

Select "Role" for Configuration type and in the Configuration name "the name of the affected role" for me it was "Authenticated user (authenticated)" - if the permission in question was applied to multiple roles, you will need to update each. If your not sure which role(s) are affected select each one then either user browser find in or hit ctrl + F and search for the field name that was listed in the error in the output area of the export where it says "Here is your configuration:"

When you find it, delete that line from the output then copy it and then click on the Import tab above and select Single Item tab.

For configuration type select "Role" like you did for the export, then paste what you copied where it says "Paste your configuration here *" and click the import button at the bottom and then confirm it.

That's it you're done, updating permissions will no longer produce the error unless there are other fields that have also been removed prior to removing their permissions.

OK "Steps to Reproduce" step by step (just did this with a fresh install of Drupal 10.2.6, PHP 8.1.16, Apache 2.4.38 Debian)

Step 1:
Go to /admin/config/people/accounts/fields
- Now add at least one field (I added 2 Number (integer) fields to be specific) with the "+ Create a new field" button.
For each field I set configuration as follows:
- Field Storage: Allowed number of values (Limited : 1)
- Set the Minimum value that should be allowed to: -1 (negative 1)
- Check on "Set default value"
- Set the default value to: 0
- Save

Step 2:
Go to /admin/structure/views
- Now add a view with the " + Add view" button.
Create the view with this configuration.
- Leave "View settings" default (Show: Content of type: All)
- Under Block settings, Check "Create a Block"
- Set the "Block display settings" to (Display format: Unformatted list of: fields)
- Set the "Items per block" to 1
- Click on Save and edit button

Step 2B:
Configure the view block and add the user account fields we previously created:
- Under the "Advanced" section (right hand view column) expand it open if it is not.
- Across from Relationships click on the "Add" button to add a relationship to the view.
- In the Add relationship dialog find under Title "User" where Category is "Content" and the Description reads "The username of the content author"
- Next click on "Add and configure relationships" button at the bottom of the dialog
- In the Configure Relationship: User dialog, Don't make any changes and just click the "Apply" button at the bottom of the dialog.
- Next also under Advanced across from "Contextual filters" click add
- In the Add contextual filters dialog find under Title "User ID" where Category is "User" and the description reads "The user ID"
- Next click on "Add and configure contextual filters" button at the bottom of the dialog.
- In the Configure contextual filter: User: User ID dialog Where it says "When the filter value is NOT available" check the "Provide default value"
- In the "Type" dropdown that appears select: "User ID from route context"
- Leave everything else as is and click the "Apply" button at the bottom of the dialog.

Step 2C:
- Now on the left column of the view display across from "Fields" click on the Add button.
- In the "Add fields" dialog find the field or fields you created in step 1.
- The "Category" should be "User" with a description that reads "Appears in: user." when you have it/them selected click on "Add and configure fields" button at the bottom of the dialog.
- In the "Configure field: User: Name of the Field" you can just hit the "Apply" button at the bottom of the dialog.
- When all field configuration is done and the dialog is closed click on the "Title" field listed under the Fields section above the field or fields you just added, when the dialog opens click the "Remove" button at the bottom of the dialog.
- Below fields (also in the views first column) where it says "Filter criteria" click on "Content: Published (= Yes) and when the dialog opens click on the "Remove" button at the bottom of the dialog to remove it.
- Next below that where it says "Sort criteria" click on "Content: Authored on (desc)" and when that dialog opens do the same as you did for the filter and click on the "Remove" button at the bottom of the dialog.
- Next under the views configuration and above the views preview area hit the "Save" button to save the view.

Step 3:
Create a new user as an authenticated user, no admin privileges and give value to the new account fields:
Go to: /admin/people
- Click the "+ Add user" bottom near the top of the page.
- Provide the "Username" and add a "Password"
- Under Roles "Authenticated user" should be checked by default and grayed out.
- Scroll to the bottom of the add user form and locate your added field or fields and give them values. (I set the first field of my two to "2" and the second number field to "4")
- Then at the bottom of the form hit the "Save" button.

Step 4
Place the view block on user account pages:
Go to: /admin/structure/block
- Scroll down to either a "Content" region or a "Sidebar" region (I used the right sidebar)
- When your at the region you want to use click on the "Place block" button to the right of the region name you are using.
- In the "Place block" dialog find the view block you created by name (using the search field and typing in part of its name should bring it right to you, its category will read "Lists (Views)" and under "Operations" click on the "Place block" button that is displayed to the right of the view block name.
- In the Configure block dialog under "Visibility" click on the "Pages" tab.
- In the Pages input field put /user/* and make sure "Show for the listed pages" is checked
- Depending on what you named the view and if you added a block name the "Machine-readable name" may be to long and you will have to shorten it to save the block.
- Finally click on the "Save block" button at the bottom of the dialog.

Step 5:
Now visit the users page:
Go to: /admin/people
- In the user list under "Username" find the user you just created and click on the name to go to their user account page (as admin doesn't matter if users can see each others account pages)
- You should be at: /user/2 (if there is only you the admin and 1 user account the path would be /user/2 otherwise it will be /user/[user-id].

What you will see is unexpected:
- Under the user account details you will see the two fields with the values you set
- However...The view block will only have the title of the view block and there will NOT be any field data and if you inspect the html the view content is empty. I would expect to see the same information displayed by the fields and clearly is not.

I'll include a screen cap of the new user account page at this point (fresh-install-same-issue.jpg).

Now if you want to give your new test user the ability to add an article or basic page you will also need to grant the "Authenticated User" role to allow it - if you do and you login as the new test user and create an article or basic page and then view their user account page admin or the user you will see the block then has the field information.
-> If you need instructions on how to do that let me know!

Couple of things to note (I did straight basic setup for the steps to reproduce) but there are reasons why I did a few things that you wouldn't get from this setup and may explain why I chose the view type I did for our use case.
1. I used a view to display content not user because for my use case I need content worked into this display seamlessly using attachments that also relate to the user and there content (which they may not have any especially when they are a new account)
2. The actual fields created on user accounts can only be set or updated by an admin or the corresponding module being developed to work with those fields on behalf of the user. The user has permission to view their field info (thus why it would be able to display in a view block), but they cannot change it. Furthermore the default fields are even hidden for our use case. As we just need it displayed in a block that does a lot more than just display the field info/data.

Any questions or problems let me know.

@jsacksick regarding your question in #8 - at this point I'm not entirely sure. After I got the products sorted regarding the title on variations as to what was coming from where (at that point still frustrated all a around with commerce) I moved on to other areas of the site that needed to be done yet (which is still in progress) and haven't been back to deal with commerce since.

I think/may have (honestly can't remember exactly), initially intended to use variations as purchase options used with recurring payments, but inevitably ended up using product attributes to handle that with the variations created in each product. It still doesn't make much sense to me the way it all works (having to have product variation types - that aren't an actual products variation(s) having to create actual variations in the product itself but have to use a product variation type, but while creating the actual variation linking in the attributes which in my case is handling the billing options...

- More so confusing that the products variation title uses the attributes option as the title and not the actual variation title. I do also think before I really dove into all that, at one point just testing to see what does what I may have (again not entirely sure) checked the option to generate variation titles based on attribute values to on, but then turned it off before I really got into setting things up and getting commerce products configured which may have complicated the entire ordeal. With that said I'm sure somewhere at some point don the line when I get back to it I probably have done something wrong or took steps in the wrong order when setting that all up and will have to redo some things as "my luck" tends to go. Especially being the original still active site using Drupal 7 uses ubercart and the new version started in Drupal 9 now 10 still in development is now using commerce.

And no, I have not tried this patch - but surely will when I get back to commerce. I did try some of the other patches at the time that seemed like they could be related, but none produced the results I was looking for.

In all "thank you" for giving this some attention, anything added that works towards making things less confusing is a plus in my book!

sidgrafix → created an issue.

@troybthompson

- I personally gave up on this feature from the patch provided and just wrote some simple jQuery as some Drupal.behaviors in a custom theme or module (can't remember which exactly at the moment) to build my own track list for use taking selected terms when editing or adding content that uses a specific term list plus a few extras specific to it's use case.

I'd be happy to share some code but it's tailored for the site it is used on (so you may have to translate some of the selectors to more generic element classes - output specifically by term reference tree should you want to use it on any term reference tree) if that makes sense...

It also doesn't rely on ajax to communicate back and forth from the term reference tree and the tracklist (but you have to save the content for any changes in the tracklist to stay - because it doesn't rely on ajax). Which based on what I remember ajax was a big part of the problem with the patch listed here for the feature. I figured someday I might be able to get around to modifying what I have and applying as an alternative patch here - but I just haven't had the time...and other than sharing what I put together, I still don't.

But if your interested let me know..

Well.. I found the cause of the problem.

It is directly related to setting the computed fields "maximum length" (The maximum length of the field in characters) during field creation. I matched the max length of the default text field of 12 (which always worked fine and displayed properly) for the computed field (which drops the last digit/character). It appears if a value for a computed field is the number of characters that is the max allowed by the computed field, on render it will drop the last digit/character and only save and display 11 characters.

I ran 3 tests to confirm this:
First I created a new computed text field and left it set to default of 255 for maximum length, and the correct 12 digits/characters rendered in the computed field.
Second I created another computed text field and set it's max length to 13, again the correct 12 digits/characters displayed.
Third I created another computed text field and set its max length to 12 (same as one of the original computed fields I had set) and this time like before only 11 digits/characters displayed... which is not correct.

So this is obviously a bug! Considering I have a regular text field that has a max character length of 12 (and it accepts and displays 12 characters/digits without issue) a computed field set the same should also display all 12 digits/characters and does not. For whatever reason it is only rendering with 11 characters and provides no errors or notices when it probably should.

I think the field storage of the value is correct (if I edit the 2 computed fields I am having issues with - the correct max length value is shown grayed out "12 and 8 respectively" meaning the database returns what was original set, so the issue is likely not in the default field storage) so it has to be somewhere during rendering after the value is calculated - somehow 1 is subtracted from the fields max length before being displayed.

I'm not 100% sure but I think Drupal's default handling of any fields input exceeding max length of allowed characters would normally returns an error stating the fact. Being that isn't happening here tells me the computed fields validation passed (during node add/edit save) and has to do with some calculation during display rendering maybe in the field formatter. Unless for some reason computed fields don't adhere to standard field validation, which if that is the case there could be a bigger issue.

With all that, I'm not sure where to start looking to create a patch for this issue.

For now as a work around (should someone else fall victim to this issue) just replace the computed fields with new ones making the max length +1 more than actually needed (so if you need 12, make it 13 - if you need 8, make it 9..and so on).

This should be duplicatable as well based on the tests I ran should someone wish to try and solve this issue.

sidgrafix → created an issue.

This doesn't appear to work - at least for my situation!

On a content type under manage display using tabs group type horizontal with 3 tab(s) first 2 are set to closed, 3rd set to open, yet no matter what only the first tab loads opened.

Tried this patch as well as dev version that I believe was patched via MR for "#3066522: Wrong default tab on page load" and nothing seems to make it work correctly.

- so the only way to achieve the correct tab opening (as things stand), appears to be moving the tab you want open as the first tab that gets loaded (as first tab in tabs group) which is unfortunate.

Just to be clear before trying this patch or the dev version the first tab in a tab group loads open (doesn't matter if you set it to closed and have another tab in the group set to open - the first tab is always loaded opened.)

First trying this patch (same behavior, nothing changed)
Then trying the dev version (same behavior, nothing changed)

And there are no errors produced on page or in dblog.

For good measure incase others have this working on different setups my setup is currently using Drupal 10.2.3 on Apache 2.4.38 running PHP 8.1.13

@AstonVictor Coolbeanz.. Updated to latest and no more errors, thank you!

sidgrafix → created an issue.

sidgrafix → created an issue.

Nevermind on this, go ahead and close it if you like.. I'm doubtful this is a bug (but could be, I have no idea what the default behavior for this should be - it's not documented)

Finally, I figured out where the actual values come from that appear in the dropdown that is listed as "Title" in a products variation next to SKU in the displayed variations table of a product; pulls from commerce/product-attributes the attribute that was initially created meaning if an attribute is used and selected in the product variation it will use it's value as the title, otherwise it is what is expected and is the title of the variation itself. (so maybe bug or maybe not, default behavior escapes me)

If it is the default behavior I think listing it as "Title" in the "Add variation" edit/tab the way it is, is extremely confusing! I would assume being when a products variation is added "as on creation it has a title field you have to fill out" that would be the "Title" listed next to the "SKU" in the table of variations for a product.

To make such things less confusing I think some kind of helper that can indicate that the title there is not the title created for/in the products variation (as in it will not be the title you will see when you click on edit for a given variation when an attribute is used in the variation) as it is pulled from the "value" selected in the attribute (in my case initially created as a "Product attribute") which was then added as a field to the product variation type. Maybe simply putting titles that are not the variations title in brackets like (Monthly Recurring) with a key above the products variation tabe showing any title in () is the selected attribute value, or something along those lines with perhaps a little documentation explaining why this is like this. (unless this is a bug?)

In general it's confusing enough having to create all the different aspects used in a product (outside of the product) to then use with and in a product, or product group, as well as any corresponding store attributes to then be limited by product variations are per product only. It honestly everything feels like it is all created/setup independently then nested upon nested with this includes that and that includes something else which in turn includes something else just to get it all to work together with very little documentation explaining things.
- sorry, if any of that sounds harsh I apologize (i'm just a bit frustrated, the lack of documentation and explainations for things with commerce core) has me on edge being this is one of the last few things I need to get working properly on a Drupal 10 site replacing a Drupal 7 site..

sidgrafix → created an issue.

sidgrafix → created an issue.

+1
Just ran into this with Drupal 10.2.3 and field_tokens 2.0.0-rc2 (wsod)

Error: Call to undefined method Drupal\views\ViewExecutable::getFieldDefinitions() in field_tokens() ..and..
Error: Call to undefined method Drupal\views\ViewExecutable::getFieldDefinitions() in field_tokens_tokens() (line 196 of /web/modules/contrib/field_tokens/field_tokens.tokens.inc).

Patch fixed it, thank you.

@jeffschuler - I honestly not entirely sure being 5 months ago, there is a chance I patched a non-dev version then by accident and the slight differences in the lines you mention would have been changed in accordance with whatever version of redirect I was patching.

Looking at the composer.json for the site I used patch 120 on I patched redirect 8.x-1.9 (which was for a D9.5 sight, since updated to 10.2.2) again apologies for any confusion this may have caused..

@jeffschuler - All I did was reroll patch from comment 114 listed as support-for-wildcard-2831605-113.patch (if you compare that to mine they are identicle.

Per "ricardofaria" post 114 he said "Created a patch with a little difference from the previous one. Will need to review this later, but for now its working for me."

- Any changes you mention (if they diverged from the patch prior to support-for-wildcard-2831605-113.patch) were done there in support-for-wildcard-2831605-113.patch before I rerolled.. I assumed that patch was the previous current working if it is not "my bad", apologies for any confusion. Tho the patch has been working fine for me!

Not exactly shor why but applying the merge request as a patch says fails to apply and causes all kinds of wacky issues. I've looked at the repo and it all looks correct nor is the first time I've use a merge request as a patch file. Regardless, when trying to patch via composer it ends up adding the feature 3 times and leaves a bunch of .rej files. Initially I thought even tho composer said it couldn't apply the patch "where you would expect it to revert any changes it may have attempted" but did not, when it did infact apply the patch (but as I said far from clean) which caused me some serious headaches for a couple days until I tracked down what actually happened.

So I'm including a regular patch file here that works no-problem. I'm also including a patch to make the external sourced css and js that are for the streaming_media_views module (mentioned above in #7)

Patches apply to streaming 2.x-dev

- I did a comparison of the feature patch here and using the merge diff as patch and noticed two chunks of extra data at the top and bottom marked GITLAB and probably why trying to apply the merge as a patch borks.

+1 patch 17 works for me too (Drupal 10.2.2)

+1 Patch fixes issue (drupal 10.2.2)

Add the directive as line entry to your php.ini config file per https://www.php.net/manual/en/outcontrol.configuration.php#ini.output-bu... like the following:

output_buffering=On

- That enables output buffering for all files, you can also limit the size in bytes if you like as follows:

output_buffering=4096

When viewing https://www.php.net/manual/en/function.ob-start.php regarding actual use of output buffering with the likes of ob_start() I believe it is reference for contributed development, like what module develpers and contributers would use to work directly with output buffering. I would imagine Drupal core (now suggesting its use) has core functions that can utilize output buffering using ob_start() as well as [ ob_end_clean(), ob_end_flush(), ob_clean(), ob_flush(), etc. etc. ] - but don't quote me on that it could be in preparation for said use as well.

I think the important part is the line added to php.ini configuration for site maintaners.

If your unsure where to find your php.ini files go to /admin/reports/status/php page, you'll see php information and down a little ways you will see "Additional .ini files parsed" on the left and to its right you will see all php related .ini files any of which can be used (if you have many) or just above that you will see "Scan this dir for additional .ini files" and to its right you'll see the path to the php/conf.d directory where you can even just add a new ini file for example output-buffering.ini with a single line entry. Regardless of what ini you edit or if you add a new one apache service will need to be restarted for the change to take affect!
If your a cPanel user I believe there should be a php.ini file you can edit directly through cPanel (I haven't used cPanel in years, so I don't know for sure) - that may have changed.

@NicholaS, @flyke,

I've given up on this module in favor of a module that actually works called "streaming." I just finished adding a sub-module to streaming as a new feature here https://www.drupal.org/project/streaming/issues/3393523#comment-15384408 ✨ Feature: streaming_transcode_queue Active which needs testing.

If anyone is interested the module I added to streaming, "streaming_transcode_queue" provides options and similarities to how transcoding worked for the video module in Drupal 7. Plus a bunch of extra tools and a manual queue processing display table.
- The only unfortunate is I haven't included any kind of upgrade/migrate path to go from video to streaming, that's a bit outside my scope of skillsets at the moment.

If you give it a try and need any help getting things set up let me know. Until it is merged into streaming you will need to use the merge request as a patch to streaming version 2.0, I've been using it myself primarily without any issue for months now.

This is a patch I'm including for "aminyazdanpanah/php-ffmpeg-video-streaming" (required by the streaming module) that fixes some php 8.x issue:

Deprecated function: Return type of Streaming\RepsCollection::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in include()

and

Deprecated function: Implicit conversion from float 0.5 to int loses precision in Streaming\Stream->__destruct()

The patch above will only be valid for PHP 8.x once PHP 9.x is mainstream I believe the RepsCollection.php file will need to be re-written to be compatible with IteratorAggregate::getIterator(): Traversable (currently beyond my scope of capabilities), should anyone know exactly what the means and knows needs to be done please submit a patch.

Additional notes and topics for discussion:

Remote assets that are included in libraries.yml for streaming_media_views:

css:
  theme:
    //vjs.zencdn.net/7.10.2/video-js.min.css: { type: external, minified: true }

js:
  //vjs.zencdn.net/7.10.2/video.min.js: { type: external, minified: true }
  //unpkg.com/videojs-contrib-quality-levels@2.0.9/dist/videojs-contrib-quality-levels.min.js: { type: external, minified: true }
  //www.unpkg.com/videojs-http-source-selector@1.1.6/dist/videojs-http-source-selector.min.js: { type: external, minified: true }

I personally believe these should be downloaded and added locally (either by the end user of' or packaged with streaming_media_views) rather than remotely via url on every page load. Reason: Overall "Security".
- Having them loaded by url causes issues when using advanced security modules like CSP "Content Security Policy".

On a personal note, I downloaded the needed files and added them to the assets directory in the streaming_media_views module. and modified streaming_media_views.libraries.yml as follows:

videojs:
  css:
    theme:
      assets/video-js.min.css: { minified: true }
      assets/backend.css: {}

  js:
    assets/video.min.js: { minified: true }
    assets/videojs-contrib-quality-levels.min.js: { minified: true }
    assets/videojs-http-source-selector.min.js: { minified: true }
    assets/video.js: {}

In regards to the css and js if someone wants a patch let me know and I'll add one for that as well.

Note on video formats: Initially I was under the impression the streaming module required the uploaded video (that will be transcoded) to be in an mp4 format. This is not the case, pretty much any format can be used (depending on the version of ffmpeg and what libraries were compiled with it).

If your apache based web server happens to be built on a Debian Linux disto 9 or 10 and ffmpeg was installed using the Debian package manager, you should be able to upload videos in (mp4, avi, mov, flv, ogg, ogv, ogm, webm, mpeg, mpg, m4v) that can successfully be transcoded to a streaming format.

Lastly I would like to discuss the handling of transcode on save. I included an option in "Miscellaneous" setting of the streaming_transcode_queue called "Transcode on node entity save" - it works, but because transcoding occurs attached/through the user session it can make your site seam like it is crawling for the user who uploaded the video - similar to how transcoding works from the admin media page (the original/default method for streaming_media_views). At the same time this suppresses any logging to Dblog that occurs during the transcode processing until transcoding has completed. In comparison, transcoding that occurs via QueueWorker using the streaming transcode queue happens in the background and continually logs to Dblog as each process occurs and there does not appear to be any kind of performance impact to users while transcoding is happening.

- Initially I was exploring options to use a callback function to trigger transcoding on node save in the background. However I'm not convinced that would actually work. Plus I couldn't figure out a method to see/check if any of the fields on a node are a media entity references (either by bundle type or the video file field name of field_media_video_file) without knowing the actual field name that was created/added to the content type for uploading a video (which in theory could be named anything) like a generic name of field_video_upload.
- So I'm looking into alternative methods (ideally without the need to include any additional libraries) were you could send something to be processed without waiting for it to complete (basically trigger a function without waiting for a response).
- My current thought process is, instead of trying to make a callback work use another queue that gets checked once a minute! For example a queue named "transcode_now" and if the option to transcode on node entity save is on, add the newly uploaded video details to the queue. The next minute the transcode_now queue is checked by its cron queue worker (if there are any items in queue to be transcoded) transcoding starts and completes in the background. Maybe that's overkill or maybe there is a better way (I'm not sure myself), so if anyone has a thought on that please chime in.

Apologies for the delay. Had to focus on some other areas for a bit. However I think I've finally got everything sorted. I just need to run some more tests and clean a couple things up. At latest I will push the files sometime next week. I'll include some screen shots with this.

To get Cron and the QueueWorker processing correctly I ended up creating a service from the controller you had in the streaming_media_views module as a service for streaming_transcode_queue I didn't modify the original so it shouldn't impact anything you've previously done. There is a lot to what I've done so I just want to double check things before pushing to git.

@arturopanetta

Apologies for delay, ended up sick the end of last week and had only managed to setup the fork and pull it. Did some cleaning up today and discovered a problem with my implementation. If I trigger the queue worker cron manually (which is how I was testing) using simple_cron module everything works, however if cron is triggered via crontab (externally triggered) it does not, it also doesn't produce any errors.

Turns out it's user/session related as cron by default always runs as anonymous user. So if I manually trigger cron via simple_cron interface my session is attached as (admin) user and works.

I tried a few things in the queue worker class itself using Drupal's "Account Switcher" with Drupal\Core\Session\AccountProxyInterface but even tho I can make it run as admin with that, it still won't fire on crontab externally. So now I'm attempting to add a service to handle the triggering of the the content controller for streaming_media_views using a similar method. I even tried setting the controller (temporarily) to access content permission in the routing.yml (figuring since anonymous users can view content) just to test as that wouldn't be ideal in any respect but that didn't help either.

If I can't get it worked out tomorrow - I'll push the manual queue form (working mostly) to the fork and post what I'm attempting here in a comment for some feedback. I think somewhere my logic (thought process) on getting this to work right may be flawed and I may be going about it all wrong.

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

Awesomsauce... I'd be happy to offer some code to this project. Would you prefer it as a patch here, or as a new branch. Just give me a day or two (end of week the latest) to clean a couple things up and I'll post what I've got.

Aside from patches I've got a queue working as a sub module to streaming like streaming_media_views (wouldn't call it pretty) I've got a bit left to do on it yet for all the bells and whistles but it works. Currently it's called streaming_transcode_queue which uses a cron queue worker as well as a manual queue interface with a table to view queue items and process them manually or in bulk.

Anyway, let me know your preference on submitting code to the project and it will be done.

@arturopanetta, I'm happy to see your moving forward towards D10.

I've actually been successfully using this with php-ffmpeg v0.19 for a couple weeks now playing with some things. Had to patch a few things, some in the streaming library as well (plus one other module we use media_thumbnail_video), I am currently working on adding a transcoding queue submodule to better facilitate upload media fields (set to streaming video) on node-content type for users that don't have access to the media library interface (non-admin accounts). Using a QueueWorker and Cron. At some point I wanna try and add real-time feedback (percent processed, time remaining, etc.) as part of the manual transcoding trigger from the media library page at admin/streaming/transcode-media/$mid instead of just redirecting back to the content/media library page and waiting (for what could be well over an hour depending on the original video file size) and yes I did find you didn't actually have to wait on the redirect page for the transcoding success or failure confirmation if you didn't want to which was at least nice being some of the videos I've run through this module are upwards of 4GB plus and they transcode without error now. I also have been testing with pretty much every video format as the upload source and everything works quite beautifully (but on that note we only use HLS .ts encoded with H.264) so I have no way of knowing if any format would also transcode to dash). So everything I'm doing and have done may only apply to HLS or at least for now as it stands.

Plus...and this is a personal preference (I made the libraries for the player locally served) as well as any other externally sourced file by downloaded them added them to assets (for now and rewrote the libraries.yml to reflect it) The reason is part personal preference and part security being we use CSP (Content Security Module) having them locally served uncomplicates a few things with CSP. I think in this situation it may be better to offer users the option of loading from external source or adding as a local library (many modules offer that as an option), not too mention if you serve locally you don't have to worry that a CDN or remote file resource goes offline or get deleted, changed or removed.

At some point I was planning to create a fork to at least offer the options to others with possibly even a new branch in the future. However right now I'm over my head in working to get a massive D7 site rebuilt to D9/10 where this module is replacing the video module used in D7 so when I can actually get to that may not be for quite some time. It's a bit unfortunate migrate wasn't an option for the site in question as most modules used either don't have a D9/10 version available or if it does "like the video module" it's incomplete and doesn't really do anything in it's current state. So I'm not only trying to replace the video module but quite a few others as well and time is running out.

I do have to say I'm loving this module "it actually works!" Thank you...

Next chance I get I'll run through my notes and at least list the files I've patched and the errors and warnings I was getting prior to patching, some of which may be PHP version related.

Patch broke on latest release of redirect so here is an updated patch (same as #114, applied to latest version of redirect).

@ newswatch - "You can't just create a subdomain and redirect it" it must be a CNAME record (or ALIAS record which is not supported by all DNS hosts, can't say for sure if cPanel does or not - it's been years since I've worked with a cPanel account) NOT an A record for a subdomain. This way (if CNAME) you'll have a canonical name (that the DNS name is an "alias" for) which points to your main domain.

- I know it's a bit much to work through (as I was once in your boat) but if you follow through with what I posted above https://www.drupal.org/project/drupal/issues/2965979#comment-14991459 ✨ [PP-1] Validate alternate domain for oEmbed iFrame Postponed - in comment 75 - you should be able to get things set up and working. I 100% agree with you on this...

It is astounding that something as basic as this does not have any documentation, and has been hanging fire for years now.

The text on /admin/config/media/media-settings is cryptic and confusing.

If you have any questions or run into problems follow up here or send me a pm and I'll help anyway I can.. Best of luck!

sidgrafix → created an issue.

Hello, I'm attempting to work with this module (more specifically version 1.2 of this module) but since it is currently locked to php-ffmpeg library v0.18, composer won't install it because it conflicts with existing requirements. Unfortunately I need to stay with version 0.19 minimum of the php-ffmpeg library for other modules to work properly.

Do you know what "breaks" in this module (per title of this issue)? Perhaps it is something I can work on or offer patches for to make this module work with a minimum of php-ffmpeg v0.19 as I am using the patch listed above (issue: 3256578) with the php_ffmpeg module.

Also, I was wondering why there is no 'current dev' version for this module which is useful when applying patches or modifying locally for testing (especially for things like this "using php-ffmpeg v0.19 and testing versus v0.18"). Usually a dev version would include the latest module version plus any additions for testing (features, bug fixes, etc.) for future releases of a module. I suppose I can just manually download modify and install the latest version removing the requirement to test, but a current dev version would be nicer considering you can't patch a composer.json file for a module because patching happens after composer calculates dependencies and installs packages or I would have removed the dependency myself just to poke around and test. For example a current dev version of this module could have a requirement set to ^0.18 making v0.18 the minimum requirement to work but allow for testing with v0.19 or even v1.x (as the php-ffmpeg library has actually progressed to v1.1.0).

From appearances this module looks to be a lot farther along and is actually useable with FFMPEG transcoding where many other modules like the "video" module don't actually currently do anything (which in part has made my life hell trying to migrate/rebuild a huge Drupal 7 site that is heavily dependent on transcoding using the video module to Drupal 9 or 10) - that said I'm looking to use this module as a replacement to the video module as I've given up hope for that module working in the next month or so as Drupal 7 end of life nears ever closer. Plus it makes more sense to use this module over the video module regardless because this has adaptive streaming - it was kind of a fluke I stumbled onto this module as I was starting down a road to build the site it's own module to handle transcoding on video upload and while searching FFMPEG and php-ffmpeg documentation throughout I noted several references to adaptive streaming which lead me to start researching adaptive streaming (figured if I got to build it from scratch adaptive would be the way to go) and a few searches later this module popped up and seamed to be the answer for the needs of site I'm working on. "Fingers crossed it is..."

@gbyte

Apparently it's in latest 4.1.5 to.. (which just makes me chuckle)..not at you, myself!

I just tried to apply patch to v4.1.4 to test (not realizing "aside from dev package" you also updated the main package) which must have been after I looked things over this morning.
- so obviously the patch failed thanks to composer updating simple_sitemap to the latest "already patch" version, at first I thought perhaps there was a difference in line count between dev and release versions of file EntityHelper.php
- so I cloned/copied the module after the fail and was gonna do my own patch to test and when I opened the file I saw it was updated already and couldn't help but laugh at myself.

Thank you, I needed a good laugh today!

I left detailed instructions on what I had to do setting up with an active domain and sub-domain for oEmbed here:

https://www.drupal.org/project/drupal/issues/2965979#comment-14991459 ✨ [PP-1] Validate alternate domain for oEmbed iFrame Postponed

If you have any problems let me know, I wrote that fairly quick but it works and well...

Here is a patch that will apply to 8.x-1.0-beta5 if anyone else wants/needs it..

@gbyte I don't know for sure, but if what your saying is true that actually does make sense (at least in my case) as I have Sitemap generation interval set to 1 week in "Sitemaps settings" and then for "Search engines settings" Submission Interval set to 1 week as well. Looks like they just ended up being on the same day per each's weekly interval 3 hours apart. I would guess the warning is occurring when sitemap regenerates the sitemap during cron (as also in settings I have "Regenerate the sitemaps during cron runs" checked on, which I think is default setting).

It looks like it was a coincidental (and completely unrelated) addition in the information I last provided which made it seem "strange" that the warning was appearing on the same day sitemap submits the latest generated sitemap to search engine. The fact that the error triggered by cron.simple_sitemap on same day queue.simple_sitemap_engine_submit is run is only do to settings (my bad) as it was just something I noticed consistently in the logs - sitemap submit exactly 3 hours after the array_flip() warning occurred each week.

Unless it's some weird thing with my setup, this should be reproducible. I may have some time towards the end of the week to run some tests on a fresh Drupal install but I make no promises in that regard, I'll try my best to get back to this as soon as I can..

Here's a little more info regarding the error.

I haven't had anytime to debug this further or trying the mod suggested by TolstoyDotCom.

However checking through dblog's I noticed the array_flip() warning is only triggered by cron on days that simple_sitemap submits to search engines. Specifically cron.simple_sitemap for me is set to run once every hour but only produces the log warning on days that queue.simple_sitemap_engine_submit is triggered (which for me is also a cron job that is scheduled for once an hour - where I use the simple_cron module for both cron and queue workers, each job as a single url) hopefully that doesn't confuse things...

On days when sitemap isn't submitted (6 out of 7) both jobs run fine and produce no errors or warning. On the 1 day sitemap is submitted to search engines this is what happens:

I get 2 slightly different dblogs with array_flip() warning at the same time one after the other in dblog (again when cron.simple_sitemap job is triggered on the hour)

Here is the first stack trace:

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 312 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#1 [internal function]: _drupal_error_handler(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): array_flip(Array)
#3 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(296): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/html/web/modules/contrib/simple_sitemap/src/Entity/EntityHelper.php(218): Drupal\Core\Entity\EntityStorageBase->load(NULL)
#5 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityMenuLinkContentUrlGenerator.php(206): Drupal\simple_sitemap\Entity\EntityHelper->getEntityFromUrlObject(Object(Drupal\Core\Url))
#6 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityUrlGeneratorBase.php(248): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\EntityMenuLinkContentUrlGenerator->processDataSet(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#7 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(360): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\EntityUrlGeneratorBase->generate(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#8 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(324): Drupal\simple_sitemap\Queue\QueueWorker->generateResultsFromElement(Object(stdClass))
#9 /var/www/html/web/modules/contrib/simple_sitemap/src/Manager/Generator.php(174): Drupal\simple_sitemap\Queue\QueueWorker->generate('cron')
#10 /var/www/html/web/modules/contrib/simple_sitemap/simple_sitemap.module(72): Drupal\simple_sitemap\Manager\Generator->generate('cron')
#11 [internal function]: simple_sitemap_cron()
#12 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(417): call_user_func_array(Object(Closure), Array)
#13 /var/www/html/web/modules/contrib/simple_cron/src/Plugin/SimpleCron/Cron.php(70): Drupal\Core\Extension\ModuleHandler->invoke('simple_sitemap', 'cron')
#14 /var/www/html/web/modules/contrib/simple_cron/src/Entity/CronJob.php(326): Drupal\simple_cron\Plugin\SimpleCron\Cron->process()
#15 /var/www/html/web/modules/contrib/simple_cron/src/SimpleCron.php(102): Drupal\simple_cron\Entity\CronJob->run(1685980801, false)
#16 /var/www/html/web/modules/contrib/simple_cron/src/ProxyClass/SimpleCron.php(70): Drupal\simple_cron\SimpleCron->run()
#17 /var/www/html/web/core/modules/system/src/CronController.php(46): Drupal\simple_cron\ProxyClass\SimpleCron->run()
#18 [internal function]: Drupal\system\CronController->run()
#19 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#20 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#22 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#23 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/modules/contrib/advban/src/AdvbanMiddleware.php(57): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\advban\AdvbanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#37 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#38 {main}

Here is the second:

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 312 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#1 [internal function]: _drupal_error_handler(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): array_flip(Array)
#3 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(296): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/html/web/modules/contrib/simple_sitemap/src/Entity/EntityHelper.php(218): Drupal\Core\Entity\EntityStorageBase->load(NULL)
#5 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/CustomUrlGenerator.php(152): Drupal\simple_sitemap\Entity\EntityHelper->getEntityFromUrlObject(Object(Drupal\Core\Url))
#6 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityUrlGeneratorBase.php(248): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\CustomUrlGenerator->processDataSet(Array)
#7 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(360): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\EntityUrlGeneratorBase->generate(Array)
#8 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(324): Drupal\simple_sitemap\Queue\QueueWorker->generateResultsFromElement(Object(stdClass))
#9 /var/www/html/web/modules/contrib/simple_sitemap/src/Manager/Generator.php(174): Drupal\simple_sitemap\Queue\QueueWorker->generate('cron')
#10 /var/www/html/web/modules/contrib/simple_sitemap/simple_sitemap.module(72): Drupal\simple_sitemap\Manager\Generator->generate('cron')
#11 [internal function]: simple_sitemap_cron()
#12 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(417): call_user_func_array(Object(Closure), Array)
#13 /var/www/html/web/modules/contrib/simple_cron/src/Plugin/SimpleCron/Cron.php(70): Drupal\Core\Extension\ModuleHandler->invoke('simple_sitemap', 'cron')
#14 /var/www/html/web/modules/contrib/simple_cron/src/Entity/CronJob.php(326): Drupal\simple_cron\Plugin\SimpleCron\Cron->process()
#15 /var/www/html/web/modules/contrib/simple_cron/src/SimpleCron.php(102): Drupal\simple_cron\Entity\CronJob->run(1685980801, false)
#16 /var/www/html/web/modules/contrib/simple_cron/src/ProxyClass/SimpleCron.php(70): Drupal\simple_cron\SimpleCron->run()
#17 /var/www/html/web/core/modules/system/src/CronController.php(46): Drupal\simple_cron\ProxyClass\SimpleCron->run()
#18 [internal function]: Drupal\system\CronController->run()
#19 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#20 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#22 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#23 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/modules/contrib/advban/src/AdvbanMiddleware.php(57): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\advban\AdvbanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#37 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#38 {main}

My bad as originally I thought they were the same and didn't report there are 2 happening.

Here is the weird part this all occurs 3 hours before queue.simple_sitemap_engine_submit job does the actual submit to search engines.

It only happens on the day sitemap is scheduled to submit to search engines, and only happens 3 hours beforehand (always, per review of several weeks worth of logs). As to the best of my knowledge (aside from the warning) everything still works as expected.

If/When I have some time I can set up a test with the suggestion from TolstoyDotCom, likely the day before search engine submit is scheduled (without changing any cron job scheduling via crontab -e on the host) to see if I get the info your looking for as running cron after modification likely wouldn't produce any meaningful results considering it doesn't occur on every cron run or day. I'm just not sure when I'll have time.

Should someone be able to tackle this before I can, hopefully the information I provided will help.

@erutan thank you.. patch for 9.5.9 works! I didn't know there was a core issue regarding this, it didn't show up in my searches before initially opening this ticket.

At first I didn't think it helped!

Here are some things to note, after adding patch rebuild cache and when you first visit a content types form-display (it will still look like it is broken) and why I initially thought it didn't do anything.

Click show row weights upper right corner of form-display, if they aren't already displayed (so you can verify the next steps by weight order, making sure they end up in the right place).

Then in the disabled section for each tab, accordion item and/or nested group change each "Region" (dropdown-select)
from 'Disabled' to 'Content'. If everything is working correctly as you change each from Disabled ajax will run and update the form putting that field_group/item where is belongs - to verify check the weights. When done make sure to hit "Save" and the form-display will reload and everything will be exactly as it should! Moving forward any changes made (moving or adding field groups, tabs or accordion items) should work as expected.

@sergioitdo -> try the patch erutan suggested. Post back if it works, no point leaving this open if a core issue can resolve it! If it works for you, then this can probably be tagged with that core issue and closed as a duplicate.

OK, found modifying the /dist/js/frontend.js (similar to /js/frontend.js) works -> but instead of using 'const' I used 'var', and as best I can tell nothing breaks anywhere.

If anyone is looking to upgrade there drupal 9 site to 10 sooner than later with this module I made a patch including everything previously patched plus added back 'jquery.once' to 'once' in the libraries.yml. Everything passes D10 compatibilty per the 'Upgrade Status' module. Side note I also (for my personal sanity) in the patch included the removal of
sourceMappingURL=admin.css.map to stop it from generating a browser console 'DevTools failed to load source map: ....' error/notice when editing tb_megamenu in drupal admin, I don't think that will hurt anything if your just using this module and not building from it.

@themodularlab your explanation helped (definitely clears things up as to why). So if one wanted to recompile the module on there own would that build the /dist/js/frontend.js file from the /js/fontend.js file that was originally modified in the previous patch? (I'm assuming by combining with other js files - correct me if I'm wrong). If that is the case is there some documentation on recompiling step by step on your own? I looked through the info at https://git.drupalcode.org/project/tb_megamenu and see the FRONT END section using NVM but it's not exactly clear (unless it is just as simple as git clone repo in repo run 'nvm use', 'yarn install' and then 'yarn develop') or is there more to it? I'm more so just curious in that regards.

I'm getting the same error every time cron is triggered for this module.

Drupal 9.5.9, PHP 8.1.13, Apache 2.4.38

dblog message with stack:

Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 312 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#1 [internal function]: _drupal_error_handler(2, 'array_flip(): C...', '/var/www/html/w...', 312)
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(312): array_flip(Array)
#3 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(296): Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array)
#4 /var/www/html/web/modules/contrib/simple_sitemap/src/Entity/EntityHelper.php(218): Drupal\Core\Entity\EntityStorageBase->load(NULL)
#5 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityMenuLinkContentUrlGenerator.php(206): Drupal\simple_sitemap\Entity\EntityHelper->getEntityFromUrlObject(Object(Drupal\Core\Url))
#6 /var/www/html/web/modules/contrib/simple_sitemap/src/Plugin/simple_sitemap/UrlGenerator/EntityUrlGeneratorBase.php(248): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\EntityMenuLinkContentUrlGenerator->processDataSet(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#7 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(360): Drupal\simple_sitemap\Plugin\simple_sitemap\UrlGenerator\EntityUrlGeneratorBase->generate(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#8 /var/www/html/web/modules/contrib/simple_sitemap/src/Queue/QueueWorker.php(324): Drupal\simple_sitemap\Queue\QueueWorker->generateResultsFromElement(Object(stdClass))
#9 /var/www/html/web/modules/contrib/simple_sitemap/src/Manager/Generator.php(174): Drupal\simple_sitemap\Queue\QueueWorker->generate('cron')
#10 /var/www/html/web/modules/contrib/simple_sitemap/simple_sitemap.module(72): Drupal\simple_sitemap\Manager\Generator->generate('cron')
#11 [internal function]: simple_sitemap_cron()
#12 /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(417): call_user_func_array(Object(Closure), Array)
#13 /var/www/html/web/modules/contrib/simple_cron/src/Plugin/SimpleCron/Cron.php(70): Drupal\Core\Extension\ModuleHandler->invoke('simple_sitemap', 'cron')
#14 /var/www/html/web/modules/contrib/simple_cron/src/Entity/CronJob.php(326): Drupal\simple_cron\Plugin\SimpleCron\Cron->process()
#15 /var/www/html/web/modules/contrib/simple_cron/src/SimpleCron.php(102): Drupal\simple_cron\Entity\CronJob->run(1684767603, false)
#16 /var/www/html/web/modules/contrib/simple_cron/src/ProxyClass/SimpleCron.php(70): Drupal\simple_cron\SimpleCron->run()
#17 /var/www/html/web/core/modules/system/src/CronController.php(46): Drupal\simple_cron\ProxyClass\SimpleCron->run()
#18 [internal function]: Drupal\system\CronController->run()
#19 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#20 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#21 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#22 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#23 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(169): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#24 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(81): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#25 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/modules/contrib/advban/src/AdvbanMiddleware.php(57): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/modules/ban/src/BanMiddleware.php(50): Drupal\advban\AdvbanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(718): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#37 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#38 {main}

Other than that the module still appears to be working fine! I use simple_cron and run all cron as single url handled by crontab file on host.

I think there is an issue with this patch. Specifically regarding frontend.js

I almost gave up, thinking I had some kind of weird caching problem giving what happened after applying patch: 3328163-11.d10-compatibility.patch - after clearing drupal cache and browser cache when a page with main menu using tb_megamenu loaded I was getting a browser console error listing line 143 of frontend.js which broke the menu drop-downs that should appear when hovering over a main-menu link.

At first I couldn't figure out how it was possible the problem be line 143 (in browser inspector for sources) line 143 was showing:
var throttled = _.throttle(updateTBMenus, 100); which based on the patch for js/frontend.js that should be: const throttled = throttle(updateTBMenus, 100); and in that file it was line 48 not 143. If you look close you'll notice where line 143 is referenced in the error it reads 'var throttled = ...' but the patch for line 48 reads 'const throttled = ...', clearly not the same (and why I almost thought I has a really strange caching problem happening because I almost missed that difference).

So I did some digging...
One thing is I'm pretty sure at least from what I can see, is the file located at tb_megamenu/js/frontend.js isn't actually used or ever loaded anywhere.
What I found was a different file located at tb_megamenu/dist/js/frontend.js is the actual file being loaded - at least for version 2.0.0-alpha3.

I'm not sure why there would be two different frontend.js files (if it's by design or not) and how this hasn't been noticed prior considering.

I also haven't tried modifying the frontend.js file at tb_megamenu/dist/js/ with the changes made by the patch, I'll be doing that first thing tomorrow (quitting time at the office for today) and I'll report what I find.

Oh, before I forget one other thing to note is in the previous patch tb_megamenu.libraries.yml removed jquery.once for once:

-  core/jquery.once
+  core/once

- which should be done for complete compatibility with Drupal 10 (I'm not sure why that would have been removed from the last patch or if it was just overlooked).

sidgrafix → created an issue.

Found the problem...

Will document just incase anyone else runs into this!

Not sure when (had to be a while ago) unless the original composer.json project file for drupal 7 had it. Which thinking about it I think I may have made the addition at some point when I was investigating options to upgrade this particular drupal 7 website to Drupal 9 (10 was beta still) - anyway in my composer.json file in the "config" section I had

       },
       "preferred-install": "source"
}, 

That was the only difference I had in comparison to the default drupal-composer/drupal-project found at: https://github.com/drupal-composer/drupal-project/blob/7.x/composer.json

Which led me to this: https://www.drupal.org/project/drupalci_testbot/issues/2971824 →
"composer install --prefer-source for contrib projects means versions are missing in info files"

and also this: https://www.drupal.org/project/jsonapi_boost/issues/3260601 →

One thing to note, removing "preferred-install" from composer.json did not fully fix the problem! Any module downloaded from source, even if downgrade and then upgrade to latest using composer require still provided the package from source, I'm assuming because of the composer.lock file.

So to fix that just composer remove the module without package information provided by Drupal.org and the run composer require latest or version needed and it will then install with package information in the info file.

...just crazy, dohhh... Hope I did cause any alarms for anyone as this is likely a rare occurrence - apologies if I did.

OK, so this is really strange!!!

One of the other modules I updated yesterday as well was metatag (again using composer). If I inspect the module via shell there is no section: Information added by Drupal.org packaging script on 2023-05-12 at the end of the info file like there is if I download the zip package and inspect the file with an editor which does in-fact include version =..

So I double checked geofield module info file again in shell and it too doesn't have a "Information added by Drupal..." and again if download the zip package the info file does.

I'm thinking this has to be an issue with the packages composer is getting and it appears to affect all Drupal 7 contrib modules!
- I checked some other, it looks like this may have been happening for a while. Modules that haven't had updates for long while all have the "Information added by Drupal..." section and appears more recent updated ones do not!

So...I'm wondering is this a composer problem/bug or a drupal package handling problem for drupal 7? As this appears to have been going on for at least a couple weeks to months...

Also ran some additional test.. If I downgrade an older module (that upon prior inspection does have Drupal package information) both the downgraded modules info file does not have Drupal package information or when switching back to the latest version of the module using composer require.

Composer Version is 2.1.14

My composer.json uses: (the only setup listed that is suppose to work for Drupal 7)
name: drupal-composer/drupal-project
repositories url: https://packages.drupal.org/7
conflict - drupal/core: 8.*

And up till now (the particular setup this is on has used the same composer.json file for more than 7 years) has never been a problem.

That said this doesn't appear to be related to any given module as it appears to be affecting any module currently installed or updated with composer for drupal 7.

@poker10 - I'm sure there is a better place for this to be posted, if you know (point me in the right direction)? Got to get some work done right now - but next chance I have if I haven't heard anything or found an open issue elsewhere regarding this I will file one against core 7.

@poker10

I use composer, and can confirm the version wasn't included (then in ssh I just cd'd to the modules directory and used nano to view the info file). I didn't download a zip, so never inspected the info file that way.. Perhaps the problem is with package registry that composer pulls from?

Which makes sense now that I think about it. I was running Geofield 2.4 prior and didn't have an issue with geocoder but after composer require 'drupal/geofield:^2.5' and got the error I initially tried to downgrade to goefield 2.4 and still received the error - meaning the version was also missing from that version even tho it existed prior to update (originally in 2.4).

So if that makes sense, and is happening, it currently means anything being installed/required by composer isn't including version in info file (at least for geofield and Drupal 7)

Now I need to check other modules recently updated with composer to make sure it's not happening for all Drupal 7 modules required by composer... (I won't be in office for a.couple.hours yet, but will check first thing when I get there and update this..

sidgrafix → created an issue.

I have a working solution for anyone still looking.

Requirements:
- Website hosted on Apache 2.4+ platform with access to Drupals core .htaccess file.
- Domain CNAME DNS record for a Subdomain pointing to your main domain
- The 'Content-Security-Policy' (CSP) → module installed
- (optional) The REMOTE_ADDR [IP Address] found under Apache Environment listed on php-info (admin/reports/status/php) page. I'm not sure if it will be available for anyone on a shared hosting platform without a dedicated IP address. Also if it matches your IP don't use it (I read somewhere the REMOTE_ADDR is the users IP when not set/specified) and if that is the case it won't work in a live hosting environment. For my use case the REMOTE_ADDR is static and was the option I chose for the allowed access.

Note: in the following example the subdomain is 'media' using 'example.com' as the domain - change those to match your subdomain and domain.

Assuming you have a correctly set up CNAME DNS record specifically for use as the alternate domain used for the oEmbed media option setting.

If you were just starting to set things up - by default without any modifications this would mean anyone visiting "media.example.com" would see and have access to the same Drupal site at "example.com". Bad for two reasons SEO and user confusion, but we will fix that.

- That said, if you create content at this point on "example.com" and add a linked video from say youtube via a media field, you would likely run into cross site load error where the iframe should display when viewing the published content and is were the CSP module helps.

- If your at this point activate the (CSP) Content-Security-Policy module and at a minimum you'll have to configure in "Enforced" Policies "Directives" "frame-ancestors" by checking it on, setting the sub option "Self" and then adding your subdomain to the "Additional Sources" https://media.example.com

- Odds are "when using this module" especially if this is a live site you'll also have to set additional policies because by default it acts as security measure and denies other scripts and resources your site will try to load for example google maps and other 3rd party scripts and css. This can be a little complicated but easiest way to get through it is to use your browsers console which will output each denial with a tag that will match in CSP modules "Enforced" "Directives" like 'object-src and script-src', I found anything related to the oEmbed media coming from the subdomain by ticking on "self" and adding the subdomain to additional sources as well as enabling whatever identifier the browser console displayed for that "Directive" like 'unsafe-inline or unsafe-hashes' got everything working, for some of the others (3rd party sources also loading on the page) you may need to play with the settings a little to you get everything working without any errors or notices. I also disabled "Report Only" polies options by unchecking "Enable 'Report Only'".

There is probably an even easier way aside from the use of the SCP module, I'm just not sure what that would be without modifying headers and responses.

If your past all that and media oembed iframes are now loading from the subdomain on your main domain your almost done.

Now to either deny access to the subdomain or redirect everything to your main domain "that is not needed for oEmbed media to display."
- please note simply redirecting all subdomain requests to the main domain will not work (doing that would negate the use of an alternate domain to serve oEmbed content from and you would again see the warning about service oEmbed from the same site is not recommended.

Add the following to your .htaccess as the last entry inside the so it runs last after any other rewrites or conditions you may be using like https enforcement, strip www or any other custom redirects runs first. Remember to change subdomain and domain names, plus "if" you are using a dedicated IP listed as REMOTE_ADDR (noted above) swap those as well.

# Check if HTTP_HOST is subdomain used for Media oEmbed.
  <If "%{HTTP_HOST} = 'media.example.com'>
    # Set the order for access.
    Order deny,allow

    # Start with deny all access.
    Deny from all

    # If HTTP_REFERER is main domain allow access (the last '/' after referer domain is needed).
    <If "%{HTTP_REFERER} == 'https://example\.com/'">
      # If you have IP from REMOTE_ADDR replace 123.123.123.123 with the [REMOTE_ADDR] IP address if not remove or comment out 'Allow from 123.123.123.123'.
      # If on shared hosting platform without dedicated IP uncomment Allow from all and remove or comment out 'Allow from 123.123.123.123'.
      Allow from 123.123.123.123
      # Allow from all
    </If>
    # If oEmbed is requesting resources from core media module let it.
    <ElseIf "%{REQUEST_URI} =~ m#/core/modules/media/#">
      Allow from 123.123.123.123
      # Allow from all
    </ElseIf>
    <Else>
      # If you do not want to redirect but instead deny access to any other part of the subdomain, empty or comment out everything in the 'Else' directive.
      Allow from 123.123.123.123
      # Allow from all
      RewriteCond %{HTTP_HOST} ^media\.example\.com [NC]
      RewriteRule ^(.*) https://example.com%{REQUEST_URI} [L,R=301]
    </Else>
  </If>

I am by no means an expert on drupal, apache or htaccess, so it took some time getting things working (more like days of trial and error).
I found you couldn't just set allow all to IP if the HTTP_HOST was the subdomain (everything would still be user accessible at the subdomain), and it had to be the REMOTE_ADDR IP not the dedicated IP listed as SERVER_ADDR for it to work at all with IP.

Using browser tools and seeing exactly what calls were made to the subdomain when displaying oEmbed media is how I finally worked it all out. First I found there were 2 resources needed, the oembed linked iframe and a css file from the core media module.

The oEmbed iframe link is passed by HTTP_REFERER of the main domain the css file is passed by HTTP_REFERER of the subdomain (but so is anything and everything if your viewing the site as the subdomain) and why I used a pattern match on the directive, should some things change and more files or other resources in the media module is needed for oEmbed in the future it should continue to work.

The (If, ElseIf and Else) Directives are only available to apache 2.4+
- Note the first thing I do in the opening if directive is set the access order as well as Deny access to all, in the following if, elseif and else you set the 'Allow for' so it will process. If you empty the last else or comment everything else it falls back to Deny for all and will show users landing on subdomain Forbidden, permission denied.

Using either method 'Allow for [IP.ADDRESS]' or 'Allow for all' seams to work great, I tested both!

And as near I can tell this satisfies/mitigates any SEO (duplicate content), user confusion and Drupal's policy for oEmbed media!

Hopefully this will help others...

Closing this, as at some point a later version of Drupal 8 the update page (update.php) started working without any problems when website is served thru a reverse proxy and having "reverse_proxy = True" set (I have no idea what version it was resolved in) "I honestly forgot this ticket was even open until it was updated for Bug Smash Initiative" and I don't believe it ever affected any Drupal 9 installations, at least to the best of my knowledge!

Tested #36 Works Great (this feature should definitely be added)

+1 (awesomesauce) saved me from having to use hook_form_views_exposed_form_alter() to modify the submitted query parameters for the exposed filter.

Specifically useful when having other view blocks on page that use contextual filters with setting "provide default value" -> "Type: Query parameter" which updates the content in those blocks when the set parameters are passed by URL from custom links that provide those additional parameters.

Set up a test installation and changed minimum-stability to dev in composer.json and this module installed without any complaints.

- closing this issue

@kryber

Tested and works! Thank you for this...
Now I just have to get actual video transcoding working, but this takes care of some of the thumbnail part of the battle. Seems both "Local Video Thumbnail and Media Thumbnails with Media Thumbnails Video" are still fairly limited providing just 1 thumbnail - multiple with options to choose which one in a video situation would be nice (when video is uploaded instead of when saved) but this gives me something to build on.

Most appreciative!

@kryber

Nice.. I will try this myself when I'm back in the office! Did you test for thumbnails yet, do they generate after this modification to vendor/alchemy/binary-driver/src/Alchemy/BinaryDriver/Configuration.php ?

sidgrafix → created an issue.

@goodboy

Tested against dev version appears to take care of the errors that were previously being logged each time Autoban is triggered by cron.

However after reviewing your commit I'm not entirely sure this actually solves the underlying problem...
$window = !empty($entity->window) ? trim($entity->window) : NULL; appears to just make it so $window "if empty" will not be passed therefor if ($window) { $date = strtotime($window); if ($date) { $query->condition('log.timestamp', $date, '>='); }} won't run, as there is no $window set, thus no errors are logged.

Maybe I'm wrong, but I did have the new setting set "Default window" to 1 hour ago in Autoban settings when the change was introduced and I was getting the error notices. I think the underlying problem is elsewhere before $window = !empty($entity->window) ? trim($entity->window) : NULL; is even evaluated (at least for what I'm seeing) - but maybe I'm wrong. I haven't had time or tried to backtrack thru the code to find out were $entity->window should be coming from to confirm anything.

This does absolutely stop the errors from being logged, but I'm not entirely sure the actual features functions are working! So I figured I'd mention it.

sidgrafix → created an issue.

sidgrafix → created an issue.

@goodboy

Tested against dev version:

The initial error: Deprecated function: trim(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\autoban\Controller\AutobanController->getBannedIp() (line 54 of /var/www/html/web/modules/contrib/autoban/src/Controller/AutobanController.php)
--> is gone

However this brings on the new error I mentioned (after my initial test by commenting out the new feature at line 54)

as well as line 144-147 (the new $date addition, where $window was used from line 54) $date = strtotime($window); if ($date) { $query->condition('log.timestamp', $date, '>='); }

which is:
Deprecated function: strtotime(): Passing null to parameter #1 ($datetime) of type string is deprecated in Drupal\autoban\Controller\AutobanController->getBannedIp() (line 144 of /var/www/html/web/modules/contrib/autoban/src/Controller/AutobanController.php)

I'm adding a patch I created for myself for version 1.8 (Note: this basically disables the newly added feature)

@nofue

As I've mastered all the quirks and features of mailer & simplenews (at least to the extend I'm happy with my installation) I'm ready to help others by writing a tutorial.

I personally would be interested in this in regards to Simple News (and would consider it additional documentation perhaps for use in FAQ/tips for Symfony Mailer or perhaps better as a new Simple News how to's)

Had to move onto other things for a while but finally figured it out...

Had to add an apache2 directive to the apache2.conf configuration file (even tho according to apache documentation apache prior to 2.4.53 has a default value of unlimited for directive "LimitRequestBody") and shouldn't even be required being the problem version of apache here is 2.4.38 "Drupal 9 setup" (when it works without a problem on 2.4.25, not having the config directive, "Drupal 7 setup")

By adding:
LimitRequestBody 6073741824 at the end of the config file
- Uploads up to 6GB can now occur (matching what was set in php settings)

Per documentation apache 2.4.53 and later have the directive included and set to 1073741824 (as bytes) which is basically a hard limit around 1GB - apparently their documentation is not correct. Which can be found here: https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody

For future reference should someone run into this, it can also be set in .htaccess

So this is not a Drupal 9 bug...(I would change the status of this issue but I don't see where I can in that respect!)

Actually, none of the email presets provided by Symfony mailer were altered or overwritten when Simple newsletter configs were imported. It was just the new presets (for simple news) that came in with an empty body, and were the only ones that Symfony mailer threw an error for when viewing/editing them in policies.

My apologies if my previous comment caused any confusion in regards to the initial issue, that wasn't my intention.

My only concern was if someone didn't know they needed to add a body field later to an imported config because it wasn't imported being it was provided empty (as a bad config) they might get confused.

Again I can't speak in regards to Simple Newsletter (there may actually be a reason their config is the way it is) possibly because "I think, not 100% sure" there are options when creating a newsletter to include other types of node content as an import by means of auto generation on a scheduled send to recipients along with options for wrapping them with custom theming and styling. Don't quote me on that last, I haven't fully had a chance to dig through that module yet (it's meant to be a replacement on a Drupal 9 site currently being built where the Newsletter module (different module) was used on a Drupal 7 site the site being rebuilt in 9.

Again don't mean to make things anymore confusing (my sincerest apologies if I have), just trying to add a little more context.

@AdamPS

Completely understand your point in regards to bad configs!

I know most developers including myself would recognize the need for subject and body in an email policy, but for a moment lets look at it from someone who is unfamiliar altogether with Drupal and email in general.

I would argue someone trying to set up a simple site for whatever purpose installs a couple modules to handle email (lets say Symfony mailer for one and then later happens to install additional 3rd party modules) "like Simple Newsletter" they may not fully understand how things are supposed to work, and should they look into documentation for said 3rd party module expecting certain "presets" or "example" emails they can edit or tailor to their needs to be available "and they are not" because Symfony mailer just didn't allow the import or deleted fields that should exist even when they are empty (they may not realize they need to add the fields if they were deleted on import and believe the policy is intact and ready for use), it would also likely leave them frustrated, confused and seeking support in likely the wrong place.

Don't get me wrong I absolutely agree "it doesn't make sense in any regard" for a module to provide a template email (be it a preset or example meant to be edited, passed to a mailer system policy) without anything present in a subject or body field if they are supplied.

My initial suggestion was to only make things less complicated "more so" for users who aren't all that familiar with how things really work!

From what I see you've noted with #3303340 "add support for required adjusters" reads like it would handle the situation well enough providing at least better feedback in warnings.

Regardless, and in any respect this module "Symfony Mailer" feels like it is going to be the best route for Drupal handling email moving forward and why I've opted to use it in place of the current standards with my current and future Drupal site development. I don't have limitless time (currently working to rebuild and migrate several Drupal 7 sites to Drupal 9 and 10 over the coarse of this year), but if there is anything I can do to help with this project let me know, I would be happy to help!

I can confirm this error and provide a little more context/information as to why it is happening. Simply resaving a policy isn't the answer (at least for the situation I was found to be in)

Both this: Warning: Undefined array key "content" in Drupal\symfony_mailer\Plugin\EmailAdjuster\BodyEmailAdjuster->settingsForm() (line 56 of /var/www/html/web/modules/contrib/symfony_mailer/src/Plugin/EmailAdjuster/BodyEmailAdjuster.php)
And this: Warning: Trying to access array offset on value of type null in Drupal\symfony_mailer\Plugin\EmailAdjuster\BodyEmailAdjuster->settingsForm() (line 61 of /var/www/html/web/modules/contrib/symfony_mailer/src/Plugin/EmailAdjuster/BodyEmailAdjuster.php) are produced on screen and in logs.

(Initially I found the thread for issue related to version 1.0.0-alpha7 [as the only google returned search result] and saw some info regarding fixes added to dev version, so I switched to that, shortly there after realized that wasn't the case being I was on 1.2.0-beta2 prior to dev and still received the errors on dev - and then through a little digging found this thread)

Anyway..

If new policies are introduced and it has a body field (listed as "content" for Symfony mailer) and that field is empty because it hasn't been edited yet or nothing was supplied when/if the policy was imported! The listed errors are produced.

In my case when I activated the "Simple News" module new policies were generated, I'm assuming during module activation with empty body fields (not sure if they are empty by design "which could be a Simple News module issue - unrelated" (only stating that as I would assume default/generic information you could/would edit should be applied for things like email confirmation, etc.) and as in my case weren't!

So when in Symfony Mailer policies (poking around to see what Simple News added after noticing Symfony Mailer had new policies to import and importing them) and as I opened each related to Simple News I received in page errors and matching PHP warning/notices in Drupal Dblog.

Simply adding information in the body/content area of each policy stopped the error from being reproduced. Any policies without a body field produced no errors upon checking through all policies after seeing the errors.

In regards to error handling in the future it may be ideal to add a check for Symfony Mailer to check for an empty body field in which case it wouldn't produce a PHP error with a large stack trace (making users feel there is an underlying problem "bigger than it really is") but instead just a simple notice to say this policy either needs the "required" body field / content added or the field removed from the policy to save without error.

- I'm not entirely sure why a policy would have a body field listed as "required" with a red asterisk, which also prevents saving and should a user close it because they aren't quite sure what they want to provide there yet, they in turn would get these errors again when they edit said policy in the future (and illustrates further why I feel a check for an empty body field should be added - providing notice on the policy edit screen, while preventing a PHP error logged to Drupal's DBlog)

At the same time that would also eliminate Symfony mailer as seen as the culprit if another module produced policies imported with empty body fields!