WaaS doesn’t just benefit clients, however. It also opens up a scalable, recurring revenue stream for agencies, paving the way for more growth.

With these dual benefits in mind, we’re taking a closer look at WaaS, why it’s great, and how agencies can make the most of it. Along the way, we highlight how Kinsta is the ideal platform to power WaaS. From the management of multiple sites to automatic backups and top-notch security, Kinsta provides everything agencies need to deliver WaaS efficiently and at scale.

Let’s begin.

What is WaaS and how does it work?

Website as a Service (WaaS) is a subscription-based model that allows agencies to deliver professionally managed websites with minimal upfront costs for clients.

Unlike traditional projects, where clients pay a substantial fee for a custom-built site, WaaS provides an all-inclusive, affordable solution that bundles hosting, maintenance, and support into a predictable monthly or annual payment.

This approach benefits clients by reducing entry costs and gives agencies a scalable, recurring revenue stream.

To be more specific, here’s what a true WaaS setup typically includes:

Bundled hosting and maintenance

WaaS packages often feature managed hosting services where client sites are secure, fast, and backed up regularly. The agency handles essential tasks like updates, security monitoring, and performance optimization. This means sites run smoothly without constant client intervention.

Pre-made themes and templates

Agencies offering WaaS generally provide a library of themes suited to specific industries, like real estate, fitness, or e-commerce. Clients select a design that fits their industry and brand, and then the agency customizes it as needed.

For example, a fitness studio might choose a theme optimized for scheduling and bookings, while a real estate agency could opt for a template designed for property listings and virtual tours. This approach lets agencies reuse themes and configurations efficiently while giving clients a polished, industry-specific look.

Optional add-ons and integrations

While any core WaaS offering includes the essentials, agencies can increase value by offering premium add-ons like SEO, social media integrations, e-commerce, and analytics.

Practically speaking, a hair salon might add an online booking plugin or SEO services to improve local search visibility. Or, an online business coach might need online course integration with an LMS like LearnDash or LifterLMS.

DIY website management

WaaS usually involves providing clients with access to a user-friendly content management system (CMS), like WordPress so that they can make simple edits on their own. Things like adding blog posts, updating images, or tweaking product descriptions can be under their control without needing the agency’s help. This self-service approach appeals to clients who want autonomy, to keep agency support hours manageable, but still want support and maintenance handled for them.

A successful WaaS model is subscription-based, scalable, and affordable. Clients pay a manageable fee rather than a high upfront cost, while agencies benefit from consistent revenue and simpler setups that can be quickly replicated. With WaaS, everybody wins.

Why WordPress is the perfect platform for WaaS

WordPress is ideal for a WaaS model because it offers unmatched flexibility, ease of use, and an extensive range of themes and plugins. This makes it easy for agencies to set up and manage ready-made, professional websites without the need for heavy customization.

But there are other reasons why WordPress and WaaS are a great match, including:

• Extensive theme and template options: There are tons of WordPress themes out there, built for every industry and style preference. Because of this, agencies can select themes that fit their clients’ needs — whether it’s a sleek portfolio theme for photographers, a booking-friendly theme for fitness studios, or a modern business theme for small companies. When they use these pre-built themes, agencies can offer clients a professional-looking site quickly, with the option to customize colors, layouts, and features to suit their branding.
• User-friendly interface: WordPress is easy to use, including an intuitive dashboard that makes it possible for clients to manage their own content. This self-service capability is invaluable. After some initial training, clients can handle basic tasks — like adding blog posts, changing images, or updating product descriptions — without needing constant help from the agency. This autonomy benefits clients and saves time for agencies, who can focus on other aspects of their service.
• Wide range of integrations and add-ons: WordPress’s compatibility with thousands of plugins allows agencies to bundle added features. Integrations like WooCommerce for online stores, Contact Form 7 for customer inquiries, or Google Analytics for tracking let agencies provide powerful, feature-rich websites without having to reinvent the wheel for each client.
• Scalability for agency and client alike: WordPress also has a flexible infrastructure, allowing agencies to scale their WaaS model whenever the need arises. With tools for managing multiple sites and easy plugin updates, agencies can manage any number of client sites from a single dashboard. For example, an agency could push out security updates or new features across multiple sites simultaneously. This ensures consistent quality while keeping maintenance manageable.

