This type of migration is applicable when you are adding new features to your subsite and want to migrate only the content. For example, moving classic editor content to the block editor or sending data to a headless content management system (CMS).

Let’s take a look at how you can export and import content by adding your own WP CLI commands. Define the goals and objectives to be achieved with the migration.

Here are some examples of goals

• Retain the post IDs
• Retain the taxonomies
• Rename certain post meta fields
• Add new post meta fields
• Rename some old custom post types to new ones
• Replace site domain or URLs

Sometimes the clients may have unrealistic expectations about how to migrate subsite content to a multisite network. There are also times when requirements cannot be fulfilled technically.

So, it is important to discuss the requirements and the possible solutions with the engineering team and the clients. Submit the proposal on what could be done and how long it will take and get approval from the client. Then, start working on the solution.

Leverage the WP CLI

WP CLI makes it easy to export and import data of any size. Extend the WP CLI class and create your own commands.

Here is an overview of the whole migration process.

Replicate the live environment locally to write and test the CLI commands. Add separate commands for export and import.

Make sure the site URL is passed every time you run the commands to avoid running commands on the default blog.

wp migrate import –url=http://mywebsite.com/blog2

Add a command to rerun export or import content by passing an array of post IDs, terms, or meta. This allows you to fix the errors during migration without running the whole process.

View the code on Gist.

Pro tip: Use the progress bar utility to display the status of the export and import process.

Prerequisites

Migration requires a lot of planning and preparation. Discuss with the client and discover the data that needs to be migrated.

Content Freeze

There should be a content freeze for keeping the data intact. Whether it is backend content entry or the frontend contact forms, user registration, etc, to be stopped during the migration. Make the site read-only.

Exporting Content

You can export data as SQL, XML, or JSON files. This example exports content as JSON files in batches. This way you don’t have to worry about MySQL timeout and you can include any data you want to export.

Include terms, metadata, and any associated data to each post item. Store the exported files in their respective folders inside the main migration folder.

The path could be something like /migration/{post-type}/1.json, where the post type refers to post type slug, and numeric 1 refers to the first batch of the exported content.

Data Mapping

Map the corresponding post meta fields of each post type carefully. In some cases, you may want to rename the meta keys.

The best advice here is to keep the old meta keys and add new ones. This way you can review the new keys and values after migration.

For example, if you want to rename customer_ip_address to customer_ip, keep old ones and add new ones.

Importing Content

Take a full backup of the site including files and database before running your migration commands on production. Get the exported data, do the mapping, validate it and then proceed with the import.

Import each type of data separately, like terms, post types, post meta and menus, and so on. Whether you are overwriting data or creating new records, add a log to keep track of the status. Test the commands on the local environment and make sure they work without errors.

Logs

Catch the errors during the migration process and log them. Log error messages to a separate file, this helps to isolate and check the migration-related errors.

Add preview links to the migration summary on the terminal, this helps you to quickly navigate different content types and check the content.

Pro tip: A table of results can be helpful to view the total number of migrated items.

Migration Runbook

List out the action items for each team with instructions and commands in hierarchical order. Discuss the process with the engineering team, DevOps, and content team. This allows everyone to be on the same page.

Divide the runbook into pre-migration, migration, and post-migration. Then, add the respective steps.

Pro tip: Do a dry run on a staging environment that mimics the production environment; this helps you to find any errors and tweak the migration script.

Run migration

Prepare the production environment for the migration process. Follow the runbook that you created, then test the output.

Testing

Review the imported content, and look for any missing or incorrect data. Check if all the items are imported to their corresponding taxonomy terms.

You could find more clues in the migration logs. If there are any errors and warnings, follow that trail and confirm that data has been imported.

Rerun the commands if needed and repeat the testing process. Once you feel confident that the content migrated correctly, do the clean-up, like removing any temporary database tables, files, etc.

Finish the items on the post-migration checklist and launch the site.

Conclusion

Each site is different, which means the process to migrate subsite content to multisite could be different as well. We hope that this article sheds some light on the migration process to make it easier.

What are the challenges that you encountered during the migration and how did you overcome them? Let us know in the comments below.

