Divi comes with a free set of very useful icons installed as a font set.The icons are available in many of the Divi Modules including a dedicated Icon module. But these icons can be placed anywhere on your website without using a module. They’re already installed in your theme, so you might as well get good use out of them!

In this tutorial, we’ll show you two methods for adding the Divi icons anywhere on your site – an HTML method and a CSS method. We’ve also included the complete Divi icon set along with their corresponding HTML and CSS codes that you can simply copy and paste:

• Divi Icons – Grid
• Divi Icons – Searchable Table

* Before we get started, it’s important to note that you may need to disable Dynamic Icons in the Divi -> Theme Options -> Performance tab. In many cases, the icons will already be loaded on the page even with this option enabled if you have icons in your header, footer, sidebar, etc. If not, disable the option to force load them on every page.

Add Divi Icons using HTML

To insert a Divi icon using HTML, you’ll need to add a span with class et-pb-icon. In between the openening and closing span tags you’ll place the icon’s HTML code. You can copy and paste that code from the HTML section directly below the icon you want to use in the grid below.

Here’s an example of what the HTML would look like for the checkmark circle icon:

Add Divi Icons using CSS

In some cases you may not want or be able to insert a span tag into the HTML. For example, maybe you want to add an icon before or after an existing element. You can do this using CSS and a pseudo :before or :after element.

In the example below we are adding the same checkmark circle icon from the previous HTML example. Only this time we are using CSS and the :before pseudo element to add it in front of an existing unorderd list item element.

In place of using the icon’s HTML code, we’ll use the icon’s CSS code as the content value in the CSS. You can copy and paste that code from the CSS section directly below the icon you want to use in the grid below.

You can add the CSS above to the Page CSS using the Visual Builder, your child theme’s stylesheet, or in the Custom CSS section at the bottom of the the Divi -> Theme Options page.

Divi Icons – Grid

back to the top !

Divi Icons – Searchable Table

The Divi theme includes a custom post type called “Projects”. These projects make it easy to add and organize portfolio type content on your website without having to use posts and the post categories and tags. Projects come with their own taxonomies (project categories and project tags).

However it’s not possible in Divi to change the URL slug of these projects from /projects/ to /houses/ or /paintings/ for example. In this tutorial, we’ll show you how you can easily do this so the URL matches the purpose you’re using the projects for and increase your SEO. We’ll also show you some more advanced options.

The solution simply involves copying and pasting the code below into your child theme’s functions.php file or using a plugin like Code Snippets:

Replace “custom-slug” in the code above with the slug you want to use. Also make sure you remove the first line in the code if you are pasting it below existing code. Declaring PHP twice in the same file will cause an error.

The last thing we need to do is go to the WordPress dashboard -> Settings -> Permalinks and click the update button. That’s it. Any current and all new project URLs will be replaced with the new slug.

If you’re looking for an easy and advanced way to display your projects, please have a look at our Divi FilterGrid plugin. This plugin allows you to search, filter your projects by category and tag, display custom fields, display featured or gallery images in a lightbox window and loads more.

Creating your own custom post type

Another option from changing the projects slug is to simply create your own custom post type using a free plugin called CPTUI. This plugin makes it very easy to add new custom post types to your site. Are there any advantages to creating your own custom post type instead of simply replacing the Divi projects URL? Lots!

The biggest advantage is that you can also make your own custom taxonomies with the same plugin and add them to your custom post type. You can also add the new taxonomies to your blog posts or other post types, making it possible to search and filter multiple post types using the same taxonomy from a single interface.

For example you could create a recipes custom post type but also a restaurants custom post type and filter both by a new custom taxonomy called ethnicity. The terms of this taxonomy would be German, Italian, Greek, Mexican, etc. Our Divi FilterGrid plugin could then display both recipes and restaurants in the same grid and filter by the “ethnicity” taxonomy (or any taxonomy registered on your site).

The other primary advantage of the CPTUI plugin over simply changing the Divi projects slug is that you would have complete control over the new post type and taxonomies you create. The CPTUI plugin gives you a lot of options for each. For example when creating a new taxonomy you can choose to give it hierarchical support or not. Taxonomies with hierarchical support can have child terms and will display like categories in the admin. Taxonomies without hierarchical support cannot have child terms and will display like tags in the admin.

Whichever option you choose, please keep our Divi FilterGrid plugin in mind for displaying your projects or other custom post types!

Are you having a hard time understanding why some of the images you upload to your website work and display correctly in Divi and WordPress but others do not? Are you confused about how WordPress and Divi thumbnail images are created? Maybe you’re here because we sent you a link to this article from our support system 😉

Getting images to display correctly on our websites can sometimes be more complicated than we would like. The goal of this article is to explain how WordPress and Divi display and alter your original images and how that can sometimes lead to unexpected results. Let’s start with a general overview of what happens to an image when you upload it to the WordPress media library.

WordPress Image Upload

Let’s say you have an image on your computer –  alien-spaceship.jpg. You upload the image to your website within WordPress to use as a featured image in your blog post. You now have an exact copy of the image saved to your webserver’s file system. However, it doesn’t end there.

WordPress doesn’t simply copy the image from your computer to your web server. It makes several “thumbnails” of your image and saves those to your webserver in the same subfolder as the original image. Thumbnails are simply different versions of your original image in various sizes and aspect ratios. The filename for these thumbnail images is the [original-filename]-[width]x[height].[extension]. For example, a 300 x 300 pixel thumbnail image of our original alien image would become alien-spaceship-300×300.jpg.

WordPress creates LOTS of thumbnails for every image. How many exactly depends on the theme and plugins you have installed as each of these can add custom thumbnail sizes for WordPress to generate. Let’s start with the thumbnail sizes included in WordPress core.

WordPress Thumbnail Image Sizes

WordPress generates the following thumbnail sizes every time you upload an image in the format of name – size:

• thumbnail – 150×150 (cropped)
• medium – 300×300 (scaled)
• large – 1024×1024 (scaled)
• 1536×1536 – 1536×1536 (scaled)
• 2048×2048 – 2048×2048 (scaled)

Divi Thumbnail Image Sizes

The Divi theme generates the following thumbnail sizes:

• et-pb-post-main-image – 400×250 (cropped)
• et-pb-post-main-image-fullwidth – 1080×675 (cropped)
• et-pb-portfolio-image – 400×284 (cropped)
• et-pb-portfolio-module-image – 510×382 (cropped)
• et-pb-portfolio-image-single – 1080×9999 (scaled)
• et-pb-gallery-module-image-portrait – 400×516 (cropped)
• et-pb-post-main-image-fullwidth-large – 2880×1800 (cropped)
• et-pb-image–responsive–desktop – 1280×720 (cropped)
• et-pb-image–responsive–tablet – 980×551 (cropped)
• et-pb-image–responsive–phone – 480×270 (cropped)

What is the Purpose of Thumbnail Images?

That’s a lot of thumbnails! WordPress and the Divi theme alone generate 15 thumbnail sizes for every image you upload to your site. Why do we need so many different thumbnail sizes?

Let’s use our Divi FilterGrid plugin for example. By default, this plugin displays a filterable grid of posts and includes the featured image, title and author. But it doesn’t display the featured image in it’s full, original size as it was uploaded to WordPress from your computer. In many cases, this image would be too big and would cause the page to load too slow. Also, since Divi FilterGrid displays four posts horizontally in each row by default, the featured image does not need to be very big. Each image only needs to be 255 pixels wide.

For these reasons the plugin instead displays the 400×284 thumbnail of the featured images generated by the Divi theme. This is usually much smaller than the original image. Some of the default Divi modules also use the 400 x 284 thumbnail along with the remaining thumbnail sizes. For example the portfolio module when changed to carousel layout displays the 510 x 382 thumbnail.

Missing & Inconsistent Thumbnail Image Sizes

Now that we know the purpose of thumbnails, let’s look at some possible thumbnail issues. In most scenarios the issue is very simple – the thumbnail does not get generated.

