Because we often use the WP Search with Algolia plugin on client projects, we make it a continuing education priority for all of our engineers. That includes me! Here’s what I want you to know about WP Search with Algolia.

First, what is Algolia?

Algolia is a site search platform that gives your website visitors a fast and useful search experience. It allows your site’s visitors to find information through search suggestions and to refine their search using facets, which are filters that allow users to narrow down their search results quickly.

Example facets of an eCommerce store might be brand, price, color, etc. It uses a powerful and fast algorithm that returns results quickly. Algolia’s analytics make it easy for site owners to refine search rankings and see how people are using search.

Algolia’s technology allows developers to interact with its API to build robust search functionality. It also provides tools for building and customizing search experiences, through analytics, search ranking, and personalization. 

Why should my site use Algolia instead of the native WordPress search?

WordPress’s out-of-the-box search is a simple keyword search across all content on your site, output into a single, long list with no way to filter or prioritize results. On larger sites with a lot of content, it can be slow.

Algolia improves your website’s search functionality in a number of ways:

1. Speed: Algolia’s search is faster and more accurate than WordPress’s built-in search, which can be slow and return irrelevant results.
2. Customization: Algolia allows for more customization of the search experience, with the ability to sort, filter, and display results in various ways. Content can also be weighted, so specific types of content are always shown first. For example, events can be displayed on an event-focused website before pages or blog posts.
3. Scalability: Algolia can handle large numbers of search queries and a large amount of data, which is good for websites with a large amount of content.
4. Analytics: Algolia provides analytics and search insights that can help website owners understand how users interact with their search and website more generally.

WP Search with Algolia

Now that you know why Algolia should replace your WordPress website’s default search engine, how do you integrate Algolia into your WordPress website? WebDevStudios’ WP Search for Algolia plugin is the best plugin to integrate Algolia search engine into your website.

Originally developed by Algolia, we forked the plugin once they ceased development, and have been developing and maintaining it since. It allows you to index your WordPress content and use Algolia’s powerful search engine to provide your users a fast and accurate search experience.

WP Search with Algolia is easy to set up and manage in any theme without having to touch your theme’s files or know how to use the API. To get started, all you need is an Algolia account and API key.

Key features of the WP Search for Algolia plugin include:

• Indexing of posts, pages, and custom post types
• Automatic syncing of the index with your website’s content
• Customizable search results template
• Typo-tolerance and synonyms support
• Faceted search
• Search analytics and insights

Customizing WP Search with Algolia

Out of the box, WP Search with Algolia works great to improve your website’s search performance. The ability to customize search using Algolia’s API makes the plugin more powerful.

WebDevStudios used Algolia to implement an eCommerce search for a recent client that bridged the gap between two data sources. The client pushed a lot of product data into Algolia from a non-WordPress source. Rather than forcing the data to flow through WordPress, our website design and development team adapted and customized the search on the WordPress side and we were able to provide a seamless search experience for their customers.

On another client site, we used WP Search with Algolia to improve the search results page by separating content types—products and pages—into two separate pages. Separating the two types of content allows users to drill down their product searches by filtering via facets, which isn’t needed for on-page search results.

Try the plugin and let us know how your WordPress website search improved!

The post WP Search with Algolia WordPress Plugin Benefits appeared first on WebDevStudios.

However, as we’ve begun entering content, we realized that we can make improvements to the editing experience for the client. In this blog post, we outline how by optimizing the WordPress Block Editor experience, we make it easier for editors to perform their jobs.

Background

The set of websites contains one main site and many subsites. We created several custom post types to handle a variety of content, some of which exist on both the main site and the subsites.

All custom post types contain meta fields, created with Advanced Custom Fields, which are used to add custom content to the post. Additionally, we use the content from two post types from the main site on the subsites.

To build the blocks for this website, we used Advanced Custom Field (ACF) blocks. For a Headless WordPress website, ACF makes it easy to structure data the way we want on the frontend, with minimal extraneous information.

Because of the complexity of information and the challenges of building a headless site, we wanted to make sure the editing experience was as straightforward as possible. We identified five ways to make improvements, optimizing the WordPress Block Editor. It’s all detailed below.

Instructional Text

When creating the blocks, we made sure to clearly label each field and add instructions for editors. We included information like image dimension requirements, character or word length limits, and location specifications (sidebar, main content, etc.).

With these instructions, editors can easily jump in and edit the website. They don’t need to search for documentation or be trained. This detail is especially important with 20+ subsites, each with different editors in different locations.

Tabs in Blocks

Advanced Custom Fields provides several layout fields, allowing you to organize content. We leveraged the tab field to separate sections and let users enter specific content in each tab.

For example, if we build a block that contains event details and a sponsor, we can create two tabs. One is for the event information, such as venue, time, etc. The other tab is to input the event’s sponsor information, such as the sponsor’s name, logo, and link.

This sounds so simple and obvious, yet this makes it more convenient than usual for users to add content. Would you prefer a long form where you scroll up and down in the editor or a tabbed block?

Leveraging the power of tabs keeps the user interface and experience better, which allows for optimizing the Block Editor experience for the editor.

Dropdowns

To decrease the chance of human error, we identified places where a dropdown select menu should be used instead of a text field.

Using Advanced Custom Fields, we were able to create custom dropdowns generated from post types and meta fields. For example, we have a block on the subsites that needs to return the ID for an organization, which is a custom post type on the main site.

Initially, we created a Text field for that input, but realized that it opened the door for user error. We changed the Text field to a Select field and queried the organization post type on the main site to get the organization ID from the meta field.

