🇩🇪Germany @mvogel

Sorry @hcanning,
but this problem has nothing to do with ajax_loader.

As the composer error message says, your system wants to install drupal/core 10.3.8 and needs ext-gd on your system but cannot find it. The drupal/core 10.3.8 dependency comes from drupal/core-recommended 10.3.8 in your composer.json.

ajax_loader does not specify a specific Drupal version (we did not even have a module-based composer.json in the first place). The problem will also occur if you just run `composer update`.

Try to install or enable ext-gd as suggested, or contact Pantheon support.

Since this issue appears unrelated, I'll need to close this for now (as I can't reproduce it).

Thanks again for the bug report; we definitely need some tests covering base functionality.

I found the bug.
A change in fb97362e unintendedly changed the structure of the install settings config. Because we did not set the empty default value properly, the auto lint fix changed the structure from string to array. My bad, I did not catch that in the code review.

I am sorry for any inconvenience this may have caused you. I released a new version, 2.1.4, and new installs are working properly now.

Thanks for your report.

I can reproduce it, and will look into it.

@fabsgugu I released a new 2.1.3 version with D11 compatibility

@EvilArgest After almost half a year, I finally reviewed your changes. Thanks for your work.

I tested it quickly, got some issues in the config form, and found this change record
https://www.drupal.org/node/3404140 →
See MR https://git.drupalcode.org/project/ajax_loader/-/merge_requests/9

I value your input and will give the other maintainers a chance to review. Once we've all had a chance to provide feedback, I will merge and create a new release.

Everything is working as expected except for the configuration form.

@fabsgugu, by chance, had you the possibility to test the module with the patch provided

poker10 → credited mvogel → .

Thanks for your work @EvilArgest. I try to review the changes soon.

there is a https://git.drupalcode.org/project/ajax_loader/-/pipelines/146942, so something works

I close this issue. Hopefully, it is all resolved with the current version.

Thanks all, I committed it and will create a new release

I tested it, and it seems promising. Maybe we can get some feedback from the persons involved in the linked issue.

@EvilArgest and @v.koval could you please test the MR in #3423380 🐛 The ajax loader is being displayed only the first time on type throbber Needs review if it fixes your problem?

Thanks, @akalam,
yes, this #3331491 🐛 Views Exposed Filter, Throbber not removed on consecutive Ajax Call Needs review MR introduced this bug, but fixes another bug. So maybe we have to roll back this change because it triggers more bugs than it fixes.

I can now reproduce this behavior with your steps.
It is still weird, with exposed filter form, pager and ajax link (a-tag) the this.progress.element is empty on consecutive ajax calls only with this viewsForm field this.progress.element is still defined.

I quickly tried to reproduce it. These are my steps.

• Fresh install enabled devel, devel_generate and created 50 articles.
• Enabled ajax_loader and flags module (for ajax link/button).
• Created a simple table view with page display for articles with a relationship to flag
• Added the flag link as field
• Enabled Pager and Ajax
• All seems to work as expected

See the video as an example. Because the ajax call is fast on fresh installs you only see a flashing black rectangle but that is the animation I saved in the ajax_loader settings. The throbber the mounted and unmounted every time for every click on the flag link or pager.
https://www.loom.com/share/513007517ee84822933e88c0ee64fcaa?sid=18c151d3...

Oh I am sorry to hear that. I will investigate it as soon as possible. For the time being, you can use the 2.1.0 release.
Are there any JS errors in the dev console?

A naive approach is to call the claro form_alter function if the form_id contains media_library.
Maybe str_starts_with($form_id, 'views_form_media_library') will work too (and is a bit more restrictive).

I released the 2.1.1 version; please check your use case if possible.

Hi,
I still can not reproduce this issue.
However, I can not see any side effects when merging the MR. So, I merged it in dev and will create a new release.
Thanks for your work :)

Hi, nice to hear that you find the problem.

It is a bit weird with custom properties and SCSS, but you must interpolate the SCSS variable to get that working.
So your code should look like this:

$color_1: 'red';

.ajax-throbber {
  --sk-color: #{$color_1};
}

For further reading https://sass-lang.com/documentation/style-rules/declarations/#custom-pro... and https://sass-lang.com/documentation/interpolation/

Hi :)
you can use the custom property --sk-color for this purpose. It is defined at the :root element so that you can overwrite it everywhere.

for example:


