Previously, this series covered WP Search with Algolia settings and index management (Part 1) and template customization (Part 2). If you haven’t read either, it’s worth going back to them since today’s blog post builds on the code provided in those.

Let’s begin.

Facet(s) configuration

Algolia comes with many useful widgets and facets for integrating InstantSearch with your business or website, allowing you to create robust UI for your users. Find quick demos of all of them over at their Algolia Showcase.

By default, WP Search with Algolia (WPSwA) makes use of the following widgets:

• Searchbox: The user types in a query
• Stats: General statistics regarding the current query
• Hits: The results for the current query
• Pagination: Navigation to move through any paged results
• Menu: General list menu
• Hierarchical menu: Menu that will nest items based on parent/child hierarchy
• Refinement list: List of content types that can further refine results
• poweredBy: A touch of branding when applicable

You could also add some extra useful widgets like a “sort by” dropdown, a “clear all” toggle to clear currently applied refinements, numeric menus, range inputs or sliders if you have some number-based attributes, a rating menu, and various other types. There is plenty to work with to fit your needs.

For the purposes of our integration with WooCommerce, we will focus primarily on the refinement list widget for finding just the products we want.

One of the WooCommerce attribute types I have in my demo site is “color.” This has resulted in a product attribute of pa_color and right now it has three terms in it.

To get this added as a widget we can further refine results with, we need to get some markup in our instantsearch.php file to render the widget. To start, we will add this below the Users section of the sidebar area. For our example, we’re using facet-color for our ID which we will need in a moment. You can use whatever ID value you want though.

<div>
	<h3 class="widgettitle"><?php esc_html_e( 'Users', 'wp-search-with-algolia' ); ?></h3>
	<section class="ais-facets" id="facet-users"></section>
</div>
<div>
	<h3 class="widgettitle"><?php esc_html_e( 'Color', 'wp-search-with-algolia' ); ?></h3>
	<section class="ais-facets" id="facet-color"></section>
</div>

Next, we need to configure the widget itself. This will go in the search.addWidgets([ ... ]) block of our template file.

search.addWidgets([

	...
	/* Search powered-by widget */
	instantsearch.widgets.poweredBy({
		container: '#algolia-powered-by'
	}),
	
	instantsearch.widgets.refinementList({
		container : '#facet-color',
		attribute : 'taxonomies.pa_color',
		operator  : 'or',
		limit     : 5,
		sortBy    : ['isRefined:desc', 'count:desc', 'name:asc'],
		showMore  : true,
	}),
]);

Here we will need the ID that you used with the widget above. We want to specify it in the container property, so that Algolia can find the div and render the refinement list widget.

Next, we need to tell the widget which indexed attribute we want to reference here. That is where taxonomies.pa_color comes in. Specifying this attribute informs Algolia to fetch all the indexed terms from the pa_color attribute, that match the determined results for a given search.

By default, WPSwA will include WooCommerce’s product_cat, product_tag, and various created attributes assigned to your products, so these should be available as soon as you index the product WooCommerce post type.

The operator property can be used to indicate which attributes should be associated with an item to be listed when refining. In this case, we use “or” to say “the product must have this attribute OR this attribute,” meaning any of the checked attributes.

If you set this value to “and,” then it turns to “the product must have this attribute AND this attribute” to be shown, meaning all of the checked attributes.

The sortBy tells in which order the refinement list items should be listed. By default, WPSwA puts “isRefined” items first, which would be if an item is checked, that item moves to the top of the list.

Next, it orders them by item with the most results available first, and then any with matching amounts shown alphabetically. Toy around with the sort order and see which display type you prefer most.

Lastly is the limit and showMore properties. If you specify a limit without showMore or showMore set to false, then Algolia will only return the amount specified by limit.

However, if you set showMore to be true, then the limit will be how many it shows before offering a button to select to show the rest of the found attribute items. You can read about all the refinementList properties in the refinementList documentation.

With these settings in place for the widget, we should see something like this below.

Most of the default widget sections in the WPSwA template and instantsearch.php don’t make sense for our purposes. You can keep them if you want, but I’m going to remove them for the rest of this article.

This will result in our facets <aside> looking like this below (about lines 27 through 32), ready for more additions as needed for widgets that make sense.

<aside id="ais-facets">
	<div>
		<h3 class="widgettitle"><?php esc_html_e( 'Color', 'wp-search-with-algolia' ); ?></h3>
		<section class="ais-facets" id="facet-color"></section>
	</div>
</aside>

This will also result in a reduction of our search.addWidgets([ ... ]) section as below. I have concatenated some parts within longer widget sections for brevity.

search.addWidgets([
	/* Search box widget */
	instantsearch.widgets.searchBox({
		container: '#algolia-search-box',
		placeholder: 'Search for...',
		showReset: false,
		showSubmit: false,
		showLoadingIndicator: false,
	}),

	/* Stats widget */
	instantsearch.widgets.stats({
		container: '#algolia-stats'
	}),

	/* Hits widget */
	instantsearch.widgets.hits({
		container: '#algolia-hits',
		hitsPerPage: 10,
		templates: {
			empty: 'No results were found for "<strong>{{query}}</strong>".',
			item: wp.template('instantsearch-hit')
		},
		transformData: {
			item: function (hit) {
				...
			}
		}
	}),

	/* Pagination widget */
	instantsearch.widgets.pagination({
		container: '#algolia-pagination'
	}),

	/* Search powered-by widget */
	instantsearch.widgets.poweredBy({
		container: '#algolia-powered-by'
	}),

	instantsearch.widgets.refinementList({
		container : '#facet-color',
		attribute : 'taxonomies.pa_color',
		operator  : 'or',
		limit     : 5,
		sortBy    : ['isRefined:desc', 'count:desc', 'name:asc'],
		showMore  : true,
	}),
]);

You can add as few or as many extra widgets as you want to be based on the needs of your store. Just make sure to remember to create the container markup so that Algolia can render the widget, and accurately specify the attribute to use for the given facet.

For a quick extra attribute demo, I’m going to add one more named “Size,” using the same steps above, resulting in these two additions. This time though, I have changed the sortBy to have just “isRefined” first, followed by the name in ascending order. I have removed the sort by count.

<aside id="ais-facets">
	<div>
		<h3 class="widgettitle"><?php esc_html_e( 'Color', 'wp-search-with-algolia' ); ?></h3>
		<section class="ais-facets" id="facet-color"></section>
	</div>

	<div>
		<h3 class="widgettitle"><?php esc_html_e( 'Size', 'wp-search-with-algolia' ); ?></h3>
		<section class="ais-facets" id="facet-size"></section>
	</div>
</aside>

instantsearch.widgets.refinementList({
	container : '#facet-color',
	attribute : 'taxonomies.pa_color',
	operator  : 'or',
	limit     : 5,
	sortBy    : ['isRefined:desc', 'count:desc', 'name:asc'],
	showMore  : true,
}),

