Ultimate Guide to WordPress Migrations and SEO: Pre-Migration Prep

There are many reasons you might need to migrate a WordPress site – a change of domain name or perhaps moving a blog from a subdomain to a subdirectory. Whatever the reason, it is important to factor in SEO when considering a WordPress migration. But why, exactly, do you need to keep SEO in mind?

There are many signals that can affect organic rankings in search engines such as Google. These range from the text used on a web page, the inbound links from other sites, to the load times and optimisation of a page for mobile devices.

So in this article – the first in a two-part series – I’ll walk you through the ways in which WordPress migrations can impact your SEO, and the pre-migration steps you should carry out to minimize a hit to your organic search rankings.

How Does Migrating WordPress Affect SEO?

#1: Changing URLs

Search engines view different URLs as different pages, even if the content is identical. If the appropriate steps aren’t taken for URLs that change, then their organic rankings and the value of inbound links could be lost.

#2: Changing Content

When determining the relevance of a web page to a user’s search query, content signals are some of the most important. If you are using the migration as an opportunity to refresh your WordPress website’s content, any changes could have a positive or negative effect on your organic rankings.

#3: Changing Code

Part of the WordPress migration might involve changing the theme used on your website. This will change how the site is coded and could affect how well optimised it is for search engines. There may also be unforeseen issues introduced if the developer didn’t have SEO as a priority whilst building the theme, such as crawling issues or mobile device optimisation.

#4: Changing Performance

Page speed has been a ranking signal for many years now, and Google has recently been placing even greater emphasis on web page performance with regards to mobile devices. You can see this with developments such as AMP (Accelerated Mobile Pages). Your WordPress migration could have involved changing how the site is built, as well as its hosting. Both of these changes could have affected your website’s load times.

The WordPress Migration Process for SEO

So, you can see that a WordPress website migration could have an impact on organic rankings and traffic. But how can you ensure the best possible migration for SEO?

You can divide the process of the migration into two phases: pre-migration and post-migration. This is a two-part series, with this particular post covering the SEO tasks you should carry out before the WordPress migration. The second post is going to cover what you need to do once the migration has been carried out, including testing, to ensure that everything has gone according to plan.

Getting Started: Pre-Migration for WordPress

Testing Your Server

If you are setting up the new site on a staging environment for testing, then you need to make sure that search engines cannot crawl the test site. The easiest way to do this, is to block search engines using the robots.txt file.

This file should be placed in the root of your staging environment. For example, if your test site is on a subdomain, the robots.txt file would be located at http://ift.tt/2gx2KCi. You need to have the following directive in your robots.txt file to block search engines from crawling the test site:

Setting up Google Search Console and Analytics

You should make sure that you have Google Search Console setup, as well as an analytics platform. A popular and free analytics solution is Google Analytics. If you don’t have analytics setup for your site, do this now. It can provide a lot of insight into your visitors’ behaviour, acquisition and conversions. You’ll need these tools for pre-migration tasks and post-migration checks.

Identifying Any Current SEO Issues

At this point, you also want to identify any SEO issues your current website might have. This step is particularly important if either the theme is being changed and/or the content is being refreshed. By flagging issues early, you can ensure that the new site build and content avoids these mistakes.

If you have the budget, then you can bring in an SEO specialist or an agency to help you identify issues. If not, then there are a number of SEO tools, such as Woorank (free trial) and Onpage.org (free for 100 URLs), that can help you to identify common SEO problems.

Onpage.org

SEO Plugins Worth Checking Out

Is your current site using any plugins for SEO? If not, now is a good time to either start using one or to at least plan one to use on the new site after the WordPress migration. WordPress SEO plugins can help with a number of tasks, such as controlling which pages are indexed, XML sitemap generation, and editing metadata.

There are a number of SEO plugins available. Here at WPMU DEV, our SmartCrawl plugin is a great option for helping to drive traffic to your site. SmartCrawl features the ability to send sitemap updates to search engines, custom descriptions and titles, auto link keywords to any URL, built-in Moz integration and more.

Record Your Current SEO Performance

You’ll want to be able to see what did and didn’t work post-migration. To do this, you’ll need to know how your website performs before migrating your website. You can use both Google Search Console and your analytics platform to get a good idea of your organic search performance.

From Google Search Console, you will want to record the following metrics:

  • Search Analytics clicks
  • Search Analytics impressions
  • Search Analytics click through rate (CTR)
  • Search Analytics positions
  • Internal links

Search Console only stores Search Analytics data for 90 days. I often find this data is something I want to refer back to in the future. If you want to compare data over many months, particularly at a granular keyword and landing page level, the last 90 days of data might not be enough. Err on the side of caution and download your pre-migration Search Analytics data. You should download “Queries,” “Pages” by various combinations of devices and search types for the last 90 days.

Search Console Search Analytics download.

You should also download the pre-migration internal links report. You can compare this with the post-migration data if you are having any issues and believe internal linking may be the problem.

If you are using an analytics platform, try and have this collecting data for at least a few months prior to the WordPress migration. This should provide you with a reasonable amount of data to compare pre-migration and post-migration.

Checking Your Website’s Page Speed

Since page speed is a ranking signal for Google, you will want to keep a record of how well your site is optimized pre-migration. You can use tools such as Google PageSpeed Insights or GTmetrix to get an idea of how fast your pages load and where improvements can be made. GTmetrix actually provides both YSlow and Google PageSpeed scores, as well as storing registered users’ most recent page analyses.

Or better yet, you can use our free WP Checkup tool here at WPMU DEV to get an overview of your SEO, site performance and security.

You should test a variety of pages, such as the homepage, single posts, category archives, tag archives and static pages. Make a note of how long it takes each page to load, the number of resources required, the total page load size and what the recommended actions are needed to optimise page loads. You will want to refer back to this information during the post-migration phase.

WP Checkup is our free tool for testing your website's SEO, performance and security.
WP Checkup is our free tool for testing your website’s SEO, performance and security.

SEO

SmartCrawl is watching. Simply scan, list & fix

SmartCrawl helps you ensure your website is optimized for search engines and aid it in climbing towards higher search results ratings. Set global defaults and customize specific pages and post types to your SEO desire.

TRY SMARTCRAWL FREE
LEARN MORE

Create XML Sitemaps for Your Site

Ensure that your website will have XML sitemaps post-migration. These are useful for getting your content crawled and indexed by Google. If you are unsure of how to do this, simply install the SmartCrawl plugin for automated sitemap creation and the ability to send sitemap updates to search engines.

If you aren’t currently using XML sitemaps, then it is recommended you implement them during the pre-migration stage. This will allow you to test them in Google Search Console and ensure they are working without errors.

You can read Google’s documentation on XML sitemaps here.

Set up Redirects for URLs That Change

Depending on the size of your website, this can be one of the most time consuming pre-migration tasks. It is also one of the most important. By correctly redirecting all of the URLs that are changing during the WordPress migration you will:

  • Alert search engines to your content moving to new URLs
  • Ensure visitors clicking on inbound links get to a live page rather than a 404 error page
  • Have the best chance of smoothly transitioning your organic search rankings from the old URLs to the new URLs
  • Retain the value of inbound links to the old URLs