Looking for help? Let WebDevStudios handle the migration, contact us now!

Further reading: WP CLI commands cookbook .

The post How to Migrate Subsite Content to a Multisite Network appeared first on WebDevStudios.

Introduction to WordPress Multisite

There is a good deal of information on the web about WordPress Multisite, but most of it dives too deep technically, or quickly shows you steps to set up a Multisite environment. I am going to tackle it from another angle, from the point of view of an outsider looking in (with possibly no technical background) wondering if WordPress Multisite will fit the needs of their organization. To help facilitate the discussion, let’s start with some terminology.

New Terminology

WordPress Multisite introduces new ideas into WordPress, and there are several new terms that come along with it. Below are the various Multisite terminologies defined to help provide a foundation in communication for the rest of the article.

• Network: The Network refers to a group of sites created on your Multisite instance. Though it is technically possible to run multiple networks on a single Multisite instance, we will focus on the basic single network that comes with Multisite. To keep things simple, you should be aware that some older literature referred to a Network as a Site.

• Site: A site refers to a single site within a network. These are sometimes also referred to as subsites, or blogs. Over the years, the term site has changed meaning to refer to the individual sites on a network. You may see reference in older literature that use the term site in the context of network.

• Blog: Another name for a single site on the network.

• Subsite: Another name for a single site on the network.

• Network Admin: This is a new section of the wp-admin area that appears in the Admin Bar after enabling Multisite on your WordPress installation. The Network Admin is where you will control the sites, plugins, and themes available to your sites.

• Super Admin: Super Admin is a new role that is available specifically for Multisites. Users with Super Admin access are allowed to access the Network Admin area and manage the entire network. Super Admins can access the dashboards of any site and administer them as well. The traditional Administrator account only has access to the sites it has permissions on.

• Subdomain Install: Network setup option that creates new sites with a subdomain of the primary domain. For example:
  • Primary domain: example.com
  • Site for Bob: bob.example.com
  • Site for Sally: sally.example.com 

• Subdirectory Install: Network setup option that creates new sites with a subdomain of the primary site. Useful when creating sites that all need the same look and feel such as corporate or language sites. For example:
  • Primary domain: example.com
  • Site for Bob: example.com/bob
  • Site for Sally: example.com/sally

What is WordPress Multisite?

You are undoubtedly familiar with WordPress. A content management system you install to manage your website content. Perhaps you have multiple websites, each with their own installation of WordPress running the site. Enter WordPress Multisite; WordPress Multisite transforms a single site into a powerhouse that can run an unlimited number (nobody has found a max number yet!) of websites from a single WordPress installation. In essence, it could combine all the individual WordPress installations you run into one single installation that supports all the sites. Each site can have its own domain, theme, and set of plugins utilized.

As an example of how I use the power of WordPress Multisite, I have several family members who have basic blogs set up to post their random thoughts. There are also several organizations that I have helped support over the years and test beds for new corporate sites running. Each of the site owners are able to manage their own content, while I ensure the network stays up and running efficiently with WordPress, and that all plugins are kept up to date.

Feel free to take a peek at a couple sites on my network:

• http://raeann.lobaugh.us/ – Sister’s site
• http://cara.lobaugh.us/ – Aunt’s site
• http://lewiscountychaplaincy.org/ – Website for the Lewis County Chaplaincy agency
• http://lobaughwedding.com – Site for Lobaugh weddings, currently featuring my wedding
• http://fetchfitness.clients.lobaugh.us/ – In-progress site for a friend’s business

You will notice there are subdomains and custom domains. WordPress handles both with elegance. By default, new sites on my network are created as subdomains of lobaugh.us and then a custom domain is applied when ready. Subdirectories are also supported. Subdirectories make it look like all the sites are part of the same domain. For example, in my network, my sister’s site could be http://lobaugh.us/raeann. There are good reasons to run WordPress Multisite in subdomain mode that I will get into in Part 3.

In Part 1, you were introduced to new terminology used by WordPress Multisite and provided a high level view of what WordPress Multisite is. In the following parts, we will cover why using WordPress Multisite matters, and how to determine if it could be the right tool for your organization.