WordPress will not generate thumbnails for an image when the original image size is smaller than or equal to the thumbnail size. This can cause inconsistent layouts. Let’s dive into this.

Let’s go back to our Divi FilterGrid plugin. Again, this plugin displays the 400 x 284 thumbnail by default. As long as this thumbnail exists for all posts, the grid will look very consistent and uniform. If a thumbnail does not exist, the plugin will instead revert to displaying the original image in its original size. This can lead to an inconsistent look.

* To check if the thumbnail exists, right click on the image and inspect element to view the image URL. Let’s use the following as an example: https://example.com/wp-content/uploads/2050/12/alien-spaceship.jpg. The 400 x 284 thumbnail URL would just get the size inserted between the file name and the extension and would become https://example.com/wp-content/uploads/2050/12/alien-spaceship-400×284.jpg. If you go to this URL and get a 404 error, the thumbnail does not exist.

Back to the inconsistent grid layout. Imagine the original image uploaded to WordPress and used as the featured image of a post is only 200 x 300 pixels. This is a very common issue when displaying portrait pics of people which are often pulled from social media.

WordPress will NOT generate a 400 x 284 thumbnail of this image because it’s too small. It would have to “upscale” the image (which would make it look pixelated) to generate this thumbnail size so instead it skips it. If the Divi FilterGrid plugin cannot find the 400 x 284 thumbnail image, it will revert to showing the original full size image. For this reason, the featured image for this post will not look the same as the other images in the grid (assuming the 400 x 284 thumbnail does exist for the other featured images). The screenshot below shows what this looks like.

All of the posts in the grid above have the same 1200 x 900 pixel featured image except “Post Eight”. The original image size for that featured image is only 200 x 300. The Divi FilterGrid plugin is set to display the 400 x 284 thumbnail by default. That thumbnail exists for all of the images except the 200 x 300 image since it is too small. For this reason, the original 200 x 300 image is displayed instead. This throws off the entire grid layout and creates white space below the other three post authors in the first row.

Solution

The moment we’ve all been waiting for. What’s the solution?

The solution is simple. Upload larger images 🙂 The larger your image, the more thumbnails will get generated in all of the different thumbnail sizes and the less likely you are to run into missing thumbnails.

Obviously this is not always possible. Let’s imagine you’re building a web page to display pictures of you and your coworkers for your website. Everyone emails you a profile pic of themselves and half of them are download from social media and are ironically thumbnails themselves of the original image. But they don’t have the original image and don’t have an alternative. If uploading a larger image is not possible you do have some alternative options:

1. Upload larger images. I know. I know. I’m supposed to provide alternatives to this solution. Once you read the alternatives, I think you’ll agree the best solution hands down is to simply upload a larger image. Even if that means finding a replacement image that is larger or retaking the photo, this is still the best option.

2. Upscale the Image. This could be a “1a” solution because again, the easiest solution is to upload a larger image. Even if that’s not possible, technically it is. Let’s take our 200 x 300 image example. We could resize it on our computer to 400 x 600 and re upload it. This would make it large enough that the 400 x 284 thumbnail would get generated and the layout would work. The downside is that up scaling an image always results in loss of quality so this is not a great option.

3. Display a smaller thumbnail size. In Divi FilterGrid, you can change the default 400 x 284 thumbnail size to any other thumbnail size registered on your site like the ones listed at the top of this article. But 400 x 284 is already pretty small. The next smallest size is 300 x 300. But this won’t work in our example above because our original 200 x 300 image is too small for this thumbnail size too. We would have to pick the tiny 150 x 150 thumbnail size which would not look great. In Divi FilterGrid, you would likely want to display more posts per row so the images were not pixelated. You can do this by decreasing the Items Width in the Design tab which will create more columns.

4. Adjust your layout. Again this applies directly to Divi FilterGrid but you may be able to adjust your layout to make a smaller image or thumbnail work. In Divi FilterGrid, you can switch from a Grid layout to a Masonry layout from within the Design tab of the module’s settings. This type of layout creates a staggered display of images. It is actually preferred that the images be different sizes and have different aspect ratios to create the staggered look. You may need to switch the thumbnail size from 400 x 284 to “Original Image Uploaded” for the staggered layout to look best. This is exactly how we created the masonry layout in the screenshot below.

Canonical tags are added to your website to provide search and indexing data to search engines. Not every page needs to have a canonical tag, but some people do prefer to add them to every page as a precaution. In this article we’ll explain:

• What are canonical tags?
• How canonical tags are handled in WordPress.
• How canonical tags are handled in the Divi theme.
• How to modify the canonical tag on pages that contain our Divi FilterGrid plugin so they are properly formatted.

What Are Canonical Tags

Canonical tags are added to the code in the head of pages on your website and provide information to search engines to help identify the master version of a page. This can be important when you have multiple URLs that all point to the same page or similar page – something that is very common in WordPress sites.

For example, the homepage of every WordPress website can be accessed from two URLs:

• https://diviplugins.com
• https://diviplugins.com/index.php

WordPress automatically redirects the 2nd link above to the 1st link so there’s no need to add a canonical tag in this case.

However, in some cases there is no redirect. An example could be a blog post. Within the WordPress dashboard -> Settings -> Permalinks page, you can control the URL structure of your posts. One possible structure could be the base URL, followed by the post category, followed by the post title:

https://example.com/category-one/post-one/

But if the post is assigned to two categories, it could also be accessed from a different URL:

https://example.com/category-two/post-one/

Same post. Two URLs. Now the search engine has to decide which URL should be displayed in search results. If it treats them as separate pages, it could display both URLs in SERPS which could dilute the search ranking of each URL. You could also get penalized for having two pages with the exact same content, even though they really are the same page.

Luckily WordPress automatically adds the canonical tag in the 2nd example above. Each version of the page has the following tag added to the head:

<link rel="canonical" href="https://example.com/category-one/post-one/" />

When this is placed in the head of the category one post with the same URL, it tells search engines “I am the original”. When it’s placed in the head of the category two post, it tells search engines “I am a duplicate version of this original page. Do not treat me as a unique page.”

Canonical Tags in WordPress

You can see from the examples above, WordPress automatically adds the canonical tag in many cases where you would need it. But it doesn’t add a canonical tag to every single page. Should it?

This is debatable. WordPress adds canonical tags to every user-created page and post. It does NOT add them to archive pages. Unless you are using a lot of URL parameters on your site that might inadvertently generate duplicate content, this should not be an issue. However, adding a canonical tag to every page is not going to hurt your SEO, even if all of your canonical tags are self-referencing (the canonical tag URL is the same as the current page URL).

One could then argue if it’s not hurting anything to add it to every page but not adding it to some pages could be harmful, why not just add them to every page? If you fall in this category, you have a few options to add canonical URLs to every page on your site.

Canonical Tags in Divi

The Divi theme has a “Enable canonical URL’s” toggle that can be turned on for the homepage, single post or page, and index pages (archive pages). You can find these toggles by going to your WordPress dashboard -> Divi -> Theme Options -> SEO tab.

Since WordPress already includes canonical URLs for single posts and pages, turning the toggle on for these is redundant.Turning it on for the Homepage is also redundant since your homepage is likely a page you created and set as the homepage. If this is the case for your site, WordPress is already outputting a canonical URL for your homepage.

That leaves the Index Page SEO tab. Turning the Enable canonical URL’s toggle for this page type will output a canonical URL for all archive pages – category pages, tag pages, search results page, etc.

Canonical Tags and Divi FilterGrid

Now that we understand more about canonical tags and how they are added to your site, let’s talk about how they relate to our Divi FilterGrid plugin. Divi FilterGrid uses AJAX pagination to display the results relative to each page. This means when the pagination at the bottom of the grid is clicked, the page does not reload and only the results in the grid are updated.

However, to maintain best SEO practices and allow for proper indexing of your results, each page in the pagination links to a unique URL with the corresponding page number. Let’s say you are using Divi FilterGrid to display your blog posts like we are on our blog page:

https://diviplugins.com/blog/

If you click on page 2 of our blog page, you stay on the same page with the same URL. Only the results in the grid changes. That’s how AJAX works. The results are retrieved from the database without reloading the page.

But if you view the page source and look at the URL assigned to the page 2 button, you’ll see it links to a different URL:

https://diviplugins.com/blog/page/2/

This URL is for search engines and for indexing purposes only. Search engines will follow each page link, indexing each blog post on each page. If you go directly to the page 2 link above, you’ll see that the results show the page 2 results. So far so good.

The problem is that WordPress will not generate the correct canonical tag for AJAX paginated pages. For example, the default output of the canonical tag for page 2 would be https://diviplugins.com/blog/. However, it should be https://diviplugins.com/blog/page/2/. Since the results of each page are different, they are in effect different pages and should be treated as such.

To resolve this issue, we can hook into the get_canonical_url filter to modify the output of the canonical URL so it reflects the correct page number. Below are three code examples you can add to your child theme’s functions.php file or to a plugin like Code Snippets.

The first example will only apply to a specific page and would be ideal if you are only using Divi FilterGrid on a single page (or few pages). The second example will apply to every page that contains Divi FilterGrid and would be ideal if you are using Divi FilterGrid on many pages or archive and search result pages. The third example applies to sites that have the Yoast SEO plugin installed.

Modify Canonical Tag on Single Page

Modify Canonical Tag on All Divi FilterGrid Pages

The code below searches the content of the current page, looks for the presence of the Divi FilterGrid module shortcode, and then modifies the canonical tag if it finds it. At the very least, you should have a caching plugin installed to cache the results of this content search.

Modify Yoast Canonical Tag

The Yoast SEO plugin hijacks the canonical URL, making it impossible to change with the built-in WordPress hook like the examples above. Instead you’ll need to use the hook provided by Yoast to modify the canonical URL. If you are using an SEO plugin other than Yoast, you may need to use a different hook depending on how it modifies the canonical URL.

Struggling to write with SEO in mind? Not a problem. All you need are great SEO blog writing tools to write amazing content that drives organic traffic and adds value for your target audience. That’s why our SEO team relies on SEMRush. Their SEO tools take the guesswork out of writing blog posts and working with website copywriters.

Consider what these three SEO blog writing tools could do for your business. With SEMRush, you can:

1. Determine your blog’s topic with a focus keyword. Just use the Keyword Magic Tool!
2. Get an edge on the competition! Review their SEO practices with the SEO Content Template.
3. Breeze through the drafting process. Write with SEO best practices using the SEO Writing Assistant.

Blogs are a fantastic way to expand your website’s SEO reach. Do you want to provide relevant answers to your customer’s questions, rank higher in search, and grow your website’s organic search traffic? That’s what a blog can do for your business. Read on and let SEMRush put you on the path to SEO blog writing success.

1. Determining a Focus Keyword

What is a Focus Keyword?

Finding your focus keyword helps you optimize your post for SEO, but what is it? Simply put, a focus keyword is what your post is about, using terms that your target audience is most likely to search.

Your focus keyword should be placed in all the important places on your page: title, headings, text, URL, etc. Each page on your website should use one focus keyword, and SEMRush’s Keyword Magic Tool is a great way to find it.

How to Use the Keyword Magic Tool

The Keyword Magic Tool is a power-packed resource for any SEO blog writer. It lets you analyze an entire search market, study niche topics and groups, and save your research as you go. Take a look at how easy it is to use.

Start with Your Seed Keyword

First, type a keyword you want to analyze into the search bar. From this, the Keyword Magic Tool will generate a list of related terms with a variety of stats, including Volume and KD% (Keyword Difficulty). Those stats will come in handy later. First, you need to make the most of your keyword search. You need to filter for question keywords.

Filter for Question Keywords

Why should you filter your keyword search for question keywords? Often, people type questions rather than search terms into the search bar. Those questions can be a treasure trove of blog post ideas.

Using the Questions button to modify your search allows you to see keywords in question form. This makes it easy for you to build a list of common questions related to your keyword. It allows you to write blog posts that target a question-based keyword simply by providing an answer.

Factors When Selecting a Focus Keyword

The Keyword Magic Tool and Questions button help you discover enticing focus keywords for your blog posts. How do you pick the right one? Here are three factors to consider:

1. Popularity: Does the keyword have a decent search volume?
2. Relevancy: Does the keyword match what your target audience is likely searching for?
3. Rankability: Are there too many competitors using the focus keyword?

This is where the Volume and KD% metrics come in. Let’s look at how they help you find the perfect focus keyword for your post.

The Volume represents the combined average monthly search volume. It helps you determine a potential keyword’s popularity and see if it’s relevant to what your target audience is looking for.

Meanwhile, the KD% shows you how hard it will be for you to rank high for a keyword. This percentage is based on content from your competitors, helping your rank higher. You’ll want to choose relevant keywords with high total volume and low average difficulty in your content marketing or SEO efforts.

With these factors in mind, you’ll be able to choose just the right focus keyword, but that’s only the beginning. If you want to outrank your rivals, you need to see what you’re up against and develop a plan that puts your posts ahead of the pack.

2. Reviewing the Competition

What is the SEO Content Template Tool?

Knowing your keywords is only the first step in writing a blog post that brings traffic to your website. Next, you need to know how to use those keywords to climb to the top of search results and boot your competitors down the line.

That’s where the SEO Content Template Tool comes in. It helps blog writers plan SEO-friendly content by generating writing recommendations based on your keywords. These recommendations help you write quality posts that leave your competitors’ content in the dust. But how do these recommendations help you write great content? Why should you use the SEO Content Template?

Why Should You Use the SEO Content Template?

Before you can write your blog post, you need to know what to include and how to include it. Do you want to create fully optimized blog posts? Build links to your new content? Draw traffic to your website with information that’s valuable to your target audience? The SEO Content Template helps you do all these things. It will:

• Suggest semantically related keywords to use in addition to your focus keyword.
• Show you where and how your competitors used your keywords on their own pages.
• Recommend best practices for your post based on the top 10 Google search results for your target keywords.
• Provide a list of websites from which to get backlinks.
• Give you a target text length and readability score to aim for when you write.
• Offer live integration with Google Docs and other platforms, so that when you’re ready to write, you have everything you need in one place.

With the SEO Content Template Tool, you can plan a fully optimized post that places you ahead of your rivals in search results. All that’s left is to write it, and SEMRush has the perfect tool for that task.

3. Writing a Blog Post with SEO

What is the SEO Writing Assistant?

Writing with SEO isn’t just about the keywords. It’s also about knowing how to insert your keywords for the highest SEO potential. In addition, it’s about originality, reading ease, and an on-brand tone of voice that keeps readers on the page. The SEO Writing Assistant was built specifically for tasks like these.

Features of the SEO Writing Assistant

1. SEO

The SEO Writing Assistant Tool will ask you to enter your blog’s target keywords. As you begin to write, the tool will show you the number of times you’ve used your keywords in the text. It will provide you with recommendations to improve your blog’s SEO capabilities.

2. Readability

This feature analyzes your text using the Flesch Reading Ease readability test. To do this, the SEO Writing Assistant looks at word difficulty and length, sentence complexity and length, and other factors. From this, it awards you a score on a scale of 100. (Recommended score is between 60 and 80 percent.) Knowing your current score allows you to edit for best readability.

The SEO Writing Assistant also compares your blog’s word count with the top 10 Google search results for your target keywords. By looking at your rivals’ blog word counts, it gives you a recommended word count for yours.

3. Originality

Google aims to provide users with the most helpful content on the web. The last thing they want is to offer search results that repeat what’s already been said. This is why original content ranks higher in search. The SEO Writing Assistant screens your content for uniqueness to ensure that you’re not saying something similar to your competitors. It’s just one more way this powerful tool helps your content climb to the top.

4. Tone of Voice

