Sometimes the conversion takes time based on the plugin used to geocode the fields, which keeps the node save on hold, and the user waiting for the node to be saved. This can get even heavier when webform are used to populate the node's data and include Geo conversion for address fields.
Update geocoder_field_entity_presave() to add items to the queue and be processed via cron at a later time as defined.
Admin option in settings at global level to enable/disable processing via a queue.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
itamair commentedWell ... indeed Geocoding processing takes so long?
How "soo long"??
I personally never experienced more than few seconds (5 at my most) ... unless there is a network or response issue.
I like Drupal Queue API and being using it quite a lot but ...
in this case you basically want to defer a second (Geocoding) part of each Content/Entity save at a later Cron run ... right?
So if Cron runs every 15 mins (or more ...) the Geocoding feedback/outcome would appear/happen (in the Content) 15 mins later (or more)?
It doesn't look the best functional UX to me ... and for sure this should be somehow configurable (not to be the only and default Geocoding behaviour).
Feel free (and welcome) to add more details to your POC here, and eventually a patch/MR ...
Comment #3
joshua1234511Yes, correct
What I meant to say is use Drupal Queue API to process the geocoding.
A scenario where the node is using geocoding and is being created using webform node submissions.
Or in case of headless sites, where forms are used to populate/create entities.
in such a case the user from time outs or has to wait long enough for the process to complete to get the response.
Raised a MR with a POC on the same.
Comment #5
kristen polI added a few comments for nitpicks/typos.
Comment #6
joshua1234511Updated the MR with the requested changes.
Comment #7
itamair commentedNice! ... & thanks both of you.
I tested and this works nice/great.
I just added 2 refinements commits (actually I removed the GeocoderProcess abstract class that doesn't look needed to me).
Marking this as RTBC ...
Are you ok with merging this into Dev branch and making it part of the new Geocoder release?
Comment #8
joshua1234511Yes, this can be merged and made available for dev branch.
Just a note, it would be good to have test cases for the same, either in this same issue or a new issue linked to this.
Comment #9
itamair commentedeh ... and would you provide test cases also?
Usually it is a task for the developer ...
Comment #10
joshua1234511Was going through the test case in module, it does have a kernel random test added.
For the above case it can be extensive and dependency.
We can go head and get this functionality included.
Comment #11
itamair commentedThanks a lot @joshua1234511 ... sincerely since I took over this Geocoder maintenance (from Drupal 8) I didn't really cared updating and extending the test coverage base (not enough time also for that).
Please go ahead if you feel comfortable with that ... in the proper spirit of the Drupal community.
Comment #12
itamair commentedPlease note that new release geocoder 8.x-3.29 made some amends on the existing GeocoderTest ...
Comment #16
dieterholvoet commentedI started a new branch from 4.x and improved the implementation, both in the old 3.x and new 4.x branch:
drupal_register_shutdown_function. Instead, I added a check that only saves the entity if any values were changed, also preventing infinite loops but without needing hacky code.Comment #17
itamair commentedOk. QA and Reviewed this on, merging into 8.x-4.x-dev ...
Comment #18
itamair commented