The post What Is WordPress Multisite and How Can It Help You? (Part 1) appeared first on WebDevStudios.

The presentation itself will be a basic introduction to WordPress Multisite, including showing how to set-up and use Multisite and going over some of the benefits of using WordPress Multisite. The event will be taking place at Cowerks, a rad coworking space in Asbury Park.

In case you have somehow stumbled across this blog without any prior knowledge of Brad Williams (or WDS): Brad is our CEO, as well as one of the authors of Professional WordPress. He has an extensive background in WordPress and web development; if you have questions about WordPress or about entrepreneurial endeavors, this is a rare opportunity to catch him and ask him questions in person!

Brad’s the right guy to ask! After all, our team has created some amazing work using WordPress Multisite, like:

• The Microsoft Bing Blogs

In addition to design and development, we created a multisite network that allows them to tailor regional specific content for their audience.

• HobNob Local

We developed HobNob Local’s network of sites that help local businesses reach local residents, encourage residents to support their local economy, and strengthen the community they live in. The local community sites also allow residents to learn about the going ons in their community real time from their mobile devices.

• Newark Public Schools

We’re especially proud to say we got to work with the largest school district in New Jersey! WDS migrated over seventy sites from a proprietary CMS into WordPress. Now the Newark Public School District calendar can post events to all of the schools, and each school in the district is a part of their multisite network.

• Technical.ly

Technical.ly is an awesome organization that you may be familiar with; they were responsible for making the incredible Philly Tech Week take place! By getting them set up on WordPress Multisite, they are now better equipped to support and enhance local technology communities through news, events, and services.

Brad’s presentation on WordPress Multisite is on Thursday, April 30th, 2015, 7 PM – 9 PM! Cowerks is located at 619 Lake Ave, 3rd Floor, Asbury Park, NJ. Join and RSVP right here (or heck, DON’T RSVP and show up anyway!), go meet yourself some fellow WP-heads, and learn something new!

The post New Jersey, Come Learn About WordPress Multisite! appeared first on WebDevStudios.

Every couple months or so, Google seems to like to shake things up a bit and add some new criteria by which they rank sites. One of the most recent of these shakeups was that your site might now be ranked based on whether it supports https. This led to a massive freak out in which everyone and their mom tried to set up HTTPS on their site. Historically, getting HTTPS working isn’t as easy as all that and I’m sure many of you reading this post were either too intimidated by the process or started and then gave up.

Recently I got HTTPS working on my site(s), and I’m going to share with you how I got it working (for free).

What is HTTPS?

HTTPS is, simply, a secure layer on the HTTP protocol we use to access websites. The ‘S’ stands for secure and indicates that all your information to and from this site will be encrypted. Occasionally you’ll see this:  which means that some content linked or referenced on the page was not loaded securely. This is usually the bane of a webmaster’s existence when trying to set up HTTPS on a site. While it’s not inherently bad to serve content that’s not secure, in order for your site to get the happy little green padlock, everything needs to be passed securely — including content you’re linking in from outside of your site.

Why should I care about HTTPS?

Besides the Google rankings, why should you care about securing your site? First of all, as of Google Chrome 68 (coming July 2018) all websites are REQUIRED to use HTTPS.

If you’re running eCommerce on your site, you have to for secure payments. Maybe you can work around this by using a service or platform that takes the transaction part of the shopping experience off your site (like PayPal), but that can be jarring to the user experience. It also inspires trust in your customers to see a green padlock on your site; they know that they can trust you with their business even if you are sending them off to a third party for the transaction and aren’t storing any personal information locally.

But even if you aren’t selling things on your site you should still care about making your site secure. It was recently discovered that the NSA stores huge amounts of data collected from the normal internet usage of people like you and me. Unencrypted sites means that it’s easy for them to get this data, and any additional information/data sent to or from that unencrypted site. While encrypting your site might not be a foolproof way to prevent the NSA from spying on you, it wouldn’t hurt, and it can at least make it more difficult for them to access your data.

Okay, what do I need to do?