Every brand has a unique tone of voice designed with its target audience in mind. The Writing Assistant add-on ensures that you remain on-brand in the type of language you use. This tool ranks your sentences as “casual” or “formal” on a weighted spectrum, with “neutral” in the center. You don’t want your formal banking post to sound like a blog for a surfing company. With the SEO Writing Assistant, you can strike the right tone for your target audience every time.

What’s Next?

When it comes to expanding your website’s SEO reach, a blog post is a fantastic piece of content for driving traffic and growing your business. Once you see the results, you’ll be eager to keep reviewing your blog for stellar optimized content and even examine your other website pages for SEO issues to correct. Fortunately, SEMRush offers many additional tools to help you meet all your SEO needs. The On-Page SEO Checker and Site Audit features ensure that your content is optimized so you can rest easy and let the web traffic roll in.

With valuable tools like these at your disposal, you’re ready to take the web by storm. Now get out there and start optimizing your SEO content! Sign up for a Free Trial at SEMRush.

What is Load Testing?

Load testing is a type of performance test you can run on your website that can help determine how well your site handles a large volume of traffic during a specified duration. This is accomplished by using a service or program that simulates real traffic. Once the parameters of the test are defined, the simulated traffic is then sent to the website and the site’s performance is monitored.

The results of the test can be measured from two vantage points: the program which performs the test and the server on which the website is hosted. For a complete picture of how your website handles the load test, ideally measurements would be monitored from both vantage points.

The program running the test can provide information that would be helpful in determining the perceived effect of the load test that your website visitors might experience. For example, how slow do pages load during the test and how many users experience an error page because the server can’t handle the load.

The server that hosts the website can provide information that would be helpful in determining whether the server’s resources need to be increased. For example, by monitoring the server’s CPU and memory usage during the test, you can see how close each resource is to reaching its limit and therefore might need increased.

Is Load Testing Important?

Load testing is not a simple task to perform, especially if you plan to do everything yourself. Most of you reading this probably already have a live website you want to determine the load for. Extra care needs to be taken here as the load test could potentially crash your website or at the very least slow it down while the test is running. This begs the question – do you even need to perform a load test on your site?

There is no easy yes or no answer to this question. Are you currently experiencing site slowness or timeout errors? Are you running an eCommerce site? Do you frequently have large spikes in traffic? Are you expecting a large spike in traffic from a promotional event? Would the consequences of your site crashing during a traffic spike be devastating? Are you managing a website for a very important client whose business you can’t afford to lose?

The more yeses you answered above, the more likely you need to perform a load test. Let me share a personal experience that load testing could have helped prevent.

Load Testing Anecdote

A few years ago the VPS server that hosted DiviPlugins.com began to throw 503 errors occasionally while visiting the site. Although concerned, it was rare enough (maybe once or twice a week) that I wasn’t so concerned to investigate right away. That would turn out to be a bad decision.

Shortly after the 503 errors began, I sent a newsletter to roughly 10,000 diviplugins.com subscribers (sent in blocks of 1,000 subscribers every 10 minutes). Almost immediately my website crashed. I logged into my hosting account, restarted my VPS server, and everything was up and running – for about 30 seconds when it crashed again. For the next two hours I had to monitor the server, restarting it every few minutes in the beginning and then every 10 or 15 minutes as the traffic died down until finally the nightmare was over.

I don’t remember if the newsletter was to announce a new product or a sale but I believe it was one of those two. In other words, the consequences of the website crashing were lost sales and frustrated users. I felt horrible about both. It wasn’t my finest hour but it also wasn’t the end of the world.

The point is, it could have been prevented by performing a load test. The sporadic 503 errors were a warning that I was reaching my server’s limits. Within a few days I worked on optimizing my site and migrated my hosting from a VPS server to a cloud server. More on that below.

How to Perform Load Testing

Again, load testing is not for the faint of heart. It’s not rocket science. But as with any task that we rarely perform or have never performed before, there is going to be a learning curve. There are several methods you can use to perform a load test with varying degrees of difficulty and thoroughness.

Regardless of which method you choose, I would highly recommend reading the first method below. There are invaluable insights I learned by working with an expert that can be helpful when planning and performing a load test should you choose to tackle this on your own. Remember also to proceed with caution regardless of the method you choose, especially if performing the load test on a production site or on a staging site that’s hosted on the same server as the production site.

Hire Someone Who Specializes in Load Testing

In preparation for this article, I was approaching load testing from the same vantage point as most of you. That’s to say that I had never performed a load test before and had no idea where to start, how much load I needed to test, or how to interpret the results. It didn’t take me long to realize I would probably be better served by hiring someone who did. I decided this would be a perfect task for Fiverr, the platform designed specifically for one-off tasks such as this. That’s where I found Mariam.

Mariam is a quality engineer tester that specializes in load and performance testing for banks and telecoms. For about $50 she can perform load testing on your site with 1,000 users (more users are possible) and deliver a basic overview of the results along with detailed results in the form of tables, charts and graphs. She can also help you interpret the results and let you know if any action needs to be taken. Here is a link to Mariam’s load testing “gig” on fiverr. Mariam has agreed to offer DiviPlugins.com users a 20% discount if you mention “DiviPlugins20” when you contact her. Thanks Mariam!

* The above link is NOT an affiliate link. I will receive zero commission from any work you have Mariam perform. I simply wanted to share a great resource for load testing that could potentially save you HOURS of work. I’m sure there are others who can perform a load test for you and do a great job. I chose Mariam based on her five-star reviews on Fiverr and how well she answered my questions.

Mariam performed three load tests for me:

• 5,000 users on diviplugins.com on current SiteGround cloud server (VIEW RESULTS)
• 5,000 users on a staging version of diviplugins.com on previous VPS server (VIEW RESULTS)
• 200 users download a free plugin and create an account on a staging version of diviplugins.com on SiteGround’s staging platform (VIEW RESULTS)

Click on the VIEW RESULTS link at the end of each test above to see the results. These are the deliverables Mariam provided for each test and you can expect if you choose to hire her to perform your load tests.

Keep in mind Mariam does not have access to the server that hosts the website she’s running the test on. The data she provides will be one half of the entire picture. For the other half, you’ll need to log into your hosting account which should provide historical data for your server’s performance. You may need to contact your host for specific instructions on accessing this data.

Below are the results of the first test above – 5,000 users on diviplugins.com on SiteGround’s cloud server.

I am on Siteground’s entry-level cloud hosting plan which provides 4 CPU cores and 8GB of memory. As you can see in the screenshot above, during the peak of the test my server still only used 1 of 4 CPU cores and about 5GB of the available 8GB of memory. I was happy the server performed as well as it did, but slightly disappointed I didn’t get to see the autoscale feature in action.

Autoscale allows the cloud server to dynamically increase resources on the fly as demand increases. Each additional core and each additional gigabyte of memory costs $10. For example, if my server had reached 6 GB of memory during the load test (75% of available RAM), autoscale would have kicked in and provided an additional 2GB for $20 (RAM is increased in 2GB chunks). My server would then have 10 GB of available memory for the remainder of the month. At the beginning of the following month, it would reset back to 8GB.

You can also set a limit on how much of each resource you’re willing to add. You can see in the screenshot below, I currently have my max CPU set to 8 Cores and my max memory set to 12 GB. If my server were to reach these thresholds, I would be charged an additional $80 for the month ($40 for 4 additional CPUs and $40 for 4GB additional RAM). If my server were to pass these thresholds, it would crash rather than continue to autoscale.

My VPS server resources are similar to Siteground’s – 6 CPU cores and 6GB of memory. Unfortunately that host does not offer the same monitoring tools as Siteground. I was originally going to SSH into this server and monitor the test live, but SSH wasn’t working right. After several hours working with support to enable my IP on the server’s firewall and troubleshooting my SSH key not authenticating, I remembered part of the reason I moved away from this host to begin with.

However, we still have the results provided by Mariam and based on those it seems the two performed very similar. The VPS was 15% slower on response times and had double the error rate.

