Is there a way to make Solr searches case insensitive? It seems to be dependant on wether the filesystem is case sensitive or not. Our local test environment is case insensitive, yet production server is, thus causing problems.

Right now, we've come up with a quick fix for this issue by adding extra altered searchterms. I am wondering if there is a better way to do this?

$query = new BaseQuery();
$query->setStart($start);
$query->setRows(12);
$query->setSpellcheck(true);

// TMP CASE INSENSITIVE FIX
$query->addTerm(strtoupper($searchTerm));
$query->addTerm(ucfirst($searchTerm));
$query->addTerm(strtolower($searchTerm));

Maybe someone can explain how to do this properly.

Describe the bug

Creating and attempting to run the SolrIndexJob in the CMS' "Jobs" section will result in errors becuase PCNTL is required by the SolrIndexTask which is never going to be available in any non-CLI, PHP SAPI.

To Reproduce

• Login to the CMS
• Select SolrIndexJob from the "Job ot create" dropdown in the "Jobs" admin
• Attempt to run it
• Observe error in browser's network tab

Expected behavior

SolrIndexJob should not appear with a "Run" icon in the Jobs GridField. It is only invoked by ProcessJobQueTask via the CLI

Describe the bug

• PHP7.2 + Solr 8.2 + v4.3.3 + Module 1.0-beta3 + Ubuntu Bionic (Vagrant + LXD)y
• Run sudo ./vendor/bin/sake dev/tasks/SolrConfigureTask
• Result:

ERROR [Emergency]: Uncaught LogicException: No classes or config to index found!
IN GET dev/tasks/SolrConfigureTask
Line 184 in /vagrant/vendor/firesphere/solr-search/src/Indexes/BaseIndex.php

My BaseIndex subclass has not changed since I used 7c78fb8c62618f, so the module's API must've changed?

Looking back at BaseIndex.php @ 7c78fb8c6261 and I'm non the wiser...

To Reproduce

• Install ^1.0
• Run SolrConfigureTaskl
• Observe errors to do with missing config

Expected behavior

No errors.

E.g: https://lucene.apache.org/solr/guide/8_5/basic-authentication-plugin.html

Example yaml config:

Firesphere\SolrSearch\Services\SolrCoreService:
  config:
    endpoint:
      localhost:
        username: 'solr'
        password: 'SolrRocks'

Most of the module does work if you hack around the parts that don’t work. These are:

• SolrCoreService::getSolrVersion()
• SolrLogger

I’m not sure if it’s best to try to hack in some auth into these specific cases, or try to make them use the main Solarium instance that does support auth.

@Firesphere I know you said you preferred an $escape argument, but I wanted to show how simple the change set would be for accepting Criteria objects as filters. Usage example:

$criteria = Criteria::where('Document_Embargo')
    ->greaterThanEqual('NOW');
$query->addExclude('Document_Embargo', $criteria);

This also means we can leave the existing escaping in QueryComponentFactory untouched

Documentation improvement to be made to 03-Usage.md. Please see the diff here: https://github.com/Firesphere/silverstripe-solr-search/compare/master...phptek:improved-docs

Hi there and thank you for taking the time and effort to make a Pull Request

No, seriously, we are delighted you made time and effort to help us, even in the smallest way!

Please check the following

• [x] Have you opened an issue to discuss the feature and agree its general design?
• [x] Do you have a use case and, ideally, an example program using the feature?
• [x] Do you have tests covering 90%+ of the feature code (and, of course passing)
• [x] Have you written complete and accurate doc comments?
• [x] Have you updated the README or docs where needed?
• [x] Code is readable
• [x] Code is tested
• [x] I've read the Code of Conduct (Or, at least, I do believe I agree with it)
• [x] Frontend features don't look completely uncared for
• [x] Code is PSR-2 compliant
• [x] I'm fairly sure this is useful
• [x] I'm not just making this PR for HacktoberFest
• [x] You rock. Thanks a lot.

Sorry, not sure if this is a bug... But at least it's bugging me...

Using setRows on BaseQuery, causes Results to get doubled.

Code that causes this: QueryComponentFactory.php line: 92

// Double the rows in case something has been deleted, but not from Solr
$this->clientQuery->setRows($this->query->getRows() * 2);

Question Why are the results doubled. Wouldn't it be easier to clean up the Solr in the indexing task?

PaginatedMatches PaginatedMatches is not working correctly, also doubles the result. Can be fixed in template by adding the same .Limit(9) again. Not sure if that was the intended way of handling things.

$query = new BaseQuery();
$query->setStart($start);
$query->setRows(9); // causes 18 results

<ul>
   <% loop $Results.Limit(9) %>
      <li>
         <% include SilverShop/Includes/ProductGroupItem %>
      </li>
   <% end_loop %>
 </ul>
<% with $Results %>
    <% include Pagination %>
<% end_with %>

Thank you for this nice module!

Is your feature request related to a problem? Please describe. The version of Solarium used does not support PHP8. More recent versions do, and I've installed it using an alias "solarium/solarium": "6.2.1 as 5.2.0"

Describe the solution you'd like Updating Solarium to ^6.0 allows the software to run on PHP8

Describe the bug

For some reason SolrCoreService::updateItems() is being passed null as the $items param, when running the dev/tasks/SolrClearDirtyClasses from the CLI and browser. When this happens I see the following error:

ERROR [Notice]: Trying to get property 'ClassName' of non-object IN GET dev/tasks/SolrClearDirtyClasses Line 150 in /vagrant/vendor/firesphere/solr-search/src/Services/SolrCoreService.php

To Reproduce

• [OK] Configure
• [OK] Index
• [OK] Search
• [OK] dev/tasks/SolrClearDirtyClasses

Expected behavior