To sum up, WordPress combines flexibility, ease of use, and extensive compatibility, making for an ideal WaaS foundation.

Key benefits of WaaS for agencies

We’ve touched on this already, but WaaS doesn’t just benefit clients. It also has several advantages for agencies looking to build a reliable, scalable revenue model.

Let’s look at some of these benefits now:

Predictable recurring revenue

Unlike one-off web design projects, a WaaS model generates consistent income through monthly or annual subscriptions. This predictable revenue stream helps agencies stabilize cash flow and plan for growth. So, instead of relying on sporadic project work, agencies have a steady stream of funds that can support scaling, hiring, and investment in tools and resources.

Scalability

With WaaS, agencies can quickly replicate their offerings by reusing themes, plugins, and configurations across multiple clients. Standardizing key elements like hosting, security settings, maintenance schedules, and essential plugins means agencies can set up new client sites much more efficiently. This also ensures faster onboarding and setup times.

Low maintenance with high returns

WaaS gives agencies the gift of time. By offering a standardized product that requires minimal hands-on work once it’s set up, agencies can take on more clients without sacrificing quality. With the right tools and hosting provider — like Kinsta — tasks like backups, updates, and security checks all become automated, minimizing the maintenance workload while still delivering consistent service quality.

How to implement WaaS with Kinsta

Setting up a successful WaaS model requires the right tools and infrastructure to ensure smooth site performance, automated maintenance, and streamlined client management. Thankfully, Kinsta is a reliable option for Managed WordPress Hosting and provides a range of features made for agencies.

If you’re thinking about offering WaaS soon, here’s how Kinsta can help you deliver:

Top-tier hosting management

As a managed hosting provider, Kinsta offers agencies a high-performance environment optimized for WordPress. Agencies can use the MyKinsta dashboard to manage multiple client sites from one place, track performance metrics, and handle administrative tasks, too.

Automatic updates and security

One of the biggest maintenance challenges in website management is keeping plugins, themes, and WordPress itself up to date. Kinsta simplifies this by offering automated updates and a full range of security features, including daily backups, firewalls, and DDoS protection.

These features minimize downtime and security risks, giving your clients peace of mind and reducing your agency’s maintenance workload.

Staging environments and site cloning

Kinsta also offers one-click staging environments, so you can test changes safely before pushing them live. If you’re offering WaaS and need to test updates or improvements without disrupting client sites, this feature is invaluable.

The site cloning feature is also helpful for WaaS agencies, allowing them to replicate a standard setup. This makes onboarding new clients much easier, as you can create fully configured sites in minutes. This is especially helpful for agencies working with industry-specific themes or recurring designs.

High-performance hosting and scalability

Kinsta’s architecture rises to the occasion as well. It’s powered by the Google Cloud, so client sites load quickly and perform well under traffic spikes. With features like CDN integration and resource scaling, Kinsta can also handle growing site demands. Agencies with expanding WaaS offerings or looking to scale stand to benefit the most.

Best practices for setting up a successful WaaS offering

A well-executed WaaS model goes beyond simply bundling hosting and maintenance. You also need to follow some key best practices to truly deliver a high-quality service that meets diverse client needs — while maximizing profitability.

Here are some best practices to set your WaaS offering up for success:

Select themes and plugins strategically

Choosing high-quality, versatile themes and essential plugins matters a lot. Look for themes that cater to specific industries or business types, as they provide a great starting point for clients and reduce the need for customizations. The incentive to “niche down” and focus on a select industry like real estate, portfolios, or finance is high.

For instance, if your agency already works with healthcare clients, you might select themes with built-in appointment scheduling or HIPAA-compliant features. Using reliable plugins for core features you know other clients will need — like SEO, security, and performance optimization — saves time, too. Also, setting up a roster of plugins like this ensures all client sites you launch are stable and effective from the start.

Define service tiers

Offering multiple service levels like Basic, Professional, and Enterprise means you can cater to a range of client needs and budgets. A Basic tier could include essential hosting and maintenance, while a higher-level package might add features like ecommerce, advanced SEO, or additional support.

Automate onboarding and support

Simplifying client onboarding and support reduces the time and effort needed to manage sites under the WaaS model. Provide clients with tutorials, user guides, and video walkthroughs to help them get comfortable with managing their own content. You only need to create these resources once and can use them again and again.