instantsearch.widgets.refinementList({
	container: '#facet-size',
	attribute: 'taxonomies.pa_size',
	operator : 'or',
	limit    : 5,
	sortBy   : ['isRefined:desc', 'name:asc'],
	showMore : true,
}),

Replacing Shop and Product Category Archives with Algolia

This section of this tutorial on WP Search with Algolia InstantSearch widget and facet customization may be our greatest trick! Ready?

We are going to replace both the shop page as well as product category archives, i.e. /product-category/inflatable-toys/, with our overall Algolia Instantsearch UI.

With the shop landing page, we will present everything as if no specific query has been made yet, while with the product category archive will be limited to the products that would be originally listed there.

Loading Necessary Scripts and Styles

To accomplish this, we must first create a couple of template files and also enqueue some assets. First, we will get our assets loaded. This will help make sure we have the scripts and styles needed.

function woo_product_cat_algolia_assets() {
	if ( ! is_product_category() && ! is_shop() ) {
		return;
	}

	wp_enqueue_script( 'algolia-instantsearch' );
	wp_enqueue_style( 'algolia-autocomplete' );
	wp_enqueue_style( 'algolia-instantsearch' );
}
add_action( 'wp_enqueue_scripts', 'woo_product_cat_algolia_assets' );

Here we’re checking if we’re on a product category or the shop page, and if not, just return early. If we are, then we enqueue our InstantSearch JavaScript and CSS, as well as our autocomplete CSS.

Template Overrides

Next, we need to create the following files in our theme:

• archive-product.php
• taxonomy-product-cat.php

Since these file names follow the WordPress template hierarchy, they can be dropped directly into the theme folder.

For my example, they will be twentytwenty/archive-product.php and twentytwenty/taxonomy-product-cat.php. Inside both files, we just need to load our instantsearch.php file instead of what would be loaded by WooCommerce.

Below should be the complete template files needed to work for both.

<?php

if ( ! defined( 'ABSPATH' ) ) {
	exit; // Exit if accessed directly.
}

require_once Algolia_Template_Utils::locate_template( 'instantsearch.php' );

If all went well, then visiting your shop landing page and any product category should now be showing Algolia-based listings.

Product category customization.

Before we can call ourselves done, we need to configure the product categories just a little bit. We want these to be limited to just products within that category.

To accomplish this part, we need to get some WordPress query details added to our inline scripts. We are going to add to our woo_product_cat_algolia_assets callback function and determine the current product category.

function woo_product_cat_algolia_assets() {
	if ( ! is_product_category() && ! is_shop() ) {
		return;
	}

	wp_enqueue_script( 'algolia-instantsearch' );
	wp_enqueue_style( 'algolia-autocomplete' );
	wp_enqueue_style( 'algolia-instantsearch' );
	
	global $wp_query;
	
	if ( empty( $wp_query->query['product_cat'] ) ) {
		return;
	}

	$term_parts = explode( '/', $wp_query->query['product_cat'] );
	$results['terms'] = [];
	foreach( $term_parts as $part ) {
		$term = get_term_by( 'slug', $part, 'product_cat' );
		$results['terms'][] = $term->name;
	}
	wp_add_inline_script( 'algolia-instantsearch', 'const woo_algolia_queried_terms = '' . json_encode( $results ) . ''; ' );
}
add_action( 'wp_enqueue_scripts', 'woo_product_cat_algolia_assets' );

With this added code, we are grabbing the current global $wp_query object and using PHP’s explode function on the product_cat portion of the query arguments.

This will get us an array of product categories for the current query. We then iterate over those categories and get term objects for each, before storing the term name values as part of our $results array.

Finally, we store that $results variable as JSON on a JavaScript constant to be used in a moment. This way we can access the product category information in our InstantSearch configuration code.

Back in our instantsearch.php file, we need to add this alongside our widgets configuration. We are grabbing that available woo_algolia_queried_terms constant that we just created, and parsing it as JSON data.

Once we have the identified terms from the current query, we add it to the Algolia configured widget and specify it as a default for the filters. This way it’s only showing items from the chosen category.

<?php if ( is_product_category() ) { ?>
	let woo_term_data = JSON.parse( woo_algolia_queried_terms );
	let item_parts = [];
	for (const item of woo_term_data.terms) {
		item_parts.push('taxonomies.product_cat:"' + item + '"');
	}
	
	let woo_query = item_parts.join(' AND ');
	search.addWidgets([
		instantsearch.widgets.configure({
			filters: woo_query,
		}),
	]);
<?php } ?>

You can read more about the configure widget over at Algolia Configure widget documentation.

Conclusion

This completes this tutorial on WP Search with Algolia InstantSearch widget and facet customization. We’ve covered a lot over these past few posts.

Hopefully, these tutorials give you a good idea of what is capable with WP Search with Algolia and WooCommerce, out of the box and with a touch of configuration and customization.

This is definitely not the end-all-be-all of the capabilities, and there is plenty of room for more. It’s all a matter of what data you put in your Algolia indexes, and how you want to make use of it.

When you need a team to integrate the power of Algolia search with your WordPress website, contact WebDevStudios.

Complete Code

As promised, below you can download a zip file that has the final code for our WP Search with Algolia InstantSearch widget and facet customizations, as well as all the topics covered in the previous posts. These are ready to install as a plugin.

You will need to copy the two template files into your active theme and place them in a folder named “algolia” for those to be detected. The rest of the code will work as a plugin named “WooCommerce Algolia.”

WooCommerce-Algolia.zip

The post Integrating WP Search with Algolia: InstantSearch Widget and Facet Customization appeared first on WebDevStudios.

I also covered the results to be shown for both autocomplete suggestions and instant search, among some other elements. It’s worth reading if you haven’t yet.

Today, however, we are going to focus on template customization for WooCommerce. Specifically, I am referring to the display of your Algolia data on your WordPress website and how to customize the display of returned results.

We will be using the product data discussed in part one of this series.

WP Search with Algolia: Autocomplete and Instantsearch Template Files

When you download WP Search with Algolia, it comes with a couple of template files for both autocomplete and instantsearch. These make for solid defaults with minimal display, but we need to make them more robust and fit our needs.

In order to customize these files safely, we need to copy the autocomplete.php and instantsearch.php files out of /plugins/wp-search-with-algolia/templates/ and into a folder named algolia in your currently active theme.

The plugin will automatically detect their existence from the theme and use those copies instead of the prepackaged versions. This allows you to customize and still update the plugin without losing customization.

Autocomplete

Below is a screenshot of the default autocomplete search when using the TwentyTwenty theme. Here, we can see a heading mentioning the content types being shown, followed by five different products matching our search term.

Each result includes a thumbnail for their product image, product name, and product description.

