DEP Move solr-php-client with PHP 8.1 compatbility to thirdparty folder#320
DEP Move solr-php-client with PHP 8.1 compatbility to thirdparty folder#320emteknetnz wants to merge 1 commit intosilverstripe:3from
Conversation
emteknetnz
force-pushed
the
pulls/3/thirdparty
branch
from
25922b0 to
a60aa94
Compare
emteknetnz
force-pushed
the
pulls/3/thirdparty
branch
from
a60aa94 to
8123a2d
Compare
|
Potentially time to migrate to https://github.com/solariumphp/solarium ? I think I looked into this quite some time ago, not sure what happened to it, though. |
|
That seems like substantially more work. There was only a single line required to get this php 8.1 compatible (at least according to unit tests). |
GuySartorelli
left a comment
GuySartorelli
left a comment
There was a problem hiding this comment.
I've checked, and the only difference between thirdparty/solr-php-client and the v1.0.0 tag of the package in github is the change made in the PR referenced in the description.
This module honestly feels a bit legacy at this point - personally I'm okay with taking the less-effort approach in this case, but given there may be some controversy I'll leave it for someone else to merge.
| */ | ||
| public function process() | ||
| { | ||
| if (!DB::is_active()) { |
There was a problem hiding this comment.
What prompted this? It doesn't seem related to the rest of the PR?
There was a problem hiding this comment.
PR that went into 3.9 though wasn't merged up - #318
|
Yeah, I think that moving to solarium should be a long-term project and not a way to solve php 8.1 compatibility. We should probably aim not to be reliant on libraries that are abandoned or haven't seen any effort in 6 years! |
maxime-rainville
left a comment
maxime-rainville
left a comment
There was a problem hiding this comment.
My preference would be to do a sminee/phpunit and fork the repo on the Silverstripe domain and stick a big nasty warning at the top that it's not supported. But this solution could work as well.
FYI Silverstripe Ltd has moved on to using Elastic for search in its new project. We'll keep maintaining this module because a lot of people are still using it, but it's unlikely we'll update it to work with the later version of Solr.
| "php": "^7.4 || ^8.0", | ||
| "silverstripe/framework": "^4.10", | ||
| "monolog/monolog": "~1.15", | ||
| "ptcinc/solr-php-client": "^1.0", |
There was a problem hiding this comment.
If we decide to include the ptcinc/solr-php-client into this module, the composer file should have a provide key to make explicit that this other packages has been bundled in.
If we decide to fork the module, the fork should have the provide key.
There was a problem hiding this comment.
I don't have sufficient permissions to fork to the silverstripe account. If you'd like to go this route could you please fork it.
There was a problem hiding this comment.
fork here: https://github.com/silverstripe/solr-php-client - I can delete it if we decide we don't want it
|
|
Thanks for forking the module @dhensby - we'll use that. I've created a follow up PR to fix a couple of things on the fork |
4 participants
Issue silverstripe/silverstripe-framework#10250
I attempted to update this upstream but got no response. Looks abandoned. So just adding to thirdparty folder instead.
The COPYING.md file says it's ok to copy this, as long as copyright is retained
Includes a fix to add method attribute to
Document::getIterator()for PHP 8.1 compatibility