Setting up automated check-ins via periodic email reminders about performance updates or security improvements reinforces your agency’s support and keeps clients informed without constant manual outreach.

Offer add-on services

Beyond the basic WaaS package, consider offering valuable add-ons like SEO optimization, content creation, or ecommerce setup. For instance, a small fashion boutique might start with a simple website but later add local SEO services as their business grows. These add-on options allow clients to scale up as they see results and provide an additional revenue stream for your agency without requiring a completely new service structure.

Following these best practices will get you far, but that doesn’t mean problems don’t arise sometimes. We’ll cover how to manage challenges related to WaaS next.

Common challenges with setting up WaaS and how to overcome them

While WaaS offers significant benefits for agencies and clients alike, setting up this model comes with its own set of challenges. Anticipating and addressing these obstacles can help you build a WaaS service that’s both scalable and efficient.

Let’s review some common challenges and tips on how to overcome them:

• Client education: Some clients may be unfamiliar with the subscription-based nature of WaaS or may initially question the value of ongoing payments for their website. To address this, clearly communicate the benefits of WaaS, like regular updates, security monitoring, and support that keeps their site performing at its best. Highlight how WaaS saves them from large, unpredictable maintenance costs and ensures they’re always getting the latest features and protections.
• Scalability concerns: Managing multiple client sites is complex, especially as your agency grows. To keep everything running smoothly, use a managed hosting provider like Kinsta, which offers management, automated updates, and a dashboard that consolidates key metrics for all client sites. Plus, features like one-click staging and site cloning help agencies streamline operations and ensure scaling up doesn’t mean adding complexity.
• Pricing strategy: Setting the right price point for a WaaS offering can be tricky. You need to balance value for clients with sustainable profit margins. Research your target market and consider offering tiered pricing to accommodate different budgets. Displaying transparent pricing and value-based explanations help clients see why a monthly or annual subscription is worthwhile.

Preparing for these common challenges helps agencies create a WaaS model that’s attractive to clients and sustainable for the business.

Summary

Website as a Service (WaaS) offers agencies a powerful way to build a scalable, recurring revenue model. With it, they can deliver professionally managed websites through a subscription-based approach.

With WaaS, clients enjoy an affordable, all-in-one solution that combines hosting, maintenance, and support, making it easier for them to maintain a strong online presence without large upfront costs. For agencies, WaaS provides predictable income, scalable operations, and greater client retention.

Should you decide to pursue WaaS in your agency, Managed WordPress Hosting from Kinsta simplifies site management, automates updates and security checks, and offers high-performance hosting features like staging environments and site cloning. With Kinsta, your agency can deliver WaaS with confidence.

The post How agencies can deliver on Website as a Service (WaaS) appeared first on Kinsta®.

To use WP-CLI effectively, it’s essential to understand key components of WordPress: the Admin interface, the file structure, and the database. Without this foundational knowledge, WP-CLI may not be as efficient or beneficial.

While WP-CLI supports standard commands like installing, updating, activating, deactivating, and deleting plugins or themes, its capabilities extend well beyond what’s available in the WordPress Admin dashboard, making it a highly versatile tool for advanced site management.

This article explains how to use WP-CLI to manage WordPress Multisite networks efficiently and provides practical examples to help you get started.

What is WP CLI and why use it?

WP-CLI is a powerful tool for managing WordPress sites via the command line. In a multisite environment, it can significantly simplify the management of a network, enabling you to perform bulk actions and streamline your workflow.

Its true strength lies in its flexibility and extensibility — you can effortlessly execute commands across the entire network or target specific sites while also enhancing its functionality with a variety of WP-CLI packages available on GitHub and other repositories.

Developers often create custom WP-CLI commands to simplify repetitive tasks. For example, you can use WP-CLI to scaffold boilerplate code for themes and plugins, saving time and effort during development.

If you’re hosting with Kinsta, WP-CLI is built-in and accessible via SSH, allowing you to manage WordPress sites effortlessly. For local development, WP-CLI is available in DevKinsta through the devkinsta_fpm container. Once inside the container, you can navigate to your site folder and run commands. While this requires a bit of setup, it provides a powerful way to manage your local WordPress sites efficiently for debugging, testing, or deploying.