Below are a few lessons learned from my first load test and questions Mariam helped me answer. Hopefully these will help point you in the right direction with your initial test.

How many users should I load test with? This is a gross oversimplified answer to this question, but basically you want to do your best to estimate the maximum number of visitors you would expect to have on your site during a traffic spike. I based mine on the number of subscribers to our email list. Taking into account that only a small percentage of email subscribers will actually make it to the website and that I would stagger the email to minimize the spike, I landed on a value of about 1,000 visitors at one time or less.

This is likely overestimated by quite a bit, but I wanted to plan for future growth. I also wanted to push my cloud server to its limits. SiteGrounds cloud servers are capable of increasing server resources on the fly and I wanted to see this in action. For this reason I had Mariam test 5,000 users within a 30 minute time frame. I also had her perform the same test on my old VPS hosting account which I still had just for comparison.

What actions will these users perform? Mariam uses a program called Jmeter to perform her load test. This program is capable of more than just simulating visitors to your website. It can also simulate complex actions that your users might perform while they’re visiting your site. For one of our tests, I asked Mariam to run a script within Jmeter to simulate visitors landing on a free plugin page, clicking on the download button, and going through the checkout process. Here is a screenshot of what that looks like in Jmeter.

I did this partly because I wanted to see how skilled she was at her craft (she didn’t disappoint) and to see what was possible with Jmeter. Ideally I would have had her perform this script on the live site to see how the server handled resource-intensive tasks like this vs simply visiting a page on the website. Instead I had her run the script on a staging version of the site in case things didn’t go quite as planned. Not to mention I didn’t want to have to deal with deleting all of the users and records created from the script. That brings us to the downfalls of staging sites.

Why is a staging site not always a great option when load testing? If your host offers a one-click staging site creation solution like SiteGround, most likely that staging site does NOT have access to the same resources as the live website. This makes sense because the purpose of a staging site is generally to test updates and changes, not test your server’s resource limits. But it’s not helpful if you’re trying to test the full capacity of your server’s limits.

To get around this, you could always copy your live or production site to a subdomain instead of using the one-click staging solution. You’ll just need to use caution here and make sure the staging site is completely detached from the production site.

Use a Service to Perform Load Testing

There are a few services available that automate load testing for you, the most popular being loader.io. You only have two options with this service:

• Free Plan – limited to testing 1 domain and limits each test to a maximum of 1 minute up to 10,000 users
• Pro plan – $100/month for unlimited tests and limits each test to a maximum of 10 mins up to 100,000 users

Since Loader.io does not have access to your server, you’ll be limited to the results they provide. You could log into your hosting account to view your server in real time while the test runs. But with the test limited to 1 minute, it might be difficult to determine whether any server resources were reaching their limits. At the very least you can review the response times and response counts. If response times are too high or there are too many failed response counts, this could indicate an issue. Below is a test I ran on diviplugins.com with 100 users.

As you can see, the test itself and the results are extremely basic compared to what an expert like Mariam can provide. However, I can see how the service could be useful for performing a scratch test. Basically to scratch the surface to see if there are any issues. If yes, maybe it’s time to hire a professional to perform a more thorough test.

Perform Your Own Load Test

The last option for load testing your site is to learn the tools used by experts and perform the tests yourself. Unless you are wanting to learn this skill so you can offer it as a service, I can’t say I would recommend this option. For a task that rarely needs to be performed, it’s just not worth your time. If you want to run a simple test, use the free plan on loader.io. If you want a more thorough test, hire someone who already has this skill.

With that said, Jmeter seems to be the most popular tool for load testing. This is the program used by Mariam to perform the load tests on my sites. If you’re interested in learning how to run this free, open-source tool you can check out this Jmeter tutorial video for beginners.

K6 is another free, open-source tool you can use to perform load testing. If you’re interested in this tool, check out this video for a k6 tutorial.

Optimizing After Load Testing

If your load test results are poor or if you’re seeing 503 or similar errors on your site, you’ll need to optimize your website, upgrade to a high performance plan, or change hosting.

Before you look at hosting, you should focus on optimizing your site. WordPress is a great platform to build your website on. But it can consume a lot of your server’s resources if not properly optimized. It pulls a lot of data from a lot of different places (database, theme files, plugin files, etc.) Without a simple caching plugin for example, WordPress will likely process dozens of database queries and PHP functions PER PAGE LOAD. This is completely unnecessary and easily avoided.

Anything you can do to minimize the amount of server resources required for each visitor will improve site performance. You should run down the usual site optimization checklist: upload images smaller than 250kb when possible and optimize them using TinyPNG, use a caching plugin like WP Super Cache, use a CDN like CloudFlare, keep active plugins to a minimum, etc.

If optimizing doesn’t help, it may be time to change your hosting. I would highly recommend a cloud server hosting plan if you can afford it and can’t afford for your site to crash. They’re more expensive than shared or VPS hosting, but the ability to increase server resources dynamically based on demand is a game changer.

The built-in parallax background option available in Divi makes it easy to create a parallax effect in your layout. But at times it can be difficult to get the placement just right so the portion of the background image you want displayed is visible. In this tutorial we’ll show you how you can use the background-position property in your CSS to control the exact position of your image.

We’re going to focus on the True Parallax option in this example since the effect is better than the CSS Parallax option. We’re also going to focus on the Fullwidth Header module. The technique and CSS will be the same whether you’re applying it to a section, Fullwidth Header, or any other module or element.

The image I’ll be using is a 1920 x 1080 px image. You may have to play around with the exact dimensions to get the effect you want, but this is a good place to start. It should give you plenty of height to work with and will look good on larger desktop screens. Using the technique below, we have full control over the vertical placement of the image. For horizontal placement, you’ll need to crop the image in a way that the objects in the image you want to line up with the left, center or right portion of the header are in the left, center or right portion of the image.

Since parallax is all about motion, please watch the video above to see the end results and walkthrough of the tutorial below. Let’s get started!

In my demo page, I am adding a Fullwidth Section and Fullwidth Header module to the top of the page. After adding placeholder text to the Title, Subtitle, and Body fields within the module’s Content tab, I now need to add my background image. Scroll down and open the Background section near the bottom of the Content tab. Click on the image tab and add your 1920 x 1080 image. Next turn on the Use Parallax Effect toggle. A new Parallax Method dropdown should appear. Choose the True Parallax option.

When the True Parallax option is enabled in the Fullwidth Header module, a new span container with class et_parallax_bg is added to the HTML output of the module. We’ll target this class in our CSS to modify the placement of the image. We’ll also need to give our module a CSS class or ID to target unless we want our changes to apply to all Fullwidth Header modules on the page or site. In my example I added the bottoms-up CSS ID in the Fullwidth Header’s Advanced tab -> CSS ID & Classes -> CSS ID.

We now have the background image set, parallax toggle turned on and set to True Parallax, placeholder text added, and a CSS ID assigned so we can target this header module only. Save the module and let’s add our CSS.

In this example we’re going to add our CSS to the Visual Builder’s Page Settings (the gear icon along the bottom of your screen). Once the Page Settings popup appears, we need to go to the Advanced tab -> Custom CSS. Here we can add CSS that will only affect this page. Below is the portion of the CSS that affects the background image placement:

The CSS above is what controls the placement of the background image (the padding in the CSS further down in this tutorial gives the Fullwidth Header its height). The first value in the background-position pair of values controls the horizontal position. You can modify this value to adjust the horizontal position on smaller screens but on large screens it won’t have any affect. The second value in the background-position pair of values controls the vertical position. This is where we can really fine-tune the placement.

By default, Divi will set these values so that the image is horizontally centered and vertically placed at the top. But because the et_parallax_bg container that holds our background image extends vertically past our Fullwidth Header container at the bottom, it’s not enough to simply change the values to center bottom. We need to lift the hidden portion of the background image container up vertically. For this we need to use a negative value.