This allowed us to create the options in the Select field with the organization name as the display and ID as the return value. Using a Select field in this way significantly reduces the likelihood of human error, and allows for a more bespoke user experience on the backend.

Readonly Fields

Another way we have addressed the possibility of human error is through ‘readonly’ fields. This is helpful when you want to keep data intact on fields like identifiers imported from an API that doesn’t require any manual editing. The user can view the field values and confirm that content has been entered, but cannot change them.

Frontend Previews

ACF blocks are great for creating complex blocks quickly, but the editor loses the Gutenberg experience of seeing a styled block as they’re building a page. Additionally, since we’re using ACF blocks in a Headless WordPress website, an editor can’t see a preview of the page and blocks they’re editing in the Gutenberg editor.

That’s because the website doesn’t use a standard WordPress theme. Plus, the CSS, Javascript, and PHP aren’t pulled into the preview.

To solve this problem, we included a screenshot of the block as a tab, but our lead developer developed functionality that displays an iframe of the block from the frontend when the “Switch to Preview” button is toggled when editing the site. This lets editors preview the block with the content they’ve entered before saving the page.

Conclusion

Working on this complex site reminded our team that not only is frontend usability important, but the editor user experience is also equally important. If an editor can’t enter content correctly, it doesn’t matter what a website looks like or how it functions.

This brings us to the end of learning the ins and outs of optimizing the WordPress Block Editor experience. We’d love to know the steps you take to improve the editing experience for your WordPress websites. Please tell us in the comments below.

The post Optimizing the WordPress Block Editor Experience appeared first on WebDevStudios.

Beyond developing websites, I was responsible for making any development related decisions—from what tools were best for our clients down to whether a project was even feasible for our company. Since the rest of my team were non-technical, it fell to me to know the answers.

Then I started at WebDevStudios, and asking questions as a website developer became a necessity. From “How do I even use git?” to “What’s the best way to register this ACF block?” to “Does anyone have any idea how to make this search results listing page work how the client wants,” I had to become comfortable asking questions.

Luckily, the team here at WebDevStudios is great at answering questions.

Why is asking questions uncomfortable?

For me, asking questions as a website developer makes me feel like less of an authority. I like to know the answer and to have the answers, not ask someone else how to do something.

I certainly Googled and Stack Overflow-ed my way around, but never posted a question. I never asked questions on Twitter or asked people within my network.

Another reason why asking questions is so uncomfortable as a developer is that in the web development world, there’s also this attitude of developers needing to be “rock stars” or “ninjas” who can jump right in and have all the answers and write all the code.

That’s great in theory, but I think in practice, it can be intimidating for developers who have questions. When you’re learning a new language or framework or even just setting up a project in a new way, being afraid to ask a question can be a big roadblock to advancing your knowledge, and thus your career.

How I learned to ask questions

Joining WebDevStudios, I had to get comfortable asking questions. How? I told myself two things:

1. There are no stupid questions.
2. You know what you’re doing.

Number 1 is important because if you think your question is stupid, you’ll never ask it. That was the biggest hurdle for me to get through.

Joining a team of helpful engineers helped with this immensely. Instead of Googling hoping to find a result, I can post in the project Slack channel or general engineers channel and get an answer or jump on a Zoom with another engineer to talk through a solution.

Seeing my teammates model that behavior helped too. Every single engineer at WebDevStudios asks questions, at all levels. Senior, junior, lead, manager, director, at some point I have seen everyone pop into Slack and ask a question. In return, everyone is around to answer questions or rubber duck to find a solution.

Number 2 is important because it reminds me that not knowing an answer doesn’t mean I’m not good at my job or up to snuff as a developer. I don’t need to be the authority on WordPress or JavaScript or CSS to do my job. When I started, my manager assured me that all I needed to do was work within my skillset and I could ask questions when necessary.

Why should you ask questions as a website developer?

First, the obvious: asking questions gets you the answer you need without ending up on page 25 of Google. It saves time, which is great for you, your team, and the client.

Second, when you’re on a team and you ask a question, the answer becomes shared knowledge. Maybe your rabbit hole search into Stack Overflow was successful, but then only you know the answer to that question. By asking questions in a Slack channel (or other group setting), everyone on the team can see the answer and refer to it if then encounter something similar.

Third, you’re on a team with a variety of skills and experience. Someone on your team has probably used whatever language or tool you’re asking about. You can and should make use of their firsthand experience. No single person can know everything about everything.

Finally, asking questions helps you become a better developer. By asking questions, you learn to talk about your code, explain how things work (or don’t work!) and communicate what you’re trying to do.

Personally, sometimes just talking through my code with someone else helps unblock me. While you may find a code snippet that works via a forum, copying and pasting doesn’t truly help you understand why you had a problem with your code or how the snippet you pasted in actually solves your problem.

How to ask questions

The key is to be as specific as possible. Telling someone that whatever you’re working on isn’t working with no context wastes your time and theirs. Your teammates are taking time out of their day to help you, make sure you make it easy for them.

Some things I include when asking a question:

• Context to the issue (For example: it’s happening locally but not on dev; it started happening after I upgraded WordPress to X version; etc.)
• Error messages in the console or browser
• Code snippets or screenshots
• Things I’ve already tried
• Lastly, thank the person or people who helped you out. At WebDevStudios we do this via virtual tacos in Slack.

Conclusion

Don’t be afraid to ask questions. Remember that there are no stupid questions. Not knowing the answer doesn’t mean you’re not a great developer, it means you’re human.

If you’re interested in working on a team where you can feel comfortable asking questions, we’re hiring! Or, if you’re interested in working with a website developer that welcomes your client questions, contact us today.

The post Asking Questions as a Website Developer appeared first on WebDevStudios.