Before you begin

The commands highlighted in this article are carefully chosen for their frequent use by WordPress Multisite developers and administrators.

WP-CLI is a broad and flexible tool, making it impossible to cover every available command. To keep things clear and practical, we’ve focused on simple, actionable examples to help you get started.

Since WP-CLI is based on Unix commands, you might not find a WP-CLI equivalent for commands that already exist in Unix.

Key notes about WP-CLI

WP-CLI’s command structure is flexible, allowing multiple ways to achieve the same outcome. For instance, both of the following examples are valid:

wp user create johndoe johndoe@example.com --display_name="John Doe" --nickname="Johnny"

Or:

wp user create johndoe --display_name="John Doe" johndoe@example.com --nickname="Johnny"

The order of flags, parameters, and values doesn’t matter once the command and subcommand are stated.

Best practices for running WP-CLI commands

Follow these best practices to avoid potential issues:

• Always have a current backup available, especially as some of these commands will permanently alter your site(s).
• Use a staging site wherever possible. If you’re using Kinsta, each WordPress install includes a free staging environment for safe testing. You can easily push changes between staging and live environments.
• Use the --dry-run flag to test database changes before applying them.

Essential WP-CLI commands for WordPress Multisite management

WP-CLI commands in a Multisite network can target different levels of action:

• Network-wide: Commands applied across all sites in the network. For example:

  wp plugin deactivate --network --all

  This command deactivates all plugins across every site in the network.

• Primary site: Commands applied to the main site created during the Multisite setup. For example:

  wp plugin list

  The command above lists all plugins installed on the primary site only.

• Secondary sites: Commands targeting individual sites within the network, specified by their URLs. For example:

  wp plugin update --url=mysite.example.com akismet

  This command updates the akismet plugin on the site mysite.example.com.

To make managing your Multisite network easier, we’ve grouped WP-CLI commands into these sections:

Basic commands

These fundamental commands help with troubleshooting and managing plugins and themes across your network.

Working with lists

WP-CLI makes it easy to retrieve lists of plugins and other components in your Multisite environment.

1. Get a list of all plugins in the network:

   wp plugin list --network

   Output: Displays all network-installed plugins with details like name, status, updates available, and version.

2. Filter plugins by status (e.g., active):

   wp plugin list --network --status=active

   Output: A table of active plugins across the network.

3. Get a list of plugins from the primary site:

   wp plugin list

   Output: A list of plugins for the primary site.

4. Get a list of active plugins for a single site:

   wp plugin list --url=<site-url> --status=active

   Input example:

   wp plugin list --url=blog.example.com --status=active

   Output: A table of active plugins for the site blog.example.com.

In addition to filtering plugins by status=active, you can also use the following filters:

• inactive: Plugins that are installed but not active.
• active-network: Plugins active across the network.
• must-use: Must-use plugins that load automatically.

Deactivate plugins

Deactivating plugins is often necessary when troubleshooting issues or preparing for updates. WP-CLI allows you to deactivate plugins across the network or for specific sites.

1. Deactivate all plugins across the network:

   wp plugin deactivate --network --all

   Result: All plugins in the network are deactivated.

2. Deactivate specific plugins for a single site:

   wp plugin deactivate <plugin-slug-1> <plugin-slug-2> --url=<site-url>

   Input example:

   wp plugin deactivate akismet hello-dolly --url=blog.example.com

   Result: The plugins akismet and hello-dolly are deactivated for the site blog.example.com.

Activate plugins

Use these commands to activate plugins either network-wide or for individual sites in your Multisite setup.

1. Activate all plugins across the network:

   wp plugin activate --network --all

   Result: All plugins in the network are activated.

2. Activate specific plugins for a single site:

   wp plugin activate <plugin-slug-1> <plugin-slug-2> --url=<site-url>

   Input example:

   wp plugin activate akismet hello-dolly --url=blog.example.com

   Result: The plugins akismet and hello-dolly are activated for the site blog.example.com.

Install plugins

Installing plugins with WP-CLI is quick and efficient. Once installed, plugins can be activated for individual sites or across the network.

The following command can be used to install a plugin for the network:

wp plugin install <plugin-slug>

Input example:

wp plugin install akismet

Result: The plugin akismet is installed and ready for activation.

