Thank you for your your work on this module. I've used it quite a bit!
I'm currently working on an event subscriber that alters the search parameters based on different criteria. In the event dispatchers, there is limited context available to the event for determining what triggered the search. In my example, I need the search id $this->query->getSearchId() for conditional logic.
Do you have thoughts on how this should be provided? I'm happy to write a patch to set the protected property on the event, but wanted to get feedback before doing so.
If I don't hear back, I may take a crack at it for review.
| Comment | File | Size | Author |
|---|
Issue fork elasticsearch_connector-3075907
Show commands
Start 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:
Comments
Comment #2
andyg5000I needed the patch anyway ;)
Comment #3
andyg5000First patch missed updating a call to
new BuildSearchParamsEvent()Comment #6
mparker17I've created merge request !120 from the patch in #3, and fixed the merge conflicts. Then, I hid the patch files, because Testbot no longer tests patch files, and the patch file no longer applies cleanly. If you need an updated patch file, you can download one from the merge request. For what its worth, the team at Lullabot recommends using local copies of patch files: from personal experience, local patch files often makes composer run faster and more reliably.
I'm in the middle of preparing for a release, more specifically, ensuring that as many patches as possible will apply on the new release, i.e.: by resolving merge conflicts, i.e.: hopefully saving people time when the new release comes out.
This means I haven't had a chance to review the code. However, a brief glance at the code shows that there are no tests, and I cannot merge without tests, so I've added the "Needs tests" tag, and moved it back to "Needs work". Automated tests ultimately benefit you. They ensure that future changes (i.e.: by other contributors) will not break the functionality that you (or your client) depends on. If you need help writing tests, please ask (although I have a large backlog of tickets to work on, and I volunteer my time on the 8.x-7.x branch, so I cannot guarantee a speedy response - thanks in advance for understanding)!
We should also update the issue summary before release, so I've added the "Needs issue summary update" tag. An issue summary helps a maintainer understand why a change was necessary ("Problem/Motivation"), why you chose a particular solution ("Proposed resolution"), and how to test the change manually ("Steps to reproduce"). After an issue is fixed, a good issue summary documents what changed and what could be impacted ("User interface changes", "API changes", "Data model changes"), for people upgrading.
Comment #7
mparker17Note that PHPCS is showing the following lints...
PHPCS wants these functions to be named
getSearchApiQuery.These functions aren't used in the patch. I assume @andyg5000 has a custom module or patch that uses these functions? If so, then I'll let @andyg5000 fix this lint, so that they can update their custom module or patch at the same time.