SSL certificates range in cost from $5 to $500 depending on where you get them and what they do. I’m not an expert, so I couldn’t even tell you the difference. In a lot of cases you can just contact your host for a security certificate and let them set it up for you, then change your URLs in WordPress.

But that’s not what I did.

A while ago (in fact, not long after Google’s announcement), Cloudflare announced that they’d be offering free SSL to all Cloudflare users, including those (like me) on their free plans. For those of you not familiar with Cloudflare‘s service: they are a DNS service that, among other things, allows you to manage all your domains through their nameservers. In addition to that, they add some additional security and speed-boosting enhancements like caching when you are using their service.

Instead of getting a whitescreen if your server goes down, your users will get either get a message at the top of the page saying that they are looking at a cached version of the page or a Cloudflare error page that says there’s a problem connecting to the server and no cached version of the page could be found (it’s a bit nicer for your users than an Internal Server Error message on a white page). I’ve loved Cloudflare’s free service for years because I like being able to manage all my domains in one place. Having a third-party service managing my nameservers means, too, that if I switch webhosts, I only have one place to make the adjustment to the nameservers (rather than having to go into different domain registrars to change each one individually).

Since I was already using Cloudflare, using Cloudflare’s Universal SSL was a no-brainer and, in fact, when I tested it out on a whim one day–just by putting an https in front of my domain name–I was shocked to see that it actually worked!

Okay, it didn’t really work. There were parts of the page that were broken and not displaying correctly, but the fact that it displayed anything at all, instead of just an error message saying a secure connection could not be made, gave me hope and sent me on the path to set up SSL on my (multi)site.

(Note: Cloudflare’s SSL free certificates have multiple domains on them, so it’s possible that some of those might not be sites you want your site to associate with, especially if you’re doing this for a business or corporate site. This tutorial is assuming you’re like me, and just want to set this up for personal use. Cloudflare is active on Twitter and you can always contact their support staff if you have specific questions or issues.)

For this particular recipe, you will need the following ingredients:

• An account on Cloudflare. Go get one for free if you don’t have one already.
• A WordPress-powered site. I’ll be using my Multisite as an example.
• (Possibly optional) WordPress HTTPS – a plugin that forces HTTPS links across your site(s).
• (Possibly optional if you want mapped domains) WordPress MU Domain Mapping – This is used to easily map custom domains to specific sites on your Multisite.

I’ll assume you have the first two things–a Cloudflare account and a WordPress install. If you have both those things set up and you just throw an https in front of your domain, you’ll probably get something that looks horrible like this:

This is because, as I mentioned before, there are unencrypted elements on the page. There are iFrames serving unencrypted video files and there’s Stylesheets and Javascript serving from http instead of https. All of these things can lead to something that makes you want to cry and claw your eyes out.

This is where WordPress HTTPS comes in. Basically, what WordPress HTTPS does for you is force it so that anywhere on a page where there is an “http://” it’s replaced by an “https://”. Every javascript, every stylesheet, every link, every everything. This is a lot easier to manage than trying to track down every individual unencrypted element on your page and fixing it individually (which I did see suggested when I was working on this).

On Multisite, you can Network Activate WordPress HTTPS and you’ll get a screen like this in your Network Admin:

Here I’ve got all the sites on my network listed, along with their SSL hosts (in this case, all my certificates are “self-hosting,” meaning the host is just your regular, root domain), and a couple checkboxes for some global settings.

Specifically, I’m forcing SSL in the admin (this takes the place of the define( 'FORCE_SSL_ADMIN', true ) that you can define in your wp-config.php file–read more about it in the Codex), and I’m removing unsecure elements from the page. This prevents insecure elements from giving you a broken page or a non-green padlock; anything it can’t explicitly fix, it’ll just drop so you can deal with it later and, in the meantime, get your 100% secure site up and running quickly.

If there are some sites on your Multisite that you don’t care or want to be on HTTPS, you can just force SSL in the admin or just leave those unchecked.

In each site’s admin, I have some additional, granular controls over how HTTPS is handled for that site:

You can see here that those same settings from the Network Admin screen, Force SSL Admin and Remove Unsecure Elements, are repeated, and from here, you can override them if you want. It also automatically maps ShareThis and Gravatar URLs to their secure counterparts, and you can use those as boilerplates for mapping your own domains if and when you come across elements that aren’t secure (but could be at a different/altered URL as opposed to just an https:// version of the existing URL). If you really want to get fancy, you can create filters so that certain parts of your site are secured, but other parts are not.

For me, I wanted the whole site to be secure, and these days, there’s no real reason to not just secure everything (especially if you are doing it for Google rankings or because you’re concerned about privacy).

Now, there’s one other part of this and that’s the Domain Mapping component. Otto has an excellent post on WordPress MU Domain Mapping, and covers it far better than I could. If you’re mapping custom domains to your WordPress Multisite, I recommend checking out his post first. The post is a little old but not much has changed since it was written.

Domain Mapping makes it so that on my Multisite, I can edit the full URL of the domain and map it to a specific site ID. I can do this from the normal Multisite Edit Site screen but I also need to do this from the Domain Mapping Domains page. However, if you’re using Domain Mapping, you still can’t edit the http/https part of the URL.

This needs to be done in the Site Settings tab:

That works fine for my subsites, but those fields aren’t editable for my main site.

In this case, you have a couple options:

1) Don’t do SSL on your main site, or just force it on the admin (this might still give you some headaches as WordPress will still be looking for http paths for elements in the admin).

2) Don’t setup Multisite until after you set up your SSL (probably ideal, but not always possible).

3) (╯°□°)╯︵ ┻━┻ give up

4) Hack your database.

As scary as the last option sounds, and as easy as it might be to break stuff, that’s what I’m gonna suggest. As long as you go into it with an understanding that stuff could break and a backup plan if it does (go back and fix things in the DB that you changed or restore a backup), it shouldn’t be that scary.

To do this, first, BACK UP YOUR DATABASE.

Seriously, back it up. In fact, back it up now, while you’re thinking about it.

Now, you’ll need access to phpMyAdmin from your host or the Adminer plugin for WordPress. If you’re more familiar with hacking the WordPress database (like I was), you might know what’s coming already: in your wp_options table, you’re looking for the siteurl and home options. Both of those will have http:// addresses and you just need to change the http to https. Then, go into the wp_sitemeta table and change the siteurl to https there. Again, MAKE SURE YOU BACKUP YOUR DATABASE BEFORE YOU DO THIS! If you used the Adminer plugin to edit your database, delete it once you’re done. There’s no reason to keep it around but there are many reasons to get rid of it.

If everything went smoothly, your Multisite should be all https-ified and you should be looking at a shiny green padlock. Now, if that padlock still isn’t green, you’ll want to open up Google’s Developer Tools (or Safari’s, or Firefox’s) and try to identify what elements on the page aren’t being delivered securely and address those individually.

The post How to Set Up HTTPS on WordPress Multisite Without Headaches appeared first on WebDevStudios.

Everyone on the project wondered if there was some easy way that we could get a snapshot of what each install had going on. The only requirement that Chris wanted was an easy copy/paste way to get the cumulative status from each so he could compare side by side. This set my brain running and I was granted the task to explore what could be done to accomplish this.

After some research, I got set out on the task and the end result became “WDS Active Plugin Data.” It is a multi-site dependent plugin that will only show up in the Network Admin settings submenu once activated.

Views

When you visit the settings page, you will be presented with a basic screen that provides three different view links at the top and the initial “Simple” view displayed below.

Simple View

With “Simple” view, you are presented with each plugin listed on their own line and their current status. Status is indicated by either blank space for not active, “[A]” for active, and “[NA]”” for network active right after the plugin name. This is all presented in a basic textarea that is non-editable and will auto-select all of the contents for easy copying.

Advanced View

While probably not THAT advanced, the “Advanced” view is not as compact in its listing compared to “Simple” view. It will list the plugins with two more columns for “Active” and “Network Active.” Each plugin will have its current status indicated by either “true” or “false” in the corresponding column.

Sites List View

