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.
Nowadays, some of the pieces of project_* depend on solr support being available.
We should enable the solr modules in the profile, or at the very least have a commented out line that people can uncomment to enable the solr modules.
I am unsure how much the site will complain if it can't connect to a local solr server.
Comment | File | Size | Author |
---|---|---|---|
drupalorg_testing_solr_modules.patch | 910 bytes | bdragon |
Comments
Comment #1
dwwYes, in an ideal world, we'd have solr, since there are a lot of drupal.org features that depend on it.
However, I really think the only sane way to handle that dependency is to put *.d.o in a VM and ship that (as per http://groups.drupal.org/node/180874 and friends). Asking people who want to do local d.o dev site stuff per this distro to jump through all the hoops to get a local solr server up and running seems like too much grief to me. I'd rather fix the parts of drupalorg module that assume solr to gracefully degrade if it's not enabled (or offline). For example, let's fix #1077524: drupalorg_search throws fatal error if solr is offline since that's also a problem on live d.o if solr goes down for any reason.
Maybe that's a waste of effort, but I'd sure hate to raise the bar any higher on the 80% of people that want to contribute to d.o and do their own local development and testing who aren't touching anything related to solr.
Or better yet, put the effort into the d.o-in-a-VM thing (since that'd also let people easily dev and test Git-related stuff, too).
But, I don't really want to raise the bar any higher for people trying to use this distro (which is all they need for a lot of things).