Client Portal was built to sit alongside the tools you already use. Keep your project management tool, keep your accounting software, and let the portal be the bit your clients see. (More on that in why I don't recommend all-in-one tools for freelancers.)

Files are a good test of that idea. If you already keep everything neatly organized in Google Drive or Dropbox, with a folder per client and a system you mostly stick to, you probably don't want to rebuild it in WordPress just so clients can see it in their portal.

Client Portal doesn't have a built-in way to embed those folders. So we tried a WordPress plugin that does, Use-your-Drive from WP Cloud Plugins. We're not affiliated with them, but it works really well with Client Portal.

What we tested

WP Cloud Plugins makes one plugin per storage service: Use-your-Drive for Google Drive, Out-of-the-Box for Dropbox, Share-one-Drive for OneDrive and SharePoint, and Lets-Box for Box. They all work the same way. We tried the Google Drive one.

Setup was quick. You install the plugin, connect your Google account, and choose how much of your Drive the plugin can reach:

• a dedicated folder the plugin creates for itself
• your whole Google Drive (what we used)
• your whole Google Drive, read-only
• full access

There are plenty of privacy and security settings beyond that too, so the plugin only gets access to what you actually want to share.

How it looks in a portal

This is the part that felt easiest. Open a content page in Client Portal, add the WP Cloud Plugin block, pick a module, and point it at a folder. That's it.

You set up each module to show only the folders and files you choose, so one connected Drive account can serve every client. And because the files stay in Drive, anything you change there shows up in the portal automatically. No re-uploading, and no out-of-date copy.

Which module you pick depends on what the client needs to do with the files. There's a file browser for a whole folder, an embed for a single Google Doc or Sheet, a gallery for images, and an upload box if you want clients to send files to you. A designer might embed the project brief, show brand assets as a gallery, and add a file browser for deliverables, all on one content page.

The full setup instructions are in our help doc if you want the step-by-step version.

Built-in files or an embed

Client Portal's own file modules are still the better fit for some projects. The difference comes down to where you want the files to live.

Before you buy

The embedded files don't get Client Portal's Private Files protection. The content page itself is still behind the portal login, but the plugin and Google (or Dropbox, and so on) serve the files themselves, using the plugin's own access settings. For anything sensitive, set those settings carefully and check your sharing settings in Drive as well. Or use the portal's own file modules for that project instead.

It's also a separate paid plugin, so it's one more license to keep renewed. And if you only need a single Google Doc, you don't need it at all. An iframe embed of a published copy works fine, and there's a help doc for that too.

The embed is for people who already have a good system in Google Drive or Dropbox and would rather keep it than switch to something new.

If you're not using cloud storage for your files, or you'd rather use Client Portal's built-in files but want to update a file once and have it change in every portal, there's a way to do that too. You can share files, Private Files included, across several portals with synced patterns. Update the pattern once and every portal using it updates.

There are lots of what I call "kitchen sink" tools on the market at the moment, all promising to run your whole business. Since AI arrived, more seem to appear every day. They promise you the world: proposals, contracts, invoicing, forms, scheduling, projects and client portals, all for one monthly price that's usually low, at least to begin with.

I understand the appeal. We're all looking for ways to streamline how we work, and we all want to look more professional to our clients. Something that does everything seems like the sensible option. But for most freelancers and small agencies, I think it's the wrong decision, and it can leave you in a bit of a tangle.

The real cost is leaving

The problem with these tools is that things will change. Prices go up, sometimes steeply. The company gets bought and heads in a direction that no longer suits you. Features you rely on get moved to a higher plan.

At that point you have two choices. You move everything somewhere else, which takes time and money, or you stay and keep paying for a product that no longer fits.

That's why so many of these tools are cheap to get into. Getting in isn't where they make their money.

Your unicorn tool doesn't exist

The other problem is that it's very unlikely one tool will suit your needs perfectly. Every business is different. You might need a form tool that does one thing, and someone else might need something completely different. Generally, the more a tool tries to do, the more mediocre it gets at each job.

Building your own stack of dedicated tools takes more time at the start, and it might cost a little more. But you get a workflow that suits you, and you're far less likely to end up tied to a product that becomes unusable or too expensive.

But how do your clients cope with all those tools?

If you're thinking your clients won't want to dig through five different tools to find an invoice, you're right.

That's the problem I built Client Portal to solve. It sits on your own WordPress site and brings the tools you already use into one branded place. You don't have to compromise on your tools, and you're not locked into anything.

Because it runs on your site, the content lives with you, not on our servers.

I think tools should be hard to leave because they're good, not because you're trapped in them. That's the standard I hold Client Portal to.

The template gallery was a big project, so I wanted to use this release to get lots of small but important requests into the product. When I use software myself, it's often the smaller changes that make the biggest difference to my workflow. Hopefully there's something in here that's been on your wish list.

I've recorded a quick video going through the main changes, and they're outlined below too.

A new Text & Media module

A few people who like the lightbox design on modules like URLs, files, and the image slider asked for a module for simple content: formatted text, images, maybe a video embed. Content pages already handle longer content, but they're a lot for a short note.

I thought that was a great idea, and it was pretty easy to do, so we built it. The Text & Media module takes formatted text, images, and YouTube or Vimeo videos, and clients see it in a lightbox without leaving the portal dashboard. You can set it to Standard, Wide, or Full width.

A built-in registration page

Client Portal comes with a login page and a portal archive page, plus Login and Register blocks you can put on your own pages. What it hasn't had until now is a built-in registration page, and that's been requested on and off for a while.

It's here now. Use the built-in page, which matches your login page and portals, or keep using the block on your own page. The new page is created as a draft, so nothing changes on your site until you publish it.

The login page has had a refresh too, so the two match.

An editable "Your portals" page

When a client has more than one portal, they see an archive page listing all of them. Until now you couldn't change anything on it.

Now you can add some introduction text, change the title, and set the order each client sees their portals in. The title and text can use {first_name}, {last_name}, or {organization}, and the order is set from each client's user profile. Editing the page needs the Five design.

Single links that open in a lightbox

If a Links module has several URLs, they open in a lightbox. If it has just one, it opens the web page straight away. Now you can choose either behavior, as a default in Settings or per module.

A redesigned file block

When you insert a file into a content page, it now matches the rest of the portal.

The Classic editor is retiring next year

This one is for people who've been with Client Portal for a long time. If you bought after April 2024, it probably won't apply to you.

We're officially retiring the Classic editor next year. I've written a separate post with all the details.

The big thing we wanted in this release was a migration tool, so you can now move your Classic portals and templates to the block editor quickly. Make a block editor copy, check it, then move your clients over. They don't get any emails, their portal link stays the same, and you can move them back if you need to.

You've got plenty of time, and we'll send reminders before support ends. A notice on your dashboard shows how many Classic portals and templates you have left.

I know a lot of you have been keen to try the block editor version of Client Portal with your existing portals, so I'd love to hear how you get on.

Other improvements

• Clients who are already logged in and land on the registration page are told they already have a portal, with a link to it
• Draft portals no longer count at login, so a client with one published portal goes straight to it
• The All Projects page uses the Five design on Five sites
• The header logo loads with the page instead of appearing a moment later
• Lightboxes have more space around tall content on desktop and narrower padding on phones
• Pages that make several background requests at once, such as embedded file browsers, load faster
• New client-facing text is translated in all included languages
• Various security improvements

What's next for Client Portal

We're continuing to work on foundational improvements, and the next release is about making Client Portal easier to live with once you have a lot of portals and a lot of clients.

1. Backend organization. You'll be able to add users to a company, group portals by company, and filter content pages. Lists that work fine at ten items and less well at a hundred are the main target.
2. Performance at scale. Making sure sites with lots of portals and clients stay fast as you grow.

Further out, this is groundwork for things like an API, webhooks, and MCP, so Client Portal can talk to the other tools you use (AI assistants included). No dates yet. If that's something you'd use, I'd like to hear what for.

You can see what's coming, and add your own requests, on the roadmap.

Client Portal has two ways to build a portal, and we're retiring one of them in 2027.

The Classic editor is the original portal builder. You add phases and modules through settings screens, and you only see what the client sees when you preview the portal.

The block editor is what Client Portal moved to in 2024. It's built on the WordPress block editor, so phases and modules are blocks you add and arrange on the page, and what you're editing looks like the portal your client will see.

This is about Client Portal's own editor, not WordPress's. If you use the Classic Editor plugin for the rest of your site, you can keep doing that. Here's how to use the Classic editor for WordPress and the block editor for Client Portal.

If you bought Client Portal after April 2024, this probably won't be relevant to you unless you've switched to the Classic editor. If your portals are already in the block editor, nothing changes for you.

If you bought before that, you may still have portals built in the Classic editor. There's now a tool to move them across, and the rest of this post covers why we're retiring it, when, and what you need to do.

Check whether this affects you

Go to Client Portal > Portals in your WordPress admin and look at the Editor column. If you don't see "Classic" anywhere in the list, you have no Classic portals and there's nothing to do.

You'll also see a notice on your dashboard if you have any Classic portals or templates left, with a count of how many.

Why we're retiring it

Client Portal moved to the block editor in 2024, and every new feature since has been built for it. Keeping the Classic editor running alongside means maintaining two versions of the same product, and in practice the Classic one has been standing still while the block editor moves on.

Retiring it means we can stop splitting our time and put all of it into the version you'll actually be using.

What you get in the block editor

If you've been on Classic for a while, a fair amount has happened without you. A few of the things you'll have once you've moved:

• Comments and notifications on content pages
• Pattern syncing, so you can update a section once and have it change across several portals
• The portal gallery, with ready-made templates you can import in a click
• The new Text & Media module, plus link lightboxes and custom module icons
• The Five design, including the editable "Client Portal Archive" page

The timeline

So nothing breaks on a particular date. Your portals keep working the whole way through, and if you do nothing at all, they'll be converted for you in April. Moving them yourself before then just means you get to check each one first.

I'll send reminders between now and then, so it won't sneak up on you.

How moving a portal works

You move one portal at a time, so there's no big switchover day.

1. Convert the portal. This makes a block editor copy, and your clients keep seeing the Classic version.
2. Check the copy and fix anything that didn't carry over the way you'd like. You can preview the Classic version to compare.
3. Move your clients over. They see the new version at the same link, and nobody gets an email.

The Classic version stays as a backup until you delete it, and you can move clients back to it if something isn't right. Templates work the same way, so new portals created from your registration form or WooCommerce products pick up the block version too.

👉 Read the step-by-step guide

Back in version 5.8 I said we were going to build a proper template library inside Client Portal, so you wouldn't have to download a file from our website and import it by hand. It's now been released.

From version 5.10+ creating a portal happens on a new screen, with your own templates and a gallery of ready-made ones both sitting on it. (Have a look at this page to see the templates included in the gallery. We have the first six on the page available now, with more coming soon.)

New ways to create portals faster than ever

Now we have three ways to start a portal, all in one place.

✏️ Start from scratch is unchanged. Blank portal, build it however you like.

⭐️ My templates shows the templates you've made from your own portals, with the date you last edited each one and an option to favorite templates to have them appear at the top.

🖼️ Portal gallery showcases are pre-made templates that you can import in one click.

Check out this video walkthrough to see how it works:

All about the portal gallery

These are finished portals we've built (not starting points). Phases, modules, and copy already written, so an imported one is ready to send to a client or ready for you to edit into whatever you need.

Each has a preview link that opens the portal in a new tab, exactly as a client would see it. Have a look to see if this is what you need, and then import it in one click.

There are six in the gallery to start with.

Want a template that isn't in there? Email us and tell me what you'd use. I'm building them in the order people ask for them, so it genuinely counts as a vote.

Other fixes and improvements

• New notifications:

  • Clients will now be notified when you upload a new file.
  • You can set a custom notification to go out when you update a content page.
• Custom module icons: upload your own icon image for any module in the block editor
• A banner in the editor reminds you when you are editing a template rather than a portal, with a link explaining how templates and syncing work
• Client Uploads modules are no longer shown on public portals, where nobody can upload
• Text placed below an image slider now has proper spacing in the popup
• The Users screen loads faster on sites with many users
• Fixed the Register block's portal and template dropdowns hiding items beyond the first 10
• Fixed deleting a WordPress user leaving a ghost client on their portals, which could hide other clients in the editor and affect their login redirect
• Fixed bundled icons occasionally interfering with other scripts on the page

What's next for Client Portal

We're carrying on with the same job, which is making Client Portal easier to use as you accumulate more portals and more clients. Three things in particular.

1. More templates. The gallery is the sort of thing that gets better the longer it exists. We'll be consistently adding more and more templates we'll be consistently adding more and more templates
2. Backend organization. Portals, content pages, and templates all live in lists that work fine at ten items and less well at a hundred. That needs sorting, and it's the next substantial piece of work.
3. A migration tool for classic editor portals. If you've been with us a long time, you may still have portals built in the classic editor. We're building a tool to move them across to the block editor properly. If you bought within the last year or so this won't apply to you, but for our longest-standing customers it's overdue.

You can keep an eye on what's coming, and add your own requests, via the roadmap.

If you've set up Client Portal and then stalled on what to actually put in it, build a client onboarding portal first.

It's the portal every client needs, it barely changes between them, and it's the only part of your process that isn't tied to a specific piece of work. It's also the easiest to get right, which matters when you're staring at an empty portal trying to decide how much of the client relationship belongs in it. We've built one as an example, and there's a link to it further down so you can click through the whole thing.

Why should an onboarding portal be separate?

Most people doing client work have some shape to what they sell. Often it's a core service with a few optional extras attached, or three or four distinct services, some productized and some custom, priced however you price them.

Whatever that shape is, onboarding sits outside it. It isn't a service you sell. It's the thing that happens before any of them start, and it runs the same way regardless of which one the client ends up buying.

Onboarding happens once, everything else repeats

Every client goes through onboarding, and for most agencies the content of it barely changes between them. Same contract process, same questionnaire, same request for brand assets, same explanation of how you work and how quickly you reply to things.

Then it's done. The client moves on to whatever they bought, and if they come back next year for a second project, they don't get onboarded again. You already know how they like to work and you already have their logo files, so they just start a new project.

That's what makes onboarding awkward inside a project portal. It isn't part of the project, it's the thing that got them to the project, and lumping the two together means the piece you built once has to be rebuilt every time you take on new work.

It's small, fixed, and useful to every client you take on

Onboarding is also the easiest portal to build, which is the practical reason to start there rather than anywhere else.

It's more or less identical for every client, so you build it once and duplicate it. Nothing in it is tied to a particular project, so nothing goes out of date when the work changes. And it's the first thing a new client logs into, which happens to be the point where they're forming an opinion about how organized you are.

Starting with a project portal is harder work for less return. You're designing around the specifics of one job and then wondering how much of it will carry over to the next one.

What should you put in a client onboarding portal?

Everything you need from a client before you can start work, and everything they'll want to know about working with you. That's usually a handful of tasks for them to complete and a couple of pages explaining how things run.

Here are some examples of what you could include:

• Welcome and how we work (your process, communication, revisions)
• Contract
• NDA, if you use one
• Questionnaire
• Asset upload
• Kickoff call booking
• Invoices
• Practical resources: Slack, FAQ, the tools you use together
• Service add-ons, like a care plan or a power hour

What doesn't go in it is anything to do with the work itself. No deliverables, no status updates, no review links. Those change constantly and belong wherever the project lives, which might be a separate portal or might be your project management tool.

See an example of an onboarding portal

We've built an onboarding portal as a working example, to give you some idea of what you could include in yours.

👉 Have a look at the client onboarding portal example

Take the parts that fit your process and ignore the rest. A small portal with six modules that you'll keep up to date is more use than a large one that impresses someone once and then goes stale, and most of what's in the example won't apply to you. Plenty of agencies skip the NDA, plenty don't use Slack.

Once you have an onboarding portal, what's next?

Add portals as the work calls for them rather than designing the whole system up front. A portal per project, or one per service if what you sell is productized enough for that to make sense.

Keep them lean. A project portal holds the deliverables, where things are up to, and the files, which is most of what a client opens a portal to find anyway.

When a client comes back for a second project, they get a new project portal and their onboarding portal stays exactly where it is, still holding their contract and their questionnaire answers. Nothing needs rebuilding.

So if you're not sure where to start, start with the portal that's the same for every client. It takes an afternoon, it never goes stale, and it's the one that gets used before anything else exists.

Running a freelance business usually means a patchwork of email threads, Google Drive links and the occasional "did you get my invoice?" message. It works, mostly. But once you're juggling more than a handful of clients, you spend a surprising amount of time just finding things and re-sending them.

A client portal fixes most of that by giving each client one place to log in and find everything: files, project status, feedback, the lot. (If you want the full primer first, we've got one on what a client portal actually is.) The question is which one, because the options range from simple plugins to platforms that want to run your entire business.

Full disclosure before we start: we make one of the tools on this list. We'll try to be fair to the others, but you can probably guess which one we'd pick.

Why bother with a portal at all?

Email and Drive links are fine with two or three clients. With five or ten active projects, the cracks show. Clients can't find the latest version of anything, you can't remember which thread the approval was in, and everyone's slightly more annoyed than they need to be. (There are also good reasons not to lean on email for files in the first place, which we've written about separately.)

A portal gives you three things:

• One place for everything. Files, updates and feedback live together, with a timestamped record of who approved what. Useful for staying organized; occasionally useful for settling disputes.
• A more professional first impression. A branded portal on your own domain looks rather different from a WeTransfer link. If you charge decent rates, the experience around your work is part of what clients are paying for.
• Fewer repetitive emails. "Where's that file?" and "what's the status?" mostly answer themselves.

It's one of those small irritations that builds up over time, and a portal is the bit that removes it.

The contenders at a glance

Client Portal: best if your website runs on WordPress

Yes, this is ours. But there's a reason it exists, and it's the same reason you might pick it.

Most portal platforms are separate products with their own logins, their own subdomains and their own monthly fees that scale as you add clients. Client Portal takes a different approach: it's a WordPress plugin, so your portals live on your website, under your domain and your branding. To clients, it doesn't look like third-party software. It looks like part of your business.

A few things worth knowing:

• Unlimited portals and clients on every license. You're not penalized for growing.
• It works alongside your project management tool, not instead of it. Keep Trello, Asana or whatever makes you happy for the internal chaos. The portal is the tidy, client-facing layer on top. (We've written more about that here.)
• No coding required. If you can use WordPress, you can set up a portal. Modules, colors and branding are all configurable from the admin.
• Files are stored securely, away from the WordPress media library, so client deliverables aren't sitting somewhere guessable.

What it deliberately doesn't do: invoicing, time tracking, contracts or built-in chat. That's intentional. Most freelancers already have tools they like for those jobs, and bundled versions tend to be the weakest part of all-in-one platforms anyway.

And the honest bit: if your website doesn't run on WordPress and you've no plans to change that, Client Portal isn't for you. One of the options below will be a better fit.

HoneyBook and Bonsai: if you want one tool for everything

HoneyBook and Bonsai both aim to run your entire freelance business: proposals, contracts, invoices, scheduling and a client portal, all in one subscription.

HoneyBook leans toward the client experience side. Its automations are genuinely good: a signed contract can trigger a welcome packet, an invoice, the works. Bonsai's strength is the financial end, with expense tracking, tax estimates and accounting reports built in. If tax season fills you with dread, that's a real selling point.

If you genuinely want one login for your whole business and you're happy to run everything the platform's way, these are strong choices. The trade-off is the usual all-in-one one: each individual piece is rarely as good as a dedicated tool, and your contracts, invoices and client history all end up living in the same place. Worth it for plenty of people, as long as you go in with your eyes open.

Trello and Monday.com: great for teams working on client projects

Neither is a client portal, strictly speaking, but both are excellent project management tools, and they really come into their own for agencies and teams. If several people are collaborating on the same client work, a shared board with tasks, owners, timelines and comments keeps everyone moving in the same direction. That's exactly what these tools are built for, and they do it well.

The snag is on the client side. Inviting clients into Trello or Monday means asking them to learn a new tool, and the learning curve is steeper than it looks from the inside. Clients have their own jobs to do, and a board full of tasks and statuses they didn't set up can overwhelm rather than help. More often than not, they take one look, retreat to email, and you're back where you started.

So a common setup is to keep the project management tool internal, for you and your team, and give clients something simpler for the bit they actually need: their files, their deliverables, and where the project's up to. That's a job a portal like Client Portal does well, and it's a question that comes up so often we've covered it in its own right (here, and a follow-up for solo founders).

Assembly (formerly Copilot) and ManyRequests: for productized services

If you sell fixed-scope packages (design subscriptions, content retainers, that sort of thing), Assembly and ManyRequests are built around that model. Clients submit requests, track progress and download deliverables through a white-labeled portal that can sit on a custom domain.

They're proper standalone platforms with pricing to match, and they assume a particular way of working. If productized services are your whole business, that focus is a real strength. That said, plenty of people run productized services perfectly well through Client Portal on their own site, so it's worth weighing all three rather than assuming you need a dedicated platform.

Notion and Google Sites: the free options

You can absolutely rig up a basic portal in Notion with shared pages and comment threads, or with Google Sites and a Drive folder. If you've got three clients and no budget, start there. It's a sensible way to test whether the portal habit sticks before you pay for anything.

The limitations arrive quickly though. No proper branding, clunky permissions, and clients get a "made in Notion" experience rather than a "this freelancer has their act together" one.

The good news is that starting free doesn't mean starting over later. When you're ready to move up to Client Portal, you're moving content you've already organized (files, sections, the structure of each project) into a tidier home. You're not rebuilding from scratch, just giving the same material a more professional front end.

One thing to think about: how easy is it to leave?

This applies to every tool on the list, so it's worth a moment on its own.

When a single platform runs your invoicing, contracts, files, scheduling and client communication, leaving it is a real undertaking. Everything's woven together, which is partly why all-in-one prices tend to creep up over time: the platform knows you're unlikely to move.

A standalone portal sits at the other end of that spectrum. Because it only does the client-facing layer, it slots in alongside whatever else you use and comes out just as cleanly. If your project management tool puts its prices up, you can swap it without touching your portals. If you want to scale your stack back to basics, nothing breaks. It's lower commitment, and lower risk, which is a fair thing to weigh up before you tie your whole business to one login.

What really matters when choosing

It's tempting to compare feature lists, but most portal regret comes down to two questions:

Do you want a portal, or a business platform? All-in-one suites bundle contracts, invoicing and scheduling. That's brilliant if you want to replace five tools with one, and less brilliant if you already have tools you like, because now you're migrating everything or paying twice. A standalone portal slots into your existing setup instead.

Whose brand does the client see? On some platforms, clients log into their product with your logo in the corner. With a portal on your own website, the whole thing is yours. For freelancers charging premium rates, that difference does more work than any individual feature.

Beyond that: check files are stored securely, check you're not charged per client (that gets expensive exactly when things are going well), and check it's simple enough that you'll actually keep it updated. A half-configured platform is worse than no platform.

Getting clients to use it

Picking the tool is half the job. If clients keep emailing you attachments anyway, you've added complexity rather than removed it.

A few things that help:

1. Introduce it as a benefit, not homework. "I've set up a private workspace where you can find all your files and track progress" lands better than "please log into this platform".
2. Put the link where they'll see it. Add a link to the portal on your website and in your email signature, so it's always one click away rather than something they have to go hunting for.
3. Record a two-minute walkthrough video. Show them where files live, how to leave feedback, where to find what they need. Most clients won't read a guide, but they'll watch a short video.
4. Redirect consistently. When someone emails asking for a file, reply with the portal link. After two or three rounds, the habit forms. Clients default to whatever's easiest unless you gently make the portal easiest.

So which one should you pick?

It depends on how you work, which is an annoying answer, so here's a more useful one:

• Your website runs on WordPress: Client Portal. Your portals live on your own site, under your own brand, with unlimited clients, and you're not locked into one platform for everything. We're biased, but over 8,000 people seem to agree with us.
• You want to replace your entire admin stack: HoneyBook or Bonsai (Bonsai if the financial side is your main headache).
• You're an agency or team collaborating on projects: Trello or Monday internally, ideally with a portal on top for the client-facing side.
• You sell productized packages: Assembly, ManyRequests, or Client Portal, depending on whether you want a dedicated request-management platform or a portal on your own site.
• You're not ready to spend anything: Notion or Google Sites, knowing you can move everything into Client Portal later without rebuilding it.

Whichever you choose, the freelancers who get real value from a portal are the ones who route everything through it. Pick the one that fits how you already work, because that's the one you'll actually use.

A question we get fairly often: can you collect and manage client feedback inside Client Portal?

Yes, in a few ways, depending on what you need. They all use the comments feature on content pages, so that's where we'll start.

Collecting feedback with comments on content pages

Everything here relies on one feature: comments on content pages. Switch comments on for a content page and your client can leave feedback right there on the page, next to the work itself.

Worth knowing before you start: comments only work with the WordPress Block Editor, not the Classic Editor. If your site runs on the Classic Editor, you don't have to switch everything over. There's a way to keep the Classic Editor for the rest of your site and use the Block Editor just for Client Portal.

There are three main ways to use it.

Option one: a dedicated feedback or chat page

Create a content page that exists purely for communication: a single spot where you and your client can talk things through, rather than scattering it across email.

The handy part is the threading. Each top-level comment keeps its own replies nested underneath, so you can run a few separate conversations on the same page without them tangling together. One thread for the homepage copy, one for the logo, one for whatever keeps coming up. Each stays self-contained.

It works well as a simple, predictable place to keep individual threads of information. The client always knows where to go, and you always know where to look Here's an example set up this way.

Option two: comments on each deliverable

Put each deliverable on its own content page (a design, a layout, a document) and turn comments on there. Feedback then stays attached to the specific thing it's about.

Where a feedback page keeps everything in one place, this gives each deliverable its own. It's the better fit when you're sharing several things and want the comments on each kept cleanly apart. Comments on the homepage mockup stay with the homepage mockup, rather than everything landing in one pile.

Option three: a module per revision round

Say your proposal promised two rounds of amends. Set up a module for each round in advance (a content page works well), then open and close them as you go.

Deliver the work and open round one. When that round's feedback is in, lock it. Your client can still see everything that was said, they just can't add to it. Then open round two. When that's done, that's the rounds used up. Build it into a portal template and you only set it up once.

The point isn't to be strict for the sake of it. It's that your client can see they've had their two rounds. So when "just one more small thing" turns up, and it will, they already know a third round means another invoice. Nobody has to have the awkward conversation, because the agreement was clear from the start.

Not sure which to use?

Roughly:

Getting notified about comments

Comments aren't much use if you don't notice them, so Client Portal sends an email automatically when one's left. It works both ways: when a client comments, and when you reply. There's no extra plugin to install and nothing to set up in WordPress.

To turn it on, go to Client Portal Settings → Notifications and open the New Comment tab. You can switch the notification on, edit the subject and message, and choose who gets it: your client, you, or both.

So that's three ways to collect and manage feedback in Client Portal: a dedicated chat page, comments on each deliverable, or a module per revision round. Same comments feature underneath, used three ways. Pick whichever suits the project and enjoy having all your feedback in one place.

Quick one this time. If you let clients register for their own portals, 5.9 adds a small but rather satisfying touch: portals that name themselves using the client's own details. There are also a few fixes underneath, a couple of which are worth knowing about.

The new bit: portal titles that fill themselves in

Up to now, every portal created through self-registration got the same default title. Fine, but it does mean a backend full of portals all called the same thing, which is less than helpful when you're trying to find one.

Now you can drop a few tags into the portal title and let Client Portal fill in the rest. A client registering as John Smith can land with a portal already called "John's Portal", without you touching a thing.

There are three tags to play with:

You can mix tags with your own text however you like. {first_name}'s Portal gives you "John's Portal". {first_name} {last_name} – {organization} gives you "John Smith – Acme Co". Simple as that.

Where to set it up

Two places, depending on how you work.

For all your registration pages at once: go to Client Portal → Settings → Register / Login and add your tags to the New Portal Title field. Every registration page uses this unless you tell it otherwise.

For a single registration page: open the Register Form block, find Custom portal title in the block settings, and set the title there. Handy if you've got different registration pages for different kinds of work and want them named differently.

Good to know

• Plain titles with no tags behave exactly as before, so your existing setup is untouched until you add a tag.
• Existing portals aren't renamed. This only applies to portals created from here on.
• If a client hasn't filled in a particular detail, that part is simply left out, so you won't end up with stray gaps in the title.
• {organization} only works if you've switched on the organisation field in the block settings.

Full instructions, including the registration setup itself, are in the self-registration help doc.

A few other things in this release

• Editor code now refreshes properly after you update, so your browser stops handing you a stale version of the editor.
• Pattern editing inside portals now works correctly in WordPress 7.0, and we sorted an editor crash that could appear when clicking "Edit original" on a synced pattern.
• Private files: fixed a download that could occasionally fail in the block template, along with some security updates.
• Reminder notifications: if you deselect every recipient, that now saves as "send to nobody" rather than being ignored.
• Phase settings no longer fail to load when the number of parts is set to 0 or left empty.
• Tidied up a few admin sidebar labels for clarity.

Version 5.8 is mostly about notifications and comments. A few new things, an overhaul of the settings page, and the usual round of smaller fixes underneath.

1) New: Notification for comments on content pages

Back in version 5.5, we shipped the ability for clients to leave comments on content pages. Up until now, that's been running on WordPress's native comments system — which works, but is fairly limited for the kind of back-and-forth that actually happens in client work.

So we built our own: you can now get email notifications when a client leaves a comment on a content page, including replies. Previously, you had to log into the portal to know if anyone had said anything — which rather defeated the point.

2) Updated: An overhaul of the notification settings