To do this effectively you will want to create a redirect mapping document. Open up your favourite spreadsheet program and create one column for Old URLs and one for the New URLs you will be redirecting to. You now need to identify all of the URLs that you will want to redirect.

When redirecting URLs for a WordPress migration, don’t just focus on the URLs that are live on the current site. You should redirect any URLs that have inbound links, even if they are URLs from previous versions of the site or they are pages that have been removed prior to the WordPress migration.

There are a number of sources you can use, some free and some paid. You should use as many as you have access to. The sources I use to identify URLs to redirect are:

#1: Search Console

Export Search Analytics Landing Pages

If you followed the section earlier regarding recording current SEO performance, you should have already downloaded your landing pages from Search Analytics

Note that Search Analytics will often limit the number of results to approximately 1000. If you have more pages than this, then you will need to use the Search Console API to get all of the URLs.

Export Most Linked Content

  1. Click Search Traffic
  2. Click Links to Your Site
  3. Under You most linked content, click on More »
  4. Export your most linked content by clicking Download this table
Search Console most linked pages download.

Export Internal Links

  1. Click Search Traffic
  2. Click Internal Links
  3. Export your internal link pages by clicking Download this table
Search Console Internal Links download.

Export Crawl Errors

  1. Click Crawl
  2. Export your crawl errors by clicking Download
Search Console Crawl Errors download.

#2: Google Analytics

Export Landing Pages

  1. Click Behavior
  2. Click Site Content
  3. Click Landing Pages
  4. Set the start and end dates to cover the entire time that you have collected data
  5. Scroll to the bottom of the page and set Show rows to 5000
  6. Scroll to the top of the page and click on ‘Export’ and then select the file format you want

Note that if you have more than 5000 landing pages, you will need to paginate through each batch of 5000 and export each set of results.

Google Analytics Landing Pages export.

#3: Inbound Link Monitoring Tools

I generally use Ahrefs and/or Majestic for monitoring inbound link data; however, there are a wide range of tools out there for you to use.

Export Landing Pages From Ahrefs

  1. Search for your domain
  2. Below the Pages in the left-hand menu, click Best by links
  3. At the top right of the page click Export
  4. Select Full Export
  5. Click Start Export
  6. The export will be available to download once it has finished processing
Ahrefs pages export.

Export Landing Pages From Majestic

  1. Select Historic Index
  2. Search for your domain
  3. Click Backlinks
  4. Click Export Data
  5. Click Advanced Report
  6. On the next page ensure Advanced Report and Domain are selected then click on Create Report
  7. On your Reports page, click on the domain you just created this report for
  8. Hover over Download Options
  9. Click on ‘Download Backlinks
  10. Click on Prepare Download
  11. Navigate to your Downloads page
  12. Click on the link Backlinks for {yourdomain.com}
  13. The data you will want to use in the export is the Target URL column
Majestic SEO export data.

#4: Screaming Frog

Screaming Frog is one of the most popular web crawling tools. There is a free version available that allows you to crawl up to 500 URLs. The premium version allows you to crawl an unlimited amount of pages.

Run a Site Crawl

  1. Open Screaming Frog
  2. Click Mode and select Spider
  3. Type your website’s URL into the input box at the top of the window and click Start
  4. Let the program run whilst it crawls your website
  5. Once it has finished, within the Internal tab click export
Screaming Frog

Once you have all of this data, you want to get all of your domain’s URLs that you have collected and place them into the Old URLs column in your redirect mapping spreadsheet. De-dupe these URLs and then you are ready to begin mapping your new URLs to the old URLs. Make sure you redirect URLs to either the URL that is directly replacing them or at least the most relevant content that remains on the site.

When the redirect mapping is complete you will need to consider how you will implement the redirects. The redirect can either be manually added to the .htaccess file or a redirect plugin can be used.

If you want to use the .htaccess file then there is a lot of useful information over on the Apache website. Generally you will be using the Redirect and RedirectMatch directives. For more complicated redirect matching, you will want to use Apache’s mod_rewrite.

A popular redirect plugin for WordPress is Redirection. This allows you to easily add redirects and provides a considerable amount of flexibility and control. You can read the documentation for this over on the official site.

WordPress Redirection plugin.

You do not want these redirects to go live yet, but you do want to have them ready for when you migrate your website. You can have the new version of your .htaccess file with the redirects ready to replace the pre-migration .htaccess file. If you are using the Redirection plugin, then you can add your redirects via the plugin and just leave them set as disabled until it comes time to migrate your site.

Please note, you should only be redirecting URLs that are changing. If you try to redirect URLs that remain the same, you will cause redirect loops. This will make the page unreachable until the redirect is removed.

Wrapping Up

That concludes part one of this WordPress migration SEO guide. At this point, your site should be ready to migrate, at least in terms of SEO.

In part two, I’ll be covering what you need to do immediately after the WordPress migration, how you can check if everything went correctly and on-going analysis you can do to make sure your WordPress migration hasn’t negatively affected your site’s SEO.

Related posts:

  1. 20 SEO Experts You Should Be Following to Stay on Top If you’re looking to seriously step up your SEO game,…
  2. 9 Obvious Things You Probably Don’t Know About WordPress SEO If there’s one thing you should include in your website’s…
  3. SEO Checklist: 4 Simple Steps to Get Your WordPress Site Ranking Higher Have you ever Googled your own website and been disappointed…
  4. Getting the Most out WordPress Tags for Improved SEO and Readability Vincent Van Gogh once said, “Great things are not done…

Object-Oriented Autoloading in WordPress, Part 3

In the last tutorial, we reviewed the original state of our autoloader and then went through a process of object-oriented analysis and design. The purpose of doing this is so that we can tie together everything that we’ve covered in this series and the introductory series. 

Secondly, the purpose of doing this in its own tutorial is so we can spend the rest of this time walking through our class, seeing how each part fits together, implementing it in our plugin, and then seeing how applying object-oriented programming and the single responsibility principle can lead to a more focused, maintainable solution.

Before We Get Started

At this point, I’m assuming that you’ve been following along with this series. If not, then please review part one and part two. This one assumes you’ve been following along thus far.

If you’re a beginner, I recommend reading the initial series in its entirety, as well. Once you’re caught up, you should be in a good position to finish out the series as we conclude with the remainder of the source code covered in this tutorial.

What We’ve Done Thus Far

To provide a quick summary and to make sure we’re all on the same page, we’ve covered the following topics in this series:

  • reviewed the definition of a class interface
  • seen how a class implements an interface
  • reviewed the single responsibility principle
  • analyzed our existing autoloader
  • created a roadmap for our object-oriented version of the autoloader
  • and designed a basic implementation for an object-oriented version of the autoloader

At this point, we’re ready to swap out our existing autoloader with the object-oriented based code. Note, however, that this will not be a simple matter of changing out files. 

What We Need to Do

Instead, we’re going to need to create the files, make sure they are following the WordPress Coding Standards, implement them, test their implementation to make sure the plugin still works, and then remove the existing autoloader.

