I was in the middle of development when I discovered Octopress. How I had never heard of this platform before, I don’t know. In under 4 hours total I had my Wordpress site migrated off of Wordpress and onto a Github Pages site generated by Octopress; it was a very smooth transition. Because development was so fast, I opted to stick with Octopress and GH-Pages.

My site is now running statically using Octopress as a site generator and Github as a free host. Octopress is built on Jekyll, so I can make plugins easily (in Ruby) as well as pull in any existing plugin with ease. Octopress seems like it is built to be the developer blogging platform. The code blocks, the post generation, and the fact that it is built on Ruby all helped me settle on Octopress as my new blogging platform. I hope you enjoy the new site!

Solr has quickly become one of the most popular search engines available. Due to Solr’s many features and its low barrier to entry it can be an ideal candidate when seeking a search engine. Solarium, a PHP Solr Client, takes Solr one step further by giving developers easier access to the Solr API.

1
2
3
4
5

{
    "require": {
        "solarium/solarium": "3.0.0"
    }
}

1
2
3
4
5
6
7
8
9
10
11
12

<?php
$config = array(
    'endpoint' => array(
        'localhost' => array(
            'host' => '127.0.0.1', 'port' => '8983', 'path' => '/solr/'
        )
    )
);

// new Solarium Client object
$client = new Solarium\Client($config);
?>

1
2
3

<field name="id" type="int" indexed="true" stored="true" />
<field name="name" type="string" indexed="true" stored="true" multiValued="true" />
<field name="text" type="text" indexed="true" stored="true" />

Introduction to Solr: Search is an important part of most web projects and should be given much care. Throughout the years, making content searchable has changed a great deal. Obviously, exposing SQL queries to users through search is dangerous. Modern search implementations require a secure approach, such as a stand-alone search server, separate from site data. There are many search options to choose from. Your search list might include: Sphinx, Flax, ElasticSearch, Google, and Solr. Solr’s scalability, speed, built in features and community make it an ideal platform for any project. Luckily, integrating Solr into your PHP project has been made easy by the Solarium Project.

In Apache’s own words, “Solr is an open source enterprise search server based on the Lucene Java search library, with XML/HTTP and JSON, Ruby, and Python APIs, hit highlighting, faceted search, caching, replication, and a web administration interface” [1]. Apache Solr is an open source, extensible, stand-alone search engine, built on Lucene, managed by The Apache Software Foundation. There are currently two stable versions of Solr available for use; Solr 3.6.2 and Solr 4.0. Either version may be used with Solarium; Solr 4 ships with added features, however, so use Solr 4 if possible.

Solr is designed to run as a stand-alone Java web application (app). The documentation for downloading, installing, and running Solr can be found at http://lucene.apache.org/solr/tutorial.html. Because Solr is meant to be separate from the primary project, it can be installed anywhere. All interactions with Solr happen over HTTP through a REST-like API. Solarium utilizes both PHP and JSON for its interactions with Solr.

One of the greatest features of Solr is its scalability. Replication can be set up to run multiple Solr instances in a master/slave setup, just like MySQL replication.The documentation for setting up a master/slave setup is very thorough, so it will not be discussed further here. Another option for scaling Solr is to search multiple search cores. Solr can run multiple search cores at a time. Solr can search multiple cores at a time through its distributed search and sharding capabilities. Large search indexes can be split into multiple smaller indexes; then through a distributed search multiple cores are searched. The best part of a multicore search setup is that not all cores need to exist on the same server. This allows for very flexible search architecture.

Solarium acts as a bridge

Solr has a REST-like API, so interactions with it are very simple and happen over HTTP. The Solarium Project is “an open source Solr client library for PHP applications” [2], which makes interacting with Solr even simpler. Solarium exists to expose the Solr API through an easy to use PHP library.

