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

Background

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

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

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

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

Instructional Text

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

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

Tabs in Blocks

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

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

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

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

Dropdowns

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

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

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

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

Readonly Fields

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

Frontend Previews

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

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

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

Conclusion

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

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

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

But before we talk about whether or not to use Multisite, let’s discuss whether or not you need multiple websites at all.

Use Cases for Deploying Multiple Websites

There are several reasons to build and manage multiple websites for one business, including:

• Companies that have more than one physical location
• Global organizations with divisions in multiple countries that require content in multiple languages
• Franchises
• Large companies that have separate divisions or subsidiaries for separate purposes and audiences
• Educational institutions with multiple campuses and/or different schools within one university network
• Companies that acquired another company, yet want to maintain separate brands
• Companies that want to deploy a microsite strategy for either SEO or building brand reputation for a specialization

Sometimes the decision of whether or not to deploy and start managing multiple websites is a simple one. In cases where the branding needs to be totally different amongst divisions, multiple websites are certainly warranted. However, in other cases, the decision is less clear.

Considerations for Undertaking the Management of Multiple Websites

If it’s possible for your organization to deliver content through a single website, but you’re considering deploying separate sites, take into consideration the following:

• Effort involved in basic maintenance of multiple websites (design changes, security updates, backups, etc.)
• Costs of maintaining separate websites (hosting, premium plugins, security subscriptions, etc.)
• Effort involved in building up SEO reputation of multiple websites

I want to expand on that last one, as I think this is one of the most overlooked considerations when a business is deciding whether or not to deploy and start managing multiple websites. SEO is HARD. It takes A LOT of work. It involves keeping up with Google’s latest technical requirements, pushing out a ton of high quality and well-keyword-optimized content on a regular basis, acquiring quality inbound links for the domain, constantly monitoring performance, and consulting with or hiring an SEO expert or agency on a regular basis.

Even a very small business can end up needing to lay out thousands of dollars (and/or dozens of labor hours) per month on web development, copywriting, public relations or social media efforts for link building, and consulting fees—just to build and maintain an SEO reputation for their website. This five-to-six figure per year expense immediately gets doubled the moment you deploy a second website.

SEO Benefits of Having Multiple Websites

With the above warning having been said, there are indeed potential SEO benefits to having multiple websites.

• Opportunity to claim more than one spot on Page 1 of search results
• Opportunity to show search engines that each site is clearly focused on one topic or geographical location, making each individual site more likely to rank for its topic or within its target region
• Opportunity to incorporate desirable keywords in each domain name—this “exact match domain” SEO tactic doesn’t carry the weight that it used to in the past, but it certainly does still carry some weight.

If you want to try to realize some of these potential SEO benefits, and are certain that you can handle the additional workload and budgetary investment required for optimizing multiple sites, then your next decision is how to deploy and start managing your multiple websites. That’s where WordPress Multisite comes in.

Using Multisite to Manage Multiple WordPress Sites

WordPress Multisite allows you to run multiple WordPress websites from one WordPress installation. This has some clear benefits, including:

• Only having to maintain one WordPress installation versus several. This means that things like core updates, plugin updates, backups, etc. only have to be done in one place.
• Technical SEO optimizations can be deployed across multiple sites at once. Google is always adding to the already-long list of things it wants site owners to implement, such as AMP, Schema markup, page speed optimizations, etc. Some of these can be very cumbersome to apply to a single WordPress installation, let alone several.
• Multiple sites can share a single theme in a Multisite network, making it easy to deploy design changes across several sites at once.
• Multiple sites can share plugins, making it easy to deploy new functionality across several sites at once.
• Multisite offers very granular control of user access rights. You can grant access to just one site, several sites, or all sites to a single user , and give them different access levels on each site.

Of course, these very same benefits of streamlined site management can present some downsides as well. Having multiple sites share the same theme can present design limitations for each individual site. Additionally, if a single plugin is shared across multiple sites, and something goes wrong with that plugin, all sites utilizing that plugin will be affected.

Despite potential downsides, many site owners believe that the benefits of Multisite outweigh possible limitations and issues. If you’ve decided that Multisite is right for you, you have one more major decision to make—whether to use separate domain names, subdomains, or subdirectories for the individual sites. Multisite networks support any/all of these configurations.