It sounds like a lot of work, but if our analysis and design from the previous tutorial was done correctly and proves to be accurate, then we should have little problem doing everything listed above.

Your Development Environment

Before we jump into the implementation, I want to provide a quick rundown of the development environment you should have on your system. Technically, this is something you should already have running as per directions in previous tutorials, but I want to be as complete as possible.

  • a local development environment suitable for your operating system
  • a directory out of which WordPress 4.6.1 is being hosted
  • a text editor or IDE
  • knowledge of the WordPress Plugin API

With that said, let’s get started.

Object-Oriented Implementation

In this section, we’re going to revisit all of the code that we reviewed in the previous tutorial; however, we’re going to be looking at each individual file along with complete documentation.

Additionally, we’re going to be including it in our project so that by the end of the tutorial, we’ll be able to use this code in place of the single, procedural-based code we used earlier.

Note that each of the following files should be named as listed and should be included in the inc directory. Furthermore, all of this is available for download by using the blue button in the sidebar of this post.

class-autoloader.php

<?php
/**
 * Dynamically loads the class attempting to be instantiated elsewhere in the
 * plugin.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */

/**
 * The primary point of entry for the autoloading functionality. Uses a number of other classes
 * to work through the process of autoloading classes and interfaces in the project.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */
class Autoloader {

    /**
     * Verifies the file being passed into the autoloader is of the same namespace as the
     * plugin.
     *
     * @var NamespaceValidator
     */
    private $namespace_validator;

    /**
     * Uses the fully-qualified file path ultimately returned from the other classes.
     *
     * @var FileRegistry
     */
    private $file_registry;

    /**
     * Creates an instance of this class by instantiating the NamespaceValidator and the
     * FileRegistry.
     */
    public function __construct() {

        $this->namespace_validator = new NamespaceValidator();
        $this->file_registry       = new FileRegistry();
    }

    /**
     * Attempts to load the specified filename.
     *
     * @param  string $filename The path to the file that we're attempting to load.
     */
    public function load( $filename ) {

        if ( $this->namespace_validator->is_valid( $filename ) ) {
            $this->file_registry->load( $filename );
        }
    }
}

class-namespace-validator.php

<?php
/**
 * Looks at the incoming class or interface determines if it's valid.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */

/**
 * Looks at the incoming class or interface determines if it's valid.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */
class NamespaceValidator {

    /**
     * Yields the deciding factor if we can proceed with the rest of our code our not.
     *
     * @param  string $filename The path to the file that we're attempting to load.
     * @return bool             Whether or not the specified file is in the correct namespace.
     */
    public function is_valid( $filename ) {
        return ( 0 === strpos( $filename, 'Tutsplus_Namespace_Demo' ) );
    }
}

class-file-investigator.php

<?php
/**
 * This class looks at the type of file that's being passed into the autoloader.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */

/**
 * This class looks at the type of file that's being passed into the autoloader.
 *
 * It will determine if it's a class, an interface, or a namespace and return the fully-qualified
 * path name to the file so that it may be included.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */
class FileInvestigator {

    /**
     * Returns the fully-qualified path to the file based on the incoming filename.
     *
     * @param  string $filename The incoming filename based on the class or interface name.
     * @return string           The path to the file.
     */
    public function get_filetype( $filename ) {

        $file_parts = explode( '\\', $filename );

        $filepath = '';
        $length   = count( $file_parts );
        for ( $i = 1; $i < $length; $i++ ) {

            $current = strtolower( $file_parts[ $i ] );
            $current = str_ireplace( '_', '-', $current );

            $filepath .= $this->get_file_name( $file_parts, $current, $i );
            if ( count( $file_parts ) - 1 !== $i ) {
                $filepath = trailingslashit( $filepath );
            }
        }

        return $filepath;
    }

    /**
     * Retrieves the location of part of the filename on disk based on the current index of the
     * array being examined.
     *
     * @access private
     * @param  array  $file_parts The array of all parts of the file name.
     * @param  string $current    The current part of the file to examine.
     * @param  int    $i          The current index of the array of $file_parts to examine.
     * @return string             The name of the file on disk.
     */
    private function get_file_name( $file_parts, $current, $i ) {

        $filename = '';

        if ( count( $file_parts ) - 1 === $i ) {

            if ( $this->is_interface( $file_parts ) ) {
                $filename = $this->get_interface_name( $file_parts );
            } else {
                $filename = $this->get_class_name( $current );
            }
        } else {
            $filename = $this->get_namespace_name( $current );
        }

        return $filename;
    }

    /**
     * Determines if the specified file being examined is an interface.
     *
     * @access private
     * @param  array $file_parts The parts of the filepath to examine.
     * @return bool              True if interface is contained in the filename; otherwise, false.
     */
    private function is_interface( $file_parts ) {
        return strpos( strtolower( $file_parts[ count( $file_parts ) - 1 ] ), 'interface' );
    }

    /**
     * Retrieves the filename of the interface based on the specified parts of the file passed
     * into the autoloader.
     *
     * @access private
     * @param  array $file_parts The array of parts of the file to examine.
     * @return string            The filename of the interface.
     */
    private function get_interface_name( $file_parts ) {

        $interface_name = explode( '_', $file_parts[ count( $file_parts ) - 1 ] );
        $interface_name = $interface_name[0];

        return "interface-$interface_name.php";
    }

    /**
     * Generates the name of the class filename on disk.
     *
     * @access private
     * @param  string $current The current piece of the file name to examine.
     * @return string          The class filename on disk.
     */
    private function get_class_name( $current ) {
        return "class-$current.php";
    }

    /**
     * Creates a mapping of the namespace to the directory structure.
     *
     * @access private
     * @param  string $current The current part of the file to examine.
     * @return string          The path of the namespace mapping to the directory structure.
     */
    private function get_namespace_name( $current ) {
        return '/' . $current;
    }
}

class-file-registry.php

<?php
/**
 * Includes the file from the plugin.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */

/**
 * This will use the fully qualified file path ultimately returned from the other classes
 * and will include it in the plugin.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */
class FileRegistry {

    /**
     * This class looks at the type of file that's being passed into the autoloader.
     *
     * @var FileInvestigator
     */
    private $investigator;

    /**
     * Creates an instance of this class by creating an instance of the FileInvestigator.
     */
    public function __construct() {
        $this->investigator = new FileInvestigator();
    }

    /**
     * Uses the file investigator to retrieve the location of the file on disk. If found, then
     * it will include it in the project; otherwise, it will throw a WordPress error message.
     *
     * @param  string $filepath The path to the file on disk to include in the plugin.
     */
    public function load( $filepath ) {

        $filepath = $this->investigator->get_filetype( $filepath );
        $filepath = rtrim( plugin_dir_path( dirname( __FILE__ ) ), '/' ) . $filepath;

        if ( file_exists( $filepath ) ) {
            include_once( $filepath );
        } else {

            wp_die(
                esc_html( 'The specified file does not exist.' )
            );
        }
    }
}

Including the Files, Starting the Autoloader

