With the release of CommandUI there has suddenly been a lot of people looking deeply at how my own product Turbo Admin works, and comparing the two tools. This has been great! Thanks to all who have made videos and write ups.
This post addresses some of the philosophy behind Turbo Admin, and clarifies some things about the tool that aren’t necessarily obvious. And yes, some of this will end up on the Turbo Admin website.
As this got long, I’m adding some contents:
The Turbo Admin Philosophy
My thinking behind Turbo Admin has really turned into something like “WordPress, your way, everywhere”. The command palette is the main feature, but the idea of it being a browser extension is that the settings apply on any WordPress dashboard that you visit.
So I can build in a bunch of dashboard improvements. You can turn on the ones you like. And you will always have them.
Another user of the site might have different preferences. And their preferences will follow them between sites too.
This also sets up the audience that I think a lot about. Well, there are two really:
- The 90% use case. Most things you would want to do (I think) in the WordPress dashboard on a daily basis are quicker to get to. More on this later.
- The person that visits lots of sites. This might be a plugin developer like me who has a ton of different local and staging sites that they’re forever logging in and out of for development and testing. Or it might be a big agency maintaining lots of client sites or a customer support department that gets to log in to lots of customer sites.
Turbo Admin shines for these use cases by not needing a plugin, and by giving you quick and easy access to what you already know.
Common myths/questions
Here’s some things that I’ve heard a lot about Turbo Admin that I want to address, and questions that are often answered.
It’s not being actively developed!
Yes it is! But I have a day job, and it’s not building Turbo Admin. So development tends to happen in bursts when I have quiet times in my personal life. The changelog clearly shows this and the roadmap is up to date.
I can only build what I know people want. So do let me know what you want Turbo Admin to do. There’s an email address at the bottom of the website.
You can’t search your content!
Yes you can! There’s a whole page on “search modes” in the instructions. You can search any post type that is available in the REST API, as well as users, plugins, WooCommerce orders and customers, and multisite sites.
You can’t manage plugins!
You can. You can search your installed plugins, but actions are currently limited to activate and deactivate as that can be done through the REST API. After activating a plugin you should really re-load the dashboard, so I encourage that.
It may be possible, in future, to install plugins. I’m investigating that. But because of how Turbo Admin works it’s not easy to achieve technically.
I’m curious to know if this is a really big downside of Turbo Admin. I feel like the 90% use case doesn’t involve installing plugins. Sure you might do it a lot when first building a site. But there are other ways to achieve that automation/speed at the start of a build (WP-CLI, Blueprints, cloning a base site, composer). However, people are talking about it a lot in the context of command palettes like it’s a big deal.
Drop me a line and let me know if it’s a big thing. I want to know if it’s worth working on more.
It doesn’t/won’t integrate with my page builder/plugin!
Turbo Admin scrapes all the WordPress menu items. So any pages your plugin/theme/builder adds there will be in the command palette ready for fast access. When you install a new plugin or create a new post type, its menu entries will appear in Turbo Admin.
It totally can do more. I just haven’t done it yet. It integrates with Oxygen builder as that was requested a while ago, and Bricks has been requested a lot so I’m working on that now.
Turbo Admin has been built to be easily extensible, so when I know there is a need to integrate with something, I can easily build it. Let me know!
I’d actually love for their to be a standard way that WordPress (or any site!) could provide that allows command palette items and actions to be registered so that any command palette tool could discover what a site can do. That would be very cool and better than all the command palettes having to build integrations, or all the plugins having to integrate with all the command palettes!
It doesn’t do deep navigation!
Correct. Again, I wonder if this is in the 90% use case though. Are people really going to the REST API settings on the Advanced tab (for example) of their favourite plugin on a frequent basis?
Genuine question – let me know.
This also poses a real UX challenge in terms of consistency. Because so many plugins have their own custom screens. I could start manually including all the pages/tabs/screens you can get to in all the plugins/themes/builders. But that would get out of date, and could break, and would be very inconsistent and that could be frustrating.
Turbo Admin’s model is simple and consistent: if it’s in the menu, you can get to it. More on this later.
The default shortcut is too long!
The default shortcut in Turbo Admin is Cmd/Ctrl-Alt-Shift-P. WHAT?!
OK. Hear me out. I’ve thought about this a lot.
The common keyboard shortcuts for command palettes are:
- Forward slash (More for search bars really. See GitHub though. And there are “Slash commands” in lots of tools like Slack and Notion)
- Cmd-K (Slack, GitHub, the WordPress command palette in Gutenberg, lots of others)
- Cmd/Ctrl-Shift-P (Usually text editors/coding tools like VS Code, JetBrains products)
- Cmd/Ctrl-T (Arc Browser)
- Cmd-Space (Spotlight)
The difficulty here is choosing a default that won’t clash with something else.
- Cmd-K is often used for “insert link”, including inside WordPress. Plus the Gutenberg command palette uses this.
- Cmd/Ctrl-Shift-P is used for “New Private Tab” in Firefox.
- Forward slash is not really a shortcut and I don’t want to hijack it.
- All the others are out, really.
So I settled on Cmd/Ctrl-Alt-Shift-P as a default because the chance of it clashing with something else and disrupting your workflow are tiny.
You can totally change it. Set it to Cmd-K. Set it to Ctrl/Cmd-Shift-P if you’re not on Firefox. That’s totally an option and one I encourage you to take.
Finding a good default was hard though.
It doesn’t have keyboard shortcuts!
CommandUI has this neat feature: You can use sets of keystrokes to navigate around. Like “e” to edit your site.
I actually played with this idea really early on in Turbo Admin’s development. (People who know Git and code can see it here in GitHub).
I ruled it out for the same reasons as the default shortcut issue. I didn’t want to hijack other keyboard shortcuts that a user might be familiar with or that a browser might be using for something else. And you’d need clever context management so that you don’t hijack form fields and stuff. It’s not as easy as it seems.
It seems that CommandUI has succeeded here though, and people like this in CommandUI. So I’m watching the feedback with interest and maybe it will come back.
It can’t know what a user has permission to do!
Below, I’ll write about how Turbo Admin works, which will help answer this point.
And yes, it is true that because it’s not a plugin it can’t see what user permissions you have.
But Turbo Admin’s command palette works by showing you what is already on the screen. If you don’t have a “Users” item in the WordPress menu then it won’t be in the command palette.
I do some other checks that I can do from the front-end to turn some other things on and off too.
And that, actually, seems to work well. No one has ever complained about having something in the menu that shouldn’t be there.
It’s also fail safe. Even if it did show you a page you can’t visit or an action that you can’t take, WordPress won’t let you do that thing if you don’t have permissions. Worst case you get a permissions error page.
Design decisions and how it works
Turbo Admin is over 3.5 years old at the time of writing. The first code was written in April 2021.
I’ve made a lot of decisions along the way. Some I’ve already explained. Mostly around keyboard shortcuts.
But the nature of it being primarily a browser extension (which itself is a decision) also has constraints on what it can do and how it has to work.
Here’s some more detail on how I decided it should work.
It shows you what you can already see.
Here’s the truth. I mainly built Turbo Admin because:
- there were plugins where I couldn’t remember if they put their page in “Tools”, “Settings”, or their own custom menu.
- I’d often visit client sites with plugins installed where I just didn’t know where the options were.
- some client sites had loads of plugins with their own menu items and the menu was a mess and finding anything was a tedious chore.
Turbo Admin’s command palette scoops up all of the menu items – it literally scrapes them all out of the WordPress menu and admin bar. It then does some filtering and arranging to make sure you see what it thinks you should see. And it adds in some custom options based on what it knows about the site.
The idea is that you shouldn’t have to learn too much new stuff. If you know there’s a “Backup” option in the menu, Turbo Admin should let you get to it by typing “Backup”. If you know there’s “Add New Spell” because you create a “spells” custom post type, then type “ansp” and it will fuzzy-search to it.
Is it perfect? No!
Is it really good the vast majority of the time? Yes!
Over 3.5 years I’d developed some pretty clever tricks for doing all of this.
Is it a bit hacky in places? Yes! Gosh, the lengths I’ve had to go to discover the API URL from the front end and figure out what nonce’s (yes, they are a thing) should be are pretty tricky. But for the most part, it works. I use it daily. I struggle to WordPress without it. And I don’t find it unstable or annoying at all.
If you do come across issues please tell me!!!
Browser extension limitations
Because Turbo Admin is a browser extension, it doesn’t have hooks into the back-end of your website. It has to do all of its discovery and functioning based on the HTML page that it can see (or based on information it got from a previous HTML page that it could see), or using the REST API.
The main thing people are saying that Turbo Admin can’t do that CommandUI can is plugin search/installs. And that’s a totally fair criticism.
But as I’ve said before, I do wonder if that’s something that people do a lot. And it’s definitely something that you can automate in other ways.
I’m continuing to investigate this. I think there might be a sneaky way to do it. But the question is really: is it worth the effort to make and maintain a hacky, fragile version of this if it’s not actually something that people do a lot.
So I am really keen to hear if this is something people would like.
Are there other limitations? Sure. I think. But when the philosophy of Turbo Admin is “Show you what you already can see” – when that’s a design decision that I’ve made about the tool – I’m not really sure it limits me much.
This decision also limits what Turbo Admin can do. But that decision comes with the benefit of consistency, as I mentioned above in the section on deep navigation.
One final thing: I have considered a companion plugin that gets Turbo Admin access to the back-end of sites. But I’m not sure it’s worth it and the inconsistent experience of hopping from a plugin-enabled site to a non-plugin-enabled site could be jarring.
Other thoughts
I will make more video content about Turbo Admin. It’s hard to market. I’m convinced that the audience is niche, and the tool has subtleties to it that are hard to communicate succinctly. But one thing I’ve learned is that a visual demonstration of its capabilities will get me a long way. So I will do that.
The WordPress dashboard is changing. I’ve written before about what this might mean for Turbo Admin. But there’s definitely a sense that React and the Gutenberg interface is taking over and the built-in command palette is probably the way forward. That puts a question mark over how much effort it might be worth investing in Turbo Admin. Eventually I’m hopeful that you simply won’t need it!
(Note: I’m not able to contribute to WordPress core, so I’m unable to contribute to the core command palette work)
It’s not a “life-time deal”. I could write a whole post about pricing. Though I shouldn’t have to because it’s simple. The idea is old school: I made a thing. You can buy it.
It seems that this is a bit of a novel (or, possibly, “retro”) concept in software. I think people are thinking of Turbo Admin as a service. This is how they’ve been conditioned to view software. And while I will continue to support and develop it as best I can, it’s not a service. It’s more like an eBook.
People have also said it’s too cheap. And I somewhat agree! But that also kinda reflects the “I made a thing, you can buy it” approach. If it were an eBook, $35 might seem a lot.
Perhaps the price will change at some point. But people have also suggested that they are sharing their license with other people, like their clients that they build sites for. So here’s a simple thing you can do to pay me more: Buy more licenses! You can also buy me coffee if you want to support my work on it.
I hope this was useful. Again, your feedback is welcome. Find the Turbo Admin email address at the bottom of the Turbo Admin Website.