All the features have been documented in the manual. The API docs have also been updated.
Version 3.1 is backwards compatible with 3.0, so if you should be able to upgrade without changing any of your code. If you are using a 2.x version of Solarium you can use the upgrade guide.

The roadmap for the next version of Solarium is not yet determined, so if you have a feature request please let me know!

• The spellcheck component now supports collate params (Solr 4)
• Atomic updates (set/add/inc) are now supported (Solr 4)
• The escaping methods are now regex-aware (Solr 4)
• Document versioning is supported (Solr 4)
• Collections have been added to the existing DistributedSearch component to support SolrCloud (Solr 4)
• A new querytype has been added for realtime-get (Solr 4)
• Support for pivot facet (Solr 4)
• Support for highlighting boundaryscanner options (Solr 4)
• Added qparserTerm helper method (Solr 4)
• Added helpers for complex filterqueries using cost, cache disable or custom qparser / params
• You can now set an endpoint as the default endpoint in the createEndpoint method with an extra param
• Update document now supports DateTime objects as field values, they will automatically be converted to a Solr compatible date string
• Fix for a bug in Edismax, it used the wrong requestbuilder resulting in missing params
• The addDeleteQuery method in the update query now supports placeholders (similar to setQuery in the select query object)
• Curl exceptions now return more detailed info about HTTP errors to make debugging easier
• Authentication is now support for endpoints
• A __toString method has been added to the endpoint object for debugging or logging purposes, similar to the one already available in the request object
• Spellcheck suggestion results now provide access to all suggested words, instead of just the first one.
• The BufferedAdd plugin now has an AddDocument event.

All the features will be documented in detail in the manual wiki in the coming weeks. Some of the new features are implemented in the examples, and all code already has test coverage. If you have any questions or run into issues while testing the new release please let it know and help to improve Solarium even further!
Version 3.1 is backwards compatible, so if you use 3.0 you should be able to upgrade without changing any of your code.

You can find Solarium 3.1.0-RC1 on GitHub: https://github.com/basdenooijer/solarium/tags