Now that we have our files created, we need to make two more small changes:

  1. We need to include all of the classes in the inc directory.
  2. We need to get rid of the old autoloader code.
  3. And we need to use our new autoloader with the spl_autoload_register function.

Ultimately, the final version of autoload.php should look like this:

<?php
/**
 * Loads all of the classes in the directory, instantiates the Autoloader,
 * and registers it with the standard PHP library.
 *
 * @package Tutsplus_Namespace_Demo\Inc
 */

foreach ( glob( dirname( __FILE__ ) . '/class-*.php' ) as $filename ) {
    include_once( $filename );
}

$autoloader = new Autoloader();
spl_autoload_register( array( $autoloader, 'load' ) );

And it will accomplish exactly what we’ve outlined above.

But Wait, I’m Getting an Error!

At this point, you’ve done a lot of work. You’ve refactored your entire autoloader to use object-oriented programming. You’ve documented your classes and functions. You’ve created new files, removed code from old files, and you’re ready to make sure everything is working as expected.

So, as any developer would do, you launch the browser window to refresh the page, only to be shown an error message:

Undefined function error message

Luckily, this is an easy fix. The problem is that we’re attempting to add our meta box too early. To fix this, we’ll update the init method in our Meta_Box class to include this:

<?php

/**
 * Registers the add_meta_box function with the proper hook in the WordPress page
 * lifecycle.
 */
public function init() {
    add_action( 'add_meta_boxes', array( $this, 'add_meta_box' ) );
}

And then we’ll introduce a function that will be hooked to the work we just did:

<?php

/**
 * Registers this meta box with WordPress.
 *
 * Defines a meta box that will render inspirational questions at the top
 * of the sidebar of the 'Add New Post' page in order to help prompt
 * bloggers with something to write about when they begin drafting a post.
 */
public function add_meta_box() {

    add_meta_box(
	    'tutsplus-post-questions',
	    'Inspiration Questions',
	    array( $this->display, 'render' ),
	    'post',
	    'side',
	    'high'
    );
}

At this point, you should be able to execute the new code with no problems, no warnings, no notices, and no errors.

Conclusion

Working through all of this might have seemed like a lot—and it was! But the nice thing is that it covered a lot of ground in three tutorials, and it built on the work of a previous series. In that regard, a lot of new topics were covered and new techniques were learned.

Note that I write regularly for Envato Tuts+, and you can find all of my previous tutorials on my profile page. Additionally, I often discuss software development in the context of WordPress on my blog and on Twitter so feel free to follow me on either place.

With that said, study the code we’ve covered throughout this series (and perhaps the one prior to it), and see if you can’t employ some of these techniques in your existing or future work.

Resources

How to Share Code Snippets in Your WordPress Posts and Pages with Style

Have you ever tried to just copy and paste code snippets into WordPress? It flat out doesn’t work! WordPress has no way of differentiating between a code snippet you want to display as source code and a code snippet you want to be rendered.

If you often need to share code snippets with your readers, you definitely need a better way. And that’s what this post is all about: the best tools and plugins to help you add stylish and easily readable code snippets to WordPress.

The Built-in WordPress Method for Sharing Code Snippets

Let’s start at the beginning:

WordPress does have some built-in ways to display code snippets. They’re not always the most beautiful, but they are functional. The two basic methods are < code > < / code > or < pre > < / pre > tags. Both will display your code snippets, but they have different styles which will depend on your specific theme.

For example, here’s what the different tags look like using the default WordPress Twenty Sixteen Theme:

twenty sixteen tags

But here are the major problems with these default tags:

  1. You have to encode your code snippet as a string before you can display it. This requires you to paste your code into an encoder like Code Beautify and then add the output between your < code > or < pre > tags.
  2. There are no line numbers, which make reading code a whole lot easier.
  3. There’s no syntax highlighting. Syntax highlighting makes different code elements different colors, which again makes reading code much simpler.

So, let’s dig into some methods of adding code snippets to WordPress which are both easier for you to embed and easier for your users to read.

1. SyntaxHighlighter Evolved

SyntaxHighlighter Evolved is a popular plugin for embedding numbered and syntax highlighted code snippets into WordPress. All you need to do is wrap your code in the relevant shortcode and it will be displayed something like this:

syntax highlighter evolved

You can also use a different style for displaying code which includes line wrapping, but makes it difficult for readers to directly copy and paste code as a result:

syntaxhighlighter evolved output

Key Features:

  • Adds line numbers to code snippets
  • Adds syntax highlighting to code snippets
  • Different color theme options
  • Can collapse code boxes to take less space
  • Can add custom CSS classes for more styling options

Price: Free | More Information

2. Crayon Syntax Highlighter

Crayon Syntax Highlighter is another popular plugin which adds line numbers and syntax highlighting to your code snippets. When compared with SyntaxHighlighter Evolved, Crayon Syntax Highlighter has a lot more customization. You can configure nearly everything about the plugin in its settings tab.

You can also do things like automatically duplicate the style of Sublime Text (a popular code editor):

crayon syntax highlighter

Key Features:

  • Adds line numbers to your code snippets
  • Adds syntax highlighting
  • Supports 65 different languages
  • Tons of styles, some of which mimic popular code editors
  • Easy to customize every aspect of your display box

Price: Free | More Information

3. oEmbed Gist

oEmbed is a simple plugin that lets you easily embed gists. I already know your next question…”what’s a gist”? Gist comes from GitHub and is a simple way of sharing code snippets and notes. To use it, you just need to paste your code into the gist Editor and create a public gist:

oembed gist

Then, you just need to paste the URL of your gist into the WordPress Editor and the plugin will automatically embed your code snippet like this:

embed gist URL

Key Features:

  • Take advantage of GitHub Gist
  • Embed gists by pasting URL
  • Can embed specific revisions or single files of multi-file gists

Price: Free | More Information

4. WP-GeSHi-Highlight

WP-GeSHi-Highlight is another plugin that adds line numbers and syntax highlighting to code you paste in the WordPress editor. As the name suggests, it’s based on the GeSHi highlighting engine. It also lets you use normal < pre > tags as long as you define the coding language.

WP-GeSHi-Highlight is lightweight, both in terms of functionality and outputted code:

wp-geshi-highlight

Key Features:

  • Adds syntax highlighting using GeSHi
  • Adds optional line numbering
  • Embed using standard < pre > tags with the language defined
  • Lightweight – only adds one HTTP request

Price: Free | More Information

5. Pastebin

Pastebin is another website for sharing code snippets. It functions very similarly to the GitHub Gist tool I showed you earlier. And just like with GitHub Gist, this plugin makes it super easy to embed Pastebin code into your WordPress site.

All you need to do is add your code to Pastebin, then you can simply paste the Pastebin URL into your WordPress editor to automatically embed your code snippets like this:

pastebin

Whether or not the code has syntax highlighting will depend on the settings you use at Pastebin.

Key Features:

  • Embed code directly from Pastebin
  • Includes line numbers and (optional) syntax highlighting
  • Just paste the URL into the WordPress Editor
  • Can also embed using a shortcode and the Pastebin ID