Update plugins

Keep your plugins up-to-date across your network or for specific sites using these commands.

1. Update all plugins across the network:

   wp plugin update --network --all

   Result: All plugins in the network are updated.

2. Update specific plugins across the network:

   wp plugin update <plugin-slug-1> <plugin-slug-2> --network

   Input example:

   wp plugin update akismet jetpack bbpress --network

   Result: The plugins akismet, jetpack, and bbpress are updated across the network.

3. Update a plugin for a single site:

   wp plugin update --url=<site-url> <plugin-slug>

   Input example:

   wp plugin update --url=blog.example.com hello-dolly

   Result: The plugin hello-dolly is updated for the site blog.example.com.

Delete plugins

Removing plugins is straightforward with WP-CLI, whether you’re working on a single site or a Multisite network.

1. Delete a plugin from the current WordPress context (network or site):

   wp plugin delete <plugin-slug>

   Input example:

   wp plugin delete bbpress

   Result: The plugin bbpress is deleted.

2. Delete a plugin for a specific site in a Multisite:

   wp plugin delete <plugin-slug> --url=<site-url>

   Input example:

   wp plugin delete bbpress --url=blog.example.com

   Result: The plugin bbpress is deleted from the site blog.example.com.

Network management

Managing sites within a WordPress Multisite network is a crucial task. Below are common WP-CLI commands to help you efficiently create, manage, and delete sites, as well as handle caching operations.

Creating sites

Adding new sites to your network is straightforward with WP-CLI.

• Basic command: Create a new site by specifying a unique slug.

  wp site create --slug=<site-name>

  Input example:

  wp site create --slug=blog

  Result: A new site blog.example.com or example.com/blog, depending on your network setup is created and is automatically active.

• Advanced command: Alternatively, flags can be appended to the command. In the example below, a site is added with a specified site title and site administrator.

  wp site create --slug=<site-name> --title="<site-title>" --email=<admin-email>

  Input example:

  wp site create --slug=blog --title="Blog Site" --email=admin@blog.com

  Result: A site titled “Blog Site” is created with admin@blog.com as the administrator.

• List all sites: Retrieve a table displaying site IDs, URLs, creation dates, and last updated dates:

  wp site list

  You can also refine the site list to get only the URLs of all sites in the network:

  wp site list --field=url

  Output: A list of URLs for each site.

Emptying and deleting sites

1. Empty the primary site:

   wp site empty

   Output: A confirmation prompt appears to delete all content for the primary site.

2. Empty a single site (removes all posts, pages, links, and taxonomies):

   wp site empty --url=<site-url>

   Input example:

   wp site empty --url=blog.example.com

   Result: All content from blog.example.com is deleted, but the site remains intact.

3. Empty all sites in the network:

   wp site list --field=url | xargs -n1 -I % wp site empty --url=% --yes

   Result: This command initiates a loop through all URLs and then proceeds to empty each site’s contents without the need to provide approval for each site.

4. Delete a single site by ID:

   wp site delete <site-id>

   Input example:

   wp site delete 5

   Result: Site with ID 5 is deleted.

5. Delete multiple sites with confirmation bypass:

   wp site delete 2 --yes
   wp site delete 3 --yes

   Result: Sites with IDs 2 and 3 are deleted. The --yes flag helps to skip prompts.

Clearing cache

Because many cache types are stored in different ways here, we use the Kinsta Must-Use plugin. It is installed automatically for each WordPress site in our system.

This clears all cache, including site cache, edge cache, CDN cache, and Redis cache.

1. Clear all cache (site, edge, CDN, and Redis):

   wp kinsta cache purge --all

2. Clear only site cache:

   wp kinsta cache purge --site

3. Purge CDN cache:

   wp kinsta cache purge --cdn

4. Clear object cache:

   wp cache purge

User management

WP-CLI simplifies managing users in a Multisite environment, allowing you to perform tasks quickly and efficiently. This section covers common user management operations:

List users

Listing users in a network or a specific site is straightforward with WP-CLI.

1. List all users in the network:

   wp user list --network

   Output: A table showing User ID, Login, Display Name, Username, Registration Date, and Role for each user or user list query.

2. List users for the primary site:

   wp user list

   Result: Displays a table of users for the primary site.