Installation of Solarium has been made very easy through the use of Composer (Listing 1). Installing through Composer will automatically add the library to the PHP autoload path. To install Solarium into a project not utilizing Composer, the files will need to be downloaded from GitHub (https://github.com/basdenooijer/solarium/tags). Next, add the solarium library to the PHP autoload path manually. After Solarium is installed, Solr can be accessed through sending a Solarium Client ($client) object to a configuration array. The configuration array should be made up of the Solr host, port and path (Listing 2).

Adding content to Solr

Before anything can be searched in Solr, documents (docs) must be added to the Solr index. Solr maintains a collection of docs in its index. A doc is a collection of fields and values. Solr fields must be defined in the Solr schema. A field can occur multiple times in a doc.

To make an update to Solr using Solarium, start with the $client object. Using the $client object, create an $update instance then make a doc:

1
2

$update = $client->createUpdate();
$doc1 = $update->createDocument();

With the newly created $doc, begin adding content to Solr fields as instances of the $doc:

1
2
3
4
5
6
7
8
9

$doc1->id = 123;
$doc1->name = 'First Document';
$doc1->text = 'This is the first document\'s content';

// Create another doc
$doc2 = $update->createDocument();
$doc2->id = 234;
$doc2->name = 'Next Document';
$doc2->text = 'This is the next document\'s content';

In this example, the Solr schema would have to be set up to accept the id, name and text fields. Solr ships with an example search app with a good demo of a Solr schema; each field will need to be added to the schema in order for Solr to add the docs to the search index (Listing 3). Next, add each $doc created to an array so that addDocuments() can be called on the array. This will run the Solr add command for every document in the array:

1

$update->addDocuments(array($doc1, $doc2));

The newly-added docs will not actually become a permanent part of the Solr index until Solr is told to commit all added docs to its index. To do this with Solarium, call addCommit() to generate a commit message for Solr, then a call to update() with the $update will send the commit:

1

$update->addCommit(); $client->update($update);

The new docs should now exist and be searchable using Solr.

Searching Solr through Solarium

Solarium offers a robust PHP API for searching Solr. To run a basic query, start with the $client object. Next, call the createSelect() instance of the $client object to generate the query for execution:

1
2
3
4

$query = $client=>createSelect();

// *:* is equivalent to telling solr to return all docs
$query->setQuery('*:*');

Because the createSelect() function is being used to generate the query, the select() function should be used when executing the query:

1

$resultSet = $client->select($query);

Use the $resultSet array to iterate over the array and display the results:

1
2
3
4
5
6
7
8
9

echo '<div class="search-results">';
foreach ($resultSet as $result) {
    echo '<div class="search-result">';
    echo '<p>' . $result->id . '</p>';
    echo '<p>' . $result->name . '</p>';
    echo '<p>' . $result->text . '</p>';
    echo '</div>';
}
echo '</div>';

The $resultSet can also be refined. Setting up pagination, for instance, is very easy:

1

$query->setStart(0)->setRows(10);

Sorting is also very easy (note that Solr will sort by score if no sort is set):

1

$query->addSort('name', Select::SORT_ASC);

Filtering, setting query fields, boosting, and faceting are also possible ways of searching Solr. Filtering is another way of narrowing search results without using a query. Query fields allow for control over what fields are searched. Boosting gives certain field’s higher precedence in the Search. Facets give users a way to better navigate search results. Solarium gives easy access to all the various ways of searching Solr content.

Removing content from Solr

Solr does not have a command called update; however, updates can be performed by re-adding content. Solr uses a unique identifier for each doc and only allows for one instance of the identifier in the search index. To update content, call the add command on an already existent Solr doc id. Sometimes updating Solr with new content isn’t enough. Sometimes the need to delete content from Solr arises. Doing this is similar to when adding docs, create an $update instance:

1

$update = $client->createUpdate();

Using the $update instance, documents can be deleted by id or by query. This offers a great deal of flexibility for deleting content. Deleting by id is used more often because it offers very precise deletes:

1
2
3

$update->addDeleteById(234);
$update->addCommit();
$client->update($update);

Deleting by query, however, can be incredibly powerful and useful. When starting development of a new search project with test content, for instance, deleting by query offers the ability to remove all test content. If all the test content starts with the word test, deleting the content is simple:

1
2
3

$update->addDeleteQuery('name:test*');
$update->addCommit();
$client->update($update);

Another common practice is to wipe the index and start fresh. Using delete by query, this task is again made very simple:

1
2
3

$update->addDeleteQuery('*:*');
$update->addCommit();
$client->update($update);

Solarium’s delete doc API is very useful in maintaining an up-to-date search index.

Conclusion

Solr is an incredibly scalable, powerful and easy-to-use search engine that should be considered for any search project. Solr is designed to be language agnostic through its REST-like API, and thanks to Solarium it fits very easily into any PHP project. This article covers only three use cases for Solarium; the examples shipped with Solarium offer a great deal more. Search highlighting, debugging, optimizing, and ‘more like this’ functionality are all possible with Solr and Solarium.

References

1. Apache Solr: http://projects.apache.org/projects/solr.html
2. The Solarium Project: http://www.solarium-project.org/

1
2
3
4
5
6

access_control:
    - { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
    - { path: ^/admin/, role: ROLE_ADMIN }
    - { path: ^/new, role: ROLE_USER }

As you can see with my code, for anything beyond the /admin/ route the ROLE_ADMIN is required. And for anyone accessing the /new route the ROLE_USER is required.

This is obviously pretty trivial stuff, but for somebody new to Symfony2 development like myself, I found it an incredibly simple and powerful way of controlling access to my app.

I finally decided on my first eZ Publish 5 project… my site of course. I am currently in the middle of upgrading my wordpress install to eZ Publish. Honestly, I don’t really need anything more than a simple Wordpress install, but it will be nice to get an eZ5 site under my belt.

Seeing as I am in the middle of development, there have been a few bumps in the development road that I have found and would like to share. Firstly, I can find no way to run eZ Publish 5 completely in legacy mode, no matter what I do my pagelayout template needs to be a twig template. I posed the question to the eZ Community and it sounds like this should be possible, but it just wouldn’t work for me (see the discussion here). I actually don’t have a problem with this, it’s not like being forced to use Symfony is a bad thing.

Second, I do not see a strait-forward way to run multiple sites in one eZ Publish 5 install right now. Site settings are declared in the ezpublish.yml file and are grouped appropriately. My problem is that the parameters.yml file only allows for the declaration of one default template. In my opinion the default template declaration should be tied to a siteaccess or a siteaccess group.

Third, the index_dev.php file doesn’t work for some reason. It would be nice to be able to use the Symfony dev toolbar. So far my only workaround has been to add the dev params to the index.php file. Either fixing this or allowing DebugOutput on a Symfony generated page would suffice.

It wouldn’t be fair to simply criticize eZ5, because it does work. The eZ Team did a hell of a job with eZ5, far more than I would have expected for a first iteration. Honestly I was expecting eZ5 to switch to the Symfony Components for round 1 and work on the rest later.

I think that far and above any other nicety of eZ5 is the ability to generate custom routes. Creating a custom module in eZ 4 was not exactly easy, but now with Symfony, creating a custom route/controller/view is extremely straight-forward and borderline easy. If a person has ever worked with Symfony in the past, creating custom ‘modules’ will be a snap.

Another awesome part of eZ5 is the full REST API. Although I have yet to use it, I know it is there and that the eZ Team put a lot of work into it, so I have to give it props.

Finally, twig is awesome to work with.

1
2
3
4

<copyField source="*_lk" dest="ezf_df_text"/>
<copyField source="*_k" dest="ezf_df_text"/>
<copyField source="*_t" dest="ezf_df_text"/>
<copyField source="*_s" dest="ezf_df_text"/>

A copyField will take any field you tell it to and copy it into another field. The code above is what ships with eZ Find, every single *_lk (lckeyword), *_k (keyword), *_t (text), and *_s (string) is added to the ezf_df_text field. For obvious reasons the average installation probably doesn’t need every piece of content searchable. The first step is to delete the default copyFields (e.g. your site users probably shouldn’t be searched by default).

Luckily, there is only one other step! Unfortunately, this one step can be very time consuming. Visit the luke output for your Solr install and make a list of all the fields you need to search. Make a copyField for every field you want to search, adding each field to the ezf_df_text field.

Remember, this can offer major speed improvements in your searches, especially if you are managing a large amount of content. There are still other optimizations (stored/not stored, indexed/not indexed, term vectors, etc), but that is for another time.

Finally, I did submit a pull request to the eZ Find project. It adds a new search parameter allowing users to declare custom search fields. https://github.com/ezsystems/ezfind/pull/93

I have spent a good deal of my freetime this past month or two learning as much about about the php framework Symfony as possible. The moment that eZ Systems announced that they were adopting the Symfony framework I knew that I would be be spending some time with it. I have found that Symfony doesn’t have the lowest barrier to entry so it has been a process, to say the least. I have a blog that has helped matters a great deal and so I wanted to give it some props here. If you are like me, wanting to learn Symfony but lacking time and resources, you should really check this site out: Symblog: Creating a Blog in Symfony2

The blog starts with the basics and explores a good deal of Symfony components in detail. In the end you will be left with a barley usable blog, but that is alright, it leaves you with a project to fix. It is a tutorial for Symfony 2.0, and because Symfony is currently on 2.1.3 you will notice some part don’t work the way you expect (but I think that forces you to learn more anyway). The tutorial also doesn’t use Composer at all; so remember, when the blog tells you to install something, use Composer and skip over the way they tell you how to do it. I hope you enjoy the tutorial, I know I did (I have not currently completed the tutorial but am nearing completion at the time of this writing).

I recently updated to Skype 6 and found something interesting out. My style package that worked in Skype 5 would not work in Skype 6. With some digging, we found out that in order to make your Skype 5 style work in Skype 6 you need to update the MessageViewVersion to version 7 (I have no idea why). So, with that, have fun updating your Skype to the latest version while still getting use out of your favorite Skype theme.

• Michele Bachmann and Muslim witch hunts
• Republican Senate Nominee Explains That Women Don’t Really Get Pregnant From ‘Legitimate Rape’

AWS authorize security groups across acounts « ShellRunner.

It is a post by @jacksonmurtha so we can trust that it is good.

I did a lot of playing around with solr to get this right. Unfortunately there is not a lot of documentation on searching within a certain field. With the SQL language you can search for multiple terms in a given field using the IN operator. In Solr you have the option of specifying a field using the qf operator, but what if you have more search terms searching other fields? The problem becomes far more complex. Given the following SQL statement how would we query Solr?

1
2
3

SELECT *
FROM table_name
WHERE column_name IN (value1,value2,...) AND other_column='foo'

There are couple of ways to do this, but I think there is one very good and much easier way. The first obvious way to query solr is to match the fields to columns manually.

1

/select?q=*:*&fq=column_name:value1 AND column_name:value2 AND other_colum:'foo'

This is all fine and dandy but what if I want to be able to add a list of content to the query? Adding the column name every time can become a chore and make the query unnecessarily large. To do an IN query try this:

1

/select?q=*:*&fq=column_name:+(value1 value2) AND other_colum:'foo'

Having used this one before, I can tell you it works for me using Solr 3.6 and that the placement of the + symbol is key.

And what about a NOT IN query?

1
2
3

SELECT *
FROM table_name
WHERE column_name NOT IN (value1,value2,...) AND other_column='foo'

The ‘bad’ way:

1

/select?q=*:*&fq=-column_namevalue1 AND -column_name:value2 AND other_colum:'foo'

This one I found from working with eZ Publish and eZ Find, and I happen to like it a lot. It is a clever little Solr query that selects all from the column then filters out what we don’t want.

1

/select?q=*:*&fq=other_colum:'foo' AND column_name:[* TO *] -column_name:(value1 value2)

column_name:[* TO *] is like saying select all from the column, but then we add -column_name:(value1 value2) to filter out what we don’t want.

Cheers and good luck!

Let me start by saying that eZ Find is a fantastic implementation of Solr functionality. With eZ Find you get a fantastic search, out of the box. eZ Find gathers all the content in your system and organizes it for you into strings, text, and keywords (there are more but those the types I use most often). It can look at an eZ Publish keyword and know that it should thereby be a Solr keyword, again, all out of the box. There are however some serious limitations when it comes time to customize it to meet your system’s needs. Do not underestimate the power found in customizing Solr to meet your website’s needs. The default setup is great, it’s made to fit into any system with very little effort; but, just because it’s made to fit in any system does not mean that it should be used for every system.

One of the best things we could have ever done for a large Solr install was to customize a default search field. You might say, “But eZ Find already creates a default search field for you.” And you’d be right.

1
2

<!-- field for the QueryParser to use when an explicit fieldname is absent -->
<defaultSearchField>ezf_df_text</defaultSearchField>

The thing that the default search field in eZ Find does not do, however, is get used. There is no way in eZ Find to tell it to search just one field (at least as far as I know). I did some testing in our environment, these numbers will change from system to system, but in our’s each search took almost 10 times as long to search all fields individually vs searching just 1 field. We gave eZ Find the option to search one given field, if defined, and it vastly improved our search experience.

eZ Find by default looks at all ‘searchable’ fields and adds them to either the qf (if you are using the dismax search like you should be) or it searches every searchable field individually (attr_title_t:(*:*), attr_title_s:(*:*), etc, etc, for all searchable fields). All the ‘searchable’ fields are by default added to the ezf_df_text field, so you should really do yourself a favor and search just one field, it is a noticable speed improvement, especially in large systems.

In Part 2 I will talk about how to better optimize the Solr schema.xml file using the ezf_df_text field.

I have been a devout git user for as long as I have been programming. I was lucky enough to bypass subversion entirely, at least that is what my friends who used svn have told me.

The cool thing about git is that it tracks changes, not files or directories. When I create a new empty directory that directory is not tracked by git because it has no file changes inside, hence, the directory will never make it into git until I add a file to that directory. For this example I am going to use the logs directory of a virtual site. In my logs directory I have two files, an error_log and an access_log. Apache error logs and access logs should never be tracked by version control because they are logs that are specific to the given system the site is installed on. However, we should try to track the logs directory in version control. As hinted at before, we can do this in one of two ways.

First, the .gitignore file. We can add as my .gitignore files as we need. You can place these files in any directory you want tracked that wouldn’t be already (technically you can put them anywhere you want and have as many as you want, but don’t go excessive). .gitignore files are technically the preferred way to go about tracking empty directories because these files are actually read by git. The .gitignore file structure is pretty simple, for defining how to ignore the contents of the logs file you just need to tell git the relative path (relative to the path of the .gitignore file). .gitignore file:

1
2
3

# log files
logs/access_log
logs/error_log

How to track the empty directory with .gitignore

So, as you can see this is pretty simple, but I think that multiple .gitignore files can become confusing.

Second, the .gitkeep file. This is a git hack that was first adopted by the Rails community. .gitkeep files are not an official file recognized by git. That said, because they start with a '.' they will be a hidden file in any system as well as have it’s changes tracked by git. Technically our file name could be .foobar and it would still work. The reason I like the .gitkeep files is because it’s purpose is directly implied by the name of the file (keep the directory in git even if it’s directory is empty). Another reason I like the use of .gitkeep files over .gitignore is I like to keep all ignored files in one spot, it can be hard to track what is ignored if there are multiple .gitignore files at work in a system. The .gitkeep file at work:

Pretty simple right? So, I have my preference, what is yours?

A while back I fell in love with Sublime Text 2 and its’ many advantages over TextMate. What it lacked however was any real support for the eZ Publish templating language (no different than TextMate). What I wanted was a simple editor that offered variable and method highlighting equivalent to a nice IDE like PHPStorm. I was originally using the Smarty package for TextMate (you can use any TextMate package in Sublime), but that does not offer a lot of method highlighting support for eZ. So what I decided to do was use the Smarty package as a template for adding more language support for eZ Publish. What I have is far from complete; I usually only add to it when I use a method that is not already supported. You can find it out on GitHub. It is my hope that there are some eZ Publish devs out there that really enjoy Sublime as I do and want to help me grow the package. Remember, it is far from complete, but nonetheless, I really hope that you enjoy the language highlighting, and if you do feel free to contribute.

Prerequisites: eZ Publish with eZ Find installed

The following post is based on the option in the eZ Find solr.ini referring to Shards.

1
2
3
4
5
6
7
8

[SolrBase]
#Shards mapping, can be to multicores in one servlet or even a crosss servers
#typical use is multilingual setups, but also for external index support
#the keys are used as shorthands in template functions
#Shards[]
#Shards[eng-GB]=http://localhost:8983/solr/eng-GB
#Shards[fre-FR]=http://localhost:8983/solr/fre-FR
#Shards[myforeignindex]=http://myotherhost:8983/solr

What this means for eZ Find developers: we can do a distributed search in our standard eZ Find fetch (with a little work).

First things first, we need to tell each siteaccess what its Search Server URI is. Within the settings/siteaccess/<siteaccess-name>/ directory we need to create a new solr.ini.append.php file (duplicate the file in the admin version). Within each siteaccess we need to input our Solr core name; for harmssite it would be SearchServerURI=http://localhost:8983/solr/harmssite and for the counterhelix siteaccess it would be SearchServerURI=http://localhost:8983/solr/counterhelix.

Next, make sure that you have your cores installed into solr. In order to do this just copy the default eng-GB from the solr.multicore/ directory and then rename it for each core you wish to have, in my case I have a harmssite and a counterhelix core. There is also a solr.xml that we need to edit. Here we declare each core that we created.

Mine:

1
2
3
4
5
6
7

<?xml version="1.0" encoding="UTF-8" ?>
<solr persistent="true" sharedLib="lib">
  <cores adminPath="/admin/cores">
    <core name="harmssite" instanceDir="harmssite" />
    <core name="counterhelix" instanceDir="counterhelix" />
  </cores>
</solr>

Finally, we need to start Solr, while giving it a new home parameter.

1

java -Dsolr.solr.home=solr.multicore -jar start.jar

There is decent documentation on this up to this point located here.

Next, we need to add a list of our shards into our override solr.ini.append.php file. Use the demo from above, just put in the url each core. Something to note here. I believe the documentation is wrong here. We should not include the http:// in this list, Solr will add this automatically for us when it runs the search. Thus, mine looks like this:

1
2
3
4

[SolrBase]
Shards[]
Shards[harmssite]=localhost:8983/solr/harmssite
Shards[counterhelix]=localhost:8983/solr/counterhelix

I am assuming here that you know how to index your content, so update your search index to follow these settings. The next step is to set up a distributed search in our eZ Find fetch.

example:

1
2
3
4
5
6
7
8
9
10
11
12
13

{set $search=fetch( 'ezfind', 'search',
                    hash( 'query', $query,
                          'sort_by', $sort_by,
                          'facet', $defaultSearchFacets,
                          'filter', $filterParameters,
                          'publish_date', $search_date,
                          'offset', $view_parameters.offset,
                          'limit', $page_limit,
                          'as_objects', false(),
                          'distributed_search', hash(
                              'shards',array('harmssite', 'counterhelix')
                          )
                         ))}

Note that we have to send the distributed_search parameter as a hashed array. In this case we are telling eZ Find to search both shards. We can have eZ Find search whatever core we want it to at this point, just harmssite, just counterhelix, both, or even new cores that we might add later. The advantages are obvious, separated indexes allowing for much larger sets of data is a huge upgrade. The downside is that searching multiple cores at once is a little slower, so really you should not use this option unless you are in need of scaling Solr out more; this would be a touch overkill for my site.

If you have followed me up to this point and have tried running this, you may have noticed that it does not work out of the box. The ezfezpsolrquerybuilder.php is still a work in process and has not been set up to handle shards just yet. Out of the box, should you send the distributed search shards array to eZ Find, eZ Find will take it, generate the shard urls and then do nothing with them. The task I leave you is to try and fix this problem for eZ Find. I have a fix for this, but would love to see what other people come up with (I will post my code here next week). The file in question. Remember, all we need to do is send the shards parameter to the search plugin should one be sent to eZ Find; the search plugin is already setup to handle shards.

When using eZ Find to search a single local site, it does a really good job at building out the result object to be used. What becomes a problem, however, is when a cross-site search is necessary. When the search fetch includes 'as_objects', true() eZ Find tries to build out an object by fetching from the database after the Solr search is completed and the necessary content is returned.

Another option, however, is to return all the information from Solr, no more object building from the DB. To do this all you have to do is enable EnableSolrAttributeStorage in the ezfind.ini. That way, if you are searching on a site that does not have access to the local database (cross-site search for instance) you can return all the content you need from Solr, because it is all stored.

So remember, set: 'as_objects', false() in the fetch.

and in the ezfind.ini

1
2

[IndexOptions]
EnableSolrAttributeStorage=true

Then just remember to re-index your content to get all the new attributes in there.

So, to start. Let’s assume that if you are reading this, you already read through my previous eZ Find tutorial (Installing eZ Find). Since we already have our sever up and running there won’t be a lot of work to do there. But, we need to move our config files to the Solr multicore directory. Last time we used the Solr directory, this time we need to use the directory solr.multicore. Inside the multicore directory there are a couple of demo cores for languages. What I did is duplicated the english directory a couple times and renamed them for each site.

I think this is the time for a nice FYI. We can go about this next part in a couple of different ways. The way we choose depends on the desired consequence. So, ask yourself this question, ‘Do I want the siteaccesses to share content?’ If you answered yes, you only need 1 core for you sites to share off of, if you answered no, then create a core for each site that you wish to keep separate from the others. Another note, this effect can also be achieved by adjusting an ini setting, but if you know you want your stuff separate, then create multiple cores, it is safer that way. The way I set mine up is I have 2 cores. 1 core has 3 siteaccess sharing content, the other has just 1 site on it (that way its index content will not get mixed by accident).

Now that we are using Solr in a multi-core environment, starting Solr is a bit different.

1

java -Dsolr.solr.home=solr.multicore -jar start.jar

Notice, we just sent the start.jar a new place for solr to call its’ home directory solr.multicore.

Now that we have Solr re-configured for multi-core work we have to set up our solr.ini files. Inside the siteaccess specific override folders we need to drop in and edit a solr.ini.append.php file. Inside the ini file we need to point eZ Find at the right Solr cores.

1
2

[SolrBase]
SearchServerURI=http://localhost:8983/solr/<core-name>

With that one ini setting set we can fully update our index with the same command as before (the update script inside the eZ Fnd extension). So, after we have that set there is 1 last setting that we need to set, it is inside the ezfind.ini.

1
2
3

[SiteSettings]
#IndexPubliclyAvailable=disabled
#SearchOtherInstallations=disabled

Notice that I have the settings commented it out here. I set it in the siteaccess specific override files, and if it is not commented out it overrides my content. Remember, this setting only applies to content that shares a core, if the content is not sharing a core it will not be able to search the other installations.

With this simple set of settings, we gain a lot of power over search. Combinations work here as well, if you don’t want to share the index, but want to search other available indexes, go for it.

Best of luck to you, if I missed something don’t be afraid to let me know. Also, if you have questions be sure to ask.