Price: Free | More Information

6. Pastacode

Pastacode

Pastacode helps you embed code snippets using the popular PrismJs library. You can highlight specific lines in your code snippets and change styles using one of the included themes. Pastacode also supports embedding code from GitHub, Gist, Pastebin, BitBucket or BitBucket, which makes it very versatile.

Key Features:

  • Add line numbers to code snippets
  • Add syntax highlighting to code snippets
  • Uses the PrismJs library
  • Can embed code from GitHub, Gist, Pastebin, and more.
  • Can highlight specific lines of code

Price: Free | More Information

7. Code Prettify

Code Prettify uses the Google Code Prettify library to automatically add highlighting to your < pre > and < code > with their plugin activated, you and outputs will look like below, instead of the ugly versions I showed you at the beginning of this post:

code prettify

Key Features:

  • Works with default < code > and < pre > tags
  • Uses Google Code Prettify library
  • Properly minified and enqueued

Price: Free | More Information

Wrapping Up

Whether you want to embed code snippets directly in your posts or bring in code from external tools like GitHub or Pastebin, these plugins will help you accomplish that. If I had to pick my absolute favorite, it would be Crayon Syntax Highlighter for the variety of styles and themes you can use.

Do you have a favorite method for displaying code snippets in your WordPress posts? I’d love to hear about it in the comments!

Article thumbnail image by Naghiyev / shutterstock.com 

The post How to Share Code Snippets in Your WordPress Posts and Pages with Style appeared first on Elegant Themes Blog.

IonMag Free News WordPress Theme

Are you looking for a great free news WordPress theme? You found it! ionMag is an amazing free theme for a blog, news, newspaper, magazine, publishing industry and reviews website. This integrated solution will change the way bloggers interact with their sites moving all the creative activities from the backend to the website’s frontend, simplifying the user experience.

Elizabeth Shilling Awarded the Kim Parsell Memorial Scholarship

Elizabeth Shilling Awarded the Kim Parsell Memorial Scholarship



0

The WordPress Foundation has announced that Elizabeth Shilling, co-founder of the Women Who Code meetup group, is the second recipient of the Kim Parsell Memorial Scholarship.

The scholarship was created in 2015 to remember Kim Parsell and provide an opportunity for a woman who may not have the financial means to attend the largest WordCamp in the US.

Bridget Willard on the left with Elizabeth Shilling on the right
Bridget Willard on the left with Elizabeth Shilling on the right

Shilling is a former biology teacher, business owner, plugin developer, and feminist leader. According to the announcement, Shilling was chosen for her dedication to open source and being a champion for women in leadership. The scholarship covers the cost of a WordCamp ticket, flight, and lodging. If you see Shilling at WordCamp US this weekend, be sure to congratulate her.

Related

Ask Sucuri: Can Your cPanel Page Be Maliciously Redirected?

Ask Sucuri: Can Your cPanel Page Be Maliciously Redirected?

Many webmasters may not be aware that hackers are able to maliciously redirect cPanel pages. The specific tactic we describe in this article is unique. Included are recommendations to prevent it, along with other suspicious issues, through logs kept on cPanel servers.

A lot of websites owners already know about the .htaccess file (short for HyperText access) and how it can be used to redirect visitors to a malicious URL. However, did you know it could be used to easily redirect users that logged into their cPanel?

Continue reading Ask Sucuri: Can Your cPanel Page Be Maliciously Redirected? at Sucuri Blog.

Understanding Copies & References in PHP

I like to think I’ve gotten pretty good at PHP, but I’ll admit there are plenty of times I feel like I know nothing. One thing that has tripped me up recently is the difference between variable copies and variable references.

Often, this difference comes into play with function or method properties, but it is more than that. I hope by reading this article you will be better equipped to deal with this tricky subtilty in the language when it affects you.

References vs Copies

When we create a variable by passing an argument to a function or method, we are almost always creating a copy of that variable. But instead, we might want to just create a reference. A reference is an alias, allowing two parts of our application to act on the same variable.

This will conserve memory, though that is less of a concern today than it used to be. The real reason to use a reference is it is a useful design decision, but only sometimes.

Let’s look at the difference. First look at this class, that doesn’t use references. Guess what the output of the last line will be:

<?php
$post = 1;
class my_post {
protected $post;
public function set_post( $post ){
$this->post = $post;
}
public function get_post(){
return $this->post;
}
}
$my_post = new my_post();
$my_post->set_post( $post );
$post = 2;
var_dump( $my_post->get_post() );

If you guessed 1, then you are right. Just because we changed $post to 2 outside of the class scope, it shouldn’t affect the copy of $post, we put into the my_post class. But what if we wanted to? Then we would have to pass $post into the my_post class by reference and set the post property of that class by reference.

<?php
$post = 1;
class my_post {
protected $post;
public function set_post( &$post ){
$this->post = &$post;
}
public function get_post(){
return $this->post;
}
}
$my_post = new my_post();
$my_post->set_post( $post );
$post = 2;
var_dump( $my_post->get_post() );

The only thing that has changed here is that I put an ampersand before the $post variable. So it’s now &$post. The ampersand tells PHP to create a reference, not a copy.

As a result, the last line, now prints 2, not 1, since the reference to $post, was changed inside of the class.

Problems With Object References

Based on what you have learned, take a look at this code and guess what the last line will print:

<?php
class second {
public function __construct( $first ){
$first->two = 2;
}
}
$first = new stdClass();
$first->two = 1;
new second( $first );
var_dump( $first->two );

If you guessed 1, that would make sense based on what you just read, since the first object is not passed into the second object by reference. You’d also be wrong because objects are always passed by reference.

Sorry, I tricked you, but it’s an important distinction. Let’s jump into a practical example that I used to really understand the problem and look at solutions if this is not what you want.

In a recent article for Torque, I wrote a simple class for tracking hooks that were being removed. In WordPress 4.7, there is a new class WP_Hook, that is used for storing information about hooks, which is what I needed to store for removed hooks, so I could add them back later.

An earlier version of that class failed for reasons that were baffling to me until I remembered objects are always passed by reference. You can see the final version of that class here, which includes the backwards compatibility checks I have removed below for clarity’s sake. I have extracted my before and after versions so you can see the difference.

Here is what I started with:

<?php
public  function remove_all( $hook ){
global $wp_filter;
if ( isset( $wp_filter[ $hook ] ) ) {
$all = $wp_filter[ $hook ];
if( ! empty( $all ) ){
$this->removed[ $hook ] = $all;
remove_all_filters( $hook );
}
}
}

In this version, I get an object of the WP_Hook class and place it in the $all variable, which ends up being stored in the removed property of this class. Even though I stored it in the property before calling remove_all_filters() the value in that property is still affected by calling remove_all_filters() which resets the callback property of that object because it is a reference.

To make this clearer here is a version, that doesn’t use remove_all_filters() but does what that function does manually:

<?php
public  function remove_all( $hook ){
    global $wp_filter;
    $all = $wp_filter[ $hook ];
    $this->removed[ $hook ] = $all;
    $all->callbacks = array();
}