Choosing the Right Multisite Structure for SEO: Multiple Domains vs Subdirectories vs Subdomains

Multiple Domains

SEO-wise, using entirely different domain names can provide the “exact match domain” benefit mentioned above; however, this approach also means that you have to build up domain authority for each domain completely separately. Getting reputable inbound links is not easy, and it simply must be done completely naturally in order to adhere to Google’s strict Webmaster Guidelines. This means that a public relations strategy and/or very strong social media and influencer marketing strategies must be in place for each and every domain.

For global organizations that need a strong search engine presence in multiple different countries, a multi-domain approach with different country code top-level domains (aka ccTLDs), i.e. maindomain.au for Australia and maindomain.es for Spain, can be of particular benefit. These organizations typically have staff based in each region that handle their own local marketing efforts in each country. So, the challenge of building up inbound links for each domain can be significantly less cumbersome in this scenario than it would be for a smaller organization.

Subdirectories

Using subdirectories, i.e. maindomain.com/site1, maindomain.com/site2, etc., eliminates the issue of having to acquire high quality links on multiple domains. It does not offer the benefit of having various “exact match domain” names, but in many cases, the streamlined link acquisition efforts is a benefit that can more than make up for having a variety of keywords in various domain names.

For an organization that has limited resources for public relations and social media efforts, the subdirectory approach can make more sense than having separate domain names—since search engines will see all the content as belonging to a single site.

However, this same benefit of multiple sites being perceived as one means that search engines won’t see each individual site as ONLY specializing content about one topic. So for a microsite strategy that intends to rank for keywords about a niche area of expertise, it may be better to go the multiple domain route to demonstrate tightly-themed topical relevance on each site.

Subdomains

Using subdomains, i.e. site1.maindomain.com, site2.maindomain.com, etc. is sort of a middle ground between the above two approaches. It offers the opportunity to use keywords in the subdomain name, yet have all sites share a main domain and therefore somewhat share inbound link equity across the network. However, search engines are aware that subdomains can be used to point to entirely different servers that host entirely different types of content, so domain authority still needs to be built up separately for each subdomain by acquiring reputable inbound links for each.

This can be a good fit for franchises or companies with multiple physical locations, where each individual location will be doing its own marketing efforts for its own site.

No Single Right Answer

As you can see, there’s no single best approach here. Different approaches make sense for different businesses. And the decision on how to set up your Multisite network gets even more complicated if there’s already separate domains or subdomains in existence. The decision of whether to maintain that structure, or whether to use the transition to WordPress Multisite as an opportunity to consolidate or change the structure, must take into account how long the separate domains or subdomains have been in existence, how much inbound link equity each has, and how much the keywords in the domains or subdomains seem to be having an impact on rankings.

Consider consulting with both an SEO expert and a web development expert before finalizing your decision on whether to create or continue to manage multiple websites, and whether or not WordPress Multisite is right for you. Each will be able to give educated perspectives on the web development and SEO considerations that apply to your own unique situation. The importance of SEO cannot be overemphasized, so investing in a little consulting up front can provide great benefit down the road.

About the Author

Pam Ann Aungst, M.B.A., President of Pam Ann Marketing, LLC and founder of Stealth Search and Analytics, is widely recognized as an expert in search engine optimization (SEO), pay-per-click advertising (PPC), and digital analytics.

A self-proclaimed “geek,” Pam began studying computer programming at 6 years old, started creating websites in 1997 and has been working professionally in the field of e-commerce since 2005. Referred to by Sprout Social as a “Twitter Success Story,” she harnessed the power of social media to launch her own agency in 2011.

Pam has been interviewed by publications such as Internet Retailer magazine and CBS Small Business Pulse. She guest-lectures at prestigious universities such as NYU and frequently travels around the country giving talks at industry conferences. Pam has been honored with several awards for her small business leadership and non-profit advocacy work, including being named one of “Jersey’s Best Marcom Professionals Under 40.”

Pam holds an M.B.A. in Marketing from Regis University, where she learned the cornerstones of traditional marketing strategy. She now combines that with her more than 12 years of professional experience to help established companies and “household name” brands take their traffic-driving and analytics strategies to the next level.