We are going to change the listings to include both the price and SKU number next to the product name, and use the short description if available, or else the current description.

For this, we need to edit the autocomplete.php template file, specifically, the section found at Autocomplete.php line 21-33.

Here, we will have a JavaScript variable data that will hold information for each suggestion hit, meaning an individual product. Now, we start making use of all that information we indexed.

The bundled template files make use of the wp.template functionality that ships with WordPress. It uses underscore.js for its templating, and has a mustache-like syntax. Luke Woodward has a great general tutorial for making use of this on your own.

<div class="suggestion-post-attributes">
	<span class="suggestion-post-title">{{{ data._highlightResult.post_title.value }}} - {{ data.sku }} - {{ data.price }}</span>
	<# if ( data.short_desc ) { #>
		<span class="suggestion-post-content">{{ data.short_desc }}</span>
	<# } else if ( data._snippetResult['content'] ) { #>
		<span class="suggestion-post-content">{{{ data._snippetResult['content'].value }}}</span>
	<# } #>
</div>

In the snippet above, I have amended the markup for the “suggestion-post-attributes” wrapper div, starting on line 26, to include a few more things. These values are all on the top level of your product index when looking at the item in the Algolia dashboard.

First, we output the SKU property, followed by the price property. Both are included in the span wrapping of the original post title value, which is getting some extra highlighting from Algolia.

Next, we can use some standard “if statement” logic on the properties to check if we have a value before acting. Here, I have checked to see if we have a short description to show, otherwise it falls back to the original snippet version coming from the full product description.

Below is a screenshot of the final result.

Other areas of the autocomplete.php template file has spots for customizing details like the autocomplete header, term suggestions, user suggestions, autocomplete footer, and no results template. We are not going to worry about those at the moment.

Towards the very bottom is the JavaScript that is powering everything. For the sake of this post, I won’t be going into details there. What we’ve been concerned about is the display of data coming back from a given query.

Instantsearch

Now that we’ve added some content to the autocomplete suggestions, we will add the same information to our Algolia hits output before we click into a specific result.

For this portion, we need to edit the instantsearch.php template file.

The section for this one can be found at Instantsearch.php line 48-68. We are going to insert a new paragraph tag above the excerpt, to conditionally show both the SKU and the current price if we have a value.

<h2><a class="ais-hits--title-link" title="{{ data.post_title }}" href="{{ data.permalink }}">{{{ data._highlightResult.post_title.value }}}</a></h2>
<# if ( data.sku || data.price ) { #>
	<# if ( data.sku ) { #>
		<span class="is-hit-sku">SKU: {{data.sku}}</span> |
	<# } #>

	<# if ( data.price ) { #>
		<span class="is-hit-price">Price: {{data.price}}</span>
	<# } #>
<# } #>

<# if ( data.taxonomies.product_cat ) { #>
	{{{data.taxonomies.product_cat}}}
<# } #>
<div class="excerpt">

To help keep our markup clean, we are only going to output anything if we have either a SKU or a price value. Once we know we have something, we output some span markup for each data item we have.

For easier styling, we have included some custom classes. To top off our instantsearch customizations, we’re going to output the product category for each.

Template Summary

These template edit examples are definitely minor but show how to take a given Algolia hit and modify the output for each. The data object variable is going to be the key here.

As a reminder, when viewing your index in the Algolia Dashboard and index explorer, each part of a given object is available via that data variable. Some parts may be top level like data.post_title, while others may be a bit more nested like you see in the images. For example, data.images.thumbnail found in use in the template files, but not as part of our code examples above.

Our journey through integrating WP Search with Algolia is not complete. Coming up next in this series, I’ll discuss facet widget customization. Be sure to come back to this blog.

The post Integrating WP Search with Algolia: Autocomplete and Instantsearch Customization appeared first on WebDevStudios.

However, our stance has been that due to complexities with WooCommerce, we are not planning to add any official support to the free plugin WP Search with Algolia. That does not mean there is zero ability for the plugins to work together; it’s just that integration is up to individual site owners to adjust to their own needs.

This has left a proverbial hole in our free Algolia support. Going into the end of 2021 and the beginning of 2022, I was assigned tasks regarding integrating WPSwA with a WooCommerce-based website.

At the time, I was still saying, “We don’t have official support for WooCommerce.” Yet, I was chomping at the bit for this opportunity and hands-on experience.

There were definitely hiccups and interesting challenges along the way, but I feel the gained knowledge has proved invaluable. I want to discuss with you here how I handled various parts of what I learned, including WP Search with Algolia’s settings and configurations for WooCommerce.

At the time of this writing, we are using version 2.2.0 of the plugin, available on both WordPress.org and GitHub. Also, for these examples, we are focused on simple products in WooCommerce. Other product types will need more exploration and work.

I am covering our overall setup in three parts:

1. Settings and index management with WPSwA
2. Template customization
3. Facet widget customization

Today’s post covers part one only—WP Search with Algolia settings and configurations with WooCommerce.

After all three parts are addressed, we will provide a plugin version holding all the code presented in these blog posts. We encourage modifying this plugin version to meet your own fine-tuned needs For the sake of brevity, I assume you already have an Algolia account and WPSwA setup, including Application IDs and various API keys.

WP Search with Algolia Settings and Index Management for WooCommerce

Settings Management

It is definitely possible to control and manage indices configuration in the Algolia.com dashboard. Those settings are reflected on your website when using search.

WPSwA, on the other hand, is also set up to manage these settings. This is done via code rather than UI, using WordPress’ extensive hooks API. Whenever you see UI or instructions to “Push Settings,” the settings provided via custom code are pushed to your Algolia instance.

Controlling the settings via custom code may sound odd, but it is actually extremely handy. It allows not only version control of the configurations, but also allows for consistently deploying those settings across various indices and between development sites. All you need to do is trigger some UI and everything is configured for you.

We are providing configuration code to help with WooCommerce integration, but if you prefer managing it via the dashboard, remove that code and avoid the “Push Settings” UI.

Index Management

When I say index management, what I mean is managing what information gets pushed when a given product object is updated or removed. Some parts are already handled for you, while others will need manually added and a re-index run.

Not every change around index management requires settings deployment, but does need a re-index of the content. We let you know when each is needed.

For index management, we’re focusing on two indexes specifically. The first one is the posts_product index and the second is the searchable_posts index.

When you enable individual content types on the Autocomplete settings page and click to index that content type, a corresponding table is added to your Algolia instance. In the case of our WooCommerce intent, we want the “Products” row which creates the index of “posts_product.”

The searchable_posts index is a bit more encompassing with less to click. It indexes all of the content types that are considered searchable by WordPress.

If you have registered your own post type before, you may recall the “Show In Search” option. This is the same.

Any time that we’re adding information to the products in our indexes, we use the following two filters available to us in the WPSwA plugin:

algolia_post_product_shared_attributes
algolia_searchable_post_product_shared_attributes

Meanwhile, whenever we’re modifying the settings for the related indices, we use the following filters (also available in the WPSwA plugin):

algolia_posts_product_index_settings
algolia_searchable_posts_index_settings

Note: the final version of supplied code is different compared to isolated snippets, but should have all parts covered by the post in the end.

SKUs

We’re starting with one of the most common questions I’ve seen regarding WooCommerce integration. How do we get a product’s SKU value indexed?

function add_product_data_to_autocomplete_and_instantsearch( $shared_attributes, $post ) {
	$product = wc_get_product( $post );

	if ( ! $product ) {
		return $shared_attributes;
	}

	// We need to make sure the SKU is a part of each index, in order to search by it.
	$shared_attributes['sku'] = $product->get_sku();

	return $shared_attributes;
}
add_filter( 'algolia_post_product_shared_attributes', __NAMESPACE__ . 'add_product_data_to_autocomplete_and_instantsearch', 10, 2 );
add_filter( 'algolia_searchable_post_product_shared_attributes', __NAMESPACE__ . 'add_product_data_to_autocomplete_and_instantsearch', 10, 2 );

First, we hook into the shared attributes data where the attributes to be indexed are set and data included. This hooks in before the final data is sent to Algolia, and is a perfect spot for us to include extra information.

In the code above, we are utilizing the passed-in $post object to retrieve a WooCommerce product object. If we have a found product, we use the get_sku() method to retrieve and set the value in a new “sku” index. Once done, we return the updated $shared_attributes array.

Since we changed what gets indexed on product objects, we need to run a sync on both the Autocomplete and Search pages. Having the SKU on both will be important in a moment.

Adding the Ability to Search by SKU

Next, we need to amend the settings for our posts_product and searchable_posts configurations.

function amend_posts_products_and_searchable_settings( $settings ) {

	$settings['searchableAttributes'] = 'unordered(sku)';

	$settings['disableTypoToleranceOnAttributes'][] = 'sku';
	$settings['disablePrefixOnAttributes'][] = 'sku';

	return $settings;
}
add_filter( 'algolia_posts_product_index_settings', __NAMESPACE__ . 'amend_posts_products_and_searchable_settings' );
add_filter( 'algolia_searchable_posts_index_settings', __NAMESPACE__ . 'amend_posts_products_and_searchable_settings' );

Here, we are adding the “sku” attribute into our list of attributes considered searchable, and telling Algolia they should be unordered.

We are also disabling typo tolerance for the “sku” attribute. This means that a sku of “40025” won’t be included when you typed “40026.”

Lastly, we are also adding the “sku” attribute to the list to disable prefix searching on. That means if you were to type “400,” neither “40025” nor “40026” are considered as a result.

All of this helps ensure that SKUs can be searched exactly, both when showing suggestions in the search bar, as well as with the final results themselves.

Product visibility and availability

Product visibility

Let’s say you’ve gone through the effort to manage your merchandise. Sometimes, you want to remove a product’s catalog visibility on the frontend.

For this, we’re going to mark the product as should NOT be indexed, if its WooCommerce visibility is marked as “hidden” or “catalog” only. We will be making use of these available filters to achieve this.

The filters are passed a boolean value for the current determined status of if it should be indexed or not, and then a post object itself.

algolia_should_index_post
algolia_should_index_searchable_post

function exclude_visibility_and_outofstock_products( $should_index, $post ) {

	if ( false === $should_index ) {
		return $should_index;
	}

	$product = wc_get_product( $post->ID );
	if ( ! $product ) {
		return $should_index;
	}

	$product_visibility = $product->get_catalog_visibility();
	if ( in_array( $product_visibility, [ 'catalog', 'hidden' ] ) ) {
		$should_index = false;
	}

	return $should_index;
}

Here, we return early if it’s already been determined elsewhere that it should not be indexed. Why do extra work?

If the product is still considered indexable, we move to retrieve a product object and check its current visibility value. If that visibility is “hidden” or “catalog,” then we set $should_index to false and return our filtered value.

This post would not be indexed and WPSwA would move on to the next item.

Product Availability

Perhaps you don’t want to show products that are presently out of stock or are on backorder. Users should only see what they can buy now. Using the same function above, we can add a few more checks to potentially prevent the indexing of a given product.

function exclude_visibility_and_outofstock_products( $should_index, $post ) {

...

	$product_visibility = $product->get_catalog_visibility();
	if ( in_array( $product_visibility, [ 'catalog', 'hidden' ] ) ) {
		$should_index = false;
	}

	$stock_status = $product->get_stock_status();
	$statuses_to_retain_indexability = [ 'instock' ];
	if ( ! in_array( $stock_status, $statuses_to_retain_indexability ) ) {
		$should_index = false;
	}

	return $should_index;
}

In this amended code, we are utilizing the $product object to get the stock status. By default, WooCommerce stores either “in stock,” “outofstock,” or “onbackorder.”

For our purposes here, we only want to show items in stock. If the found status is not in our array, set $should_index to false and return the final value.

Bonus points: How could this information be used in conjunction with Yoast SEO content settings?

Extra product information

When it comes to your products, the SKUs don’t have to be the only thing you index. Any detail about the product that you can fetch can be included as part of it’s indexed object.

For the sake of the rest of this post, I’m going to add both the price (with currency symbol) and short description to my products. Don’t forget to re-index!

$product = wc_get_product( $post );

if ( ! $product ) {
return $shared_attributes;
}

...

$currency_symbol = html_entity_decode( get_woocommerce_currency_symbol() );
$shared_attributes['price'] = $currency_symbol . $product->get_price();
$shared_attributes['short_desc'] = $product->get_short_description();

return $shared_attributes;

Conclusion

Whew, we have accomplished a fair amount here. We have successfully integrated WP Search with Algolia’s settings and configurations for WooCommerce. Additionally, we marked some of our attributes as being searchable and added a fair bit of product information to our products in Algolia.

Lastly, we also configured our install to control whether or not a product should even get indexed, based on catalog visibility or current availability. Next time, we will get into how to make use of this information when performing a search and how to customize the display of everything.

If you’re ready to have WP Search with Algolia integrated with specialized settings on your WooCommerce website, contact WebDevStudios.

The post Integrating WP Search with Algolia: Settings and Configurations for WooCommerce appeared first on WebDevStudios.

Thanks to some well-placed WordPress hooks, we have technically had WPGraphQL support for a long while now, but never formally as part of the plugin itself. Jason Bahl, the creator and maintainer of WPGraphQL was also maintaining a Custom Post Type UI (CPTUI) extension that provided the UI fields to set and save WPGraphQL integration within the settings for post types and taxonomies registered with CPTUI.