You might look at this and think that $this->removed[ $hook ]->callbacks shouldn’t be empty, only $all->callbacks should be. But they are not two different things, one is a reference to the other.

The Clone Solution

The problem I was facing was that I needed to keep a copy of an object, before letting WordPress remove_all_filters() modify that object. Instead of keeping a copy, I was creating a reference.

The solution to the problem was to create an object clone using the clone keyword when defining the $all property. Here is what that looks like:

<?php
public  function remove_all( $hook ){
global $wp_filter;
if ( isset( $wp_filter[ $hook ] ) ) {
$all = clone $wp_filter[ $hook ];
if( ! empty( $all ) ){
$this->removed[ $hook ] = $all;
remove_all_filters( $hook );
}
}
}

Now $all is a copy, of the object WordPress acts on with remove_all_filters(). Mission accomplished.

The Clone Magic Method

Object cloning creates a new copy of an object, but all of its properties, that are objects are still references. This is one of the reasons why PHP provides a __clone() magic method, which is called in the cloned object after the new object is cloned.

This provides an opportunity to clone any properties that may be references, if needed. Here is an example that does that:

<?php
class deep_clone {

public function __clone() {
foreach( get_object_vars( $this ) as $property => $value ){
if( is_object( $property ) ){
$this->$property = clone $this->$property;
}
}
}

}

Beware The Attack Of The Clones

I hope this article has helped you understand the difference between references and copies in PHP and some of the tricky rules involved. Next time you don’t understand how a variable or class property suddenly changed for no apparent reason, consider that you may be dealing with a reference that changed somewhere else.

Josh is a WordPress plugin developer and educator. He is the owner and a developer for CalderaWP, makers of Caldera Forms, a different kind of and Ingotthe native WordPress A/B testing solution.

The post Understanding Copies & References in PHP appeared first on Torque.

10-ish Unix CLI File Commands Every WordPress Developer Should Know

Two weeks ago, we published a conceptual primer on the command line for WordPress developers who’ve never used it and never thought of using it. That article didn’t really touch on any of the nitty-gritty of using the command line, though. And the heart of deftly using the command line is really down to just have sufficient knowledge of a bunch of different commands that you can use.

As we mentioned in the original CLI article, the command line varies a lot from traditional Windows and the more-Unix-y command lines of Macs and Linux distributions. This means that while some of these commands may roughly work on a Microsoft operating system, they will work differently enough that this tutorial is probably not useful for someone working in an exclusively or primarily Windows environment.

Also as mentioned in the first article, there are alternative shells for working on the Unix command line. As BASH (the Bourne-Again Shell) is the most common, all commands in this article will be in that format.

With those proviso out of the way, I think there really is a lot of mileage that comes form just having some basic familiarity with a large number of Unix commands and having a sense of when and how they’re useful. So lets get started. At the end of this tutorial you should have a solid understanding of all the most essential file-and-folder-manipulations commands.

Commands for Filesystem Navigation and Creation

Our last Quick Guide was about the very basic commands that you need to understand to move around the filesystem on the command line. Folders or directories are one of the most foundational concepts of modern computing, and being able to confidently and fluently move around there is the first step to take to be good at using the command line for your WordPress (or any other) work.

pwd tells you where you are

The first command that I think you must know to understand the command line is pwd. Because it tells you where you are already. Knowing where you are is always (in technology and in life ?) the first step to getting to where you want to be.

pwd stands for “present working directory”, and that’s just what it tells you: where you are right now. Here’s the basics of it working:

MacBook-Pro:~ david$ pwd
/Users/david

If you’re not used to seeing the Unix/BASH command line, there’s a lot of unimportant gibberish to the left of the “$” on the first line there. You can really ignore it. For the curious, it lists where we are, and who we are. Then to the right of the dollar sign is the area where we type out command. In this case, we’re typing pwd and it’s responding with a location of /Users/david.

That directory is actually really special. If we look just to the left of the dollar sign ($), we see that to the terminal we’re currently david. And the /Users/david directory is thus our “home” directory for our user. This directory, in various commands and references, is used a lot. Because of its frequent use, it has a nice little shortcut: the tilde (~). That is on the key to the left of your number 1 in the top row of your keyboard.

cd moves your command line location for you

Changing where you are is accomplished with the cd command. What does it do? It “changes” your current “directory”. So if you’re in /Random/Folder/on/your/computer and you want to get back to your “home”, you’d type

cd ~

And if you wanted to go to an arbitrary relative path (starting from where you are), you’d type:

cd arbitrary/relative/path

If you wanted to deterministically and with certainty know where you were going, you’d start your cd command with a file path that has a forward slash (/) at it’s start.

And if you wanted to deterministically and with certainty know where you were going, you’d start your cd command with a file path that has a forward slash (/) at it’s start. /Users/david is an absolute path. I could go from there to the /Users/david/Dropbox/WebDev directory by using any of the following commands:

cd Dropbox/WebDev #relative to where I am now
cd ~/Dropbox/WebDev #relative to my user root
cd /Users/david/Dropbox/WebDev #relative to the system root

Assuming I started in /Users/david, all three of those commands take me to the identical location. Knowing that, and being able to see how all of those yield the same location is crucial.

The final common need when cding is to go up a level. If I’m in /Users/david/Dropbox/WebDev I can get back to my home directory in a couple ways:

cd ../..
# or
cd ..
cd ..
# or
cd ~

The primary piece of new knowledge here is that .. means “up a level” in the Unix command line. (Less necessary to know but still really useful—a single dot, ., is where you currently are.) So typing cd .. twice is the same as typing cd ../.., which will both move me to a location two folders above (in the hierarchical structure of Unix directories) than I currently am.

ls tells you what’s in your current directory

So we’ve learned how to tell where we are. And we’ve covered how to change where we are. The last crucial thing to know (and the last bit of knowledge that we covered in the Quick Guide about starting to move around the filesystem from the command line), is ls. ls “lists” what is in the current directory that our terminal is resting. As if we’re in /Users/david, typing ls will show us all the folders and files that are sitting in that folder.

If we need a little more detail, we’ll want to add the -l flag. ls -l will tell us not just the files and folders, but a wealth of other information like the user who owns each file, its size, and more. (Again, for a little more detail on the ls flag(s), look over the Quick Guide about the using the CLI to navigate the filesystem.)

mkdir makes a new directory

mkdir is the first command that changes something other than your current terminal. And as you may have been able to guess, the mkdir command is how you “make” a “directory”. That is, if I want a new folder, I’d just simply type the command:

mkdir new-directory

If that worked—no typos—then we’ll now have a folder wherever we are called “new-directory”.

touch creates a file

touch is one of the less-obviously-named commands

Finally, the last command that I think you should know about for basic navigation around the command line is touch. touch is one of the less-obviously-named commands, in my opinion. What touch does is create a file for you. If I wanted a text file called “touched.txt” I could easily create an empty file with the command:

touch touched.txt

Once that file exists, I can add things to it using other commands. Or I can remove it. Or move it. And that’s the focus of our next section: the essential file-manipulation commands that are crucial for effective use of the CLI in a Unix-y system.