In my example, I am using a negative value of 250px. You may need to adjust this value slightly depending on the padding you add to the Fullwidth Header for your image to get the portion of the image visible that you want. You can also change the media query values to your liking if you want to have more granular control over the placement for different screen sizes.

The full CSS that gives the Fullwidth Header its height and controls the style and placement of the text is below:

There’s a lot going on here. I’ve included all of the CSS I’m using to control the placement of the background image, module padding, text appearance and text placement and I’m modifying all of this slightly for different screen sizes using media queries. At the risk of providing too much data, I wanted you to see all of the CSS I’m using to get the layout you see in the video above.

That’s it! If anyone has an improvement, suggestion, alternative method, or any issues please comment below.

* If you see a gap between the bottom of your background image and the bottom of your Fullwidth Header, you’ll either need to reduce the negative vertical value in the background-position (2nd value) or you’ll need to use a taller image.

WordPress is one of the most popular website and CMS platforms on the Internet. With that popularity comes a huge catalog of free and premium plugins to extend the platform and make it even more useful. As with most things in life, plugins come with trade-offs. In the case of WordPress plugins, one of the biggest trade-offs is compatibility and conflicts.

With every WordPress plugin you install, you are introducing the possibility of bugs and conflicts with other plugins. For this reason a “less is more” approach should be used when installing plugins. Keeping the number of installed and active plugins on your site to a minimal is your first line of defense in reducing plugin conflicts.

But plugins are an important part of WordPress and should be celebrated, not feared! After all, what would WordPress be without plugins? We just need to apply some common sense and preventative measures to set ourselves up for success. In this post we’ll discuss best practices you can use to minimize your risk of plugin conflicts and also guide you on troubleshooting and resolving conflicts when they do happen.

In this article we’ll discuss:

• Choosing quality plugins
• Backing up your site
• Updating plugins
• Testing
• Troubleshooting
• Summary

Choose Quality Plugins to Prevent Plugin Conflicts

The first thing you can do to minimize plugin conflicts (aside from minimizing the number of plugins you install) is to be proactive and only download and purchase plugins from reputable developers. Whether you are downloading free plugins from the WordPress repository or premium plugins from third party websites, you can save yourself a lot of time and heartache by doing a little research.

WordPress Repository Plugins

Free plugins on the WordPress repository are fairly easy to vet. When you click on a plugin’s page, there is a lot of data available to help you choose high quality plugins:

• Last updated – This tells you how recently a plugin was updated. If a plugin hasn’t been updated in several months, it could (not always) indicate that the plugin is not actively developed and could contain bugs.
• Active installations – This is the number of WordPress websites that have the plugin installed and activated. The higher the number, the more stable the plugin is likely to be. Newer plugins with only a few hundred or thousand downloads should be installed and activated with caution.
• Tested up to – When a developer pushes an update for their plugin, they can choose to disclose the most recent version of WordPress their plugin has been tested with. If the version of WordPress is outdated it could indicate the plugin is not being actively developed.
• Ratings – You should try to stick with plugins that have a good amount of four star or higher ratings.

In addition to the info above, WordPress will also place a banner at the top of the plugin page to let you know when a plugin has not been tested with the latest three major releases of WordPress. In most cases these plugins should be avoided as it’s a good indication that the plugin is no longer actively developed.

Premium Plugins from Third Party Websites

Plugins downloaded from third party websites can be much more difficult to determine their quality and whether they’re actively developed. If the plugin is sold on a marketplace such as the Elegant Themes Marketplace, they must often go through a review process to help with quality control. Many of these marketplaces also offer a review and commenting system that you can browse through to see what the user feedback is and what issues others may be having with the plugin.

All of our plugins sold on DiviPlugins.com also offer a 30 day money-back guarantee, review and commenting system, current version, last updated date, and changelog so you can see the latest features and bug fixes. You should be cautious downloading any plugin that does not allow users to leave a review or does not disclose the active development of the plugin or offer a guarantee.

Back Up Your Site to Prepare for Plugin Conflicts

Sticking with our preventative measures first, it’s important that we have a reliable, recent, onsite and offsite backup of our website in case a new plugin or update causes catastrophic failure. Plugin conflicts, much like security holes, can be minimized but it’s nearly impossible to avoid them entirely.

While installing and updating plugins doesn’t generally come with great risk of breaking your site to the point it’s not recoverable, it has the potential. Third party plugins can have malicious code that can be expensive and nearly impossible to remove. Plugins that rely on a custom table in your database like ecommerce plugins have the potential to destroy data in this table during the update process. Having a backup of your website is a must.

We always recommend the free but highly reliable UpdraftPlus Backup Plugin. It’s easy to set up. Easy to connect to an offsite storage service like Dropbox or Google Drive. Easy to recover. And it just works which is more than can be said of many other backup plugins. UpdraftPlus allows you to schedule automatic backups that run on a schedule but it also allows you to manually create a backup with the click of a button. You should do this right before performing plugin updates on your site, especially if you have an active site (you post new content often or users frequently interact on your site).

Updating WordPress Plugins

So far we’ve only installed and activated a minimal number of plugins that we’ve deemed to be high quality to the best of our ability. We have a reliable, recent, onsite and offsite backup of our site. It’s now time to update. There are two approaches you can take to updating the plugins on your site: auto updates or manual updates.

Auto Updates

Since version 5.5 of WordPress, plugins can now be set to auto update. I would highly discourage enabling this feature. You take a big risk by allowing plugins to auto update in the background at random intervals and possibly break your site without your knowledge. You should always be present when updates are performed so you can immediately monitor and test for any bugs or conflicts.

There are also third party, freemium services available like ManageWP and MainWP that automate the update process but with more control. If you’re an individual with only one or a few websites, these services are probably overkill. If you’re a small agency or independent web developer with multiple clients, these services can provide a lot of value and are worth checking out.

Manual Updates

There are two approaches you can take to manually updating plugins: update all plugins at once from the Updates page or update plugins one at a time from the Plugins page. There is no right or wrong approach here. Personally I like to manually update plugins that play a significant role in the functionality of my site. After each plugin update, I test and make sure the function they provided is still performing as expected. I then update all other plugins that play a smaller role at once from the Updates page.

Using this approach comes with several advantages. By splitting my updates into smaller chunks, I can easily determine which plugin(s) created a bug or conflict. If you were to update all plugins at once, it would be much more difficult to determine which plugin is the culprit. This approach also saves time testing. By updating and testing important plugins individually first, I can bulk update less important plugins knowing that the core functionality of my site is less likely to be affected.

A final suggestion on updating your WordPress plugins is to update often. A good target would be weekly or bi-weekly. This doesn’t mean you should update every plugin as soon as an update is available. This is actually a bad idea, especially for major updates. But waiting too long between plugin updates can open your site up to security holes and will make the update process a more tedious chore. A weekly or bi-weekly update cycle should limit your updates to a small handful of plugins at a time which is much more manageable.

Production Site or Staging Site?

A production site is the live version of your website that users interact with in real time. A staging site is a copied version of your production site that can be used for testing updates or custom code without affecting your production site and user experience. When installing plugin updates, you’ll need to decide whether you want to install them directly on your production site or on a staging site. The method you choose is really going to depend on your situation.

Staging Site Testing

Many WordPress experts will tell you NEVER install new plugins or plugin updates on a production site. This is a very hard-line and probably unnecessary approach for most users. Time is money and staging sites are a time vampire. You really need to balance and assess the risk potential with the amount of time that would be involved in creating and testing on a staging site. Again this is going to be different for every situation and every individual.

If you decide the stakes are too high for you to update on your production site, there are several methods you can use to create a staging site. Many hosts now make it fairly easy to create a staging site through an interface they provide in your hosting account or even directly in your WordPress dashboard. This would by far be the easiest solution.

If your host does not offer this, you’ll need to manually create a staging site on your computer. For this I would highly recommend Local by Flywheel which makes creating a staging site much easier than other options. But it’s still not for the faint of heart. If your technical skills are lacking, it can be a little overwhelming to manually create a staging site. You’ll need to decide if this is something you want to tackle yourself or throw in the white flag and pay someone to manage your website for you. I would imagine if your website is too important to update plugins directly on your production site and you lack technical skills, you are likely already paying a developer to help manage your site anyway.