The post SEO Considerations for Managing Multiple Websites appeared first on WebDevStudios.

Part 3: Can WordPress Multisite Help You?

In the previous two parts, we introduced you to new concepts in WordPress Multisite that a single site installation does not have. In this final part, we will guide you toward an understanding of when using WordPress Multisite is the best option, and help you determine if it is the right fit for your organization.

So far, I have provided a lot of information on what WordPress Multisite is and the benefits it contains, but what about the practical application of it? You came here wondering if WordPress Multisite might be the solution for you. This section will outline key things to consider when deciding whether or not to use WordPress Multisite.

When You Should Use WordPress Multisite

There are some instances when it makes perfect sense to use WordPress Multisite. Multisite typically works best when the sites on the network all run along a similar theme or have a limited differential in terms of required functionality. Let’s take a look at a few prime candidates.

Multilingual Network

If your site needs to be translated into additional languages, using WordPress Multisite can quickly get you there. The theme and plugins will likely be the same across all sites with only content differences. Each language would be its own subsite that could be configured with access only for the translators who need to be able to touch the content. This is a strategy we utilize here at WebDevStudios (WDS) with a subdirectory install that winds up looking like:

• English – http://acmecorp.com/en
• Spanish – http://acmecorp.com/es
• French – http://acmecorp.com/fr

Blog Network

WordPress can be a high-performance blogging engine. If your use case is to put together a group of basic blogs, WordPress Multisite in the answer. WordPress.com is a prime example of a blog network. Users have a limited set of functionality available to them and several different themes they can choose from. The variety in look and feel of sites hosted by WordPress.com is impressive.

While we are on the topic of WordPress.com’s service, I want to mention some of its staggering statistics. 

• 21.7 BILLION page views per month
• 79.2 million new blog posts each month
• ~74 million sites hosted (this number is questionable as the full number is not released)

Wow! That is a huge amount of data and traffic for one WordPress installation, and guess what? Nobody has ever reached the limit of Multisite’s capabilities. As long as you have the hardware to support it, there is theoretically no limit to the number of sites you can host on a WordPress Multisite install. WordPress.com proves that.

Multi-Department Corporate Sites

Earlier, I shared a multi-department Acme Corp example. It is a common scenario we see at WDS, wherein companies desire to have departmental websites in which each department controls its own content and has some limited ability to manage the look and feel from a common style guide.

One such client we worked with tapped WordPress Multisite for their intranet. It was not even a public facing site! It was one of the more creative uses I have come across and included:

• A couple dozen departmental sites
• Centralized file management for forms, memos, etc.
• HR/personnel management
• Employees’ corner
• Monthly corporate newsletter
• Classified similar to Craigslist
• Employee blogs

When You Should NOT Use WordPress Multisite

As awesome as WordPress Multisite is, there are also times when it does not make sense to use. Take a look at these examples.

Each Site Needs Significant Custom Development Work and/or Plugins

When you have a group of sites, even within the same organization, that need a significant amount of custom development work, WordPress Multisite may not be a good idea. One tiny mistake in the code for another site can have implications across the entire network—possibly crashing it.

Even when the “significant custom development” is nothing more than installing a bunch of plugins, WordPress Multisite can cause issues. Some plugins alter network operations in ways that only a super admin should be altering. Ideally, the network will have a well-defined purpose that limits the amount of customizations to functionality that will be needed per site.

A great example of this scenario is my own personal site https://ben.lobaugh.net. Being a developer, I have the ability to go in and tweak the code on my site as often as needed. I know that I can bring down the site if I screw up, but it will not affect anyone else. I am also not worried about ensuring the code I write is safe for a Multisite environment.

Each Site Needs Its Own IP Address

WordPress Multisite aims to make running a network of sites as simple and painless as possible. When you have a network of sites that all need their own IP addresses, a lot of complexity is introduced. It is absolutely possible to make it work, but it will require significant time investment in development operations to configure the servers properly. For a small network with a few sites, this may not be a big deal; but when you get into dozens and thousands of sites, it is simply not feasible.

Ecommerce