.ajax-throbber {
--sk-color: red;
}


I forgot to change the status to "needs review"

I created a merge request.
I defined an alter hook to change the value for the autocomplete result. The will run after the default code so contrib or custom modules can change it.
I made the original code null save by adding ?->

$raw_field = $entity->$real_field_name?->value;

Because otherwise, it will generate watchdog entries for the 'realname' fields.

I don't know if this adds too much complexity, and if it is a straightforward approach, I tried to document as much as possible and give the hook as much context as someone may need.

Hi,

sorry to be a grave digger. But we are just now working on CKEditor 5 update on my site, and it seems that your commit d0a43eb6 lost the crucial line from the patch #8 and MR/PR

diff --git a/js/ckeditor5_plugins/editorAdvancedImage/src/EditorAdvancedImageCommand.js b/js/ckeditor5_plugins/editorAdvancedImage/src/EditorAdvancedImageCommand.js
index ee7a681..b39d3a4 100644
--- a/js/ckeditor5_plugins/editorAdvancedImage/src/EditorAdvancedImageCommand.js
+++ b/js/ckeditor5_plugins/editorAdvancedImage/src/EditorAdvancedImageCommand.js
@@ -72,6 +72,9 @@ export default class EditorAdvancedImageCommand extends Command {
     if (element.hasAttribute("id")) {
       this.attributes.id = element.getAttribute("id");
     }
+
+    // Force an execution at refresh time in order to set attributes even when the Balloon form has still not been used.
+    this.execute(this.attributes);
   }
 
   /**

that fixes the bug from the issue.

You are right. Inversion of control should be the approach here. I will think about it and make a proposal later.

attached patch

mvogel → created an issue.

Thanks, that solves the issue :)

mvogel → created an issue.

2.0.x-dev branch works well +1

attached patch

mvogel → created an issue.

+1 from me. Now all works 100%

@vasike, great work that you found a way to distinguish between the entity and possible entity relationship. I tested it and it works almost 100%

I have found a bug but I think it is a combination of this issue and https://www.drupal.org/project/views_autocomplete_filters/issues/3345680 🐛 Attempt to read property "value" on null in src/Controller/ViewsAutocompleteFiltersController.php on line 220 Needs review

Steps to reproduce:
1. add a plain text field to node article (field_plain_text)
2. add entity reference field to user pointing on node article (field_reference_field)
3. create a node article with a filled field from (1) and update a user field_reference_field to this node
4. create a user entity view with a page
5. add "Relationships" to content from field_reference_field
6. add a field from (1) to "Fields" and add "Filter criteria" with the exposed form and "Use autocomplete"
7. visit the page from (4) and search for the value you created in (3)

$real_field_name = $view_field->realField;

$real_field_name = 'field_plain_text_value' for some reason see screenshot

I hope you can reproduce it, it is kinda hard to explain, if you need a video or want a call you can write me

You are right, my problem is the issue you posted. I tested your commit and it fixes the problem with different field identifiers field_somethink_2

sorry for the unnecessary noise.

Unfortunately, your commit does not fix my problem. For example, I got a "user entity" view that has an entity reference field to a node entity. In my exposed form I can filter this entity reference field. So I got the problem:

$entity is an instance of User and the $real_field_name is a field from a NodeType, that results in Attempt to read property "value" on null in Drupal\views_autocomplete_filters\Controller\ViewsAutocompleteFiltersController->autocomplete() Line 231

Steps to reproduce:

1. Create an entity reference field for user that points for example on node article
2. create a view for users that has an exposed filter for the entity reference field from 1 for example the title field (activate views autocomplete filters)
3. Type something in the input field and get the error message from above

Ok, got it. Thanks for the quick answer

Hi,
nice rewrite, thank you.
One question: Will the Group entity method `getMember()`be rewritten as well in version 2.x, 3.x?

  public function getMember(AccountInterface $account) {
    return $this->membershipLoader()->load($this, $account);
  }

  public function getMembers($roles = NULL) {
    return $this->membershipLoader()->loadByGroup($this, $roles);
  }

+1

It seems you forgot to move the "accessCheck" to the outside of the if clause. And there is a second occurrence in the .module - file (see patch)

After reviewing I found some points

1. Declaration of EventSchedulerDispatcher::dispatch still does not match the declaration from Symfony\Contracts\EventDispatcher\EventDispatcherInterface because the return type has to be object instead of ?Event
2. The function in event subscriber EventsProcessSubscriber public function onKernelTerminate(Event $event): void can not use Event as the parameter, it has to be TerminateEvent but we can drop the argument because it is not used
3. In the public function setPageSent() inEventSchedulerDispatcher you have on ->dispatch() call where we have to swap event name and event parameter

Thanks for your patch. I tested the patch but it does not work.
It will only work when the field belongs to the entity type.

In my case, I got a user view, so the $entity will be a user object. My user object has an entity reference field to a node object. In my view, I can filter for a field in the node object (like for example field_node_title). The code will then try $entity->field_node_title->value which will always be null, because the user object hasn't a field node_title

see the patch for refactoring

mvogel → created an issue.

I got the same problem.

https://git.drupalcode.org/project/views_autocomplete_filters/-/commit/b... introduced the "bug"

with $entity->$field_name->value

          $langcode = \Drupal::languageManager()->getCurrentLanguage()->getId();
          $entity = $view->result[$index]->_entity->getTranslation($langcode);
          $raw_field = $entity->$field_name->value;

The patch does not fix it for us, because in our case we have a user view and join with a node table and the autocomplete exposed form filters some field value of the node table, and the user entity can not have the node field in this case.

Proposed solution:
The code has to check to which entity the field in the exposed form belongs to get the right field with the translation.

Rerolled PR works for me. Thanks for your work. :)

Thank you for the quick replies. I am ok with disable_balloon. The PR looks good and I tested it successfully locally. 👍

I couldn't get the test on drupal.org running because of the dependency on the inline_entity_form module. So despite that, I set the status to "Needs review"

Hi @heddn
sorry I don't understand what you mean with test coverage. Your existing tests will fail at the moment with

Testing /var/www/html/web/modules/custom/prepopulate/tests/src/Functional

Behat\Mink\Exception\ElementNotFoundException : Button with id|name|label|value "Save" not found.
 /var/www/html/web/core/tests/Drupal/Tests/WebAssert.php:144
 /var/www/html/web/core/tests/Drupal/Tests/UiHelperTrait.php:77
 /var/www/html/web/modules/custom/prepopulate/tests/src/Functional/PrepopulateFieldTest.php:111
 /var/www/html/web/modules/custom/prepopulate/tests/src/Functional/PrepopulateFieldTest.php:91
 /var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

for example. Because you get an error page with no form and button. See this video https://www.loom.com/share/b46ec9da74c5481faf32f7d6f3ed3a8c

adding the missing patch for config schema.yml

mvogel → created an issue.

mvogel → created an issue.

mvogel → created an issue.

mvogel → created an issue.

changed accessCheck from FALSE to TRUE

Relying on entity queries to check access by default is deprecated in drupal:9.2.0 and an error will be thrown from drupal:10.0.0. Call \Drupal\Core\Entity\Query\QueryInterface::accessCheck() with TRUE or FALSE to specify whether access should be checked.

in EREFNodeTitles.php

fixed in patch

There is a problem with symfony new implementation of $request->query->get() function.

In Drupal 10.0.2 with PHP 8.1.13 I get the following error message when opening a page with ?edit%5Btitle%5D%5Bwidget%5D%5B0%5D%5Bvalue%5D=Title

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "edit" contains a non-scalar value. in Symfony\Component\HttpKernel\HttpKernel->handle() (line 81 of /var/www/html/vendor/symfony/http-kernel/HttpKernel.php).

In src/Populate.php L92

$this->request->getCurrentRequest()->query->get('edit');

produces an error in vendor/symfony/http-foundation/InputBag.php L36

if (null !== $value && $this !== $value && !\is_scalar($value) && !$value instanceof \Stringable) {

because it is an array. Proposed solution for this problem in patch file.

I have successfully upgraded to Drupal 10 using the following patch. However, it is important to note that all custom code must be updated to comply with the new event dispatcher standards, including the proper order of event objects and event names. Additionally, we must ensure that the declaration of Drupal\event_scheduler\EventSchedulerDispatcher is compatible with Symfony\Contracts\EventDispatcher\EventDispatcherInterface to get the page running. While there may be alternative methods, this approach has worked well for our test site. I will be able to provide more information on the effectiveness of this approach by the end of February when we push it to production.

Refactored jquery once function calls in js files to core once function calls

patch #3 looks good, works for me. Info yml for the 3 modules needs to be updated as well.