Manipulating Files on the Command Line

Once you’ve moved around and have created some files and folders, the next thing you’ll need to do is make changes to them. Maybe that’s taking away a file or folder, or moving it, or changing its contents. The possibilities are big, but only a few commands are really essential to getting comfortable with manipulating files and folders from the command line. The core ones are listed below: rm, mv, cp, editing commands, and version control.

rm deletes files

rm has a pretty understandable name, it “removes” files. So lets assume we have the touched.txt file we made with the touch command, but we decide we no longer want it. What do we do?

rm touched.txt

And it’s gone. What about removing a folder though? There are a couple options. The first is that there does exist an rmdir command which is made to remove directories. The hitch is that if the directory has anything in it, it won’t work.

So that’s why most people use rm -rf to remove a directory and all the files inside of it. This is just the same rm command we used to remove touched.txt, but we’ve given it two flags. The -r flag signifies that we want rm to act “recursively”. “Recursively” means “keep doing the same thing all the way down”. So when we rm recursively we’ll remove all files and folders inside the file and folder we’ve told the CLI to remove. The -f flag stands for “force”, which is your way of telling the CLI that you really mean it and you don’t want it questioning you or double-checking with you or quitting part-way on you.

mv moves files and folders for you

The “move” command works about how you’d expect: it moves files or folders for you. It’s typed as mv and you start with where it is, and then say where it’s going. So it basically looks a little like this on your command line:

mv touched.txt moved-touched.txt

You can use it the exact same way for folders. And you can also use mv to put a file in a folder. That’s done with a command like:

mv touched.txt moved-folder/touched.txt

Make sense?

cp is the CLI way to copy a file

You use move when you want to change the place a file is. You use cp when you want to replicate file or folder. Like mv you first say where it (the file or folder you want to copy) is, and then where you want to new duplicate to go. So to duplicate touched.txt you’d do something like:

cp touched.txt touched-copy.txt

It’s more idly interesting than useful, but judicious use of cp and rm can get around you ever typing the mv command. Why you’d try to do that is a bit of stumper for me though…

nano, vi, or emacs are text editors that work from the command line

My newbie-CLI-editor of choice is nano.

rm, cp and mv can do for you most everything with your files as black boxes of data. But they don’t change what’s inside of them. You can see what’s inside of your files with commands like cat, head, tail (that’ll be my only mention of them, as I don’t think they’re crucial to know, just cool).

But to really see your files and be able to make changes to them, you need a text editor. If you’re already comfortable with Sublime Text or Atom or whatever, getting to know a command line text editor is not completely required when you’re on a local machine. But as soon as you start using the command line on a remote server, having at least some familiarity with a CLI text editor is essential. vi and emacs—about which whole books could and have been written—are heavy-duty and may replace your current GUI editor for you if you learn them really well.

My newbie-CLI-editor of choice is nano. And you can get inside of touched.txt and start to actually add some content to it with a simple:

nano touched.txt

What I really like about Nano—as opposed to VI(M) or Emacs—is that all your basic manipulations are shown on the screen. It tells you that you write/save the file with CTRL+o, and so on right on the screen. If you’ve never found yourself (as many newbies do) in VI not being able to quit. That seems pretty trivial, but if you’ve been there, you’ll understand why I think the using screen space for those explanations is great for beginners (or anyone who just occasionally finds a need for a CLI text editor).

git, svn, etc let you version control

Knowing that the git command exists is useful, even if you stick to the GUI app you prefer.

Finally, as with the text editors, the scope of these commands are too big to cover in depth. But version control is a core part of file manipulation for developers in WordPress and beyond. And git is the most common version control application in use today.

You can do version control with a GUI app, or even in your text editor itself, but the real heart of Git is in the command line interface. And so knowing that the git command exists is useful, even if you stick to the GUI app you prefer. A commit is done with the git commit command, and a push is done via git push. I could go on, but as I said knowing the Git CLI well is far beyond this article’s scope.

If you ever doing any work with WordPress.org, it’s also important to know that svn, which is the command line interface for the Subversion version control system, is also available on most Unix computers. That’s what WordPress.org uses, so as a WordPress developer it’s good to have at least passing familiarity with.

What We’ve Learned About Commands for File Manipulation

We’ve only scratched the surface of the entirety of the command line. It is a vast and long-established kingdom. But I hope now you feel confident in all the basic functions that you might need to do as a developer trying to make your first go at the command line.

I think there are other non-file commands that are essential to really know how to use the command line to it’s full potential, but it’s impossible to really get those under control without having an ability to do all the basic file manipulation things. So hopefully how you use pwd, cd, and ls are all kind of clear to you. And you know that touch and mkdir make new things for you. That rm gets rid of them, cp duplicates them, and mv will change where they are.

Knowing that version control and text editing can be done from the command line is crucial too, though many WordPress developers never really have a need for either of those. But some prefer it for one or the other operation. Try out the Unix command line interface for one or both at least a few times and you’ll find it much easier to do in the future when you absolutely must. Happy hacking!

Divi Plugin Highlight: Divi Dashboard Welcome

The WordPress dashboard is a great place to put useful tools and information. Many plugins add things in this space, giving you quick access to their information. What if you wanted to create your own dashboard page using the Divi Builder? That’s what Divi Dashboard Welcome, from Tim Strifler of DiviLife.com, does.

Divi Dashboard Welcome adds a new area to your current dashboard that displays a page you make using the Divi Builder. The dashboard welcome page is added above all of the other dashboard information, placing it the most prominent area of the screen.

There are lots of ways to use this plugin. In this article I highlight its features and I’ll build a few dashboard welcome screens of my own.

Who it’s For

This is ideal for:

  • Developers who want to provide links and information for their clients, up-sale products, provide videos for training, affiliate links, insert blog content, etc.
  • Admins of sites with multiple users that want to supply links and information for their contributors, a to-do list, create an FAQ, a troubleshooting list for users to follow for support, etc.
  • Anyone that wants to create a welcome screen that’s customized for their own needs, such as notes for image sizes, links to download resources, calendar, to-do list, etc.

Tim provides tutorials for using the plugin at his website. Tutorials include:

It also works with Extra or any theme using the Divi Builder plugin, so Divi isn’t required for you, your team, or your clients to benefit from it.

Installation

The download is a zipped file that includes several files within it. Files include:

  • Start Here – an HTML link to the installation instructions. I recommend reading the installation instructions. You can read the PDF or watch the video.
  • Install this first – XML document. This uses the WordPress import plugin.
  • Divi Dashboard Welcome Layouts – JSON file. Import this into your Divi Layouts.
  • Plugin – zipped file

Unzip the download package and import the files before uploading the plugin. Divi Dashboard Welcome includes some Divi theme files. Import the files according to the instructions. If you’ve ever imported Divi theme files you’ll be familiar with this process.

Layouts

layouts

The plugin includes five layouts that can be loaded into the Divi Builder. Layouts include:

  • Agency Contact
  • WP Style
  • Handwritten Note + Map
  • Simple Contact Form
  • Default

