Same problem here, with facet 3.0.0-beta1, search_api_solr 4.3.3 and drupal 10.2.6. Unable to save the form at admin/config/search/facets, getting wsod with the message above
Begging of the debug trace:
Drupal\facets\FacetListBuilder->submitForm()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 224)
Drupal\Core\Form\FormBuilder->getForm() (Line: 94)
Drupal\Core\Config\Entity\DraggableListBuilder->render() (Line: 23)
Drupal\Core\Entity\Controller\EntityListController->listing()
call_user_func_array() (Line: 123)
There are two sources relying to View Solr Search (page, and block), there is not so much to configure a part the Filter key. Fields are present by default in solr index but I see no way to add a facet block in block layer.
erwangel → created an issue.
The new dev looks fine. It works on all my media types. I had a look in your code and it seems the right approach. However it produces the default language links as pointed in issue 3316244 (url not translated) 🐛 Generated URL of parent entity is not translated Postponed: needs info . Have a look there; I commented it and proposed a working solution.
Also I noticed that $formatters are defined in InitialSettingsService as ['image', 'responsive_image']. I tested and it's okay with both of them, but what about other formatters that modules may add (I have blazy and colorbox, but also image_field_tokens, I don't know where the last comes from perhaps token module). I understand we can't plan ahead what formatters may be available there. Perhaps make it clear in documentation and presentation page that the module acts only on core 'image' and 'responsive_image'.
Blazy is widely used and it may be worth having some kind of compatibility. I tried to add 'blazy' in the $formatters array, the 'link to parent' option appeared in formatter's settings but it had no effect on display. I was not surprised as Blazy has it's own 'link to' called 'Media switcher' but it's mostly for switching to colorbox or other lightboxes supported by this module and anyhaw it lacks an option to 'link to the parent'.
I think we can consider the $sources issue fixed and if you think a solution to make the module compatible with other formaters is possible, perhaps open an other issue.
What about this ?
// ------ Added line ( 45 of last dev - media_parent_entity_link_media_view() )
// to get the current language then set the right translated link
$language = \Drupal::languageManager()->getCurrentLanguage();
foreach ($components as $componentkey => $component) {
if (!empty($component['third_party_settings']['media_parent_entity_link']['link_to_parent'])) {
if ($entity->_referringItem) {
if ($entity->_referringItem->getParent()) {
if ($entity->_referringItem->getParent()->getParent()) {
/* @var \Drupal\Core\Entity\EntityInterface $parententity */
if ($parententity = $entity->_referringItem->getParent()
->getParent()
->getValue()) {
if (!$parententity->isNew()) {
try {
// ------ Set the right translated link here ------
//$url = $parententity->toUrl();
$url = $parententity->toUrl('canonical', ['language' => $language]);
}
catch (Exception $exception) {
$url = FALSE;
}
if ($url) {
...
In some of my tests it gives the right links
No more warnings after applying #4 on ffs-2.0.x-dev and D10.2.6.
Confirmed working by me too.
"Private images" appeared as an extra media type in my settings after the upgrade from Drupal 7 to 9. And I think one has to create this type if he wants to store images in a Private file system path (see settings @ /admin/config/media/file-system). The image field (field_media_image) of media image type doesn't permit to chose the storage on uploading; you have to define it in settings (see @ /admin/structure/media/manage/image/fields/media.image.field_media_image). So if for some of your images you want a private storage (outside of site root) you have to define a new media type (p.e. private_images) and set the appropriate storage. You can still access private images for display through styles but not directly by their url.
I'll come back in a few days to test the new dev version. Thank you for making it.
Footnotes 4.0 works fine with no dependency to fakeobject. Not sure but, if I noticed well, it (or composer) even removes fakeobjects and Ckeditor 4 while updating from fn3 to 4
I tried MR 8 on a Drupal 10.2.6 which applied with no problem on ffs 2.0.x-dev. Using it on a media module image field (admin/content/media) as well as directly on a node with media field, the remote image is downloaded and listed in admin/content/files but when saving the media or the node I get:
Error: Object of class Drupal\media\Entity\MediaType could not be converted to string in Drupal\Component\Render\HtmlEscapedText->__construct() (line 31 of /path_to_site/web/core/lib/Drupal/Component/Render/HtmlEscapedText.php).
I can confirm #147: with smart_trim module enabled, try to format a body field in views using smart_trim formatter and you get the error.
The error also occurs with several other modules. I'm not using them but I landed on their issues while seeking a solution to this error message. I set some of them for reference in "relationships".
Thank you for the quick reply. So quick that I haven't seen the 3.0.4 was already up including the fix; I was trying to patch the 3.0.3 until composer shows me it was updating to 3.0.4! Everything is working perfectly now.
erwangel → created an issue.
erwangel → created an issue.
patch #30 worked for me (gin_login 2.0.4 on D core 10.2.5)
erwangel → created an issue.
erwangel → created an issue.
Although that's confusing for people wanting to install the module. You require it with composer as "front" but you have it to enable it with drush as "front_page". confusing and not very intuitive when drush tells you "Unable to install modules front due to missing modules front." I had to look in the modules's directory to realize that its "real" name was "front_page" and not "front". I think a quick fix will be useful so more people could install it and you could gain more feedback.
Still not working. With the suggested changes I was able to access the settings page but once I validated the form I got again a wsod and was logged out with a RuntimeException: Failed to start the session. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 173 of /path_to_site_root/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
Cache rebuild didn't help, it just permit access to the login page but once the credentials validated, white scren again. I had to uninstall the module to get the site back.
In the php logs Maximum execution time of 40 seconds exceeded and Allowed memory size exhausted as well as Warning: session_start(): Failed to decode session object. Session has been destroyed in Drupal logs which just explains the symphony session failure.
#4 worked for me, especially after watching the video (it helps to place the two js lines). Thanks pradipmodh13
Sorry, this was due to a drush&devel issue as I had upgraded devel just before.
See issue and solution @ https://github.com/drush-ops/drush/issues/5941
erwangel → created an issue.
I tested patch from marco.aresu (#10) and it works but page attachments remain in http. For the moment I used hook_page_attachments_alter to correct this with a str_replace("http:", "https:", $url) looping through
$attachments['#attached']['html_head_link'][1][0]['href']
I suppose the other patches don't correct this either.
erwangel → created an issue.
Problem encountered with user account fields on Drupal 10.2.4.
- Sites's default language is "fr", and two other languages activated "en" + "el"
- In admin's profile Language settings: "Site language" is "fr", "Administration pages language" is "en".
- Field settings "Users may translate this field" is "off"
The problem doesn't occur on all custom fields, but on newly created fields.
Newly created custom fields take original language "en"
Example creating a new "text plain" field. I add translations for "en" and "el"
As all my other fields have original language "fr" (they come from a D7 migration, D7 site wasn't multilingual and had default language "fr"). Wanting to have coherence through languages, I set the newly created field to original "fr" by executing
drush cset field.field.user.user.field_test_text langcode fr
drush cset field.storage.user.field_test_text langcode fr
Result: I have language original "fr" but "en" translation disappeared while "el" is preserved and is still here. I click to add translation "en". The modal window opens but when I save the translation I get
Status message
English translation was not added. To add a translation, you must modify the configuration
I understand that I have to edit the field (supposed to be now in original "fr") and so do I. After saving it, apparently it has been saved in "en" instead of "fr" because I get
Warning message
The configuration objects have different language codes so they cannot be translated:
field.field.user.user.field_test_text: fr
field.storage.user.field_test_text: en
Similar issue with metatag field.
- My conclusion is that whatever the original language is, when the field settings page is saved, drupal reverts the original language to the admin's "Administration pages language". There is some logic there although I could expect save a "fr" version when I edit a "fr" version. But what happens when your site has two admins with different setting for "Administration pages language" in their profile ? Field's original language will be reverted in the admin's language each time one edits the field and such erasing the other admin's translation.
- My recommendation: drupal should respect the field's original language even when the admin's language is different. Perhaps we should have a language selector for the original/default field language at field level like in multilingual content types in case one wants to change the original language instead of the drush "cset" command.
- That said, I don't understand why this happens only to newly created fields and not on old ones (those coming from the D7 migration).
The Ajax issue is still present on 10.2.4. In a custom module I have a very simple form, I simplified the ajax response to jus say "Hello", I switched to the default Olivero theme to be sure there is no interference with any other jquery or ajax call. This form was working with no problem on 10.1.2.
What I noticed in the console display of he error is that whatever the context of my form is used (and so producing variable ajax responses), it always has a "settings"; nul' in the response text. This quote after nul sounds suspect to me.
message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code: 200\nDebugging information follows.\nPath: /path_to_the_calling_page?ajax_form=1\nStatusText: parsererror\n
ResponseText:
[
{"command":"update_build_id","old":"form-rjF70Nh6-v5uOijTmG0ZX6MHU8dDqTYYjLsJzf79Stk",
"new":"form-LHnajKIYq8szIGH0kkk-4vqtqzU_FsZmY2tLXUHqkqc"},
{
"command":"insert",
"method":"replaceWith",
"selector":"#my_ajax_form_element",
"data":"Hello",
"settings":nul'
name: "AjaxError"
stack: "@https://my_site.com/core/misc/ajax.js?v=10.2.4:196:32\n@https://my_site.com/core/misc/ajax.js?v=10.2.4:1916:3\n"
<prototype>: Error:
ajax.js:196:32 etc.
Extra line-breaks are mine to make it evident that there is a malformed json array, probably due tho the nul'.
I tried patch 10.2.1 from #35, it worked on the first call of the form (a click on submit button), but it didn't work on the next calls although there was no error displayed on the console.
Changed title to better reflect the issue
Hmm... A bit long the new description. Metatags are not only in content types; we found them in taxonomies, in users, in views, etc... Why not set a second permission ? Two permissions are not too much and could avoid long explanations to say what a permission does and what it does not. Example : the current permission "Who controls the per bundle Metatags settings. And a new one for "Who controls the Metatags content".
Metatags demands quite technical skills or at least knowing to what they serve. Or in a site with large audience, the presence of this field can be confusing to users. For example, in my site I have content types that are reserved to accredited authors. Okay they can be informed and trained on the usage of metatags, but other content types are open to all registered users while some other content types (like forums) are open to even anonymous users. We usually fill default metatags, eventually with tokens. We can not trust all these users that they will fill correctly the metatag fields.
Imagine you have a recipe type where users can post their preferred recipes (I hope you like cooking), SEO is important for this kind of content. You activate default metatags + Schema.org: Recipe. Users will then be faced with several dozens of metatags to fill. And if they search some help clicking the "available tokens" link they will really be... lost in translation.
I think that access of metatags to users should be only an option and by default users should not have access. Metatags is too powerful to leave in the hands of just anyone. I think metatags should behave by default like the other "system" fields (authored, promoted, sticky, alias, ...). I'm not sure but I think this was the case in Drupal 7, anyway I don't remember having to deal this kind of problem in D7.
I was confused by the "admin meta tags" permission scope. Your answer makes it much clearer now. Thank you for taking the time for this.
Damien, I understand that I have to manage permissions but as I wrote "the permission to 'administer meta tags' is set to admin only". Isn't that enough ? With this setting, I don't understand why any other registered user has access to field_metatag too. Secondly, if I remove the field from the user entity, admins will not have access any more. Tercio, what is the benefit of users managing metatags by themselves? Metatags are used mainly for SEO purpose, and seo is not a user's concern.
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
This is still a big problem on Drupal 10.2
Patch from #2 worked for me too on upf-2.0.0. I had to use patch for D-10 compatibility 📌 Automated Drupal 10 compatibility fixes RTBC before to be able to install the module with composer.
Thank you for this plugin which as it says aims to "reduce the need in custom plugins for each content type"! This MR-88 applied and worked perfectly on D10.2.3 and SCS 1.4.4 for transferring feed entities (type feeds_feed). I just had to change the 'owner' field in the export yaml text ; this is hardcoded, to 'uid'. Perhaps you should set the default name of the entity owner to 'uid' that is more likely to meet than 'owner' or at least set a comment close to the corresponding line in yaml to attract user's attention that they may have to adjust the name of this field. I also had to move by hand the 'source' field which is of type 'uri' but this is rather a general issue, not this plugin's concern, as SCS lacks definition for 'uri' field in SingleContentSyncFieldProcessor.
Finally, there was an other entry remaining in the key_value table:
entity.definitions.bundle_field_map entity_message N;
Deleting it seems the error has gone.
erwangel → created an issue.
Finally, I could achieve the exactly same display with formatter "blazy grid" and adjusting the media display mode accordingly with colorbox formatting. So I can have the contextual links displayed close to the media. So there is no problem and you can close the issue. It's just confusing between "blazy media" and "blazy grid". Perhaps make the difference between the two and the corresponding use cases clearer somewhere in the documentation.
erwangel → created an issue.
Yes, dev version (2024, February 11th) removed the media_colorbox display from all media types and the entry has gone from the database config table as expected.
Installation with #31 and migration steps from #25 worked for me going from D7 to D10.
However I got some errors with quiz_results_answers. I had 189 items in d7_quiz_result which were all migrated, but only 1516 items from the 1869 processed by quiz_results_answers were migrated. Perhaps the non migrated items are unfinished quizzes but there is nothing in migrate:messages that could help to debug. Also while rolling back quiz_results_answers , I got this error:
TypeError: Drupal\quiz\Entity\QuizResultAnswer::getQuizResult(): Return value must be of type Drupal\quiz\Entity\QuizResult, null returned in Drupal\quiz\Entity\QuizResultAnswer->getQuizResult() (line 26 of /path_to_site/web/modules/contrib/quiz/src/Entity/QuizResultAnswerEntityTrait.php) #0 /path_to_site/web/modules/contrib/quiz/src/Entity/QuizResultAnswer.php(162): Drupal\quiz\Entity\QuizResultAnswer->getQuizResult()
The other problem I got is with custom fields (I have a media_field in D7 quiz and question nodes) and usual drupal node fields like published y/n, author/date display, promoted, comments, etc or fields added by modules like metatag (essential for SEO), Any idea how to migrate these fields ? It is impossible to recreate all them as they are not accessible by "Re-use an existing field" and not available in the "Create a new field" options list. But perhaps this is not a migration problem but a limitation of the new quiz module concept. In such case, it is preferable to go the old way with quizzes and questions as nodes rather than trying to recreate a whole distinct entity.
You can close this issue. I've just seen that D10 Paragraphs has its own migration for D7 Field_collection, and it works. So no need of field_collection_to_paragraphs module.
Just to say for others coming here that there are two migrations to execute with drush:
- d7_field_collection_type and
- d7_field_collection:name_of_your_field_collection_type
In my case d7_field_collection_type didn't create the corresponding paragraph fields as I was expecting. They had to be created by hand with the same machine_name as in d7 field collection. So my migration process was the following:
1) Import the nodes or entities containing the data related to the fields used in your field_collection_type
2) drush migrate:import d7_field_collection_type
3) Create manually the fields in the paragraph type as explained above
4) drush migrate:import d7_field_collection:name_of_your_field_collection_type
4) Import the entities using this paragraph type
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
This seems to be a Drupal function called to get values of entity fields. I removed all media_gallery specific fields that had been created by the d7 migration such as media_gallery_block_columns, media_gallery_expose_block, media_gallery_image_info_where, media_gallery_block_rows, etc. from the Manage form display (admin/structure/types/manage/media_gallery/fields) and I can now edit gallery nodes with no problem. But is this normal behavior ? Should we consider the issue as solved ?
erwangel → created an issue.
The issue is still present with the dev version (25 Oct 2023). it reports the CckIframe despite the comment in the other issue (D7 to D9 Migration (3327719))
@_shY,
1. yes, it is patch from #11
2. As you can see below, it works after your correction! ["drupal/field_collection"] not ["field_collection"]
From the composer require print out:
- Installing drupal/field_collection (dev-4.0.x 81ea688): Cloning 81ea6884dc from cache
- Applying patches for drupal/field_collection
https://www.drupal.org/files/issues/2023-09-13/field_collection-3297187-... → (3297187-11 - Automated Drupal 10 compatibility fixes)
Thanks @_shY and @RogerB for all your guidance!!!
Hi @_shY,
Still no chance, with your command composer.json was indeed update to allow lenient but still compatibility errors:
Problem 1
- Root composer.json requires drupal/field_collection dev-4.0.x -> satisfiable by drupal/field_collection[dev-4.0.x].
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.1.7 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
In my composer I have :
"require": {
"mglaman/composer-drupal-lenient": "^1.0"
...
},
"minimum-stability": "dev",
"prefer-stable": true,
"config": {
"allow-plugins": {
"mglaman/composer-drupal-lenient": true
...
},
},
"extra": {
"patchLevel": {
"drupal/core": "-p2"
},
"patches": {
"drupal/field_collection": {
"3297187-11 - Automated Drupal 10 compatibility fixes": "https://www.drupal.org/files/issues/2023-09-13/field_>
}
},
"drupal-lenient": {
"allowed-list": ["field_collection"]
}
}
...Well, this is no more a real problem as I could proceed with a manual patching and installation but just trying to understand why lenient is not working to do it the composer way...
erwangel → created an issue.
I'm using Media gallery 2.2.3 with Drupal 10.1.7 but there is no folder named media_gallery_migration. Instead there is media_gallery_import folder and the corresponding module is marked "incompatible with version 10.1.7" by Drupal Extend. So what is the solution we have to migrate media galleries from D7 to the latest D10 ?
Indeed this may be a solution and even better that what I suggested (option to select bundles) but we will still need an option to apply or not to summary which inherits the text format of the main field (body). I think most people don't want to have summaries with plenty links. Also I didn't check how such glossified summaries appear in metatags or in other token based fields.
erwangel → created an issue.
I couldn't install it event with #11 + mglaman/composer-drupal-lenient. "composer.json" was correctly updated with the composer config --merge --json extra.drupal-lenient.allowed-list '["field_collection"]' instruction but the composer require gave the following error:
Problem 1
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.1.6 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- drupal/field_collection 4.0.x-dev is an alias of drupal/field_collection dev-4.0.x and thus requires it to be installed too.
- Root composer.json requires drupal/field_collection 4.0.x-dev@dev -> satisfiable by drupal/field_collection[4.0.x-dev (alias of dev-4.0.x)].
I then tried to remove composer.lock and install mglaman/composer-drupal-lenient globally as indicated on its page but this doesn't seem to be the road as it gave a huge list of require incompatibilities. I finally ported the patch modifications manually and installed the module without composer.
Any new development on CER migration from D7 to D10 ? How can we map cer_left and cer_right (and cer_bidirectional ?). Do they have any relation with the D10 "prepend" and "append" ?
Thank you RogerB for your quick answer. However I still have a problem reported by composer
- Root composer.json requires drupal/field_collection dev-4.0.x -> satisfiable by drupal/field_collection[dev-4.0.x].
- drupal/field_collection dev-4.0.x requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (10.1.6 as 9.5.11).
My question is
1 - should I try it with the option --with-all-dependencies, and in such case is there any risk to import update dependencies to D9.5.11 for other parts/modules that are properly running as D10 compatible ?
2- do I have to remove the line "drupal/core": "10.1.6 as 9.5.11" after installation in order to avoid other modules being downloaded with a D9 version ?
My request is a bit different but concerns the same issue: is it possible to have field_image migration to media entity as an option ? In other words, is it possible to leave image_field as image (and migrate associated items without changing the field type) and only change file(image) field to media file ?
Can not apply #11 because of info.yml is patched for core version requirements (4.0.x-dev requires D9 is patched for D10)
See @
https://www.drupal.org/project/drupalorg/issues/3066468
📌
Packaging info from .info.yml often creates conflicts when patching (ddo)
Active
Is there any other option than manual patching ?
In complement of my previous comment (#15). Although there were no alerts on enabling footnotes, in the drupal modules listing (extend), fakeobjects and ckeditor4 were enabled and and error appeared in the Status report page. It was impossible to uninstall these modules with Drupal's UI but I managed to do it with drush pm:uninstall fakeobjects, ckeditor4 but then a new error appeared in the Status report "Fakeobjects module isn't installed/enabled. Etc."
Patch #13 worked for me and I was able to enable footnotes without the fakeobjects dependency alerts. Unfortunately composer still downloads fakeobjects and ckeditor4 that are useless to D10.
In complement of my previous comment, I could not install any other module (at least feeds which was the next in my list) without having the same problem while enabling the module. I had to uninstall "facets" then I could enable the other modules without the errors above.
I think this is a dependency declaration or a dependency issue. I had the same problem while trying to install fancy_file_delete module which has a dependency to views_bulk_operations. Facets module had been installed and enabled just before. I didn't explore further as I did'nt have timefor this and fancy_file_delete is not essential for what I'm doing, so I gave it up without installing the module.
$ composer require 'drupal/fancy_file_delete:^2.0'
./composer.json has been updated
Running composer update drupal/fancy_file_delete
Loading composer repositories with package information
Updating dependencies
Lock file operations: 2 installs, 0 updates, 0 removals
- Locking drupal/fancy_file_delete (2.0.9)
- Locking drupal/views_bulk_operations (4.2.5)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
- Installing drupal/views_bulk_operations (4.2.5): Extracting archive
- Installing drupal/fancy_file_delete (2.0.9): Extracting archive
Generating autoload files
48 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
No security vulnerability advisories found.
$ drush en fancy_file_delete
The following module(s) will be enabled: fancy_file_delete, views_bulk_operations
Do you want to continue? (yes/no) [yes]:
> yes
[error] Error: Class "Drupal\search_api\Entity\Index" not found in facets_views_data_alter() (line 393 of /home/athan/domains/aktigram.com/public_html/aktigram/igr_10/web/modules/contrib/facets/facets.module) #0 /home/athan/domains/aktigram.com/public_html/aktigram/igr_10/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(545): facets_views_data_alter()
#1 /home/athan/domains/aktigram.com/public_html/aktigram/igr_10/web/core/modules/views/src/ViewsData.php(245): Drupal\Core\Extension\ModuleHandler->alter()
#2 /home/athan/domains/aktigram.com/public_html/aktigram/igr_10/web/core/modules/views/src/ViewsData.php(154): Drupal\views\ViewsData->getData()
... etc
Same problem here. Even with the --with-all-dependencies option
Sorry I hadn't read the README. As I suppose that most people read this file after installing, perhaps you could add an Install section in the presentation page
erwangel → created an issue.
Facing the same problem while enabling "bibcite_entity" before doing a migration (bibcite_migrate). Results in a WSOD and throws same php error mentionned in the initial issue. Using version 3 with Drupal 9.5 and php 8.2. As I understand the release presentation, version 3 is supposed to work D9 or you should change the release page to avoid confusion.
3.0.0-beta3 released 5 July 2023
Works with Drupal: ^8 || ^9 || ^10
✓ Recommended by the project’s maintainer.
Drupal 10 compatibility for PHP 8.1+
erwangel → created an issue.
Typing composer require drupal/geocoder:^3.20 || ^4.0 as per #61 simply installs the geocoder 3 (3.34.0 in my case on Drupal 9.5). Of course geocoder 3 seems to work with Drupal 9.5. But we still need a solution for installing geocoder 4 on Drupal 9 and 10.
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.
erwangel → created an issue.