The notifications themselves have been around for a while now. They work, they're useful, and most people are happy with them. But there have been a handful of small UX issues tripping people up — individually they were just annoying, but together they added up to a settings page that wasn't enjoyable to use.

So we took some time to properly think through how to make these easier to set up, easier to maintain, and easier to manage day to day.

Here's what's changed:

• New pill-style sub-tabs, so it's easier to see where you are
• Clearer copy throughout (the old labels assumed you knew what we meant)
• Per-notification enable/disable toggles are easier to find and use
• The "Email appearance" tab is now "Email settings" and actually explains what it does
• "Module available" is now "Module activated", which is what it's always meant
• Custom notification fields pre-fill with your global defaults, so you're not starting from a blank box

If you've previously customised your default email subject lines or body content, your customisations are preserved — only the out-of-the-box defaults have been rewritten.

A feature you might not know exists: Customize notifications per-portal

While we're on the subject of notifications — this is a feature a lot of people don't realise is in Client Portal: you can customise notifications portal-by-portal.

You've got your global notifications (what gets sent for every portal by default), and then you can override those defaults for individual portals when you want different behaviour. Say one client wants to be notified about absolutely everything and another would rather be left alone — you can set that up portal-by-portal.

The redesign hasn't changed how this works under the hood, but it has made it noticeably easier to find and use.