Production Site Testing

When performing plugin updates on a production site there are a few ways to minimize your risk as much as possible. Having a recent backup of your site is more important than ever when updating plugins directly on your production site. Make sure you manually back up your site immediately before updating.

I would also highly recommend performing the update late at night, on weekends or on the day and time of day you see the least amount of traffic. You can even log into your Google Analytics account to monitor your visitors in real time and update when you see the least amount of visitors. You’ll be able to think much more calmly if disaster strikes during a plugin update and there are minimal users on your site.

Test New Plugins and Updates for Plugin Conflicts

Our final step in the update process is to test. It’s not fun. It’s time-consuming. It’s tedious. But there’s no way to be sure a plugin or plugin update hasn’t introduced a bug without testing it.

Always make sure you clear your cache if you have server cache enabled or a caching plugin installed after updating anything on your site. In most cases this should be automated by the caching mechanism but I would not take this for granted. Manually clear the cache so you know 100% that what you see while testing is what others will see once the cache expires.

Start your testing by visiting your homepage and scrolling top to bottom, looking for any obvious bugs visually. Next move onto high priority items such as call to actions, popups, contact forms, product pages, checkout and cart pages, etc. What is the purpose of your site? To sell products? Collect emails? Gather leads? Inform? Make sure your website’s main purpose has not been compromised by the plugin update.

Once you’ve verified the main purpose is still being served, you’ll need to balance how thorough you want to be with the rest of your testing with how much you value your time. Everything is a tradeoff. After going through this process enough you’ll learn to anticipate which items need more attention during your testing. Some website components (contact forms, login forms, popups, etc.) are much more fragile and easier to break than others. Spend the majority of your time on these items and consider testing less important items every other update or let your users report and minor bugs.

Troubleshooting Plugin Conflicts

With all of the preventative steps you’ve taken and a bit of luck, there’s a good chance you won’t encounter any plugin conflicts when you perform your weekly or bi-weekly updates. However it is likely that eventually your luck will run out and you will encounter a plugin conflict or bug. The following steps should help you narrow down the culprit and recover quickly.

The first thing we need to decide is whether we know which plugin caused the conflict. If you updated your plugins manually as suggested and in batches, it shouldn’t be too difficult to determine which plugin caused the conflict. If you got behind on updates and had to update a lot of things at once, you may have a long road ahead of you.

You Don’t Know Which Plugin Caused the Conflict

If you’re not sure which plugin caused the conflict or if it was a plugin update at all, you need to spend some time narrowing it down. You really shouldn’t get to this point if you’ve followed all of the preventative steps above. Even if you’ve done everything right and a plugin still causes a conflict, you should have a really good idea which plugin it is. If not, there are methods we can use to find the culprit.

If you’re using Divi, go to the Divi -> Support Center page, scroll down near the bottom, and enable Safe Mode. This will temporarily disable all plugins, child themes, and custom code added to the Divi Integrations tab but only for the your current session as the admin. Visitors to your website will continue to see the site as if all of the above are still active.

Did this solve the issue? If yes, now you know it’s related to a plugin or your child theme. If no, it’s possible you updated WordPress or Divi at the same time you updated your plugins and one of those is the issue.

If yes, disable Safe Mode. Go to your Plugins page and temporarily deactivate all plugins. You can do this by clicking on the checkbox next to Plugin just above your first plugin in the list. This should select all plugins on your site. Next click on the Bulk actions dropdown above the checkbox and change this to Deactivate. Click the Apply button.

Did this solve the issue? If no, try temporarily activating your parent theme which will in turn deactivate your child theme. If this solves the issue and assuming you didn’t update WordPress or Divi, there’s custom code in your child theme causing the conflict.

If yes, it must be related to a plugin. Go back to your Plugins page and click on the Recently Active link. This should list all of the plugins you deactivated in the previous step. Now you can activate all plugins again and then deactivate them one at a time until you find the culprit. Another approach is to only reactivate the top or bottom half of the plugins. If that doesn’t resolve the issue, reverse the deactivated plugins with the activated plugins. Repeat this halving approach until you’re left with only a few plugins which you can then deactivate one at a time until you find the culprit.

You Know Which Plugin Caused the Conflict

Knowing the source of the problem is a major advantage when trying to find a solution. Half of your work is already done. It now becomes a matter of importance. Is this a major issue that broke your production site or a minor issue or an issue that only affected your staging site?

Revert to Previous Version of Plugin for Major Issues

If the issue caused by the update is catastrophic, you can revert to the previous version of the plugin running on your site before the update. How you do this will depend on your setup. If using the UpdraftPlus Backup Plugin, the process is very simple. Log into your dashboard and go to Settings -> UpdraftPlus Backups. Remember that backup you created right before you updated your plugins? You should see it waiting for you under Existing Backups. Click the Restore button next to the correct backup. On the following page you should see a list of available components you can restore from backup:

• Plugins
• Themes
• Uploads
• Others
• Database

The safest option here is to select the Plugins component only, click Next, and then click Next again. This will revert all plugins to their previous versions right before you updated them. No data will be lost and you should be right back where you started when everything was running properly.

If that’s not the case, try running through the You Don’t Know Which Plugin Caused the Conflict troubleshooting steps above. In many cases it’s a simple matter of clearing your cache or optimizing plugins.

Another possibility is that you may need to restore your Database component as well. I would be very careful before choosing this option. This is not a common cause for plugin update issues. You should only restore your database if the plugin update that caused the issue also required a database update. Most plugins that update your database will display a notification at the top of the WordPress dashboard immediately following the update that says something like this: “Thanks for updating our plugin. We need to make a few changes to the database. Please back up your data and click this button to proceed.”

Just keep in mind that if any ecommerce transactions, new account creations, new comments, etc. were made between the time you updated the site and the restoration of the database, those will be lost. This goes back to only updating your site during non-peak hours.

Contact the Developer for Minor Issues

If the issue caused by the update is minor or you performed the update on your staging site, reverting to the previous version of the plugin may not be necessary. In this case I would contact the developer for a solution. No one knows the inner workings of the plugin better than the people who developed it. If it’s a plugin from the WordPress repository, you can check the support tab on the plugin’s page. If it’s a popular plugin and you’ve waited several days since the update was released, it’s likely that others have encountered the same issue you’re having with the update and have already reported it.

Browse through the support topics, find a recent one that sounds similar to your issue, and read the responses from the developer. Sometimes these can include a temporary fix you can implement,  a promise of a fix in an upcoming update, or a realization that the issue is actually caused by another plugin or theme.

If you don’t see any topics related to your issue, you can create a new topic and hopefully receive a fast response. Don’t miss out on an opportunity to quickly resolve your issue because you’re too afraid to be the first to report it. Even if you end up being wrong and the conflict is caused by another plugin, it’s likely that your question could help others.

For third party plugins, use their support system or contact form and explain the issue you’re having. Too much information is almost always better than not enough. Provide the plugin name, version, issue you’re having, and if possible a URL so the developer can see the issue firsthand. If it’s complicated to explain with text, use free screen recording software like Loom to make it even easier for the developer to understand the issue. Support tickets can sometimes take 24 hours or even longer to get a response. You don’t want to wait that long only to receive a response like “Which plugin are you referring to?”. Again, too much information is almost always better than not enough. Try to be clear and concise.

If you decide to tackle the troubleshooting yourself, here are some common steps you can perform to resolve the issue with the plugin update. Keep in mind the following steps won’t do a bit of good if the issue is a bug in the plugin. If that’s the case, you’ll need to revert to the previous version or wait for help from the developer.

Clear Your Cache

Caching plugins are important and necessary, but they sure make things infinitely more difficult when it comes to testing changes. If you have a caching plugin installed or your host includes a server cache interface in your WordPress dashboard (usually along the top bar in your dashboard), delete the cache on the entire site and test again.

