drupal 7

Multisite Apache Solr Search with Domain Access

Using one Apache Solr search core with more than one Drupal website isn't too difficult; you simply use a module like Apache Solr Multisite Search, or a technique like the one mentioned in Nick Veenhof's post, Let's talk Apache Solr Multisite. This kind of technique can save you time (and even money!) so you can use one Hosted Apache Solr subscription with multiple sites. The only caveat: any site using the solr core could see any other site's content (which shouldn't be a problem if you control all the sites and don't expose private data through solr).

There are two ways to make Apache Solr Search Integration work with Domain Access (one of which works similarly to the methods mentioned above for multisite), and which method you use depends on how your site's content is structured.

Solr Search with Domain Access - Siloed Content

If the content you are indexing and searching is unique per domain (just like it would be unique per multisite Drupal instance), then you can set up Domain Access to index content with a different Apache Solr hash per site, like so:

Hosted Apache Solr for Drupal

Midwestern Mac has been offering Apache Solr hosting for Drupal websites for the past three years, but this service has never been given too much attention or made easy to sign up for and use—until now!

Today we're announcing the re-launch of our service with a new website: Hosted Apache Solr.

Hosted Apache Solr home page - Drupal 7

The website was built on Drupal 7, and uses a custom base theme shared with Server Check.in (our server monitoring service built with Drupal and Node.js). We built a small payment integration module for PayPal subscriptions (though we're considering using Drupal Commerce, so we can use different payment processors more easily), and have built a very simple to use front-end for managing Solr core subscriptions.

If you don't know much about what Apache Solr can do for your site's search and listings, here's a one-sentence summary: Solr enables highly customizable and speedy content indexing, faceted and advanced search filtering abilities, and raw speed—indexing and searching are many times faster than database-backed search (like Drupal's default search or basic Views filtering).

Overriding a template file (.tpl.php) from a module

There are many times when a custom module provides functionality that requires a tweaked or radically altered template file, either for a node, a field, a view, or something else.

While it's often a better idea to use a preprocess or alter function to accomplish what you're doing, there are many times where you need to change the markup/structure of the HTML, and modifying a template directly is the only way to do it. In these cases, if you're writing a generic custom module that needs to be shared among different sites with different themes, you can't just throw the modified template into each theme, because you'd have to make sure each of the sites' themes has the same file, and updating it would be a tough proposition.

I like to keep module-based functionality inside modules themselves, so I put all templates that do specific things relating to that module into a 'templates' subdirectory.

In my example, I'd like to override field-collection-item.tpl.php, which is included with the Field collection module. To do so, I copy the default template into my custom module's 'templates' folder, and modify it how I like. Then I implement hook_theme_registry_alter() to tell Drupal where my template exists:

Migrating Drupal 7 users from site to site while preserving password hashes

From time to time, I use the incredibly powerful Migrate module to migrate a subset of users from one Drupal 7 site to another.

Setting up the user migration class is pretty straightforward, and there are some great examples out there for the overall process. However, I couldn't find any particular documentation for how to preserve user passwords when migrating users from D7 to D7. It's simple enough to set the 'md5_passwords' boolean for Drupal 6 to Drupal 7 user migrations, so passwords will be updated when a user logs in the first time on the D7 site... but it's not as straightforward if you want to simply move the salted/hashed passwords from D7 to D7.

During the migration, when the user account is saved, Drupal will re-salt and re-hash the already-hashed-and-salted password you pass in through your field mappings, and users will have to reset their passwords to log in again.

To override this behavior, you need to implement the complete() function in your user migration, and manually overwrite the just-saved user account password field:

Boost Expire module being deprecated; how to switch to Cache Expiration

BoostI'm a huge fan of Boost for Drupal; the module generates static HTML pages for nodes and other pages on your Drupal site so Apache can serve anonymous visitors the static pages without touching PHP or Drupal, thus allowing a normal web server (especially on cheaper shared hosting) to serve thousands instead of tens of visitors per second (or worse!).

For Drupal 7, though, Boost was rewritten and substantially simplified. This was great in that it made Boost more stable, faster, and easier to configure, but it also meant that the integrated cache expiration functionality was dumbed down and didn't really exist at all for a long time. I wrote the Boost Expire module to make it easy for sites using Boost to have the static HTML cache cleared when someone created, updated, or deleted a node or comment, among other things.

However, the Cache Expiration module has finally gotten solid Boost module integration (through hook_cache_expire()) in version 7.x-2.x, and the time has come for all users of Boost Expire to switch to the more robust and flexible Cache Expiration module (see issue). Here's how to do it:

Need to evaluate a Drupal module, theme, or distro quickly? [Updated]

...there's a site for that.

Simply Test.me Screenshot

I just found out about SimplyTest.me today, and it allows you to, well, simply test any Drupal.org-hosted module, theme, or distribution in seconds.

No longer do you need to spin up (or maintain) a live website locally (which usually takes an extra minute or two—at least) just to check out a module or make sure a theme or distribution fits your needs before using it on a live or development site.

Instead of simply getting a screen shot or trying a theme on a demo site, you get a full Drupal website set up and configured with the module/theme/distro (as well as it's dependencies), so you can play with it to your heart's content (for 30 minutes if you don't have an account on the site, an hour if you do).

According to the site's Q&A page, Drupal 6, 7, and 8 are all supported—even with sandbox projects! You can read more about the architecture and service implementation on the simplytest.me project page on Drupal.org.

Check it out, and thank Patrick Drotleff and all the sponsors (who help provide the hosting) for the hard work on this awesome tool!

Pages

Subscribe to RSS - drupal 7