The last view we have is the “Sites List” view. With this one, we extrapolate the data and apply it to each site in the network. This will allow you to see which plugins are active in which sites, but does not denote status of “Network activation.” When the plugin is active for a site, its corresponding cell will be green with a checkmark in it, and when inactive, red with an x in it.

Summary

With the three available views, it is easy to see what plugins you have available, and where each is currently active. When working on client work, comparison of the status between development and production sites, or between two development sites is right at your fingertips.

You can find the plugin on our company GitHub page at https://github.com/WebDevStudios/WDS-Active-Plugin-Data or as a direct zip file download.

The post Checking Plugin Activation Status on Multisite Networks appeared first on WebDevStudios.

• wp-config.php – ‘DOMAIN_CURRENT_SITE‘
• wp_blogs table – domain column
• wp_site table – domain column
• wp_options and wp_*_options tables – ‘siteurl‘ and ‘home‘ option values

That should get you to where the site will load and you can log in. You’ll still need to search and replace urls in the post content using a tool like Search Replace DB 2 or the Search Regex plugin.

The post Migrating WordPress Multisite from a Development URL to Staging or Production URL appeared first on WebDevStudios.

Over the past few years, WDS  has worked diligently with NCI to convey their social media vision into a huge and successful network that has the potential to change the online real estate business.  We have enabled and customized the great features provided by WordPress MU (now Multisite) and made it possible for NCI to host their own blogging community of over 1,200 members AND provide a variety of other great services to the members of their community.

Recently, social media consultant Mack Collier spent some time working with NCI teaching the company’s bloggers how they can better create blog posts that help them reach their client’s objectives.  He wrote a great article on his experience with the people of NCI, the new business model they have created and how their business is growing so quickly that they almost can’t keep up with the demand. We think this is not only a great use of social media, but also a great example of just how versatile WordPress and WordPress MS can be.

If you would like to learn more about NCI’s services and see just what WordPress MS can do for your business, you can find more information here:

The post NCI Creates a New Business Model with the Help of WDS appeared first on WebDevStudios.

Dr Hyman’s team was looking for a way to show the world who Dr. Hyman is while maintaining the many facets of his work under a single platform.  We knew that WordPress MultiSite would be the perfect platform to provide just what they needed. WordPress MS allows Dr. Hyman to manage DrHyman.com, UltraWellnessCenter.com and his microsites from one centralized location.

Using the Genesis theme framework, we worked with Dr. Hyman and his team to create a new design and layout for DrHyman.com and UltraWellnessCenter.com.

Working along with the consulting services of Margaret Roach and the design services of Kenneth Smith, the new DrHyman.com is clean, informative, easy to maneuver and easily manageable for Dr. Hyman and his team!

If you are interested in learning how you can maximize your current website with WordPress, please contact us today!

The post Have you visited the new DrHyman.com? appeared first on WebDevStudios.

Keeping your WordPress installation current is the single most effective way to keep your website secure and safe from vulnerabilities and hacks. Our support packages also offer plugin and themes upgrades, offsite backups, support ticket system (with unlimited tickets!), and even phone support.

Stop worrying about your website. Stay protected with updates, backups, and a support staff that truly understands WordPress and WordPress MU. Get signed up for a maintenance package today!

The post New WordPress Maintenance Packages! appeared first on WebDevStudios.

BuddyPress is a set of WordPress MU plugins that adds social networking functionality to any standard WordPress MU installation. Each BuddyPress component is independent, meaning you can choose which features you’d like and are not required to install all features on your site.

Andy Peatling, the developer behind BuddyPress, did an excellent interview on WordPress Weekly last Friday. In the interview Andy goes in to detail on BuddyPress features and functionality, the future of BuddyPress, developing BuddyPress specific components, and much more. As always Jeff did a great job with the interview.

We recently started development on our first production BuddyPress website. We are excited to work with the new BuddyPress plugins and can’t wait to launch this great new website. If you are interested in creating your own BuddyPress website please contact us today to learn how WebDevStudios.com can help!

The post BuddyPress Beta Released – WordPress Meets Social Networking appeared first on WebDevStudios.