Let’s discuss the best practices for general index management during website development and how to best launch a new website powered by Algolia Search and WebDevStudios’ own WP Search with Algolia. If you’re considering or have already decided to enhance your WordPress website’s search with the power of Algolia, that’s great news! Using our WordPress plugin, WP Search with Algolia, is even better for connecting that bridge. All of it together helps you create magic!
So, let’s get started by diving right into the topic of WP Search with Algolia index management.
Indexes for Local vs Staging vs Production
While not set in stone, on any professional site build, especially if multiple developers are involved, these are the three most likely copies of the website at any given time.
- Local: You have local copies of the site for each developer to do their own work in isolation.
- Staging: You then also have a staging copy where everything converges for testing and review.
- Production: Then you have the production site, which is where everything shines, and you’re getting all your traffic.
With WP Search with Algolia, there are two ways to define the index prefix that gets used for a given site. First, there’s the field presented on the Settings page of the Algolia Search menu, and this defaults to wp_.
There is also a PHP constant that you can set named ALGOLIA_INDEX_NAME_PREFIX. This can be set within the wp-config.php file for the install, or, ideally, in a mu-plugin file. Whenever the constant is defined, the settings page field becomes uneditable and reflects the value from the constant.
When to Use the Setting Option vs PHP Constant
PHP Constant
With developers doing their own coding on their local installs, and due to the potential for having considerable differences in content between the sites, giving them their own index prefix that is not a part of the database would be the way to go here. Have the developers define their own ALGOLIA_INDEX_NAME_PREFIX constant in a file that is not part of version control. For example, I would define this prefix: define( 'ALGOLIA_INDEX_NAME_PREFIX', 'mdb_local_' );
Setting Option
With the developers being given their own sandbox indexes to work with, we’re now on to the staging and production sites. The setting option becomes more prominent here.
Since active development is not being done here, and more of the quality assurance testing and review, it makes more sense that the database setting option can be used. Perhaps something like mysite_staging_ and then the same pattern for the production site, mysite_production_
What about using a constant for staging and production as well?
This is a good point and one that could go both ways, really. This could depend partly on how often database syncs may happen, if at all. If part of the workflow pushes database content from staging to prod or vice versa, using the constant for these environments makes sense so that you don’t accidentally overwrite the setting and point an environment to the wrong index set.
It really depends on how content flows occur in the long term.
There are more than just the
ALGOLIA_INDEX_NAME_PREFIXconstant available. You can also define constants for the App ID and API keys, and the settings page fields also become uneditable for those. Read more at WP Search With Algolia Wiki: Constants.
Indexes for Single Site vs Multisite
We have technically already covered a single site above, but what if you’re running a multisite? Whether you’re putting all of them into one Algolia app or multiple apps, locals, staging, and production copies of the network will still be the focus.
Here, you will also likely want to separate indexes on a per-site basis. You wouldn’t want to mix content from all the sites into one index that each site then pulls from. It’d be data pandemonium!
We can use WordPress code to help construct some constants, whether used just for developers’ locals or across all environments. For this example, we are going to include the current site ID as part of the constant.
define( 'ALGOLIA_INDEX_NAME_PREFIX', 'mdb_local_' . get_current_blog_id() . '_' );
If you want to use this for staging and prod, then you’d adjust it as such: 'mysite_staging_' . get_current_blog_id() . '_' and 'mysite_production_' . get_current_blog_id() . '_'.
If you are using the options for at least staging and production, you can put whatever value you want to differentiate which site it is in the network, but the blog ID is a good one to consider.
Launch Time
So, you have finished working on your website and are ready to push everything live. You go through the process, merge all the changes into your production branch, and prepare to click the deploy button…
WAIT!!!
Before you deploy anything into production, let’s review some situations where your new search experience may break upon complete deployment.
- Your Algolia search templates rely on newly indexed fields that are not in the index quite yet.
- You have any sort of custom plugins that modify WP Search with Algolia hooks to customize what data gets pushed to your index.
- If a new version of WP Search with Algolia gets released and the changelog mentions breaking changes.
Preparing the Site for Algolia-Specific Steps
For the sake of this post, we’re going to assume that without Algolia integration, your site search still shows just fine, and the results show in a functional way. It’s just not powered by Algolia yet.
Before deploying all of the new changes and database content, disable the Autocomplete and Instantsearch settings. This will allow the search to still technically work while you handle some chores after deployment.
Once the deployment is complete, we can index the new site copy in the appropriate places. The settings don’t need to be enabled to handle indexing. If you’re dealing with a really large site, it could take a little bit to complete indexing, and if the features were enabled during that process, they would appear broken or return no to minimal results.
Once you’ve finished indexing and confirmed the results in your Algolia Dashboard, we can re-enable the Autocomplete and InstantSearch settings, unleashing the power of Algolia Search to your visitors! This is a feel-good moment, my friend.
Steps Summary
- Make sure you’re utilizing prefixes for each site environment.
- Disable Autocomplete and Instantsearch before deploying changes, ensuring that basic search still works without them.
- Deploy the production-ready changes.
- Ensure your production index prefix is accurate.
- Re-index your content for both Autocomplete and Instantsearch experiences.
- Once re-indexed, re-enable Autocomplete and Instantsearch.
- Celebrate a successful launch with a brand-new search experience.
Conclusion
I hope this post has been helpful and insightful in helping to create a wonderful developer experience during all stages of a project integrating Algolia Search and launching the project.
If you have any questions, feel free to ask in the comments below. If you’re interested in collaborating with our parent company, WebDevStudios, and the developers behind WP Search with Algolia to create your own Algolia Search experience, you can contact them via their Contact page.