Jan 22 2019
Jan 22

[embedded content]

Over the years I’ve written a fair bit about Drupal and its modules, but all the videos and tutorials focused on a single module or topic.

So I decided to try something different and record a video where I build a whole website in a single go. I recorded the video in one night and only stopped recording to get a drink.

In this video, which is over 3 hours long, I’ll teach you how to build a basic directory website. We’ll start right at the beginning by setting up a local Drupal site for this we’ll use DDEV-Local. Then we create content types, create a sub-theme, create a few custom views, a search page, media management functionality and so much more.

I’ve broken out the video into sections below with timecodes and extra resources. For the content below to make any sense you should follow along by watching the video.

Enrollments are now open for the Drupal 8 Site Building Bootcamp: 7-week program, 2 live lectures per-week. Enroll NOW!

1. Set up Local Drupal Site

Time: 00:01:33 – 00:09:49

Download Drupal

We first need to download the Drupal codebase, run the following Composer command:

composer create-project drupal-composer/drupal-project:8.x-dev SITE_NAME --stability dev --no-interaction

Replace SITE_NAME with the name of the folder.

Tip: If you want to speed up Composer then install the prestissimo plugin. This is a Composer plugin and has nothing to do with Drupal.

Configure DDEV-Local

We’ll use DDEV-Local to run our local Drupal 8 site. It requires Docker to run, and you can get the install instructions from their documentation site.

Once you’ve installed DDEV-Local go to your Drupal site within the terminal and run:

ddev config

You’ll be prompted with a few options, and it’ll configure the environment.

MacOS Users: If you’re using macOS make sure you set webcache_enabled to true in the ddev config.yml.

Go to your Drupal codebase and open .ddev/config.yml and change:

# From:
webcache_enabled: false
# To:
webcache_enabled: true

Time: 00:06:58

Links:

2. Create Content types and Taxonomy Vocabularies

Time: 00:09:50 – 00:29:08

Just like on any Drupal site we need to build the data model: content types and taxonomy vocabularies.

Content Types

Listing:

  • Body
  • Email
  • Listing categories
  • Logo
  • Website

Blog:

  • Body
  • Comments
  • Featured image
  • Tags
  • Blog categories

Taxonomy Vocabularies

  • Listing categories
  • Blog categories

Links:

3. Modify Content types

Time: 00:29:08 – 00:41:20

Once the content types have been created we’ll need to modify them. For this, we’ll use Display Suite.

To install Display Suite, run the following command:

composer require drupal/ds

If you’re keen to learn more about Display Suite check out our following tutorial series:

  1. How to Customize Content Pages
  2. How to Use Display Suite Fields
  3. How to Use Switch View Mode Sub-module
  4. Webinar: Customize Content Pages using Display Suite in Drupal 8

4. Create Bootstrap Sub-theme

Time: 00:41:22 – 01:01:40

We’ll use the Bootstrap theme on the site, and we’ll create a basic CDN sub-theme.

If you need step-by-step instructions on creating a Bootstrap theme, then read our “Getting Started with Bootstrap in Drupal 8“.

Install the theme using this command:

composer require drupal/bootstrap

Please note: The Bootstrap theme (as of this writing), only supports Bootstrap 3, not 4. If you need a Bootstrap 4 theme look at Barrio or Radix.

We have a tutorial on Barrio called “Getting Started with Bootstrap 4 using Barrio in Drupal 8“.

Bootstrap Layouts

The Bootstrap Layouts module ships a bunch of prebuilt layouts for Drupal 8. We’ll use these layouts in Display Suite.

composer require drupal/bootstrap_layouts

If you want to learn more about Bootstrap Layouts, then check out our tutorial “How to Implement Layouts using Bootstrap Layouts in Drupal 8“.

Links:

5. Block and Menu System

Time: 01:01:42 – 01:15:03

Once we’ve created our sub-theme, we’ll create four new footer regions.

Add the following into your theme’s .info.yml:

regions:
  footer_one: 'Footer one'
  footer_two: 'Footer two'
  footer_three: 'Footer three'
  footer_four: 'Footer four'