📚 Check out our help doc on how to set up portal-by-portal notifications →

3) New: Send admin notifications to more than just the site admin

Up until now, admin notifications went to whoever was set as the WordPress site admin and that was that. Fine if you're a one-person operation. Less fine if you've got a project manager, a VA, or an accounts person who actually needs to see this stuff and isn't the WordPress admin.

You can now add additional email addresses to receive admin notifications, alongside (or instead of) the site admin.

It's been on the request list for a long time. A small thing, but if you've ever forwarded the same notification email three times in a row to the right person, you'll be glad to have it.

To set this up: go to your Client Portal Settings → Notifications → Email Settings. You'll see an input where you can add additional email addresses.

4) Updated: A few image slider tweaks

The image slider modal is still relatively new. As we've been using it ourselves, we spotted a few small things worth tidying up:

• Full-width images
• Proper navigation arrows on the images
• The download dropdown now opens upward, so it doesn't get clipped by the bottom of the modal

Nothing dramatic, but the kind of small improvements that add up.

Other fixes and improvements

• Pasting formatted content from Google Docs or Word no longer breaks list styling in the module popup view
• Inactive modules in the content page sidebar are now properly greyed out and non-clickable, matching the behaviour elsewhere in the portal
• Digest emails now correctly respect notification settings on individual portals
• Multi-recipient admin emails report delivery status correctly (a previous quirk could occasionally lead to duplicate sends)
• A handful of smaller notification reliability fixes
• Hardened security on notification emails containing user-generated content

What's next for Client Portal: 1-click Template Library

The migration tool I mentioned in the 5.7 post is still in the works. Bigger job than it looks, but we're getting there.

Beyond that, we're going to be overhauling the way you add new portals — specifically by introducing a proper template library inside Client Portal.

Right now, if you want to use one of our pre-built templates, you have to download it from our templates page and import it manually. We're going to be building a full template library directly into Client Portal, so you'll be able to browse what's on offer and add a template in a single click.

The goal is to make getting started easier — especially when you just want to spin up a new portal without spending an hour thinking about structure.

You can keep an eye on what's coming (and add your own feature requests) via the roadmap.

Not using Client Portal yet? Check out Client Portal and see what it's all about.

Current Client Portal user? Head over to your WordPress dashboard and update.