Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Fatal error: Only variables can be passed by reference in \sites\all\modules\apachesolr\search_api\includes\processor.inc on line 171
(I'm using Taxonomie autoselect fields)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | indexing.jpg | 72.51 KB | IT100 |
Comments
Comment #1
IT100 CreditAttribution: IT100 commentedThere's no Error when I set the field Solr Server Index -> Field (Taxonomy) to String.
Setting this to "Full text" then i get the above error.
Setting it to string does make the index work. However, no text is found when using the search box.
Screenshot in attachment.
Kind regards,
Chris.
Comment #2
IT100 CreditAttribution: IT100 commentedI also get this error:
Warning: Invalid argument supplied for foreach() in SearchApiAbstractProcessor->processField() (line 170 in \sites\all\modules\apachesolr\search_api\includes\processor.inc).
Comment #3
drunken monkeyUrgh. Yes, sorry, the processing component is one of the messier (and, therefore, more prone to bugs) parts of the module. Not quite as awefully to debug as the database backend, but probably second-worst by far.
However, I think that — against all odds — I managed to fix this (and maybe some other nastinesses in there). Please verify with the latest CVS version.
Comment #4
IT100 CreditAttribution: IT100 commentedok, nice work!!
Solved.
I'm willing to contribute if interested. I haven't had a look at the code though.
Just give me time to work through it, in that case.
Regards & thanks,
chris.
Comment #5
drunken monkeyHelp is always appreciated, of course! As you can see, there are a lot of open issues, even some bug reports. Things that change the architecture would of course be dangerous to do, as those will really need to match my personal taste, but there are still enough opportunities if you want to contribute.
So yes, if you want, take a look at the code and then at issues that you might be able to solve. Assigning them to yourself would of course help to avoid conflicts.
If you would like that better, I could also scan the list myself and suggest a few issues that should be doable for someone new to the code.
Comment #6
IT100 CreditAttribution: IT100 commentedOk Thomas, suggest me an issue.
As I'm going to have to dive into the code first, feel free to solve the issue yourself if you find it needs urgent attention. I'll understand.
C.
Comment #7
drunken monkeyI'm proud to say that there are no urgent issues, currently. ;) However, suggesting an issue isn't that easy, as I see, since most of them are either rather hard (or at least require thorough knowledge of the module code) or architectural changes, which I of course don't want to "outsource".
But, let's see …
There are two issues with the database backend, which I'd love to get fixed. However, they probably are a rather aweful introduction to the module, as the database backend is really, really complicated and I myself am scared to look at those two issues … But if you are, by any chance, exceptionally good with the database layer and not scared of pretty complex queries, these would probably be your best options:
- #946286: Multi-term fulltext filter results in exception
- #1013632: Support facets for database based searches
If you are more at home with cron queues or the Batch API, there is an issue that shouldn't be too hard to handle (at least everyone's been telling me that ;)), would still be a great addition to the module and also would make a good introduction, I think:
- #946624: Use a cron queue for indexing
Finally, there are two data alterations that could (or should) be added to the module, one probably rather hard, the other should be feasible.
- #939430: Integrate Rules conditions to filter indexed entities If you know Rules, you could ask fago to provide with a few hints on how to do this — this would certainly be a great addition to the Search API, as it would give a lot more flexibility to the indexing process.
- #914702: Add "search" view mode for all entities This one should be a lot easier. Ignore most of the issue content, it's just this: add a data alteration that creates a field with the output of
entity_view(), and a form for selecting the view mode to use.All things considered, I'd probably suggest the middle one (and that one is actually two separate issues, so you can also do just one of them), as it is mostly about using core features, but still goes a bit into Search API functionality. And, as said, it would be a great addition.
But pick whichever you like, help with any of these issues would be very much appreciated. :) And in no case there seems to be a danger of me needing to fix it urgently.