Going into our March Five for the Future day, Greg informed me that Jason reached out about getting official integration for the two pieces, and after a touch of consideration, I agreed that it was time to merge them into one. Utilizing that day’s time, I set out to adapt and pull in Jason’s work into our primary plugin. If you are not using WPGraphQL at all with your site, or are perhaps not even sure what it is, you have nothing to worry about. We made sure to load the related changes only if the WPGraphQL plugin is available. If it is not, then you will only see the other 1.9.0 changes.

To help with transitions, we set up an admin notice for those with the now legacy CPTUI integration, letting the users know that they no longer need that original extension and can remove it without any loss of data. It should switch over seamlessly.

We are excited about the future of Headless WordPress and the types of creations developers around the world can produce with it. We are even more excited that users of Custom Post Type UI who are wanting to explore and try out Headless WordPress can now do so without having to leave us behind.

So what are you waiting for? Download or upgrade to Custom Post Type UI 1.9.0 and share with us what you are thinking about making in the comments below.

The post Custom Post Type UI Supports WPGraphQL appeared first on WebDevStudios.

Job Title: Support Engineer

Years at WebDevStudios: 8

My move into working for WebDevStudios (WDS) was a very swift transition in September 2012. If memory serves me right, on a Saturday or maybe Sunday, I was tipped off that WDS was hiring by a then-employee and he encouraged me to apply.

The next day, I sent in my resume. I believe Monday I had an interview with our CEO, Brad Williams, over Skype, and by Tuesday I had the job offer. It was something close to that, for sure, and I was happy to leave freelancing in favor of steadier work. I’ve been here ever since.

As I sit here reflecting about the past eight years, I’m realizing that I’ve had a finger firmly on the pulse of support for WebDevStudios, almost from the start. By “support,” I mean a different type than what a typical agency provides a client. That support is most definitely important, especially for maintaining long-working relationships. The support I’ve been involved in, though, has been a mix of long-term relationships along with one-offs or momentary needs.

Plugin Support

WebDevStudios had developed some plugins during the early years. Most notable is Custom Post Type UI (CPTUI), with Brad having good foresight that user-registered custom post types and custom taxonomies were going to be BIG for the WordPress community. He jumped on that pretty early on, and CPTUI emerged as a forerunner in opening up those possibilities.

WDS also developed various other plugins that were also published on WordPress.org over time. However, there’s only so much time in the day, and running a business takes up a lot of that time. This limited Brad, and whomever else may have been asked, to handle incoming support requests for those published plugins.

I was actually fairly active in the official WordPress Internet Relay Chat (IRC) channel, which is an available avenue for general WordPress support even in 2020. It was in there that I believe Brad saw a natural knack I had for helping others. He also knew that public perception was incredibly important, and on the plugin front we weren’t doing so hot. By the spring of 2013, I was dubbed the “plugin czar.” Not only did I take on the responsibility of handling all of the incoming support requests for ALL of our free plugins, but I also took on the continued development of them.

While I haven’t called myself the plugin czar much since, the role is still very much a part of my workday. I primarily make sure that the support threads are responded to and helped in as timely of a manner as I can. If serious bugs or security issues arise, I address and release fixes as quick as possible. As time and schedule permit, I also try to work on new features, but that is usually not as actively handled daily. Sometimes, a solid, stable plugin that does its job well is better than a constantly moving plugin.

Regardless, every day I’m checking both RSS feeds and email notification for the support forums that I’m tasked with monitoring. These two methods help me make sure I am keeping an eye on new activity for each plugin. On top of that, I also manage and monitor any communication provided through GitHub, where we publicly host all of the source code for our free plugins. A majority of the open issues are probably created by me to help track ideas from both myself, as well as users suggestions, but users are able to contribute their own, and I respond there, as well.

Maintainn

WebDevStudios realized that they wanted to take an active role in not only helping clients release awesome websites but also maintain longer-term relationships with them well after project completion. The idea of, “Hello, get the work done, goodbye!” was not enough. Why not move a client internally to a different part of WDS to keep that relationship going?

Enter Maintainn, a WordPress support company that was started by Shayne Sanderson to provide ongoing and routine support for various sized clients, who wanted help keeping their sites updated, backed up, secured, and have custom development managed. WDS acquired Maintainn to not only continue helping those smaller website owners, but also provide a branch of the company that the agency-level clients could also rely on, after the initial project build is finished.

Once again, Brad approached me with the idea of moving me away from the agency side of WebDevStudios and put me on the Maintainn team. I agreed to the move. At the start, I was also helping out with AppPresser support when WebDevStudios still had a hand in that product, and I began splitting my time essentially three ways: plugins support, AppPresser support, and now Maintainn support.

Did I mention I can do support?

With Maintainn, I’ve done practically everything at one point or another. Whether it be the small quick-ish requests from clients, to larger feature requests for major functionality, to the grunt work of applying available updates each week, checking on security scans or reported vulnerabilities, and making sure backups are running like expected.

Today, though, my primary focus is less on the routine maintenance tasks, and more on the support requests. On a given day, I will be reviewing new requests to evaluate what is being asked for, what needs to be done to achieve that, and how much time I think it’s going to take. Some tasks are going to be pretty quick and require less than 30 minutes. Sometimes, the requests are considerably large and could range in the 20-30 hour range. It really depends on what is being requested.

I would easily say that a good portion of my Maintainn day is communication, both internally and with the clients. I’m checking my email for notifications from our various tools used by Maintainn, communicating internally with our project managers and my fellow developers, and communicating with the clients about their requests. Once estimates have received official approval, I then go heads-down on the task to begin fulfilling the request and hopefully making a happy client. I wrote a behind-the-scenes look at my role at Maintainn on our blog. Take a peek.

Pluginize

Pluginize definitely scratches the itch I have for being part of a product team. I love the idea of being able to develop the tools that help the web developers help their clients. Pluginize is also an extension of the plugin support role that I’ve had for years, but on the premium product level. As you may have guessed by now, I am also tapped to be the primary support person there. My day-to-day dealings with Pluginize include handling support tickets that come in through our ticketing system, whether it be a pre-sale question about one of the products, technical support for an issue someone is having, or if they just aren’t happy with the product and want a refund.

I also get to help continue evolving the premium products, develop new features, handle any bugs or security issues in the code, and manage new releases. Between the free plugins support and Pluginize, if you’ve ever reached out to WDSs for questions about our plugins or products, chances are you’ve had at least some feedback come from me, which I think is pretty awesome.

Constant Contact

The last proverbial hoodie I wear at WebDevStudios is the role I play with our ongoing relationship with Constant Contact. You can read more about at Success Story: Constant Contact Forms Plugin for WordPress.

This product/project has evolved and changed over time, but one thing that has managed to stay pretty consistent is my involvement with it. With that, I have a lot of contextual knowledge about how things were and are now with these plugins. This is also a different type of scratched itch, as it’s also a product, but not one that is owned by WDS.