Add the following into page.html.twig (make sure you override the Twig file):

<div class="footer footer-grid {{ container }}">
    <div class="row">
        <div class="col-sm-3">
            {{ page.footer_one }}
        </div>
        <div class="col-sm-3">
            {{ page.footer_two }}
        </div>
        <div class="col-sm-3">
            {{ page.footer_three }}
        </div>
        <div class="col-sm-3">
            {{ page.footer_four }}
        </div>
    </div>
</div>

6. Views

Time: 01:15:03 – 01:38:10

We need to create a few custom Views for our website. The first one, which lists blog content is fairly simple.

The second, which is “My listing” is complicated because you have to deal with contextual filters.

Read our tutorial “Add Custom Tab to User Profile Page with Views in Drupal 8” for a step-by-step tutorial on implementing this type of View.

7. Build Search page using Search API

Time: 01:38:10 – 02:10:32

We’ll use the Search API and Facets module to build our custom listing search page.

Download the required modules using the following command:

composer require drupal/search_api drupal/facets

Watch our webinar “How to Build Custom Search Pages in Drupal 8” which covers the core Search module and Search API.

Links:

8. Media Management

Time: 02:10:55 – 02:30:54

We now need to add media handling functionality to the directory site.

Run the following Composer command to download the required modules:

composer require drupal/entity_embed drupal/ctools drupal/entity_browser drupal/inline_entity_form

For a detailed tutorial on configuring all this stuff and more go to “Managing Media Assets using Core Media in Drupal 8“. And there’s a video: “Live Training: Managing Media Assets using Core Media in Drupal 8“.

9. Roles and Permissions

Time: 02:30:56 – 02:51:10

Now we need to create a role called “Contributor” and configure its permissions.

To allow users to publish/unpublish listings, you’ll need to use Override Node Options.

Install it using the command below:

composer require drupal/override_node_options

The “Contributor” role needs the following permissions:

  • Use the Contributor HTML text format
  • Image: Create new media
  • Image: Delete own media
  • Image: Edit own media
  • Listing: Create new content
  • Listing: Delete own content
  • Listing: Edit own content
  • View own unpublished content
  • Override Listing published option

Create Registration Page

To create a registration page, we’ll use Multiple Registration.

Run this command to install it:

composer require drupal/multiple_registration

Read our “Create Individual Registration Forms using Multiple Registration in Drupal 8” for a detailed tutorial on the module.

Links:

10. Paragraphs

Time: 02:51:10 – 03:06:45

We’ll use the Paragraphs module to allow an editor to add a Bootstrap Jumbotron to a page.

Install the module by running:

composer require drupal/paragraphs

If you want to learn more about Paragraphs, then check out our free course, “Build Edge-to-edge Sites using Paragraphs in Drupal 8“.

Links:

11. Webform

Time: 03:06:47 – END

We’ll use the Webform module to build functionality which sends an email to the owner of the listing.

You can install Webform by running:

composer require drupal/webform

Below is the token which is used:

[webform_submission:submitted-to:author:mail]

Links:

Summary

I don’t expect many people to make it to the end of the video but if you did, congratulations! I hope you learnt something new by seeing how a Drupal site is built.

We can often learn a lot just by watching a developer build something.

Ivan Zugec

About Ivan Zugec

Ivan is the founder of Web Wash and spends most of his time consulting and writing about Drupal. He's been working with Drupal for 10 years and has successfully completed several large Drupal projects in Australia.

Sep 07 2016
Sep 07

A recent project involved the use of the Simple Hierarchical Select module to input category data for a particular content type. Simple Hierarchical Select provides a clean way of browsing hierarchical vocabularies to easily add taxonomy terms to nodes.

An initially tricky user interface problem to utilise this module with Search API and Views exposed filters was solved using a couple of Drupal 8 plugins and a bit of smart thinking!

A recent project involved the use of the Simple Hierarchical Select module to input category data for a particular content type. Simple Hierarchical Select provides a clean way of browsing hierarchical vocabularies to easily add taxonomy terms to nodes.