3. List users for a specific site (secondary site):

   wp user list --blog_id=<id>
   wp user list --url=<url>

   Input example:

   wp user list --blog_id=6

   Result: Displays a table of all users for the site with Blog ID 6.

Create users

In a Multisite network, users are registered to the network by default. Their roles depend on whether they are the first user added to a site or subsequent users. Usernames must be at least four characters long.

1. Add a new user to the primary site:

   wp user create <username> <email>

   Input example:

   wp user create johndoe johndoe@example.com

   Output: A success message is displayed, including a generated password.

2. Add a new user to a specific site with a specified role:

   wp user create <username> <email> --role=<role> --url=<url>

   Input example:

   wp user create janedoe janedoe@example.com --role=editor --url=blog.example.com

   Output: The user janedoe is added to the site blog.example.com as an “Editor”.

3. Add user account meta during creation:

   wp user create <username> <email> --display_name=<name> --nickname=<nickname>

   Input example:

   wp user create johndoe johndoe@example.com --display_name="John Doe" --nickname="Johnny"

   Result: User johndoe is created with a display name John Doe and nickname Johnny.

Update user

Updating user information, such as roles or passwords, is quick with WP-CLI.

1. Change (promote or downgrade) user roles:

   wp user update <username|email|user_id> --role=<role>

   Input example:

   wp user update johndoe janedoe adminuser --role=super-administrator

   Result: Users johndoe, janedoe, and adminuser are promoted to Super Administrators.

2. Reset or change a user password:

   wp user update <username> --user_pass=<new_password>

   Input example:

   wp user update johndoe --user_pass=securePassword2024

   Result: The password for johndoe is updated.

3. Daisy-chained commands: WP-CLI allows you to combine multiple actions in a single command, saving time when editing users. For example, you can simultaneously update a user’s password and role.

   wp user update <user> --user_pass=<new_password> --role=<status>

   Input example:

   wp user update johndoe --user_pass="newPassword2024" --role=editor

   Result: The password for user johndoe is updated to newPassword2024, and their role is changed to “Editor”.

Manage user meta

User meta allows you to add, retrieve, or delete metadata for user accounts.

1. Get user meta:

   wp user meta get <username> <meta_key>

   Input example:

   wp user meta get johndoe nickname

   Output: Displays the value of the nickname meta key for user johndoe.

2. Add user meta:

   wp user meta add <username> <meta_key> <meta_value>

   Input example:

   wp user meta add johndoe display_name "Mr. John Doe"

   Result: Mr. John Doe is set as the display name for user johndoe.

3. Delete user meta:

   wp user meta delete <username> <meta_key>

   Input example:

   wp user meta delete johndoe display_name

   Result: This command deletes the display_name meta key for the user johndoe.

Delete users

Removing users from the network or specific sites is efficient with WP-CLI.

1. Delete a user from the network:

   wp user delete <username|user_id> --network

   Input example:

   wp user delete johndoe --network

   Result: The user johndoe is removed from the network.

2. Delete a user from a specific site:

   wp user delete <username|user_id> --url=<site-url>

   Input example:

   wp user delete johndoe --url=mysite.example.com

   Result: The user johndoe is removed from the site mysite.example.com.

Database management

WP-CLI provides a powerful alternative to tools like phpMyAdmin for managing your database. This section covers common database operations you can perform using WP-CLI:

Exporting a database

With WP-CLI, you can export your database as an SQL file. The exported file is saved in the root directory of your WordPress installation.

wp db export

Result: An SQL file is created in the root directory.

If the exported file has an ungainly name, you can rename it using the following command:

wp eval 'if ( rename( "unganglyfilename.sql", "newfilename.sql" ) ) { echo "File renamed successfully."; } else { echo "Failed to rename file."; }'

Input example:

wp eval 'if ( rename( "cilawawugo4504_gTr4kSXUsmJ9FNauVnPb-2024-11-17-9545b3f.sql", "network-db.sql" ) ) { echo "File renamed successfully."; } else { echo "Failed to rename file."; }'

Result: File cilawaw…nPb--9545b3f.sql is renamed to network-db.sql.

Downloading a database

To download the exported database file to your local machine, use the curl command.

curl <remote-url> -o <local-path>

Input example:

curl example.com/network-db.sql -o ~/Downloads/network-db.sql