Much like our other products and plugins, this is also one that I do a lot of forum and troubleshooting support for, as well as gather user feedback for what we’re doing well, what we’re doing not so well, and ideas to pass along to Constant Contact for how we could make the product better.

This helps Constant Contact with a more robust and solid product which helps them with their customers. I think I also benefit because at least temporarily, I get to put myself into a different pair of shoes where I need to think like a marketer and try to determine things that would be important for someone in that type of role. Because I’m on the frontlines, I am often also participating in the annual meetings with the client to help outline future roadmaps and plan for new releases.

After the work day is over…

2020 is a year that will go down in various levels of infamy, but that doesn’t mean that I don’t have my habits and hobbies away from my work computer, although those were definitely slowed by our pandemic. When I’m not at my work computer, chances are you will see me in one of a few various places.

First up is some local gyms. I recall it vividly, the moments when I decided that enough was enough, and it was time for a change. September 2015, right after WDS Camp 2015 in Wisconsin, I started seeing some event photos, including ones that had myself in them, and I realized what physical state I was in.

Mentally, I thought I was doing alright, even when I looked at myself in the mirror. Somehow, the event photos told me a different, more realistic story. In short, I decided it was high time to start going to the gym, and be serious about it too.

Since that September, I’ve regularly worked with a trainer multiple times a week and eventually participated in group classes, as well. All this time and effort has turned around many aspects of my life. They say it’s not a diet or a brief habit; it’s a significant life change in how you live. I have to agree. Five years later, I’m not quite to where I’d like to be (hi, abs, wherever you are), but I know I’m continually doing much better than I was before.

The second, and slightly more random place you’ll find me when away from my work computer, is one of various coffee shops around town, often with a book in hand. At the tail end of 2017, and the first part of January 2018, I noted that I didn’t do much book reading. Not only that, I wanted to actively change this, as well. It was at that point that my personal weekend reading challenge began.

The challenge is simple. Every weekend, regardless of where I am, I would read at least ONE page from an actual book. I am proud to say that the weekend streak continues to this day, and I have not missed a single weekend, as of the time of this writing. I’m not sure at the moment exactly what my grand total book and/or page count is, but I do recall the book that I started off with—The Hobbit by J. R. R. Tolkien.

Beyond that, I also fill my time with movies, TV, and podcasts. It’s easy to say that time is filled pretty well. And that, my friends and readers, is a pretty good idea about a day in my life with WebDevStudios and Maintainn, as a Support Engineer.

The post WebDevStudios Day in the Life of a Support Engineer appeared first on WebDevStudios.

Here are a few ways I’ve found help me make my health a priority, while still working all the while.

Please note: I am not a licensed professional or “expert” on the topics that follow. Take the presented information as general information and things to consider.

The small stuff

Throughout our days, we should be making sure to take small breaks to get up and move around. A little bit of stretching goes a long way. Even just a walk around the house for a little bit helps us get moving and alleviate stress on the body.

This keeps us active and provides a break for our brains.

It’s such phenomeNOM…join us for the nomathon!

Diet and nutrition have been topics of discussion for decades.

No matter how often the topic gets hammered into our minds, most of us are still not as on top of it as we should be.

You can still do your part to limit detrimental effects that your diet can have. Strive to eat healthy foods instead of junk food as much as possible. Limit or completely remove sugary drinks from your daily intake. The benefits are not fast-acting and immedaite, but give it enough time and they will present themselves. When in doubt, talk to a nutritionist or your doctor about what is best for you.

Do you even ___, yo?

Short breaks are necessary, and a good place to get started, but longer duration physical activity is important, too.

The type of activity is up to you, and there are many types available. A mixture of walking, jogging, and running is a popular activity that many use, but it is not the only option. Visiting a gym for other forms of cardio or weight training offer nice ways to take a break from your day.

When you do this is totally up to you! Some people prefer early morning and before work. I prefer right after work, even if it is during “rush hour.” Hiring a trainer or joining a fitness group can also help you reach your goals and keep you motivated.

If you have talked to me at all since September of last year, you know that I have taken a proactive approach to my physical health. Through both diet change and active gym attendance, I have slimmed down significantly, and the impact has definitely helped me throughout any given work day. I feel all in all better throughout my workday, which helps me get my job done. It also provides me a well earned mental break every afternoon.

It will be in your best interest to find activities that you enjoy, or at least tolerate. If you are doing something that you hate, you will have minimal motivation to continue or will stop completely. Doing physical activities that you enjoy–or at least do not hate–will help you return regularly.

It’s not all physical

It takes more than just brief breaks throughout the day to keep your mental health in check.

If you already have pursued mental health support (as needed!), then you are already a step ahead. Whether you have a general anxiety disorder, adult ADHD, or any of the other potential illnesses that impact your mental health, the effects impact your day to day, and those around you. By pursuing your own wellness and, if applicable, a diagnosis, your self-awareness will help you move forward into a better state of being.

If you’re struggling with stress, signs of depression or anxiety, or generally feeling as though your focus, mental clarity, or emotional well-being are at risk, consider seeking professional support.

There is nothing shameful or wrong in pursuing mental wellness. It does not make you less of a person. I would argue it makes you more of a person–one who is taking care of themselves proactively, which is what we all should be doing.

If you are suffering, I hope you have already sought help, but if not, check out a few of these resources:

• MentalHealth.gov
• Mental Health America
• National Alliance on Mental Health
• How to Choose a Psychologist

If you are having thoughts of suicide or are worried you may be a risk to yourself, please take a moment to breathe, and call the National Suicide Prevention Hotline: 1-800-273-8255.

Find out if your insurance can cover supporting you; if not, there are often low-cost options available in major metropolitan areas. If it’s impacting your work negatively, and you trust the people you work with, pull aside your supervisor and have a conversation about what is going on with you so you can get the support you need.

We need you around and well to keep creating amazing things.

Wrapping up

I’m not able to cover every aspect or area for what goes into personal physical and mental health. I do hope you’re thinking about it though, and what you can do to take care of yourself a little better.

Here are some other resources that cover these topics in greater detail:

• How Technology Can Help Your Health – Allison covered some tech-based methods for health tracking back in December.
• Open Sourcing Mental Health – Changing how we talk about mental health in the tech community.
• MyFitnessPal – Nutrition and exercise tracking throughout the day.
• MyFitnessPal Blog – MyFitnessPal’s blog with regular posts about exercise and recipes.

What are some things you do to take care of yourself?

The post Stay Healthy While Working at a Desk All Day appeared first on WebDevStudios.

Here are some of the awesome updates you can find in 1.3.0:

Visible changes

UI update

The most notable change is that we have continued evolving the UI for the post type and taxonomy editor screens. We have moved to a single column view with more separation of sections. These sections include required fields, optional labels, and optional settings. We hope this design is more intuitive and less burdensome for both current and new users.