The module works great and does exactly what it says on the tin, however it created something of a head-scratcher as the same project, which was using Apache Solr via Search API, required this data to be searchable by the end user. Creating a view of the indexed data and then exposing the various filters to be included in the search was the obvious answer and initially it was felt that it should be pretty straightforward.

For a number of the exposed filters, it was straightforward; although some required the use of hook_form_alter to make some alterations to the output of some exposed filters such as changing boolean filters from a True/False selection to Yes/No.

Unfortunately, the simple hierarchical select filter was not available as an exposed filter for Search API index views. A few approaches were made to try and resolve this including using hook_form_alter and trying to force the exposed filter to make use of simple hierarchical select. In the end, a solution was found that was actually more simple but perhaps not quite immediately obvious and required creating two plugins; a Search API processor plugin and a Views filter plugin.

Because the taxonomy that required to be searchable was hierarchical in nature, it is quite possible that the user making a search may want to do a search on higher level categories and return results that included sub-categories. For example, the top level categories could be Business and Community and below Business may be sub categories such as Manufacturing, Transport and Retail and then perhaps below Retail would be child categories such as Food, Clothing, Consumer Electronics. A user searching on Retail would expect results to be returned that have been categorised with Food, Clothing or Consumer Electronics rather than simply those categorised as Retail.

The Search API processor plugin is needed to add the parent terms of each taxonomy term to the index so that the views filter would be able to refer to those parent terms when the search query is generated.

It looks something like this:

namespace Drupal\search_api_demo\Plugin\search_api\processor;

use Drupal\search_api\Processor\ProcessorPluginBase;
use Drupal\taxonomy\TermStorageInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Adds an additional field containing the term parents.
 *
 * @SearchApiProcessor(
 *   id = "term_parents", 
 *   label = @Translation("Term parents"),
 *   description = @Translation("Adds all term parents for directory field."),
 *   stages = {
 *     "pre_index_save" = -10,
 *     "preprocess_index" = -30
 *   }
 * )
 */
class TermParents extends ProcessorPluginBase {