No errors are observed and I can run the dev/tasks/SolrClearDirtyClasses task without issue.

Additional context

Interestingly, running the task still seemed to clear out records with dirty IDs, with ref to the CMS UI.

Describe the bug

PHP 7.2 + v4.4.3 + Solr 8.20 + dev-master#7c78fb8c62618fbd50c926e5772457c827a6f4f0 (If you can convince me the latest build will also fix this issue, I'll update the version - OK, I tried ^1.0-beta3, different errors: #158)

Uable to save config anywhere other than a local .solr dir.

Attempting to use a different dir for storing Solr's core data, defined in YML results in a local .solr dir being re-created and populated instead regardless.

To Reproduce

Set the site into "test" mode and use the following local YML config, and run the Configure task:

---
Name: my-search
After: 'SolrSearch'
---
Only:
  environment:
    - live
    - test
---
Firesphere\SolrSearch\Services\SolrCoreService:
  config:
    endpoint:
      myhostname:
        host: localhost
        port: 8983
        timeout: 10
        # set up timeouts
        index_timeout: 10
        optimize_timeout: 100
        finalize_timeout: 300
        http_method: 'AUTO'
        # commit within 60ms

Expected behavior

Cores and metadata are persisted to "'/opt/solr/server/solr" and not ".solr"

Hi there and thank you for taking the time and effort to make a Pull Request

No, seriously, we are delighted you made time and effort to help us, even in the smallest way!

Please check the following

• [ ] Have you opened an issue to discuss the feature and agree its general design?
• [ ] Do you have a use case and, ideally, an example program using the feature?
• [ ] Do you have tests covering 90%+ of the feature code (and, of course passing)
• [ ] Have you written complete and accurate doc comments?
• [ ] Have you updated the README or docs where needed?
• [ ] Code is readable
• [ ] Code is tested
• [ ] I've read the Code of Conduct (Or, at least, I do believe I agree with it)
• [ ] Frontend features don't look completely uncared for
• [ ] Code is PSR-2 compliant
• [ ] I'm fairly sure this is useful
• [ ] I'm not just making this PR for HacktoberFest
• [ ] You rock. Thanks a lot.

Hi there and thank you for taking the time and effort to make a Pull Request

No, seriously, we are delighted you made time and effort to help us, even in the smallest way!

Please check the following

• [ ] Have you opened an issue to discuss the feature and agree its general design?
• [ ] Do you have a use case and, ideally, an example program using the feature?
• [ ] Do you have tests covering 90%+ of the feature code (and, of course passing)
• [ ] Have you written complete and accurate doc comments?
• [ ] Have you updated the README or docs where needed?
• [ ] Code is readable
• [ ] Code is tested
• [ ] I've read the Code of Conduct (Or, at least, I do believe I agree with it)
• [ ] Frontend features don't look completely uncared for
• [ ] Code is PSR-2 compliant
• [ ] I'm fairly sure this is useful
• [ ] I'm not just making this PR for HacktoberFest
• [ ] You rock. Thanks a lot.

Describe the bug The module will not install on a PHP 8.0.x installation without some persuasion

To Reproduce Steps to reproduce the behavior:

1. Try to install composer require firesphere/solr-search
2. Observe php-http/guzzle6-adapter[v2.0.0, ..., v2.0.1] require php ^7.1 -> your php version (8.0.25) does not satisfy that requirement.
3. Install this instead: composer require php-http/guzzle6-adapter 2.0.2 (this specific tag added "untested" PHP8.0 support)
4. Then install Guzzle 7, as 6 composer require guzzlehttp/guzzle 7.5.0 as 6.5.7
5. Finally composer require firesphere/solr-search 2.0.0-rc1

Expected behavior I should be able to install the module when Guzzle 7 is present, but the project forces the install of 6 because the guzzle6-adapter is pulled in as a dependency. If the project can use 7 (as indicated in the requirements), the parent project should be responsible for using the guzzle6-adapter if they want to use 6

Context Using php:8.0-apache-focal container

Bumps terser from 4.8.0 to 4.8.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hi there and thank you for taking the time and effort to make a Pull Request

No, seriously, we are delighted you made time and effort to help us, even in the smallest way!

Please check the following

• [ ] Have you opened an issue to discuss the feature and agree its general design?
• [ ] Do you have a use case and, ideally, an example program using the feature?
• [ ] Do you have tests covering 90%+ of the feature code (and, of course passing)
• [ ] Have you written complete and accurate doc comments?
• [ ] Have you updated the README or docs where needed?
• [ ] Code is readable
• [ ] Code is tested
• [ ] I've read the Code of Conduct (Or, at least, I do believe I agree with it)
• [ ] Frontend features don't look completely uncared for
• [ ] Code is PSR-2 compliant
• [ ] I'm fairly sure this is useful
• [ ] I'm not just making this PR for HacktoberFest
• [ ] You rock. Thanks a lot.

Hi there and thank you for taking the time and effort to make a Pull Request

No, seriously, we are delighted you made time and effort to help us, even in the smallest way!

Please check the following

• [ ] Have you opened an issue to discuss the feature and agree its general design?
• [ ] Do you have a use case and, ideally, an example program using the feature?
• [ ] Do you have tests covering 90%+ of the feature code (and, of course passing)
• [ ] Have you written complete and accurate doc comments?
• [ ] Have you updated the README or docs where needed?
• [ ] Code is readable
• [ ] Code is tested
• [ ] I've read the Code of Conduct (Or, at least, I do believe I agree with it)
• [ ] Frontend features don't look completely uncared for
• [ ] Code is PSR-2 compliant
• [ ] I'm fairly sure this is useful
• [ ] I'm not just making this PR for HacktoberFest
• [ ] You rock. Thanks a lot.