Slug helpers

We have also added some enhancements for the post type and taxonomy slug fields that are meant to help ensure the slugs are as they should be. We felt it was best to take a proactive approach with this to help our users be up and running more quickly and with less support requests around slug issues. On top of that, we also work to provide better prevention of duplicate slugs between WordPress core and other third party plugins.

WDS Promotion spots

Lastly the biggest thing users will notice is on the post type and taxonomy add/edit screens, with the placement of promotion spots from WebDevStudios.

A few things I want to drive home:

1. We are not going to use this for any third party ads. The only thing you should see in these spots are for WebDevStudios products and services. Nothing else.
2. The links on those product promotions do have some tracking on them, but this is simply for our own analytics so we can see what sort of traffic we are getting. In the future, there will be ways to remove these as well.

Under the hood changes

Localization

One big thing that came with the release of version 1.3.0 is that we have moved all localization of the plugin to the WordPress.org language packs. This is intended to both help distribute the necessary files for Custom Post Type UI in your language, as well as make it easier for people wanting to contribute back and help provide the plugin in their native tongue.

Hooks everywhere

Along with the UI evolution mentioned above, we also worked to continually add new hooks in useful places for others to interact with and modify content being manipulated to fit their needs. If you are a developer wanting to extend Custom Post Type UI, there’s never been a better time than now.

Contributor changes

GitHub branches

With the start of the post-1.3.0 development cycle, we are moving to a more proper “Gitflow” workflow. For the longest time we had left the GitHub repo master branch at a matching state with WordPress.org’s copy. However, this often provided unneeded confusion and even made my own workflow a bit cumbersome at times. So from here on out, the master branch on GitHub is a development branch, and all features should and will be done on other branches. When we are ready for a new release, whether bug fix or major, we will tag appropriately and push the tagged version up to WordPress.org.

Conclusion

We are very excited about the present state of Custom Post Type UI and are looking forward to the future, both with the still free plugin as well as potential new and evolving premium extensions. We hope you are too! If you have any feedback or ideas you would like to share, send ’em our way!

The post Welcome Custom Post Type UI Version 1.3.0 appeared first on WebDevStudios.

Since then, I’ve been slowly but steadily working on the next major version. Today, I am happy to announce the release of version 1.2.0. A mix of 21 new features, bug fixes, and updates have gone into this version. We will go over some highlights today.

Notable new features

Individual post type and taxonomy output for the “Get Code” area

In version 1.1.x and earlier, the “Get Code” feature allowed you to move your registered types and taxonomies to external locations. This output provided a paste-ready block of code for use in custom plugins or your theme’s functions.php. The only drawback was that it was always all or nothing. In version 1.2.0, there is now output for individual post types and taxonomies as well.

Support for adding post types and taxonomies to the WordPress REST API

In WordPress 4.4, the core developers added the REST API infrastructure. In Custom Post Type UI 1.2.0, we added the ability to add REST API support to your post types and taxonomies. If you are unfamiliar with the WP REST API, or need a refresher, check out Ryan‘s WP REST API Overview once done here.

Template hierarchy references in the Registered Post Types and Taxonomies area

When you are reviewing your registered post types and taxonomies, you will now see a new column. Here you will see common template file names you can use to better target your post types and taxonomies. With those, you can further customize the frontend of your website. These are not special names from Custom Post Type UI. They come right from WordPress’ template stack.

Accessibility and usability improvements around the plugin

Last year one of our design leads, Greg, talked about The Basics of Developing Accessible Websites, and I knew I wanted to increase the accessibility of Custom Post Type UI. With that, I worked and revised the labels used on various forms used in Custom Post Type UI. I also updated the headings to match accessibility changes made in WordPress core. I plan to continue reviewing and improving accessibility in future versions as well. It is a job that is truly never done.

“Debug info” tab with debugging information  on the support forums

While I try to keep Custom Post Type UI as user-friendly and simple as possible, it is just not always the case. Sometimes, you just need some help figuring out how to do something. When that time comes, you hop over to the Custom Post Type UI support forum and post your questions. If you have ever had to do that, you have no doubt seen me show up. Depending on the situation, I may need more information to help debug the issue. This is where the new “debug info” tab will come into play. It will provide me with the needed extra information. This information will include:

• Site URL
• WordPress version
• permalink structure
• active theme
• active plugins
• registered post types from both Custom Post Type UI and elsewhere
• Custom Post Type UI posts types and taxonomies settings
• many other details.

If you are hesitant to share this information to the public, please let me know. I will provide a way to send the data in private.

Other quick notes

We have bumped the minimum version to WordPress 4.2. We also migrated the textdomain to match the slug we have on WordPress.org. If you would like to help translate Custom Post Type UI, let us know and we will point you in the right direction.

All in all, I am quite happy with how Custom Post Type UI version 1.2.0 turned out. I hope a lot of the new features help our users and address issues they were having.

The post Custom Post Type UI Version 1.2.0 Now Available! appeared first on WebDevStudios.

Custom Post Type UI is one of our many plugins, and undoubtedly our most popular one. So popular, that it is the first WebDevStudio plugin that has reached one million downloads with an active install count above 200,000. Not only that, but it maintains a 4.6 out of 5 stars rating with an impressive 87 5-stars at the time of this writing. This is quite an impressive feat to achieve since Brad Williams first tagged version 0.1.0 five years ago.

What Exactly Is Custom Post Type UI?

In case you are not familiar with what Custom Post Type UI does, it provides a user interface that someone can use to easily provide settings and labels to be used for registering custom post types and custom taxonomies for their install. The plugin then takes those values and does the actual registration, allowing users to start using them right away. Other features as of the 1.1.0 release include import, export, “get code”, and settings listing functionality. The import and export area helps port the plugin’s settings between installs. The “get code” facilitates moving where the post type and taxonomy registration occurs, while the settings listing acts as a quick view of all your settings with our plugin.

It really takes the pain out of having to type out all the necessary code to register post types or taxonomies and helps non-coders to get a start with extending their sites content. It’s the ease of use and aid to which I attribute its success.

Evolution

Much of the development of the plugin in the early years was the gradual addition of features and fields for associated parameters available to post types and taxonomies. This allowed for more flexibility with the settings for users. By the time I first stepped into maintaining the plugin, we were at the 0.8.0 release, and that was the first release I pushed up to the WordPress.org repository.

During this time, the seeds of the first major shift were planted. I wanted to make it easier to develop the plugin and add new features, but the codebase at the time had slowly become an unintentionally complex. I also felt that the actual UI was not keeping up with the times of the WordPress Dashboard, and also mixed the settings for post types and taxonomies too much.

