🇺🇸United States @uri_frazier

uri_frazier → created an issue.

I'm running into the same type of error, but in involves a complex node bundle type with a lot of fields.

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'e72b42aa-af28-4aeb-80c3-4cb1e4e20ed8' for key 'paragraph_field__uuid__value': INSERT INTO "paragraphs_item" ("revision_id", "type", "uuid", "langcode") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => [:db_insert_placeholder_1] => accordion [:db_insert_placeholder_2] => e72b42aa-af28-4aeb-80c3-4cb1e4e20ed8 [:db_insert_placeholder_3] => en ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 817 of /mnt/alidata/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

#0 /mnt/alidata/web/core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()
#1 /mnt/alidata/web/modules/contrib/single_content_sync/src/ContentImporter.php(247): Drupal\Core\Entity\EntityBase->save()
#2 /mnt/alidata/web/modules/contrib/single_content_sync/src/ContentImporter.php(202): Drupal\single_content_sync\ContentImporter->createOrUpdate()
#3 /mnt/alidata/web/modules/contrib/single_content_sync/src/Plugin/SingleContentSyncFieldProcessor/EntityReference.php(170): Drupal\single_content_sync\ContentImporter->doImport()

I'm running into this issue with
Drupal 10.3.5
Ubuntu 22.04.5 LTS
Apache/2.4.52 (Ubuntu)

Everything works fine when running the site with files under the default directory, but when using sites.php to run the site with files under a specific site name (e.g. sites/my_site/, sites/my_site/files), Drupal can only generate the following directories: php, languages, private.

It cannot add js/css/styles. However it can (strangely enough) remove them.

I've compared the owner, group and permissions multiple times and even ran the same permissions fix script (https://github.com/Metadrop/drupal-fix-permissions-script) but it doesn't make any difference.

I got the same error when visiting /admin/config/regional/translate/settings:

"TypeError: Drupal\locale\Form\LocaleSettingsForm::Drupal\locale\Form\{closure}(): Argument #1 ($overwrite_customized) must be of type bool, null given, called in /var/www/html/comg/web/core/lib/Drupal/Core/Form/ConfigTarget.php on line 187 in Drupal\locale\Form\LocaleSettingsForm->Drupal\locale\Form\{closure}() (line 82 of core/modules/locale/src/Form/LocaleSettingsForm.php)."

Was able to resolve using the fix mentioned in #10 🐛 strtr(): Passing null to parameter #1 ($string) of type string is deprecated in locale_translation_build_server_pattern() Needs work
cp web/core/modules/locale/config/install/locale.settings.yml config/sync/locale.settings.yml && drush cim

(Drupal 10.2.6 & PHP 8.1.2)

uri_frazier → created an issue.

I know this is an old issue, but thank you @a.milkowsky for your solution. It works fine on version 4.1.9

I'm experiencing http links being generated on an https multilingual site (with multiple domains). The issue was originally reported here:
https://www.drupal.org/project/simple_sitemap/issues/2842097 →

We also have reasons to not use the Default Base URL setting.

Works well for me, thank you!

I will say, that after selecting the filter - the page flashes and the View resets as if no filter was selected. So perhaps it's working, but then just being automatically reset.

uri_frazier → created an issue.

I agree with sahilgidwani - this is not resolved and needs to be reopened.

I added some simple conditional checks so that the warning/errors are fixed.
Besides the warning that appears when visiting /test-stuff (see "steps to reproduce") there was also an issue when trying to edit the dependent filter via Views admin where it caused an AJAX error and clicking "Settings" failed "silently" (error was accessible in the browser console log), but you couldn't edit or change anything as a result. The change to ViewsDependentFilter.php fixes that.

I'm going to work on this as part of 4K Contrib Day.

I also was getting the same error originally reported along with the following:
Warning: Trying to access array offset on value of type null in /app/web/modules/contrib/file_mdm/src/Element/FileMetadataCaching.php on line 66 Warning: Trying to access array offset on value of type null in /app/web/modules/contrib/file_mdm/src/Element/FileMetadataCaching.php on line 75

The problem occurs (SettingsForm.php) when there is no default/value set in $this->config('file_mdm.settings').

Also in the code below, splitting off the save() function doesn't work as intended.

$this->config('file_mdm.settings')->set('metadata_cache', $form_state->getValue(['metadata_cache', 'settings']));
    // Only save settings if they have changed to prevent unnecessary cache
    // invalidations.
    if ($this->config('file_mdm.settings')->getOriginal() != $this->config('file_mdm.settings')->get()) {
      $this->config('file_mdm.settings')->save();
    }

I've created a proposed solution here:
https://git.drupalcode.org/project/file_mdm/-/merge_requests/23

To reproduce this error, try configuring Metadata caching settings while running PHP 8.1.x and on a site that has not no previous Metadata caching settings saved in Drupal config.

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

I still get the bug described in issue https://www.drupal.org/project/gin/issues/3338209 🐛 Sticky header triggered to early Closed: outdated (Sticky header triggered to early) even after updating to 3.0.0-rc4. This is while using Chrome 114.0.5735.198 and Firefox 114.0.1

(See screenshot gin_sticky_header_bug_screenshot.jpg ).

Created a MR to fix the typo.
Changed status to Needs Review.

uri_frazier → created an issue.

The patch works, but causes an unexpected change to the admin/content view (see screenshot).

I added a commit based on my previous findings/comment 🐛 Undefined index: name in composer_manager_installed_packages() Needs review .

There was another instance of $json that needed to be replaced with $json['packages'] in function composer_manager_package_dependents()

Did anyone else notice this related (?) bug in conjunction with this fix?
Namely, the package status page says several packages are not needed, but composer says otherwise and doesn't remove them when running composer update. (see screenshots)

https://www.drupal.org/files/issues/2023-01-31/3247179_1.png →
https://www.drupal.org/files/issues/2023-01-31/3247179_2.png →
https://www.drupal.org/files/issues/2023-01-31/3247179_3.png →