  /**
   * Term storage.
   *
   * @var \Drupal\taxonomy\TermStorageInterface
   */
  protected $termStorage;

  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    $plugin = parent::create($container, $configuration, $plugin_id, $plugin_definition);
    $plugin->setTermStorage($container->get('entity_type.manager')->getStorage('taxonomy_term'));
    return $plugin;
  }

  protected function setTermStorage(TermStorageInterface $storage) {
    $this->termStorage = $storage;
  }

  public function preprocessIndexItems(array &$items) {
    foreach ($items as $item) {
      foreach ($this->filterForPropertyPath($item->getFields(), 'field_category) as $field) {
        foreach ($field->getValues() as $tid) {
          foreach ($this->termStorage->loadAllParents($tid) as $term) {
            $field->addValue($term->id());
          }
        }
      }
    }
  }

  public function calculateDependencies() {
    parent::calculateDependencies();
    $this->addDependency('config', 'field.storage.node.field_category);
    $this->addDependency('config', 'taxonomy.vocabulary.category');
    return $this->dependencies;
  }
}

​The most interesting part of this class is the preprocessIndexItems method. When Search API indexes the data, the processor plugin iterates through each item to be indexed, filtering out fields other than field_category, which contains the term id stored by the particular node and the field we are interested in working with. It loads the parents of the term, by term id, and adds the id of each parent to the index using the addValue method. This method is basically storing each term id value in the item field, in this case field_category.

Note that the indexed item mentioned above isn’t an entity, it is referring to a Search API Item. This item could as easily be a user as a node, taxonomy term, file, comment or any other piece of data that Search API is able to index and it represents data that is being indexed or returned as a search result.

Incidentally, this functionality is already available in the Drupal 7 version of Search API and progress is being made on porting this to Drupal 8.

The second plugin is the Views filter itself. This is in two parts, the plugin itself and a hook that lets Views know about the filter. Firstly, the hook:

/**
 * Implements hook_views_data_alter().
 */ 
function search_api_demo_views_data_alter(array &$data) {
  $data['search_api_index_default']['shs'] = [
    'title' => t('Category filters'), 
    'help' => t('SHS filter for category'), 
    'filter' => [
      'field' => 'field_category’, 
      'id' => search_api_demo_shs_taxonomy_index_tid_depth',
    ],
  ];
}

The array key search_api_index_default refers to the Default Search API index or if you were creating a custom filter for node data, you would want to use node_field_data to refer to the database table instead. The field key is the important item in this array and refers to the actual field, field_category, we want to be able to filter on. shs is a reference in Views to the field_category field and can be set to anything. Lastly, the id key is the plugin we want to use.

Alternatively if you simply wanted to create a filter that would provide a text filter for a particular database, or Search API, field, this id could be set to String which would use the core Views string filter plugin and you’d be finished now. As we have a specific requirement for our filter, we need to create a plugin, which has been given the id search_api_demo_shs_taxonomy_index_tid_depth.

The plugin code is simple and looks as follows:

namespace Drupal\search_api_demo\Plugin\views\filter; 

use Drupal\search_api\Plugin\views\filter\SearchApiFilterTrait; 
use Drupal\search_api\UncacheableDependencyTrait; 
use Drupal\shs\Plugin\views\filter\ShsTaxonomyIndexTidDepth; 

/**
 * Filter handler for taxonomy terms with depth. 
 * 
 * @ingroup views_filter_handlers 
 * 
 * @ViewsFilter("search_api_demo_shs_taxonomy_index_tid_depth") 
 */ 
class SearchAPIDemoFilter extends ShsTaxonomyIndexTidDepth { 

  use UncacheableDependencyTrait; 
  use SearchApiFilterTrait; 

  public function query() {
    if ($value = reset($this->value)) {
      $this->getQuery()
        ->addCondition('field_directory_type', $value);
    }
  }
}

The magic happens in two places. Firstly the class extending Simple Hierarchical Select’s ShsTaxonomyIndexTidDepth views filter, which does all the hard graft of creating the hierarchical select widget, and secondly SearchApiFilterTrait, a trait which gives access to Search API filter methods and lets us add our filter as a condition to the search query, as can be see in the query() method in the code above.

All this results in turning the default select list that only works on the current term id...

...to something more flexible and easier to use, and that respects taxonomy hierarchy:

Search API Drupal 8 Plugins Views
Apr 21 2016
Apr 21
     This is blog describes about how to add custom field to Search API solr index in Drupal 7.

     Suppose we need a new field, we can add new fields for a content type at /admin/structure/content/ types. Then all fields are showed at /admin/config/search/search_ api/index/default_node_index/ fields. Now you can add desired fields to solr index.

     Suppose you want to show custom field to Search API results but that field is not created for any specific content types. Is it possible in Search API? Yes you can done this with use of hook_entity_property_info_ alter().

/**
 * Implement phponwebsites_get_nodecountviews_nid()
 *
 * Return count of views by particular nid
 */
function phponwebsites_get_nodecountviews_nid($ nid) {
  $result = db_query("SELECT COUNT(*) as count FROM {nodeviewcount} WHERE nid=:nid", array(':nid' => $nid))->FetchAssoc();
  return $result['count'];
}

/**
 * Implements hook_entity_property_info_ alter().
 */
function phponwebsites_entity_property_info_ alter(&$info) {
  $info['node']['properties'][' is_nodeviewcount'] = array(
    'type' => 'integer',
    'label' => t('Node view count'),
    'description' => t("Number of views."),
    'sanitized' => TRUE,
    'getter callback' => 'phponwebsites_get_is_nodeviewcount_ callback',
  );
}

/**
 * Implement phponwebsites_get_is_nodeviewcount_ callback()
 */
function phponwebsites_get_is_nodeviewcount_ callback($item) {
  $count = phponwebsites_get_nodecountviews_nid( $item->nid);
  $total = (int) $count;
  return $total;
}


          After added above code into your custom module, go to /admin/config/search/search_ api/index/default_node_index/ fields. Now you could see new custom field is displayed as in below images.

Add custom fields to search API solr index in Drupal 7

         Now you can add your custom field into search api solr index and index that field. The custom field is listed in views add field section. Now you can add custom field into search results.

Related articles:
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7 Create menu tab programmatically in Drupal 7
Redirect users after login in Drupal 7
Dec 08 2014
Dec 08
drupal-8-logo

For all of us who care about site search for Drupal, the maintainer Thomas Seidl has written a report about the current status of Search API for Drupal 8. The search crew’s vision is not only to port Search API to Drupal 8, but also to remove all known limitations, making site search for Drupal 8 the most powerful and flexible search integration so far. At Visitors Voice we are really excited about this since our own vision is to empower all Search API sites with actionable search analytics and tools to help more visitors find what they are looking for. This is Thomas’ report.

After eight months of intense development in a sandbox, a few days ago the Drupal 8 version of the Search API module finally reached the first large milestone: I moved it back out of the sandbox into its proper repository and created a first Alpha release right away. A good moment, I think, to go a bit into detail about what has happened so far, what changes you can expect from the Drupal 8 version and maybe whet your appetite a bit for the great features that will soon come to a CMS module near you.

What is a “Search API”?

In case you don’t know it, the Search API is a Drupal 7 module which provides a feature-rich, powerful and flexible search framework for Drupal. Together with its numerous extension modules, it covers a wide range of search functionality and can easily be extended and customized further. Its prime features include support for searches on any kind of entity (as well as extension points for adding other kinds of data sources), a large selection of supported backends which can be switched on the fly, and a powerful Views integration. It is currently the most popular search-related module on drupal.org, with over 50,000 reported installations.

Changes in Drupal 8

If you want to keep up to date about what is planned and what has happened for the module’s D8 version, just follow the meta issue and any of its sub-issues that interest you. Below, I want to highlight a few of the larger improvements to expect in the Drupal 8 version.

Apache Solr

Most of you have probably heard it already, but one of the largest improvements in the Search API in Drupal 8 is not a technical, but a “political” one: after a lot of discussions, the maintainers of the Apache Solr Search module and I eventually agreed to merge our two Apache Solr integration modules into one for Drupal 8, thus hopefully eliminating a lot of confusion and duplicated work, leading to a better solution for everyone. You can read more about it in Nick Veenhof’s announcement blog post.

Searching across multiple item types

The probably biggest technical innovation concerns searching across multiple item types (like nodes, comments, user profiles, …) – especially, creating site-wide searches. Even though this is a very common use case, it is frustratingly difficult to implement in the Drupal 7 version of the Search API. There is the Multi-Index Searches module which tries to solve the problem, but it has to fight against a lot of inherent technical restrictions and consequently only does a rather poor job, lacking support for nearly all add-on features of “normal” searches.

This problem was caused by the initial decision of limiting each search index to a single entity (or other) type – since normal searches are always executed on a single index, a search across multiple types cannot be created this way. While other, maybe better-working workarounds in Drupal 7 would be possible, this is solved completely in Drupal 8 where this restriction doesn’t exist anymore. You can now use any number of item types (or “data sources”, as we now call them) for a search index, and even change them completely at any time later on, which makes searches across entity types, or even over both Drupal-internal and external data, work exactly as smoothly as searches on a single entity type did before. This makes it possible even for a large site, with lots of different types of content and associated searches, to use a single search index for the whole site. When creating a search (view), you can then just filter by the appropriate types to get a type-specific search.

Indexing only specific content types/bundles

Still, sometimes you want to be very specific about what you index – e.g., indexing only nodes of a certain content type. Though this was already solved early on in the module’s Drupal 7 version, people soon complained that this solution was very limited: it excluded the items with wrong types from being indexed on the server, but the Search API still had to look at each item when indexing, and also afterwards every time the item was edited. (Especially very problematic on large sites with over a million nodes, where you want to only index a few hundred.) Also, the list of fields that could be indexed wasn’t affected by this setting, offering fields that weren’t present in the selected content types. While at least the former issue was finally (more or less) fixed pretty recently, the Drupal 8 version took care of this functionality right from the start, thus achieving a much cleaner integration than possible in Drupal 7. Selecting bundles to include/exclude in/from the index is done right at the beginning, when also selecting the data sources to use, and this is then also reflected when selecting the fields to index.

Usability

If you’re like me, then reading the words “feature-rich, powerful and flexible” (as above) you immediately think “Usability nightmare” – and, unfortunately, that was really one major problem that the Search API always had. It always took new users a while to figure out how things are supposed to work there, and there a countless issues in its issue queue bearing witness to that. An initiative to provide a helpful handbook also didn’t change that much – as is usually the case. No, the problem had to be tackled at its root, and in the Drupal 8 version that’s exactly what we are planning to do: providing a UI that makes intuitive sense to users, that works much more along the lines of how someone building a search is thinking – not along the lines of how it works internally. One major plan to this end is providing a “simplified UI” mode (or module), which hides all the more complex configuration behind a wizard-like frontend and aims to provide the correct defaults for those settings that inexperienced users generally don’t care about. Currently, only a few minor UI tweaks have been implemented, since finishing the underlying framework makes sense before overhauling the UI. If you still want to chime in already, or keep up to date with this work (once it starts), this issue is the right place to go. Once the framework is stable enough and the other larger changes implemented, we’ll re-open that and start to work there.

And various others …

The list is really too long to include in a single blog post, but in general we also looked at all the other complaints the Search API received in the past years that were hard to resolve in Drupal 7, or the features that were hard to add. So also expect a lot of smaller improvements, drawing from over four years of experience with the module, of the use cases it should solve, the restrictions it had and the possibilities it has for evolving. If you have a pet peeve in the Search API, just take a look – maybe it was now finally resolved (or we’re planning to)! Otherwise, try to push or open the issue for the Drupal 8 version – we are still far from finished and very open to any suggestions you have!

Try it out!

As said, we are now officially in “Alpha” stage with this module. While this means that a lot of the planned improvements still need to be implemented, it has already reached a stage where it can be tested by normal users to get a glimpse of what’s coming. So, if you are interested, please do that, give it a try and then go to the issue queue to provide feedback: Were there any bugs, did you get any error messages? Did you think of some additional feature which would be great to have – or another way to present existing functionality? In all these cases, please either find an existing issue or, if none exists, create a new one and provide input, and we will try to incorporate as much of that as possible as we move forward. However, there is yet no upgrade path from D7, and also no support for D8-to-D8 updates planned at least until Beta, so it is definitely not recommended to use the module in production yet. Also, a lot of the Views integration is currently still missing (you can show rendered entities and add a fulltext search filter, but that’s about it), so you are also very limited in the range of searches you can create.

Other ways to help

Testing out the module and providing feedback is a great way to help, as is helping to reproduce bugs and test patches – and both don’t require any programming skills. We can also always use help keeping the issue queue organized and up-to-date. Then, for developers, there are of course countless programming tasks to help with, for every level of experience (with both the Search API and Drupal 8), so please contact me if you are interested in contributing. If you want to help in any of these ways, try to attend our strategy meeting next Tuesday (12/16), where we’ll discuss how to move forward and coordinate the corresponding tasks. Or join #drupal-search-api on Freenode IRC and ask around there. Finally, for companies planning to use the Search API in Drupal 8 (especially early on), please consider donating to support this project. Nearly all of the work on it is currently unpaid, and some funding could go a long way in ensuring people are able to work on it in a reliable way. Contact me if you want to help with that.

Coda

I hope this post was interesting to you and I could make you as excited about the new Search API version as I am. I also want to seize this opportunity to thank everyone who has helped me with this project so far! An incomplete list can be found here. If you have any questions left, please just comment here, create an issue or ping me in IRC.

Thanks!

Thomas Seidl

Succeesful site search projects


Learn what it takes to be succeesful with your site search.

In this guide we share our experience from more than 100 site search projects.

x
    × Previous Next
    Nov 01 2013
    Nov 01

    Disclaimer: I have much more experience USING Solr with Drupal than setting up a Solr service so please use the comments to correct me.

    Having Solr index your content has loads of benefits, but best of all in my humble opinion is the beauty of have facetted filtered search. Of course you could do it with database indexes, but the performance win of using Solr is very noticeable.

    Prerequisites:

    • A working LAMP stack.
      • I am using Ubuntu 12.04.
    • Java version 1.6 or higher.
      • Use 'java -version' to check.

    Download Solr

    Download a copy of the Solr tarball to your computer and extract it to a directory of your choice. Make sure you have root privileges, otherwise you will need to prepend 'sudo' to the following:

    cd /usr/share
    wget http://mirrors.ukfast.co.uk/sites/ftp.apache.org/lucene/solr/4.5.1/solr-4.5.1.tgz
    tar zxvf solr-4.5.1.tgz
    rm solr-4.5.1.tgz
    mv solr-4.5.1 solr
    
    

    And now you have Solr downloaded. You can test it by going to the example directory and executing the start.jar

    cd /usr/share/solr/example
    sudo java -jar start.jar
    
    

    Now if you navigate to the example.com:8983/solr you should get this lovely screen:

    Now it is a bit of hassle always having to run a command from terminal when you want to start solr so here is a little trick to automate it.

    cd /etc/init
    vim start-solr.conf
    
    

    Enter the following into the file and save it.

    # start-solr
    
    start on startup
    
    script
        cd /usr/share/solr/example
        java -jar start.jar
    end script
    
    

    Now solr will start whenever the machine you are running starts up.

    Configure Solr for Drupal

    Most of what you need to know for this can be found on d.o here but I will take you through it anyway.

    Download the newest release of the Drupal search_api_solr module. There are some files that we need to to our solr settings.

    cd /path/to/search_api_solr/solr-conf
    cp 4.x/*  /usr/share/solr/example/solr/collection1/conf/
    
    

    And that is pretty much it. Simples!

    Configure Drupal for Solr

    Now install Drupal and Search API Solr (including dependencies) as you would normally. Go to the Search API configuration page (example.com/admin/config/search/search_api) add a new server (choosing Solr as the service class) and if you get this wonderful message:

    you are done!

    You can now index Drupal to your heart's delight.

    Aug 28 2012
    Aug 28

    Posted Aug 28, 2012 // 1 comments

    Search API Attachments is very similar to Apachesolr Attachments in that it lets you extract text from attachments using Apache Tika. It makes this text indexable and searchable so that documents on the site can be searched along with nodes and entities.

    However, while Apachesolr Attachments lets you select either to use a local copy of Tika or Tika installed on a remote SOLR server, Search API doesn't support the same configuration. Search API Attachments only supports local Tika extraction. For large-scale sites, this is an issue as it takes resources away from the web server to do resource-intensive processing work.

    There is a way to enable remote SOLR extraction in Search API with just a few patches.

    First, make sure you are using the 7.x-1.2 copy of the Search API Attachments module. If you are not, upgrade to that version.

    Next, apply the http://drupal.org/files/search_api_attachments-allow_external_extraction_and_cache_extraction-1289222-8.patch patch to your Search API Attachments module. This patch adds a configuration option to the Search API Attachments screen to allow for remote SOLR extraction or local Tika extraction, and contains the necessary code to make it work. It also adds a table to store the text that was extracted, so that you don't need to send the files to the server every time you need to re-index your site. Don't forget to run the database updates after this patch has been applied.

    Last, apply the http://drupal.org/files/search_api_solr-allow_abitrary_query-1580118-1.patch patch to your Search API module ( not Search API Attachments ). This patch is required by the previous patch in order to make the query to the remote SOLR server.

    You'll want to re-index your site after you've made these changes if you are already using the local Tika extraction.

    Web Developer Brad Blake brings a wealth of expertise to our team and our clients whenever he creates software tools and websites on the LAMP platform. For more than five years, he has been using PHP to build cutting-edge technologies that ...

    About Drupal Sun

    Drupal Sun is an Evolving Web project. It allows you to:

    • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
    • Facet based on tags, author, or feed
    • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
    • View the entire article text inline, or in the context of the site where it was created

    See the blog post at Evolving Web

    Evolving Web