Because of this, I set out to do the first major update to Custom Post Type UI. This planned update included both a completely redone UI for the users, as well as a much easier to use codebase for myself and others to develop with. In the winter of 2013, I branched off from our GitHub copy and got to work…then development stopped. It wasn’t for any specific reason that things came to a halt, other than just being busy with other work. It wouldn’t be till winter of 2014/2015 when the initial rewrite would be completed and what I thought would be release ready.

Tremulous Times

No matter how much testing you do, or how solid you believe the code to be, massive codebase overhauls are always going to be difficult and rarely go off without a hitch. This is definitely true with Custom Post Type UI in early 2015. Not enough testing went into the changes for Custom Post Type UI 0.9.0, and I will not point blame at any specific aspect of update testing for plugins. It just is what it is. Very shortly after the first attempt at the 0.9.0 release, the forums lit up citing various issues that became evident as users clicked the update button. Live sites were encountering issues and broken links, and it was related to the new release.

I got a very nice tip from the WordPress Plugin Moderation team about doing another release that simply re-installs the last working version. This idea, coupled with the fact that I preserved the original settings and was simply converting the saved settings into a new option row honestly saved myself more headache than I likely realize. I was able to instruct users that they could upgrade to 0.9.5 which would take them back to the previous stable codebase and regain all their original settings while I worked out the missed bugs.

As I started getting bugs taken care of, I started pushing them out, but it was still a long process. One consolation is that I got to get the version as 1.0.x. I feel it is a more fitting version number for such a massive release. It was not until the 1.0.8 release that everything appeared to finally die down and upgrade hickups stopped for users who stuck with it. It is those who stuck with me and worked with me to get their sites back in proper working order that I personally thank the most.

Change Is Hard

Outside of the undetected bugs was the user-facing side of things–the UI for the plugin. The user experience of the new version got mixed reviews from users, especially those who had been using the plugin for a long time already. While some loved it or did not mind the change enough to raise concern, others found it to be harder to use and involved too many clicks to achieve the same results. I did not ignore that feedback, but did put much of it on the backburner for later review. It was my intent to get the functionality back at square one first. While working on the last couple point releases for the 1.0.x line, I was also working on the 1.1.x release. At that point, I started really reviewing the feedback and doing what I could to aid the users there. A lot of focus was put into reducing the amount of clicking needed to get things done, and also getting some new or returning features into the plugin.

Thankfully the 1.1.x release has been notably less rocky and I do not believe there have been any issues reported related to the changes it provided. Much of this can be attributed to the fact that majority of the changes were not related to the setting values. Instead the release was primarily cosmetic and related to display of the user settings.

Looking Beyond One Million

It is hard for me to say what exactly is in store for Custom Post Type UI in the future. At the time of this writing, there are ten open enhancement issues tagged for 1.2. However, I would not call any of them critical to get in as soon as possible. I would love more to get more people up-to-date on the current version and let it be the stable version for awhile. Looking at our stats page, we still have reported active installs using as far back as version 0.6. While I can sit here scratching my head as to why, I also have to consider that that version is stable enough and still meeting the needs of 0.6% of our users. If it is not breaking for them, and there is no security concerns, then it is not all bad that they are still marching on. There is also the minimum version requirement to keep in mind. There are still WordPress installs active and out in the wild that are not running WordPress 3.8 or higher. Until they are, those users are not going to be notified that there is even an update available.

What One Million Downloads Represents

I believe this milestone represents the fact that making features usable and more user-friendly to the “average Joe” can take you a long ways. Custom Post Type UI made it easier for more people to tap into the power and customization ability that custom post types and taxonomies offer to a WordPress powered website. Because of that ease of use, many have added it to their toolbox for every website they have or work on, and recommend it to their friends. All of those points have lead us to where we are today, and where we will continue to go in years to come.

If you have not given Custom Post Type UI a shot, and are interested, you can install it via your Plugin Install screen, or by downloading from the Custom Post Type UI WordPress.org page. We’re super excited about hitting this major milestone, but there’s still work to be done! We would love to hear from you and receive your feedback.

The post The Custom Post Type UI Million Download Celebration appeared first on WebDevStudios.

Not a literal stage!

The answer is to set up what is known as a staging, or development site. What is that you ask? It’s a duplicate copy of your existing site that is located in a place that visitors are not going to know about, and not be able to access. This will allow you and others to develop and revise the website safely without risk of real visitors knowing anything is going on.

When I should get a staging site?

In February 2015, Google posted an article about finding more mobile-friendly search results. This meant that they would favor mobile-friendly websites over non-mobile friendly websites starting later that spring. If you had been holding out on making your website more responsive, Google’s announcement may have been a good kick in the pants to get started. No one wants to lose their search ranking, and we do not want to see you lose that either! Having a staging copy of your website allows you to make your current theme mobile friendly (or replace your website’s theme with one that already is). Both aren’t quick changes, so allowing your users to see the current site while you do the work benefits everyone.

Some other examples of times where you would want to consider a staging site include:

• When making any template file or style changes, responsive or not
• When doing upgrades of WordPress core or plugins, especially between major versions. This helps prevent white screens
• User testing of new features

There are many more reasons, but these are just some common times using a staging site benefits you in a big way.

How do I go about acquiring this copy?

This is a good question, and the solution will depend on certain things. The first question to ask is if your hosting provider has any staging management already provided. If you are hosted through WPEngine or SiteGround for example, then you have easy staging management already. Other hosting providers may vary.

If you are not hosted through either of those, you are not out of luck, but there will be more required steps. It is possible to have a subdomain or alternate domain created to host the copy of the staging site. The only real difference would be amount of work needed to have it created.

If you would like to minimize the manual work required and have no problem with the staging site being hosted by a third party, a plugin/service like WP Stagecoach is a viable option for you. It is a premium service, but from the looks of it, they would be worth the annual fee.

If you are looking for an extensive how-to that does not rely on third parties, check out a more extensive post over at the Maintainn blog. You can always just hire Maintainn to help you out as well.

We have the copied site created, now what?

This is the point where the real work starts. All people involved in the desired work are going to be able to make changes and test things out and get it all ready for the eventual release on the live site without worry.

Once all the changes have been made and verified to cause no major issues, the changes need to be uploaded and implemented on the live site. This will include importing or re-implementing any changes for database content, as well as uploading changed files via (s)ftp or, if you are lucky, merging the changes into the production branch of your version control. Once that is done, any caches should be flushed so that users will receive the labors of your hard work.

What should I keep in mind with a staging site?

The primary thing to keep in mind is access by those who should not have it. This includes more than just people. You don’t want search engine spiders to be crawling the site as well, as you will risk having duplicate content indexed, which is not good in their eyes.

Enabling password access will be a big step in preventing both from occurring. There are WordPress plugins available for this as well as server-level configuration options.

You will also want to disable any caching you have available for your site while working on changes. This will make it easier to see what you have done and keep development swift.

If you have any questions, let us know in the comment section below.

The post Staging Websites for Safe Development appeared first on WebDevStudios.