My Drupal 6 site uses 3 custom node types that are hierarchically organized: page, book, library. I want to use Solr to index and search the content.
I want the search to return only Book nodes in the results.
But I want the search to use the contents of children (pages) and parents (libraries) when performing the search.
Can Solr be configured to index & search in this way?
Thanks!
You are going to have a couple of issues with this:
Solr isn't hierarchical by nature, it's denormalized so indexing a heirarchy is hard.
You're going to have to figure out how to boost various terms/fields based on where in the hierarchy they are (is the library more important than the book, so to speak).
Drupal has a specific configuration related to nodes and modifying that, by default, wouldn't be the easiest.
The Solr implementation is tightly tied to the database, so modifying the configuration would probably take a lot of effort on your part.
I would recommend you don't try to implement this, but if you did you could look at the Apache Solr Attachments module. You would have to do something similar... basically:
hook_modify_query to modify the actual indexing of the node
custom theme your search results to display this hierarchy
Or you could create a single giant field with a bunch of searchable text and use that as part of your searches.
Related
I need to implement a central search for multiple plone sites on different servers/machines.If there is a way to select which sites to search would be a plus but not the primary concern.Few ways I came upon to go about this:
-Export the ZCatalog indexes to an XML file and use a crawler periodically to get all the XML files so a search can be done on them,but this way does not allow for live searching.
-There is a way to use a common catalog but its not optimal and cannot be implemented on the sites i am working on because of some requirements.
-I read somewhere that they used solr but i need help on how to use it.
But I need a way to use the existing ZCatalog and index and not create another index as i think is the case with using solr due to the extra overheads and the extra index required to be maintained.But will use it if no other solution possible.I am a beginner at searching so please give details as much as possible.
You should really look into collective.solr:
https://pypi.python.org/pypi/collective.solr/4.1.0
Searching multiple sites is a complex use case and you most likely need a solution that scales. In the end it will require far less effort to go with Solr instead of coming up with your own solution. Solr is build for these kind of requirements.
As an alternative, you can also use collective.elasticindex, an extension to index Plone content into ElasticSearch, for this.
According to its documentation:
This doesn’t replace the Plone catalog with ElasticSearch, nor
interact with the Plone catalog at all, it merely index content inside
ElasticSearch when it is modified or published.
In addition to this, it provides a simple search page called
search.html that queries ElasticSearch using Javascript (so Plone is
not involved in searching) and propose the same features than the
default Plone search page. A search portlet let you redirect people to
this new search page as well.
That can be and advantage over collective.solr.
Just started using Drupal and tried to understand the core concepts. I have a developer background but I would like to use Drupal as a site builder and not digging into the code.
I'm trying to build a website which lists various vendors. One could be a Restaurant, another can be Photographer and other possible services (I have like 15 different ones).
They all have some things in common like Title, a Location (used Taxonomy/Vocabulary for that), description, image gallery, address, website, office hours and so on.
But they also have some custom fields. Restaurants can have fields like Facility options:Parking, Smoking area, etc or Capacity; Photographers can have others.
So there are lots of fields which are common for each vendor and some are are unique per each vendor.
What's the best way to implement this kind of structure as a Site builder?
I tried using Entities via ECK (Entity Construction Kit) and defining Entity types (as Vendor) and Bundles (as specific Vendors) but then I'm really limited in defining the common fields on Entity type level since Properties does not seem to be flexible in this regard, meaning that I cannot define them as normal fields and can't associate to them various widgets but only as a text input. Not sure if this a limitation of ECK or of Drupal 7 itself?
On the other hand I see the option of creating normal Content types for each kind of vendor which seems like alot of repetitive work, not sure if this is the right way (that's my only option at the moment)?
Maybe I should start learning more of Drupal and do some coding to create specific entity types? - but this means being more than a site builder. Since it will be a big project will this save me of some trouble later on or you see that I can accomplish the task easily without this extra effort?
Also by coding I'm not sure if there are easy ways of defining fields/widgets for Entity type Properties.
I would later on want to use faceting as well for filtering which will be based both on the fields which are common and unique for each vendor type, not sure if this is an important factor when creating the structure.
Any feedback is appreciated!
I have setup a Solr server, now, I have two sites that I want to index and search using SolrNet.
How do I differentiate the two sites' content in Solr?
You may want to take a look at this document: http://wiki.apache.org/solr/MultipleIndexes
I think the best approach is to use Multiple Solr Cores.
Another option is you can simply add a new field that indicates the item's Web site. For example, you can add a field called type.
Searches on website1.com would require you to filter on the type field.
&fq=type:website1.com
That way you only need to deal with one core and one schema.xml file. This works if the pages of both sites have a very similar field set, and it will make it easier to search across both sites if you plan on doing that.
http://wiki.apache.org/solr/MultipleIndexes#Flattening_Data_Into_a_Single_Index
how does one implement partial keyword search in drupal since by default drupal does not search for partial keywords.
If you want to search on a single field, you can create a view with an exposed filter and set it to "contains" that will allow partial keyword searching.
You can also patch the core search module, which is going to make maintenance a pain in the backside later on. Patch at http://drupal.org/node/103548 .
The Porter Stemmer module attempts to extrapolate partial searches into full keyword matches (http://drupal.org/project/porterstemmer)
For real fine-grained control over search, you'll need to ditch the Drupal core search functionality completely and upgrade to Apache SOLR search, which is exceptionally powerful but requires a fair amount of configuration.
You can also drop Drupal search entirely and use a Google Custom Search Engine if you just want to do text matches across the site (http://drupal.org/project/google_cse)
I'm creating a web application and I just want to know how to think about Drupal's db coming from an MVC background.
I have tables to represent people's data such as SSN, First Name, Last Name, Zip Code, Address, Language, Location. Now on the front end I want to create a form to populate this information for a bunch of subjects (people). I have my database normalized so the Zip Code has its own table (with a foreign key link to the person table). The "person" table has stuff such as First Name, Last Name, Address etc... and the "language" table will have the different language abbreviations (again with a foreign key back to the person table).
I would like to know how to move something like this to drupal's schema. I know I could create my own tables and link them back to the "node" table and then I guess build my forms to accept user input...but is this the suggested way to do it? I was looking at webform, but it seems this should be used for simpler forms where the database isn't normalized and everything is just stored in one large table. I'm not sure, but I would definitely love to hear what you guys think...and if you could point me to some resources that'd be great.
Drupal is flexible enough that you can create whatever tables you want and then write code to link them back to the node table. However doing this will mean that you end up with a lot of code which is very specific to your schema, and is not very interoperable with other Drupal modules.
You will find that you get on better with Drupal if you mostly do things the Drupal way. And only go for a very customized solution where you are doing something which isn't covered by standard Drupal modules.
For example you may find that the profile module fits your needs as far as standard information about people goes. The location module (specifically user location) will cover users addresses. By using these modules you are more likely to find other modules which work with them in future and overall you will find you have less code to write.
One thing you may find useful is the migrate module for getting your existing data into Drupal.
It sounds like you're just storing information and the subjects (people) won't be users of the Drupal site.
Leveraging the node and CCK modules to make this happen would remove most of the development work. For example, each of your tables (e.g. Person, Zip Code, Language) could be represented by a content type with a number of fields. The foreign keys would be represented by node reference fields. So the Person content type may have one or more node references to nodes of type, Language.
The migrate module seems well used (626th most popular of 4000+ modules used in at least 10 distinct Drupal sites), but it may be easier to whip up your own migration script, but I'm not familiar with either your situation, your familiarity with Drupal's API, or the migrate module.
Node reference fields display as links to the referenced nodes by default, but can be themed to load and display the referenced node instead (e.g. displaying Language information in a Person node). There's a handy screencast that illustrates how to go about theming node reference fields to load and selectively display the referenced nodes' contents.
Coming from an MVC background you may not like how Drupal stores data in the DB.
Profile module was mentioned, but I find I get more flexibility with Content Profile and CCK combined.
I've written some migration scripts before from Coldfusion to Drupal, and it's not too involved.