Most caching plugins will display the non-cached version of a site when the site is viewed while logged in as admin. See if the issue you’re seeing is resolved when viewing the site while logged in as admin. If not, there’s a very good possibility the issue is related to cache or a security plugin. When in doubt, you can always temporarily disable your caching plugin to be 100% certain you are not seeing the cached version of your site.

Disable Optimizing Plugins

Just like caching plugins can affect plugin updates, so can optimizing plugins – especially ones that minimize CSS, JS and/or attempt to move scripts to the footer. Any plugin that claims to optimize your site or increase your page speed or Google PageSpeed score falls into this category. Do yourself a favor and just temporarily disable these plugins if you’re having any issues. Once you’ve done this, clear your cache again and test again. If that does the trick, you can try enabling these plugins and test again. If the issue comes back, contact the developer of the optimizing plugin.

Disable Security Plugins

This one should be exercised with caution, especially if you’ve encountered a lot of security issues on your website. But when time is money and you’re trying to find the source of an issue, you should be perfectly safe temporarily deactivating any security plugins for testing purposes. Just make sure you remember to activate the plugin again when you’re done.

The most common plugin conflict created by security plugins is they sometimes block important files needed to perform AJAX tasks. If you have issues with plugins that use AJAX to update content on your page without refreshing the page, temporarily deactivating your security plugin may solve this. If it does, contact the developer of the security plugin who will likely have a solution for this.

Disable Divi Performance Toggles

Since Divi version 4.10 was released, there is now a Divi -> Theme Options -> Performance tab with over a dozen toggles that turn off and on new performance features. There’s a lot going on here but here are some general suggestions. If you’re having issues with a third party Divi plugin, try disabling the top three toggles:

• Dynamic Module Framework
• Dynamic CSS
• Dynamic Icons

Plugins that are not compatible with Divi 4.10 may need these toggles turned off to function correctly. If this works, you can turn them back on one at a time (you can also do this with any of the toggles) until the issue comes back and then you’ll know which toggle needs to stay disabled.

Another toggle to pay attention to here is the last one – Defer Additional Third Party Scripts. This can break some plugins and would be one of the first ones I would turn off during your troubleshooting.

Disable Your Child Theme

Child themes can contain custom CSS in the style.css file, custom functions in the functions.php file, custom javascript in the Divi -> Theme Options -> Integration tab, and other more complex modifications as well. I’ve seen child themes with nearly as much code as the parent theme. Something as simple as display: none; in the stylesheet can make it seem like a plugin is broken. Disabling your child theme can be a quick test to make sure you or your developer isn’t causing the conflict with custom code.

Summary

• Limit the number of plugins you install on your website. Less is more.
• Only install trustworthy plugins that are actively maintained and have good reviews.
• BACK UP YOUR SITE! This is the most important rule and WILL bite you eventually if you don’t adhere to it. If you are installing a major plugin update or new plugin that handles an important process on your site, make sure you create a backup of your site immediately before updates.
• Update regularly but don’t install a new update the day it’s released. This is especially true if it’s a major update or if you are running an ecommerce or vital site. Developers make mistakes. Give an update several days or even a few weeks to propagate before you install. This gives the developer time to receive feedback from other users and fix any major bugs. If your website is just for fun, consider ignoring this rule to be one of the early adopters and report any bugs you find.
• Clear your cache immediately after updating. Many caching plugins will do this automatically when a page or plugin is updated, but not always. If you’re testing a cached version of your site, you won’t know if the update broke anything.
• Test all of the important features of your site: checkout, account creation, login, contact forms, signup forms, social share buttons, etc. Only you can determine the most important aspects of your site. Start with those and make sure they’re all working properly.
• Narrow down possible culprits until you find the plugin causing the conflict.
• Revert the plugin to the previous version, contact the developer, or troubleshoot the issue on your own.

The filter we’ll be using is the Custom Items filter. You can find more information and a basic example for this filter on the Custom Items documentation page. Again, this will only apply to the DP Owl Image Carousel module (NOT the DP Owl Carousel module).

Add the following code to your child theme’s functions.php file:

• ocp-parent-wc-categories (add this to the module you want to display WooCommerce parent categories)
• ocp-child-wc-categories (add this to the module you want to display WooCommerce child categories)

You can add the IDs above to your module by going to the module’s Advanced tab -> CSS ID & Classes -> CSS ID input. Once added, the code above will display either WooCommerce parent or child categories in a carousel based on the module ID. Please note we are also adding a is_archive() check on the child category module since this module will likely be placed on the Divi -> Theme Builder -> All Product Category Pages template. If you are not using this method, you may need to remove the is_archive() check and manually set the $current_term_id variable.

Once we know which module we are working with (parent or child categories), we then get an array of term IDs for the parent categories or the child categories of the current category. We then send that array of terms to the second function which creates the content.

In the dp_ocp_item_output_wc_categories() function, we are getting the data from each WooCommerce category (term name, thumbnail, URL) and outputting it in a format compatible with the carousel.

One thing to note is that the number of items (categories) displayed in the carousel at one time will default to the module’s default values: 5 for desktop, 3 for tablet, and 1 for mobile. There may be scenarios when there are less WooCommerce categories than the default values. For example, if a parent category only has three child categories, the carousel will still display five items in the carousel on desktop – cloning carousel items until it has enough to fill the carousel.

We can add another bit of code to our functions.php file to solve this:

Since we are duplicating a portion of the code and querying the terms multiple times for different filters, it would be a good idea to install a caching plugin to cache the resulting HTML of these pages.

The Divi FilterGrid plugin has a lot of click options available within the module settings including:

• None
• Link to post
• Show post in popup
• Show featured image in lightbox
• Show all featured images in lightbox gallery
• Open custom lightbox gallery

It’s the last option in the list above we’ll be paying attention to in this tutorial – Open custom lightbox gallery. Once this option is selected in the module’s settings (Content tab -> Posts Elements -> Click Action) a new field “Custom Field Name for Images” will display under the Click Action dropdown.

Here we can enter the name of a custom field that will contain an array of image URLs we want displayed in our custom lightbox gallery. Once you have this custom field name entered, you would simply edit each post (or any custom post type) that will get displayed in the grid and add this custom field multiple times, each time entering the URL of an image. This will create an array of images that will be used for the lightbox gallery. When the featured image for that post is clicked, the images in the custom field will get displayed in a lightbox gallery.

However, the images that are shown in the custom lightbox gallery do not need to come from a custom field. For example, they can also come from an Advanced Custom Field (ACF) “Gallery” field using the custom lightbox filter. This filter is already documented with examples. One of those examples shows how to display an ACF Gallery in the custom lightbox gallery.

As you can see, the custom lightbox gallery click action option is very versatile. Using the filter, you can display images from any source you want as long as you return them in an array format. In the example below, we’re going to show you how to display images from a Divi Gallery module located within each post.

Please add the following to your child theme’s functions.php file:

In the code above, we are finding the first gallery module from the post. Then we are extracting the image IDs that are found in the module’s shortcode. Once we have the image IDs, we are looping through each ID and using the built-in WordPress wp_get_attachment_image_url() function to get the corresponding image URL. Finally, we are returning this array of image URLs to be displayed in the lightbox gallery.

A slight variation of this would be to get the images from ALL gallery modules within the post. Please use the code below if you have multiple gallery modules in each post and want to display images from all gallery modules:

What I like most about the custom lightbox click action is the flexibility it brings. We’ve shown three examples how you can display a custom lightbox gallery for each post by populating the gallery with images from:

• A custom field
• An ACF Gallery field
• A Divi Gallery module

But you are not limited to the options above or to any single option above. For example, you could check if the post has a gallery module. If it does, display images from the gallery module in the lightbox. If not, check if the post has a custom field or ACF Gallery field. If it does, display images from one of those sources. If not, do nothing or display the featured image for that post. Lots of possibilities with this one 🙂