[meta] Important project announcements

Also important for non-developers: #1190324: Adapt to API change in Entity API.
If you are using the dev version of Search API, you'll also need the dev version (or Beta 9) of Entity API!

See #1064884-27: Add support for indexing non-entities for a major API change looming ahead, and please help testing it!

Please see #1222630: [meta] Stable release for a discussion on when to create the 1.0 stable release.

Due to the commit of #1064884: Add support for indexing non-entities, it is important to run update.php right after updating to the latest dev version of Search API!
See #1227702-1: Improve error handling for fixes if you didn't read this on time.

For everyone attending the upcoming DrupalCon: I'm planning to schedule a Search API BoF there. If you are interested, you can help me find the best time slot here.

For those attending DrupalCon: The BoF is on, Thursday, 08/25, ~12:20 – 13:30.

Just had a great Search API BoF yesterday and, guess what: There are new stable release blockers, yay!

#1260768: Move "Search pages" into its own project
#1260812: Move "Database search" into its own project
#1260834: Add a way to define custom data types

Comments welcome there (the last one is not very controversial, though).

If you are interested in data source controllers (i.e., providing your own data types), the Search API architecture and/or integrating with external data, the following issue might be interesting for your (and your thoughts on it would be much appreciated): #1264418: Make data source controllers index-dependent.

#1308638: Reduce size of stored index settings will weed out anything from $index->options['fields'] that isn't set by the user and can't be inferred, being a not too small API change, especially for server backends.

