🇺🇸United States @edmund.dunn

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

@mably I would love to add you; however, it won't let me. I will do my best to get D11 release out ASAP.

This needs to be updated and a new releaseneeds to be pubished. This is NOT the responsibility of the sites. The maintainers need to publish a new release.

Update to the patch. This is separate from the MR because it takes into consideration https://www.drupal.org/project/entity_browser/issues/2851580 🐛 Re-order + remove broken with the Entity Reference (and File) widget Needs review

This one worked for us!

This one worked or us!

We also had to apply the patch from https://www.drupal.org/project/entity_browser/issues/2851580 🐛 Re-order + remove broken with the Entity Reference (and File) widget Needs review , which altered the necessary changes. The MR is applied against 8.x-2.x.

edmund.dunn → created an issue.

This worked for us. I will note that entity_diff_ui is not the same as the revisions UI work in core.

Adding a patch. Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC.

edmund.dunn → created an issue.

edmund.dunn → created an issue.

This worked for us!

fixed the file name.

Here is a patch to address this.

edmund.dunn → created an issue.

Attached the patch with changes. Checked permissions for the current user and then rendered the count alone or the count as a link to the entities usage tab.

edmund.dunn → created an issue.

I copied the getSourceEntityLink method from ListEntityUsageController.php. They also accounted for the use of block_content in that method. It now generates the links to the paragraphs.

We used this successfully. We had this same error. Two revisions, one created by an automated migration job, the other by an editor, both within a few hours. This created a conflict of some sort. This solved the issue. Well done!

Turns out this patch was no longer necessary to fix our issue once we applied the patch from entity_browser_table.

I am rerolling for 10.2.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue. Again, nice work!!

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue. Nice work!!

@evaldas-užkuras, that is a good point. The combination of your patch here, and the patch you added for entity_browser_table seemed to fix our issue. We will be doing some more testing here in the next couple of weeks. Nice work!

I am not sure that @EthanT 's solution is ideal. We have cases where it is still needed and is not being injected. I am wondering if there is something to do with the recent changes to using the create() methods to inject? Although why it works the first time and not the second (see video) is the true mystery.

This is occurring for us as well. When I stepped through the first time entityTypeManager was injected correctly, everything appeared to be working correctly. The second time, see attached screen recording, it was not there. The entity type is loaded correctly, but entityTypeManager = null.

Feel free to pull down https://github.com/department-of-veterans-affairs/va.gov-cms. It runs on ddev. ddev pull va --skip-files gets you the database.

Full error is:
Error: Call to a member function getStorage() on null in Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget->formElementEntities() (line 759 of modules/contrib/entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php).
Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget->formElement(Object, 0, Array, Array, Object) (Line: 130)
Drupal\entity_browser_table\Plugin\Field\FieldWidget\EntityReferenceBrowserTableWidget->formElement(Object, 0, Array, Array, Object) (Line: 342)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 92)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 183)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 669)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->formElement(Object, 0, Array, Array, Object) (Line: 342)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 849)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->formMultipleElements(Object, Array, Object) (Line: 111)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object, NULL) (Line: 968)
Drupal\paragraphs\Plugin\Field\FieldWidget\InlineParagraphsWidget->form(Object, Array, Object) (Line: 183)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 121)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 127)
Drupal\node\NodeForm->form(Array, Object) (Line: 107)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('node_step_by_step_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object) (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 592)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 68)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 53)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

edmund.dunn → created an issue.

And missed one change for the patch.

I had to update the patch to add an accessCheck() to the query for the getAlertsByLabel method. Missed that!

This mostly works for us. Thank you and good work @sascha_meissner! It is definitely a big improvement on the previous. The style replicates on the same line but doesn't follow if you hit enter. This is workable until a permanent fix is in place!

I went ahead and created a patch from the work @puidu did in #113. That worked for us; we have several instances where the initial render of one of the ckeditor5 instances was out of the viewport, and the height when it was revealed was set to 65px. Changing it to 24 gets us close to the 180pc height all of our other ckeditor instances have.

edmund.dunn → created an issue.

I rerolled this to move the menu link from config->system to config->user interface. Also had to move the setting.yml file into the config/install directory to prevent an error when installing the module.

This works well for our needs.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue.

We are in the process of upgrading to D10 from D9.5. We didn't notice the issue until we got it up on our test instance for testing. On our local and dev environments, we have aggregation turned off so we hadn't noticed any issues.

Turning aggregating off does fix the issue.

edmund.dunn → created an issue.

We are having the same issue as @FiNeX in #56.

Just an update on our testing. There were a couple of bugs with the dedicated metadata URL. Those have been fixed. We are waiting for our IAM team to set up or test site with their test IdP with he updated metadata to complete testing. I will update this thread once that is complete.

@caesius good catch! That worked! Thank you!

4.x-dev still requires dev-master not 2.1.

Ok it is installed, and everything seems to be working. Once we get the IdP configured we can test. I will update this thread once we can confirm either way.

I just ran into it too! Adding "twig/twig": "3.7.0 as 3.6", fixed it. I just used that in my main composer.json. This hacky approach will at least work for testing.

@nitesh624 we can test it. It will take us a bit to set up because we have to coordinate with the IAM team for our organization. I will post our results here.

I am unable to replicate this. Could you please provide some more info on your setup?

Here is the patch.

We are going to address this. Working with our designer to get comp to work from. More to follow.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue.

ALso tested on 10.1 and this fixed everything right up for us! Thank you!

This was addressed in https://www.drupal.org/project/textfield_counter/issues/3358129 🐛 Module does not work in d10 due to .once js issue Fixed . Thank you for identifying and patching.

#4 would not apply for me. I re-rolled it.

This should fix the tests.

Good point @swirt! Made the relevant changes as this simplifies things.

Updated patch to allow for the above situations.

Attached patch.

edmund.dunn → created an issue.

Ok, I will rework it to do the above.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue.

Rerolled for 10.1. Applies cleanly.

Rerolled for 10.1.

Slight change in approach; this just returns the none string value so that the next process in the chain can continue on. I misunderstood and thought this was what the MigrateSkipProcessException did. This also iterates through an array and acts aon all strings in the array, returning all non-string items as is.

We had this issue pop up again in a different area. This time it was a field that isn't always populated. It comes in with a value of NULL when it isn't populated. Here is a patch. I added a check to verify whether the incoming value is a string or an array of strings, and if it isn't it will throw a MigrateSkipProcessException. I also added a unit test for it.

I messed up the above patch. Here's the correct one.

Somehow the first one ended up empty. This one has the patch.

As requested! :)

This uses the php boolval() function. It also accounts for yes/no strings.

This worked for us and applied cleanly! Thank you!!

Here is the patch for this issue.

edmund.dunn → created an issue.

Posting the static patch because using the MR doesn't allow pinning to a specific commit, so anyone can submit pretty much anything and inject it into our codebase IIRC. This also fixed our issue.

#11 would not apply. I rerolled it for the latest release(3.4.1).