Result: The file network-db.sql is downloaded to your local Downloads directory.

Uploading a database

You can upload a database file to the root directory of your Multisite installation using the scp command.

scp <local-path-to-file> <username>@<remote-server>:<remote-path>

Input example:

scp ~/Downloads/network-db.sql admin@example.com:/var/www/example.com/public_html

Result: The file network-db.sql is uploaded to the root directory of your WordPress installation after authentication.

Importing a database

Before importing a database, you may need to reset your existing data tables.

1. Reset data tables:

   wp db reset

   Result: All data tables in the database are emptied.

2. Import the database:

   wp db import <file-name.sql>

   Input example:

   wp db import network-db.sql

   Result: The file network-db.sql populates the emptied data tables.

3. Delete the imported SQL file:For security purposes, delete the SQL file after importing:

   rm <file-name.sql>

Practical examples

We can think of many commands that will speed and simplify your workflow. Here are three examples.  While some of these commands are more complex, they build upon simpler commands to carry out useful operations.

Install and activate plugins and regenerate thumbnails simultaneously.

This command loops through all sites in the network, installs and activates two plugins, and regenerates image thumbnails for each site.

wp site list --field=url | xargs -n1 -I % sh -c 'wp plugin activate <plugin slug> <plugin slug> --url=% && wp media regenerate --url=%'

Input example:

wp site list --field=url | xargs -n1 -I % sh -c 'wp plugin install akismet bbpress --activate --url=% && wp media regenerate --url=%'

Result: The plugins Akismet and BBPress are installed and activated across all sites, and image thumbnails are regenerated.

Adding a custom meta field for all users

This command loops through all sites, retrieves the list of users, and adds a custom meta field for each user.

wp site list --field=url | xargs -n1 -I % sh -c 'wp user list --fields=ID --url=% --format=csv | tail -n +2 | xargs -n1 -I {} wp user meta add {} <meta-key> <meta-value> --url=%'

Input example:

wp site list --field=url | xargs -n1 -I % sh -c 'wp user list --fields=ID --url=% --format=csv | tail -n +2 | xargs -n1 -I {} wp user meta add {} favorite_color "" --url=%'

Result: A custom meta field, favorite_color, is added for all users across all sites.

To surface the favorite_color field, you’ll need to use your functions.php file or create a custom plugin.

Converting a single site install to a multisite

WP-CLI makes it easy to convert a standalone WordPress site into a Multisite network.

wp core multisite-convert

Result: The single site is converted into a Multisite network.

Before conversion, make sure to deactivate all plugins.

After converting the site, you need to configure the network URLs in the wp-config.php file. You can choose between using subdomains (e.g., site.example.com) or subdirectories (e.g., example.com/site). Additionally, check the .htaccess file, as the URL rewrite rules (handled by the mod_rewrite module in Apache) may require manual updates to ensure your permalinks and site structure work correctly.

Summary

This guide highlights the power and flexibility of WP-CLI for managing WordPress Multisite environments, making it an essential tool for developers and administrators seeking efficiency and control. From handling plugins, users, and databases to performing advanced operations like converting single sites to Multisite, WP-CLI simplifies complex tasks with precision and speed.

Kinsta offers an invaluable and extensible WP-CLI tool that enables seamless management of WordPress Multisite networks. Whether you’re working on live or staging environments or using our local development tool, DevKinsta, WP-CLI is readily available to streamline your workflow.

Start creating sites, adding plugins, users, and more with WP CLI!

The post Working with WP CLI for WordPress Multisite appeared first on Kinsta®.

That function — wp_is_mobile() — appeared at a time when the celebrated “Retina Display” Apple had unveiled for its iPhone 4 was a meager 640 x 960 pixels. When the iPhone 5 arrived a few months after WordPress 3.4, the phone’s display reached 640 x 1,136 pixels — still a long way from the displays of modern smartphones and tablets, which blur the lines between mobile and desktop screen real estate.

So, is wp_is_mobile() of any use today?

The purpose of the wp_is_mobile() function

In 2012, browser support for CSS media queries enabling responsive web design was still relatively new. (Really new for users of Microsoft’s Internet Explorer browser!) But enabling page layouts that adapt to varying viewport dimensions wasn’t the goal of wp_is_mobile().