Ecommerce is a sticky wicket with WordPress. In recent years, ecommerce support on WordPress has improved dramatically for single site installs; however, Multisite ecommerce support has largely been neglected. This is in part due to the overhead needed to run a proper ecommerce site. There are additional database tables, relationships, and processing power needed to run an ecommerce site, in addition to things such as payment systems and SSL certificate requirements. Though it is possible to run WordPress Multisite in this manner, it requires a significant investment in time and architectural knowledge that usually makes it more time and cost-effective to use multiple separate WordPress single site installations.

You made it!

Congratulations on getting through all three parts in this series on WordPress Multisite. Multisite is a powerful tool that I hope you will be able to utilize. WDS loves WordPress Multisite, and we are always interested to see how others are using it. We would love it if you dropped us a line in the comments. If you would like to chat about your implementation or work with us on your project, head over to the contact page.

Looking forward to hearing about your projects!

Photo by rawpixel.com on Unsplash

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

Part 2: Why Does WordPress Multisite Matter?

If you have not read it already, go read Part 1 in this series, as it introduces the new terms WordPress uses for its Multisite environment. It also provides a high-level view of what WordPress Multisite is. In this part of the series, we will go over the why WordPress Multisite matters.

WordPress Multisite takes the hassle out of maintaining several individual WordPress installations, each hosting only a single site. It comes in handy in organizations with several brands, departments, or business units that need to share functionality, or data, in a convenient manner. It helps IT teams spend less time maintaining multiple hosting environments, patching security issues, and ensuring sites are kept updated. In my example (see Part 1), WordPress Multisite allows me to create a platform as a service (aka, PaaS) hosting environment for family and friends.

Let’s delve a bit deeper into some of the powerful features of WordPress Multisite.

Centralized Management

Because WordPress Multisite is running from a single installation of WordPress, it brings all the sites together into one centrally managed location. This has several benefits, including:

• Shared core/plugin files
• Shared updates
• Super admin management

Let’s look at each of these in more detail.

Shared Core/Plugin Files

Maintaining multiple individual WordPress installations can be a pain, as you are required to ensure the WordPress core files, plugin files, and theme files are available for each installation. WordPress Multisite simplifies this to a single copy of all the files. Let’s use the following illustration as an example.

• Acme Corp has four departments that each need a website: HR, Engineering, Products, Support.
• Acme Corp has a standardized style guide and required functionality for each site.

With a typical WordPress single site setup, Acme Corp would normally be responsible for four completely separate sites, including all the developmental operations that go into it, such as hosting plans, DNS management, and remembering which plugins need to be installed for consistency.

WordPress Multisite flips that situation on its head. In the Multisite paradigm, Acme Corp will now save time and money with one installation, one DNS entry, one hosting plan. Plus, all themes and plugins are available to every site out of the box.

One Place to Update All the Things

That brings us to updates and security patches. Getting updates processed and completed in a simple and efficient manner is important. In the Acme Corp example above, it would take four times the effort to get all the sites updated. As the number of sites you run expands, so do the efforts of maintaining these sites.

WordPress Multisite simplifies this down to the same amount of effort it takes for a single site. With just a couple of clicks, updates are applied to all sites on the network. There is no need to remember account information for multiple sites, or run the risk of forgetting an important security patch on one of the sites, and thus compromising potentially sensitive data.

Site Administration Made Easy

Providing proper access levels is paramount in any organization. Users should only have the level of access that they need to do their job and nothing more. The person in charge of administrating the site will need administrative access over all things. In WordPress Multisite, the administrator role remains, but it is limited to the site on which the user has been assigned the administrator role. For users who need access to all of the sites, a new role called super admin is introduced. Super admins have the ability to manage network level actions as well as get into the dashboard on any site. This allows super admins to not only control the network, but to also help site administrators when they have questions or need assistance running their site.

By now, you should understand what WordPress Multisite is and why it it is such a valuable tool. In the next and final part of this series, we will cover when using WordPress Multisite is a good idea, and if it could be the right fit for your organization.

Photo by Carl Heyerdahl on Unsplash

The post What Is WordPress Multisite and How Can It Help You? (Part 2) 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.

Translation Lengths