Thanks for linking to the documentation, I couldn't for the life of me find that! I was already aware of the feature though. However, as it seems there isn't a way to subscribe to change records (please correct me if I'm wrong) I still found this approach more practical.
Furthermore, this also allows to notify people of changes before they occur, giving them the opportunity to discuss or help with them. Also, pointers to other discussions or important issues/pages are possible this way.

Remembered another stable release blocker: #1330506: Remove the old Facets module.
I guess this should be done before a stable release. If you don't think so, please comment there.

However, on the plus side we are almost down to zero in the blocker list (#1308638: Reduce size of stored index settings is just open for non-blocking follow-ups and the others could be committed right away) so there's almost definitely gonna be an RC this week.
Finally.

Please help me with my (hopefully happening) DrupalCon session: #1555808: Brainstorming for my DrupalCon session.

#1528436: Support exportable entity types will change the stored data type of entity references if the entity in question uses string keys for identification (e.g., most exportables). Those were broken before, so if you didn't have any problems, this won't affect your site.
However, module maintainers might want to check their modules whether they make that assumption (entity key = integer) anywhere currently.

Also, additional testers would of course be welcome.

Please see, read and (if you have an opinion or some arguments) comment on #1390598: Add a way to easily identify facet filters inside the query, which contains a small API change/addition (which would probably mostly only affect maintainers of service classes).

If you're coming to DrupalCon Munich, you might be interested in these:

• Search API and Facet API session (mainly for sitebuilders new to the Search API, though)
• Search API BoF (for more advanced discussions)

Not relevant to the Search API in general, but important enough for all Solr users, I guess: in #1846254: Remove the SolrPhpClient dependency I aim to finally remove the SolrPhpClient dependency from the module and thus get it (finally!) ready for a stable release. Please help by testing any functionality you are using (or more, if you want to)!

Especially important for maintainers of service classes: #1783746: Add support for "between" operator would add – the title probably gives it away – a between operator for use in Search API queries. This is necessary as combining >= and <= leads to unexpected/undesired results for multi-valued fields, thus constricting functionality.
I'd love to get this in, but it would be an API change, or at least add a feature. So please keep this on your radar, and provide feedback if possible.

Two other issues which would introduce (almost completely backwards-compatible) API changes are #1760706: Add a flexible way for determining whether an index contains entities and #1720348: Add the concept of query extenders. These could also use some additional eyes, or hands.

Just realized that, since #1783746: Add support for "between" operator also changes the filter handlers of the Search API Views module, developers who have written their own filter handlers based on those might be affected, too. I tried to mitigate that in my revision of the patch, but please see, review and test yourself, and possibly prepare to update your own code accordingly.

As some of you might have noticed, I finally cracked down on old issues in the last weeks, especially on ones in "needs review" (or even RTBC), and managed to commit/fix a lot of them.
However, my issue queue is … long (about 750 issues currently), and going through all of them isn't really feasible. Therefore, I wanted to ask everyone's help:

• If you have an open issue for one of my modules (or are interested in one), please review whether it still applies (Is it fixed in latest dev? Are you still interested in it?) and either close it or bump it as applicable.
• If you have no (more) old issues and still want to help me a bit, just go through a few old ones, ask whether they still apply (or just close them if they clearly don't) and set them to "postponed (maintainer needs more info)". Testing/reviewing some patches, trying to reproduce problems or answering questions would of course be even better, but just asking whether issues still apply will help me a lot.

I want to apologize again for being unable to keep up with new issues for so long. I know it's very frustrating to feel completely ignored when you create an issue (especially if you provide a patch). But, as you see, I just get a lot of issues and sometimes I'm just too busy to review all new ones and things pile up.
But now's the chance to get your issues resolved, so please help out! ;)

In #1184610: Limit indexes to specific entity bundles (an issue slightly older than this one, which even made it into the FAQ) it has now been proposed to move bundle-restrictions on the indexed items from the "Bundle filter" data alteration to a direct setting for the index itself.
This would lead to a medium-sized API change for data alterations and maybe some other code. If you think this could affect you, or have something to contribute to the discussion (even if it's just a "+1" so I see how sought-after this is), please go to that issue.

#1414078-25: Revert of exportables not working would change the way reverts of servers and indexes are handled (calling update hooks instead of delete and insert hooks). Especially service class maintainers should make sure their modules are compatible with the changes. And users working with features should probably also test the patch and check whether everything works as expected.

I again proposed sessions for Drupalcon Prague, two this time. Please see if they would interest you:
One for site builders
One for developers
If you have feedback for me, please comment there or use #2038731: Search API session(s) at Drupalcon Prague. (I would love to hold both or either of these sessions, so I proposed both for now to see which would get accepted.)

I've now kicked off development of the D8 branch of the module: #2044421: [meta] Upgrade to Drupal 8.
Since D8 still makes me sit in the corner sobbing if I look at core code for more than a few minutes, any help (be it coding or just advice) would be greatly appreciated!
Also, I want to use the D8 branch for various changes in the module's architecture and API. Discussing these might be also interesting for non-developers and people new to D8. I'm also open for suggestions from others – so if you are dissatisfied with any aspect of the current API, please complain (or rather, link to an issue where you complain) there.

(oops sorry, force of habit... not sure how to delete this now... i'm an idiot)

That happens, no worries. ;) And you can't delete comments on d.o, you'd have to contact a webmaster for that (if it was that important).

On a different note, Bojhan Somers has kindly agreed to do a usability review – see the issues tagged "Usability". If you have an opinion on any of them, please chime in!
Also, of course, also create issues for usability problems you yourself encountered in the module!

#2115127: Index logic does not add failed items back to the queue or does not retry might overhaul the queuing/cron/indexing mechanisms of the Search API. If you have some opinion or suggestions for that, deeper knowledge of cron queues or some special setup for indexing with cron that could be in danger, please participate there!

Sorry for the increased frequency here, it just means I'm working hard on improving this module! ;)

#1551302: Fix server tasks system would overhaul the current system for disabling/disabled servers. If you have a use case for shortly disabling servers, are otherwise interested in it or are even (God help us all!) using the search_api_tasks variable in custom code, please participate in that issue! (Only the last comments, starting today, are relevant for what would get changed.)

Updated issue summary.

Is anyone here really using the performance key of search results? If so, please comment at #2044393-1: Changes in search query functionality. Otherwise, this will probably go in D8 – it's just unnecessary cruft, even though small.

A short heads-up: I will be on vacation from Christmas through the end of February, so support for my modules will be severely limited in that time.

The good news is, the vacation brings me (by pure luck) to New Zealand in February, so I will attend and speak at Drupal South 2014 in Wellington. The session, like those in Prague and Vienna, will focus on beginner site builders, but if you haven't seen those and aren't a complete Search API pro, there might still be some interesting information in there.

After the last effort sadly ground to a halt due to a lack of time, I plan to properly kick off development on the D8 version of the Search API (again) at the Dev Days in Szeged.
So, if you want to help, or have your opinion heard, Szeged is a good place to go!
Here's the full story.

Also, there's a new issue just for posting ideas for the D8 version: #2160029: Ideas for the Drupal 8 version. What do you wish to be different about the Search API? What would you change? Provide your ideas there! (Or, of course, just create a new issue.)

As announced above, I will in the next days leave on vacation until the end of February.
I have created new releases for the Search API as well as the DB and Solr backends. These new releases should hopefully not introduce new bugs and should be used in these coming months. (Also, maybe take extra care this time when updating to not run into problems afterwards – I can't offer support at the moment if you do.)

I have then committed some more "dangerous", lesser tested patches for the Search API and Solr modules to their dev versions. You might want to try those out (locally or on a test server), too, since they do offer several improvements and new features, and should also stay "stable" for the next two months. This way, you can also help me make sure they don't contain any new bugs or regressions before creating new releases for those modules.
(The patches #2155767: Improve the speed of full text searches by using a single index table and (very unlikely) #2007874: Performance issues with multivalued (list) fields and multiple OR filter for the Database Search might follow before I leave.)

Wow, this has gone quite quiet in the last year …
Anyways, again an advance warning: I will be on vacation from December 24 through about January 20, so don't expect any official responses to issues in that time.

I've just discovered a bug I introduced in #2450333: Increase performance of indexing entity references. It should already be fixed with the follow-up, but before I create a new stable release (which I wanted to do in the next few days) it would be great if a few other people could take a look and make sure things don't break for them in the latest dev release.

And another bad bug, this time in the much sought-after "bundle" setting for indexes/datasources: #2520684: Bundle-specific indexes with "Index items immediately" will index other bundles.
On the other hand, there's potentially excellent news for people who want to create a site search with Search API: #2520934: Add an item type for indexing several types of entities in one index.

Since both of these issues are quite "high profile" (I'd say) and I'll probably create a new release soon after they have been committed (so the bug is fixed as fast as possible in the stable releases), it would be great if I could get some thorough tests/reviews for both! Especially, please make sure the Views bugfix in the second issue doesn't break things on your site.

Huh, completely forgot that this existed. Should remember this more often again, sometimes more feedback would be really helpful.

Anyways, if you are using Drupal 7 and care about exception handling, your input in #3154538: Unhandled PDOException on db_update in trackItemChange would be appreciated. (I’m always rather worried about changing exception handling behavior.)

I think #3214236: How to change input type from "text" to "search" might have the potential to break the search forms on some sites, by changing the form field type for the fulltext search keys in Views from textfield to search. While I’m pretty sure the change is a good idea regarding semantic markup, I’m not certain how to best implement it without breaking sites whose CSS, JS, alter hooks, …, might depend on the current type.
(Search API Autocomplete complicates this even further: #3228546: Allow "search" form element for Views search fields, too.)

Any input would be welcome! (Including things like, “Just don’t bother, not worth the trouble.”)

DamienMcKenna suggests changing the default type for newly added string fields (that is, Core data type string) to Fulltext instead of String.
As both can be potentially confusing for some fields, I’d appreciate input on which of the two is less confusing: #3224311: Make string fields default to "fulltext" field type.

• #3260862: Add a $add_directly parameter to QueryInterface::createConditionGroup() would make Query::createConditionGroup() a bit more user-friendly, but require changes to all code using it before a Search API 2.0.0 release. I’d appreciate input on whether or not to make this change.
• In case you’re actively using the search_api_base_path query option added by our Views integration, please go to #3243313: Any view with a path is always cached per route and stop me from removing it.