The layouts are uploaded the same way any Divi theme files are uploaded. This means it’s possible to share your layouts with others.

Dashboard

dashboard

Once the plugin and theme files are installed you’ll see a dashboard screen that looks like the one above. This is a private page called Divi Dashboard Welcome Screen. The dashboard screen itself is a window that maintains its size. The content of the page will fit horizontally within the window. If your content is larger vertically then the window will be scrollable.

The Divi Dashboard Welcome Page

the-divi-dashboard-welcome-page

The dashboard welcome screen is actually a private page made with the Divi builder that can be edited just like any page. Since it’s a private page it won’t be indexed by search engines and can’t be viewed by your readers. Tim has even protected the page against being deleted. Users have to uninstall the plugin before the page can be deleted. To create your own dashboard screen you’ll need to edit this page.

the-divi-dashboard-welcome-page-2

Use the Divi Builder to create any layout you want including modules, rows, sections, styles, code, layouts, shortcodes, etc. Everything you place in this page will display in your dashboard screen. Select Preview to see the page. The page was created using the Blank Page template, so it won’t show the header or footer of your website.

Visual Builder

visual-builder

The dashboard page can also be edited using the Visual Builder. All of the elements work as they normally do except it doesn’t display the WordPress menu across the top of the screen. Once I made my changes and saved them I clicked the back arrow to return to the back end. The changes appeared in the Divi Builder and had no issues.

The Included Layouts

the-included-layouts

To load the layouts into the Divi Dashboard Welcome Screen page click Load From Library in the Divi Builder and then select Add From Library. Here you’ll see the five layouts that come with the plugin. You can also create or upload your own.

Here’s a look at each layout.

Agency Contact

agency-contact

Agency Contact includes all of the contact information that your clients need to contact you including your opening hours, phone number, email, website, and a simply contact form. In this form only the submit button is clickable (which will send the message to your email) but you can make the others clickable if you want.

WP Style

wp-style

WP Style is a simple screen that uses the WordPress styling to blend in. It includes clickable links to create new or edit pages and posts, customize menus, manage comments, add or remove users, and manage media. Easily view your website by clicking a button. It also includes a support contact form.

These clickable links are internal, meaning they keep you inside your WordPress back end. You can have them link to somewhere else in the admin panel by using the parent link attribute (target=”_parent”). Leave off the link attribute if you want to open the link within the dashboard window. If you want external links simply supply the link as normal.

Handwritten Note + Map

handwritten-note-plus-map

Handwritten Note + Map includes a note area with a handwritten font (The Girl Next Door, in case you’re wondering) so you can leave a special note to your clients. There’s also a contact area that includes your phone number, email address, and a Google Map with pin in case you want to give them directions to your office or event. This can also be used to tell your team about an event and provide them with the time and location.

Simple Contact Form

simple-contact-form

Simple Contact Form is exactly that – just a simple contact form so your clients or team can send a message. This one clears out the clutter, providing just this one tool with nothing else getting in the way.

Default

default

The default dashboard provides a welcome message, internal links to create pages, posts, and manage menus, comments, users, and media, a contact form, and links to additional services that you provide for your clients. This is a clean layout with usable tools to ensure users will actually use it while at the same time providing simple links to up-sale your services.

Dismissing the Screen

dismissing-the-screen

If you or your clients want to dismiss the welcome screen click the x Dismiss in the upper right corner. If you want it back just click Screen Options and select Welcome from your choices. This is helpful if you use a welcome screen that only has a thank you message or a contact form that clients won’t need to see all the time.

Creating My Own Custom Dashboard Welcome Screen

creating-my-own-custom-dashboard-welcome-screen

Rather than create a welcome screen for clients I wanted to create a welcome screen for contributors to my website. When contributors log in they will see this screen and they’ll have the information they need for creating and publishing content for the website.

I wanted to include information and links such as:

  • Guideline overview with information such as word counts, image sizes, file types, etc.
  • PDF download link to writer’s guidelines
  • Links to sources for images
  • Pre-publishing checklist
  • Approved titles and topic ideas
  • Link to team discussion group
  • Contact form

I wanted to keep the form simple and clean, but still provide the information I needed. For this I started with the Default layout and created my own layout. The WP Style layout would have also worked as a template.

creating-my-own-custom-dashboard-welcome-screen-2

Here’s the first version of the welcome screen. This just took a few minutes to create using the layout.

Using the Visual Builder

using-the-visual-builder

I wanted to give it a little more visual pizazz so I loaded the page with the Visual Builder to make my changes.

using-the-visual-builder-2

I mostly changed colors. I also added a new text module to include a motivational saying in the empty space below the contact form.

using-the-visual-builder-3

Now my dashboard is customized with my branded colors. Almost all of the styling was done from the front end. I saved this one to my library so I can reuse it.

A Personalized Custom Dashboard

a-personalized-custom-dashboard

For the next one I wanted to create a dashboard where all of the latest posts of my favorite websites, YouTube channels, and Facebook pages would appear – essentially creating my own personal network right into my dashboard so I can see their content when I log into my website without having to go anywhere else.

a-personalized-custom-dashboard-2

To create this I used three free plugins:

For the blog posts I created a new widget area called Dashboard RSS, placed an RSS Feed Widget for each blog feed I wanted to display the dashboard, and pasted in the URL’s of the feeds I wanted into the widget. In the Divi Builder I placed a sidebar module and selected my new widget area. If I wanted to display them side-by-side I would use multiple widget areas and multiple sidebar modules. Clicking on the RSS feeds within the dashboard brings the article to my dashboard where I can read it without leaving my website.

For the YouTube videos I wanted to show the latest videos from both Elegant Themes and Divi Life. The YouTube Embed plugin makes it easy to add Elegant Theme’s and Divi Life’s YouTube channels into a textbox as embedded links, which then displays the videos. I can place the feeds from the channel as a gallery or as a playlist. I selected playlist. I can watch the videos directly from the dashboard without having to leave my website.

For the Facebook feeds I created the links in the plugin and then placed the shortcodes in text modules. I could have created a single module, but this way I can easily drag and drop them if I want to modify the layout. I can see the latest Facebook posts in my dashboard without having to go to Facebook first and risk getting sucked into the void.

a-personalized-custom-dashboard-3

All of this content will refresh and update all on its own (according to the settings within each plugin) with no further input from me. Some plugins may require refreshing the screen.

License

Divi Dashboard Welcome has unlimited usage for life for your own sites as well as sites for clients.

Final Thoughts

Divi Dashboard Welcome is an excellent tool for creating custom dashboard screens using the Divi Builder. Developers can supply information and up-sale for clients, and admins can create tools for their team, and bloggers can provide themselves an easy access point for their tools. There are lots of ways to use this plugin and you’re only limited by the Divi Builder and your imagination. Just like anything created in Divi, the layouts can be saved, reused, and shared.

Have you tried Divi Dashboard Welcome? If so, we’d love to read your thoughts below.

Featured Image by print10 / shutterstock.com

The post Divi Plugin Highlight: Divi Dashboard Welcome appeared first on Elegant Themes Blog.