Typically, during the design phase the text being used will be your native language or some alternative filler text (lorem ipsum). While this is perfectly acceptable practice, one thing to keep in mind is that many languages around the world have different writing systems. When translating a site for different languages, it’s important to think about margins and padding between elements as well as line heights.

Although it’s perhaps not always possible to know how long each and every word will look once it’s translated, it’s definitely something you’ll want to account for especially when space is limited. In my experience, some languages like Russian and Polish will have words that are 1½ times the amount of space as that same word written in English.

There are a couple of options for when these situations that come up. For example, conditionals can always be added to template files based on blog id or body classes can be added to target specific blogs if you’re doing a Multisite multilingual install. This can become overwhelming and difficult to manage for larger networks, so that’s also something to keep in mind.

Here’s an example of adding a body class for sub-sites for smaller fixes:

<?php
/**
 * Add Body Class for Language Sites
 */
function wds_subsite_body_classes( $classes ) {
        $id = get_current_blog_id();
        $classes[] = 'site-id-'.$id;
        return $classes;
}
add_filter( 'body_class', 'wds_subsite_body_classes' );

Using Plugins for Sub-site Modifications

Another great process that I highly recommend for making major modification to the same template based on certain language needs is to put all site specific changes into a Plugin. Although it’s not a new process by any means, I think it’s something that can be forgotten sometimes. This helps things stay organized and your theme files will be much cleaner overall. Just make sure to add it as a plugin for each site rather than an MU plugin, as that can cause for translation headaches sometimes depending on which plugin you decide to use for generating translations.

As you can see in this example adding conditionals throughout the theme in various places can become very difficult to manage if they were spread throughout the theme:

<?php
/**
 * An example of how conditionals can become difficult 
 * to manage in large Multisite Networks
 */

global $blog_id;
 
if ( '2' === $blog_id ) {
// you see here;
} 
 
elseif ( '3' === $blog_id ) {
// more here;
} 
 