• Support only PHP 5.3+
• Fully namespaced
• File restructuring and class renaming
• Code style switched from Zend Framework 1 to Symfony 2 (but Solarium is still not tied to a framework!)
• The concept of ‘Endpoints’ was introduced to support multiple Solr instances/cores in one client
• Interfaces were added for all important concepts in the library
• Internal classmaps for querytypes and components were simplified
• The default adapter has been switched to Curl
• OmitHeader support was added and enabled by default
• Edismax is now a separate component (used to be combined with Dismax)
• Http authentication support
• Support for the Extract querytype, to index various documents
• Support for PHPS Solr response data (in some cases much faster)
• Custom hooks have been replaced by the very well documented and tested Symfony EventDispatcher component.
• CreateFacet* methods can now directly add the created facet
• The spellcheck component query now supports placeholders
• Tagging and excluding of the main querystring is now supported
• Added new grouping params: group.func, group.format, group.facet
• Update query supports softCommit
• The Curl adapter now has proxy support
• Geospatial functions in query helper now support dereferenced params
• Facet results can now be extracted from the response data (facets defined in the Solr config, not in your Solarium query

All the features have been documented in the manual and example code for new features or updated features is included in the release. An upgrade guide is also available in the manual.

Starting from this version no pre-packaged versions of the library will be supplied on the site anymore. The recommended way to install Solarium is by using Composer that also manages the Symfony EventDispatcher dependency. You can find Solarium on Packagist .

If you somehow still want or need to manually download the library, just get a package from Github. But in that case you need to manually manage dependencies.

If you run into any issues during an upgrade from 2.x that are not described in the upgrade guide please let me know, so it can be added.

Last but not least, I want the thank the various people that contributed to Solarium 3, great work! And some nice pull requests are already waiting for Solarium 3.1!

In previous posts a lot of changes were already mentioned, but here’s a quick list of changes:

• Support only PHP 5.3+
• Fully namespaced
• File restructuring and class renaming
• Code style switched from Zend Framework 1 to Symfony 2 (but Solarium is still not tied to a framework!)
• The concept of ‘Endpoints’ was introduced to support multiple Solr instances/cores in one client
• Interfaces were added for all important concepts in the library
• Internal classmaps for querytypes and components were simplified
• The default adapter has been switched to Curl
• OmitHeader support was added and enabled by default
• Edismax is now a separate component (used to be combined with Dismax)
• Http authentication support
• Support for the Extract querytype, to index various documents
• Support for the much faster PHPS Solr response data
• Custom hooks have been replaced by the very well documented and tested Symfony EventDispatcher component.
• CreateFacet* methods can now directly add the created facet
• The spellcheck component query now supports placeholders
• Tagging and excluding of the main querystring is now supported
• Added new grouping params: group.func, group.format, group.facet
• Update query supports softCommit
• The Curl adapter now has proxy support
• Geospatial functions in query helper now support dereferenced params
• Facet results can now be extracted from the response data (facets defined in the Solr config, not in your Solarium query

All the features will be documented in detail in the manual wiki soon. Example code for the new features is already included in the release. If you have any questions or run into issues while testing the new release please let it know and help to improve Solarium even further!
As this is a new major versions with lots of big changes it’s not backwards compatible. But upgrading shouldn’t require too much work either, many parts are still compatible. An upgrade guide will also be included in the docs asap.

Starting from this version no pre-packaged versions of the library will be supplied on the site anymore. The recommended way to install Solarium is by using Composer that also manages the Symfony EventDispatcher dependency. You can find Solarium on Packagist . The ‘installation’ using Composer is also something that will be described in the manual soon, but should be easy to figure out as Composer is well known by now. And if you still prefer the old way, just download a package from Github. But in that case you need to manually manage dependencies.

Please provide feedback  if you use Solarium 3 (you can use a comment, Github message, the forum or Twitter).
I’d really like to hear about issues, but also if everything works just fine!

The past few months development has been going a bit slower than I had hoped. But still, good progress has been made. Some highlights:

• The default adapter has been switched from ‘Http’ (using streams) to ‘Curl’. Curl supports all features, for instance parallel query execution. Also, the Http adapter makes use of streams which may cause issues of you execute a large number of requests, for instance a full index. Nowadays the Curl extension is available on most environments, if not it’s just one setting to switch back to the Http adapter.
• Support for the ‘omitHeader’ param was added and enabled by default. In most cases the header info isn’t used at all, so sending it down the wire and parsing it is useless. If you do use the headers you can always enable them.
• Edismax is now a separate select query component. In Solarium 2.x Edismax was a setting of the Dismax component but this wasn’t very intuitive. On top of that Edismax and Dismax params are not fully compatible. Splitting into two components fixes both issues.
• The client class has version info. In Solarium 2.x there was a separate (static) class for version info, this has been merged into the client for ease of use.
• Coding standard has been switched from Zend Framework to Symfony 2. It fits better with the current code and PHP-CS is saving a lot of work. While Solarium 3 uses the SF2 coding standard, it will of course still be framework agnostic.
• Http authentication support was contributed and has been merged into the Solarium 3 code
• A new querytype has been added: ‘Extract’. You can use it for indexing documents in Solr, a much requested feature. For more info see this issue on GitHub.
• Support for the Solr ‘phps’ responsewriter. This responsewriter returns data as serialized PHP, instead of JSON. Much more efficient for large responses, at the cost of a possible security risk in PHP deserialization. As long as you use a trusted Solr server this should be no issue, but to be safe the default is still JSON
• The custom event hook system introduced in 2.x for plugin has been replaced by the Symfony EventDispatcher. All events are now defined in detail by event classes, priorities can be used and many more advantages. Any callback can be used as a ‘plugin’, so even a closure can be used. Makes events much more easy to use.

This release includes the following features:

• New suggester querytype
• ParallelExecution plugin
• BufferedAdd plugin
• SequentialPrefetch plugin
• Support for parameter dereferencing (implemented in the join helper, see below)
• The query helper now has support for join
• Support for the new “hl.q” and “hl.phraseLimit” params was added to highlighting
• The request class now has a __toString method for easy debugging
• New formatDate method in the queryhelper

Thanks guys!

All the features have been documented in the manual, and example code for the new features is included with the release. The API docs have also been updated.
Version 2.4 is backwards compatible, so if you use any earlier 2.x release you should be able to upgrade without changing any of your code.

Endpoints

Currently in Solarium a client instance has a single adapter and this adapter holds the Solr connection settings. This effectively means you need a client instance for each Solr server / core you want to use, or need to alter settings to switch servers. Both are not ideal. Multiple client instances introduces some overhead, especially when using plugins. You need to setup each client instance. Switching adapter settings between servers is possible but not very handy.

Using multiple Solr cores, or even multiple Solr servers is quite common so this needed to be improved. I came to the conclusion that a single client should be able to communicate with multiple servers/cores. The adapters should only handle how to communicate with the servers, and not handle server settings. So, I’ve introduced a new concept in Solarium 3: ‘endpoints’. An endpoint is basically a collection of settings that define a solr server / core: host, port, path, core and timeout.
Each endpoint is defined with a key. For each query you execute you can (optionally) supply an endpoint  or endpoint key, and the query is executed using this endpoint, using the same client and adapter. The first endpoint you define is automatically used as the default endpoint. This makes use for a single endpoint easier, as you don’t need to pass it to execute queries. Of course you can always set your own default endpoint if needed.
So in Solarium 3 you will only need a single Solarium client instance, no matter how many servers / cores you use.

It’s one of those changes where you immediately notice it’s the right thing to do. In Solarium 2 the implementations of the parallel execution and loadbalancer plugins had to use quite some tricks to work correctly. When switching these plugins over to the new endpoints it was very clear this was the missing concept that made the previous implementations hard.
There are also little issues with backwards compatibility. The API and config have changed a small bit, but by making the first endpoint the default endpoint it otherwise works the same as it always did in previous versions.

Interfaces

Until now Solarium used ‘ducktyping’. As suggested by Igor and Joshua, using interfaces would be better. I’ve introduced the following interfaces:

• Solarium\Core\ConfigurableInterface
• Solarium\Core\Client\Adapter\AdapterInterface
• Solarium\Core\Query\QueryInterface
• Solarium\Core\Query\RequestBuilderInterface
• Solarium\Core\Query\ResponseParserInterface
• Solarium\Core\PluginInterface

In most cases there also is a base implementation of the interface that can be used to extend. But that’s entirely optional, as long as you implement the interface your object will be accepted. Also, in the various methods that use these objects checks have been added for the interface.
Hopefully this helps plugin development.

Simplified classmaps

Solarium uses classmaps for querytypes and for components in the select query. These maps where quite complex, for each type multiple classes had to be registered in an array structure. For instance each querytype has a query class, requestbuilder class, responseparser class and result class. This has been simplified to a single class, the query class. This class then has methods to get any other classes needed, all required methods are defined in the interface. A similar solution is used for select query components.
It makes the classmap simpler, and  allows for more flexibility in implementations.

More to follow…

The set of changes described in part 1 and this part is about the current state of development. More changes are still coming up, but they will take some time to develop. As soon as there is more news I’ll post another development update!

There’s already several months of work in the new version and it will take another few months to finish. There is no exact timeframe yet. I’m planning on highlighting several of the bigger changes in blog posts so you can get an idea of the direction Solarium is going. And you can take a look at the current code in GitHub, you can find it in the feature/nextgen branch.

Namespaces

First of all Solarium 3 makes use of namespaces. Igor Wiedler did a lot of work for this. It’s is very useful as some of the Solarium class names where getting very long. This raises the Solarium requirements to at least PHP 5.3. That shouldn’t be an issue, it’s about time to say goodbye to 5.2 and older versions…

Restructuring of files

Currently Solarium has quite a lot of folders. In some cases related files are spread over multiple locations. A good example are queries. Each query has one ore more classes in /query/[name], in /client/requestbuilder/[name], in /client/responseparser/[name] and in /result/[name].

In Solarium 3 each querytype has a single folder: /query/[name]. This folder has it’s own (sub)namespace and contains all files related to the querytype: the query class, the requestbuilder, the responseparser and the result class. Besides being a more logical way to group related files it also makes a lot more sense to do it this way when using namespaces. All files for a querytype are in the same namespace.

The plugins already had a special folder, but this contained both plugin implementations and a base class. This base class has been moved outside of the implementation folder and into the new ‘Core’ folder.

There are some other smaller changes, for instance the document classes have been moved from their own folder into the select and update query folders. You can browse through the new structure to take a look for yourself.

The folder layout now looks like this:

• Core
• Query
• Plugin

The ‘Core’ folder holds all the Solarium base classes. For instance things like the client, adapters and the base query classes.
The ‘Query’ folder holds all querytype implementations
The ‘Plugin’ folder holds all plugin implementations.

If you’re using the Solarium API you probably won’t notice the restructuring. But for anyone browsing or even working on the library code this should make things a lot more clear.

Code style

Solarium used underscore prefixes for protected methods and variables. This was inspired by the Zend Framework coding style, but in Solarium 3 this is no longer used. There are already visibility keywords and this should be enough, especially when using an IDE. It’s a matter of personal preference, but I think it also reads nicer.
The impact for must users is none, the public API has not changed.

More soon…

That’s it for now, the first three changes. But there’s a lot more that will be changed in v3. More development updates to follow soon!

In this second release candidate several minor issues have been fixed, but most importantly the parallelExecution plugin has been improved. The implementation in RC1 had two big issues: a busy loop was causing cpu load and there was no support for requests to multiple cores/servers. A fix for both issues has been included in RC2 and can now be tested.

Meanwhile documentation for the new features in 2.4.0 has already been added to the manual. The API docs have also been updated.

• New suggester querytype
• ParallelExecution plugin
• BufferedAdd plugin
• SequentialPrefetch plugin
• Support for parameter dereferencing (implemented in the join helper, see below)
• The query helper now has support for join
• Support for the new “hl.q” and “hl.phraseLimit” params was added to highlighting
• The request class now has a __toString method for easy debugging
• New formatDate method in the queryhelper