The function makes no distinction between phones and tablets and is completely unaware of the available pixels in a visitor’s browser. Instead, wp_is_mobile() was conceived as a tool that would allow developers to optimize bandwidth when responding to mobile devices that were often underpowered and possibly in the hands of users who were paying their telecom providers for data transfers.

With phones and tablets today more powerful than many desktops available in 2012, throttling bandwidth may be less important, but there are still use cases for a function that simply divides the world in two: mobile devices and everything else.

The wp_is_mobile() function in action

The WordPress wp_is_mobile() function returns true when executed as the result of a request from browsers in most smartphones and tablets (including the Kindle). So, the classic example of the function generating different content streams in PHP looks like this:

<?php if( wp_is_mobile()){ ?>

    <p>This content is for mobile devices</p>

<?php } else { ?>

    <p>This content is for desktops (and laptops).</p>

<?php } ?>

If you really do need to optimize your website’s output for mobile devices (probably to minimize bandwidth requirements), the technique above could be used in theme files to output entirely different structures for mobile and desktop pages.

Device detection for granular content adjustments

CSS media queries and other techniques supporting responsive web design can help page layouts adapt to a wide variety of screen sizes and orientations. But they can’t help you communicate with your site’s visitors as mobile or desktop users.

For example, you know that desktop users will probably be using a mouse to “click” on elements of your site, while mobile users will “tap.” Desktop users might “right-click” on a link to begin opening the link in a new browser window. Meanwhile, mobile users might “press and hold” to start the same task. Just communicating with users about how to navigate your website (like in your help documentation) could mean you are using the wrong terminology half the time.

Here’s how we can combine wp_is_mobile() and WordPress shortcodes to support granular output of mobile or desktop content in a way that’s also easy for website editors to command.

We’ll use our mobile/desktop detection in conjunction with the WordPress add_shortcode() and do_shortocde() functions to create shortcode tools editors can apply in posts.

First, we’ll add this code to our theme’s functions.php file (after protecting it by creating a child theme):

/**
 * Add shortcodes
 */

// Create [desktop] shortcode
add_shortcode('desktop', 'show_desktop_content');
function show_desktop_content($atts, $content = null){
    if( !wp_is_mobile() ){
        return do_shortcode( $content );
    } else {
        return null;
    }
}

// Create [mobile] shortcode
add_shortcode('mobile', 'show_mobile_content');
function show_mobile_content($atts, $content = null){
    if( wp_is_mobile() ){
        return do_shortcode( $content );
    } else {
        return null;
    }
}

That creates the [desktop] and [mobile] shortcodes (and their closing tags) that we can use in any post or page content like this:

<h2>Password Help</h2>

To change your password, [desktop]click[/desktop][mobile]tap[/mobile] the cog icon.

On a mobile device, the content above will appear like this:

On all other devices, visitors will see this:

This technique makes it fairly easy to deliver content that is “aware” of how visitors interact with your WordPress site.

The wp_is_mobile() function and WordPress caching

You don’t need to have been using WordPress since 2012 to know that page caching is one of the most effective ways to improve performance. But basic WordPress caching can throw a monkey wrench into attempts to deliver differing content on requests for the same page.

A WordPress cache of an individual page is initiated by a client request. If that first request comes from a mobile device, the cached content will be tailored for mobile users if modified by wp_is_mobile(). And every subsequent request for that page will deliver mobile content — even to desktop users — until the cache is cleared.

That’s why Kinsta’s Managed WordPress Hosting platform supports separate caches for mobile and desktop content — starting with the local cache of your NGINX web server and extending to Kinsta’s Edge Cache in 260+ Cloudflare PoPs around the world.

Enabling the caching of pages for mobile devices is accomplished with just a couple of clicks (or taps!) in the MyKinsta dashboard:

Summary

The WordPress function wp_is_mobile() may seem like a blast from the past, but you might find uses for its “mobile-or-desktop” detection that can help you create a better experience for all visitors to your website.

Don’t forget that you’ll need separate caches for the different content you generate if you want to get the best performance out of these mobile and desktop pathways.

Do you have a great idea for taking advantage of wp_is_mobile()? Let us know in the comment below.

The post The WordPress wp_is_mobile() function: is it still useful? appeared first on Kinsta®.