elseif ( '4' === $blog_id ) {
// much more here;

else {
// how this can get out of control quickly with lots of sites in the network;
}

Internationalization and Localization

Once you’re into the development stage of a new multi-language project, you’ll want to make sure Phrases (translating Phrases is better practice than just words) are translation ready throughout the project (plugins and theme). This could be an entire post in and of it’s own, but a couple quick things to keep in mind.  For example, text domains, domain paths, basic strings, variables, plurals, and so much more. It’s all really nicely documented in the codex and developer handbooks and I highly recommend these as really good examples with solid explanations.

Codex

• http://codex.wordpress.org/I18n_for_WordPress_Developers

Themes

• https://developer.wordpress.org/themes/functionality/internationalization/
• https://developer.wordpress.org/themes/functionality/localization/

Plugins

• https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/
• https://developer.wordpress.org/plugins/internationalization/localization/

A Few Issues that can come up with Translations and Characters

Some other issues that inevitably come up are often with languages with accents and different characters when translating. Recently, I came across a post by WPEngineer for character based languages and languages with accents. This post by WPEngineer does a really nice job of explaining how you can address the issue when/if it arises on a project.

Along the same lines, with certain character based languages, you’ll notice font rendering issues depending on which fonts you’re using on the site. There are some workarounds like declaring font weights, or if you’re using Sass, you can create a mixin along these lines:

// ------------------------------------------------------------
// Font Stacks for Non Multi-Language and Multi-Language sites
// ------------------------------------------------------------
 
// Example Font Stack Usage
// @include font(light);
// @include font(normal);
// @include font(semibold);
// @include font(bold);
 
@mixin font($fontstack) {
 
    $wds_font: (
        light: 'wds_font_light',
        normal: 'wds_font_normal',
        semibold: 'wds_font_semibold',
        bold: 'wds_font_bold'
    );
 
    $fallback: (
        light: normal,
        normal: normal,
        semibold: bold,
        bold: bold
    );
 
    font-family: map-get($wds_font, $fontstack), WDS UI, Tahoma, Arial, sans-serif;
 
        html:lang(bg) &, // Bulgaria
        html:lang(cs) &, // Czech Republic
        html:lang(el) &, // Greece
        html:lang(ko) &, // Korea
        html:lang(pl) &, // Poland
        html:lang(ro) &, // Romania
        html:lang(ru) &, // Russia
        html:lang(th) &, // Thailand
        html:lang(vi) &  // Vietnam
        {
            font-family: Tahoma, Arial, sans-serif;
            font-weight: map-get($fallback, $fontstack);
        }
 
        html:lang(zh) & { // China
            font-family: 'Yahei UI', 微软雅黑, map-get($wds_font, $fontstack), sans-serif, WDS UI, Tahoma, Arial, sans-serif;
            font-weight: map-get($fallback, $fontstack);
        }
 
        html:lang(ja) & { // Japan
            font-family: 'Meiryo', map-get($wds_font, $fontstack), sans-serif, WDS UI, Tahoma, Arial, sans-serif;
            font-weight: map-get($fallback, $fontstack);
        }
 
}

With International sites, it’s also good practice to be mindful of excerpt lengths. In English, having an excerpt of 55 words will look a lot different than it would in Chinese since most words are a single character. Not a deal breaker, but certainly something to keep in mind when working with different languages.

Social media is a huge part of most websites, but believe it or not, Facebook, LinkedIn, and Twitter are not always the most popular networks in other countries. If we use China as an example: they use things like WeChat, Weibo, and Yammer more than Facebook or Twitter, so you’ll want to account for that when building out your theme templates, plugins, etc.

This really just scrapes the surface of some of the basics to keep in mind when building and working on Language Sites. There are lots of great posts with information on internationalization plugins to use, ways to generate .po/.mo files and so much more, including this fantastic article on Post Status by Brady Vercher.

When building and designing sites, these are just a few pointers to keep in mind. If you have other experiences, tips or things to remember, let us know in the comments!

The post What to Consider When Creating a Multilingual Site 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.

So, it should stand to reason that sharing a specific sidebar, or set of sidebars, across an entire multisite network should be just as great (and easy), right?

Well, if it were, we wouldn’t be here right now.

I know what you may be thinking…

Just use switch_to_blog(), ya dingus!

Oh, how I wish it were that easy!  That was our first guess as well, but it unfortunately didn’t do the trick.  Apparently, switch_to_blog() is a trick that does not work when attempting to share a sidebar across a network.  Total bummer.

In our situation, though, we had a set of sidebars in our footer that we wanted the client to be able to manage but also share across every site within their network.  So, hardcoding the widgets in place wouldn’t have been a proper solution; neither would have been telling the client that they would need to manage three sidebars on 300+ sites.  Ouch.

We had our task: allow a set of sidebars to be displayed across the sites in a multisite network.

We had our problem: switch_to_blog() doesn’t work for this, so we needed to figure out another way to accomplish our goal.

Now we have our solution.

The first thing we want to do is build the output of our sidebars. That seems kind of important, right? Can’t see some sidebars if we’re not telling the sidebars to display. We don’t want to just display the sidebars and be done with it, though. What we want to do is store our sidebars in a transient. This transient will be deleted whenever a widget is updated in one of our three sidebars (you’ll see this later, be patient!). In order to store our set of sidebars as a variable, we need to wrap everything in an output buffer.

/**
 * Generate sidebar for footer across all sites
 */
add_action( 'init', 'wds_footer_widgets_all_sites' );
function wds_footer_widgets_all_sites() {

    if ( ! is_main_site() )
        return;

    if ( ! ( $wds_footer_widgets = get_site_transient( 'wds_footer_widgets' ) ) ) {
        // start output buffer
        ob_start();

        // Display our footer sidebars
        if ( ! dynamic_sidebar( 'sidebar-footer-1' ) ) :
                endif; // end sidebar widget area

        if ( ! dynamic_sidebar( 'sidebar-footer-2' ) ) :
        endif; // end sidebar widget area

        if ( ! dynamic_sidebar( 'sidebar-footer-3' ) ) :
        endif; // end sidebar widget area

        // grab the data from the output buffer and put it in our variable
        $wds_footer_widgets = ob_get_contents();
        ob_end_clean();

        // Put sidebar into a transient for 4 hours
        set_site_transient( 'wds_footer_widgets', $wds_footer_widgets, 4*60*60 );
    }
}

Next comes our theme’s footer. This is a bit more straight forward – we want to get the site transient that we established in our functions file above, then display its contents.

// Display our stored footer widgets
$show_footer_sidebar = get_site_transient( 'wds_footer_widgets' );
echo $show_footer_sidebar;

Now we should have our sidebars displaying, but we also want some additional magic to happen. We need to clear our transient when a widget is updated or saved in one of our three footer sidebars.  The first step of this process is to enqueue some scripts that we’re going to be using. I’m doing this in a separate file housing all of our AJAX-related commands, ajax-functions.php in our theme’s /inc/ directory.

/**
 * Enqueue and localize our scripts
 */
add_action( 'admin_enqueue_scripts', 'wds_enqueue_ajax_scripts' );
function wds_enqueue_ajax_scripts() {
    global $current_screen;

    // Only register these scripts if we're on the widgets page
    if ( $current_screen->id == 'widgets' ) {
        wp_enqueue_script( 'wds_ajax_scripts', get_stylesheet_directory_uri() . '/js/admin-widgets.js', array( 'jquery' ), 1, true );
        wp_localize_script( 'wds_ajax_scripts', 'wds_AJAX', array( 'wds_widget_nonce' => wp_create_nonce( 'widget-update-nonce' ) ) );
    }
}

In the same file, we want to create the AJAX function that runs when updating our sidebars. This function checks to make sure our nonce is present; if it is, it deletes the site transient.

/**
 * Register our AJAX call
 */
add_action( 'wp_ajax_wds-reset-transient', 'wds_ajax_wds_reset_transient', 1 );

/**
 * AJAX Helper to delete our transient when a widget is saved
 */
function wds_ajax_wds_reset_transient() {

    // Delete our footer transient.  This runs when a widget is saved or updated.  Only do this if our nonce is passed.
    if ( ! empty( $_REQUEST['wds-widget-nonce'] ) )
        delete_site_transient( 'wds_footer_widgets' );
}

We’ll need a JavaScript file to handle some back-end functionality, and we’ll need to localize the script so we can interact with that file.  We’re passing a nonce in our script as well; this will ensure that our widget form is being updated properly.

Finally, we want to create the AJAX that is going to listen for an updated widget. With jQuery first, we’re listening for a click on the remove, close, or save links on individual widgets within one of our three specific sidebars. If one of those links is clicked and we’re in one of our specified sidebars, we want to run our AJAX function.

jQuery(document).ready(function($){

    function wds_reset_footer_transient() {

        // Run our AJAX call to delete our site transient
        $.ajax({
            type : 'post',
            dataType : 'json',
            url : ajaxurl,
            data : {
                'action' : 'wds-reset-transient',
                'wds-widget-nonce' : wds_AJAX.wds_widget_nonce
            },
            error: function ( xhr, ajaxOptions, thrownError ) {
                console.log( thrownError );
                console.log( ajaxOptions );
            }
        });
    }

    // If one of our update buttons is clicked on a single widget
    $( '.widgets-holder-wrap' ).on( 'click', '.widget-control-remove, .widget-control-close, .widget-control-save', function() {

        // Get our parent, or sidebar, ID
        var widget_parent_div = $(this).parents().eq(5).attr( 'id' );

        // And if our parent div ID, or our sidebar ID, is one of the following
        if ( widget_parent_div == 'sidebar-footer-1' || widget_parent_div == 'sidebar-footer-2' || widget_parent_div == 'sidebar-footer-3' ) {

            // Run our function
            wds_reset_footer_transient();
        }
    });
});

And that’s about it! Now you can manage a set of sidebars on the main site within your network and pass those sidebars to every site within your network. One set of widgets to manage for an entire network of sites. It wasn’t the solution that jumped out at us at first, but it’s the one we found and it’s the one that works for us. We’re pretty happy with the way it turned out, and we think the client is going to be happy only having to edit their widgets once and have those changes visible on 300+ sites.

The post Sharing Sidebars Across a Multisite Network 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.

Brad will be giving a presentation on WordPress Multisite on Saturday.  If you plan on attending make sure you track them down and say hi!

The post WebDevStudios is Attending WordCamp San Diego 2012 This Weekend! appeared first on WebDevStudios.