Nothing has foregrounded the fundamental bargain of open source like the past couple months of WordPress drama. I’m not here to talk about that in particular, but it has really gotten people thinking about what’s legal, what’s ethical, what you can charge for, what you can give away, and how a business will or won’t work within the ecosystem based on how you answer these questions.
Matt Mullenweg recently took over the WordPress.org repository copy of Advanced Custom Fields, for which he received a great deal of criticism. Just a couple of days ago, he included advanced features (the one’s you’d ordinarily have paid for) as part of this free (renamed) version of the plugin.
GPL is a free pass
As nearly as I can tell, this is completely within the letter of the GPL (General Public License, a baseline agreement created by GNU). If you use GPL’d software to make your thing, the anyone else can use your thing for whatever they like.
At the same time, there’s been something of an understanding in the WordPress world that you can charge for plugins and themes if you want to, and there’s a genuinely large business ecosystem built around this.
But this business ecosystem is in some respects built on faulty assumptions, and Matt’s release of “premium features” from Advanced Custom Fields is solid proof of this, barring some significant turn of events in a legal action that hasn’t happened yet (ACF’s parent company WP Engine is suing Matt and others but not over this particular matter).
New models
I am convinced that there needs to be a model for code that is examinable and extendible, but that requires a low-cost license to use (or to use in a business resale context, but I prefer the simpler idea of just charging a small amount for any use). I think a blockchain model of project governance is the way to accomplish this, but that’s a post for another day.
Meanwhile, though, those of us trying to run businesses in the WordPress space are pretty concerned by the idea that their features can be distributed for free on the primary distribution site for the ecosystem at WordPress.org.
SaaS, API or Bust
My take is that you have to offer your business as a SaaS, or a SaaS with a connector plugin, if you want to operate in a way that you can legally protect. If I sell you a service, all you see and use is the service. To date, anyway, what I build the service with is my choice and the code I did it with isn’t necessarily anyone else’s concern.
So if what I’m selling you is essentially access to a WordPress site, you’re using the site, not running the code, and you aren’t necessarily entitled to see the code. I’m probably obligated to make the code available to you if I build it within a GPL context, but this seems effectively unenforceable.
For one thing, anything that I want to keep outside of GPL provisions I can implement as a separate service that’s used via REST calls. The code that processes the REST requests isn’t GPL and you’re not entitled to take it and resell it.
I can even make the source code available to you, but not under a GPL license. I can let you see it but not use it yourself, let you see it but only use it if licensed for a fee, and so on.
Business behind the curtain
In the current environment, what I suspect will happen is that developers will cordon off some portion of what they do behind a REST API and not let you see the inner workings. That’s not really the way I want PeakZebra to do business, but I want there to be a revenue stream that Matt can’t gut at a whim.
The good thing about this sort of workaround, where it is feasible, is that it makes it possible to continue to do business in the WordPress space without undue risk to the business owner. And there are all sorts of great reasons to keep WordPress (and it’s ecosystem) thriving and moving forward.
With the WordPress block editor, you get a reasonably good editor for managing the pieces that make up a typical web page. And that can include things like forms and interactive charts and so on.
For that reason, PeakZebra uses the block editor as the interface for any clients that want to build or customize their own pages. They are otherwise shielded from the potential confusions of the WordPress back end.
But while the block editor is good for making a page that looks like part of an application, you have to ask the question: what happens when something is supposed to happen.
Enter logic
For “normal” form processing, PeakZebra justs handles putting any updated values from forms on the page into their appropriate database records. For use cases where you’re just tracking data (what’s this client’s mailing address?) that’s surprisingly powerful all by itself. If you use address fields in a form that gathers client information, for example, simply submitting that form ensures that the data winds up stored in the right table.
But what’s needed beyond that is a (relatively) easy way to make more complex interactions happen. I think what you need is some kind of logic block that’s configurable in the editor–you give it a set of instructions through some kind of GUI–and presumably not visible (though present and ready to do its work) in the front end.
Alternatively, you could simply make it possible to attach actions or code to each element of a form or other block and tie them to specific actions (onclick, for example), in pretty much the same matter that HTML lets you attach JavaScript to element events.
The lotsa-pulldowns approach
While Bubble and other no-code platforms use a sort of “assemble instructions by clicking options” approach to attaching procedures to elements, I’m resistant to this, even with a client base that doesn’t really want to code.
That’s because it quickly becomes nearly impossible to keep track of what’s going on (or what’s going wrong) because you have to go back through all the options you selected in that visual interface, plus you can’t get any coherent overview of your whole application’s logic flow. (Actually, maybe one or another of the no-code options handles this well–I’d love to get a heads up on that.)
So it’s tempting just to make it easy to insert plain old code snippets into a logic block that essentially just exists as a container to put that code in. This, of course, means people have to code at least a little in order to take advantage of this.
One ecosystem divided by two languages
In the WordPress world, this approach gets more complex right out of the gate because, of course, WordPress uses two separate languages: PHP on the server and JavaScript on the client side. So should the logic block handle one or the other, or both. And does this increase the complexity sufficiently that this just can’t be termed “low code” anymore.
I’m tempted by the idea of creating a highly-simplified language for describing what should be done, like:
see if zipcode begins with “19”
if yes, set timezone to “EST”
And then this would parse back into _either_ JavaScript or PHP, as appropriate. Sounds so easy, right? What’s a programming language but a huge nested if statement, amirite?
Let’s be real, or else let’s use AI. It’s magic.
Sure. However. Given that this is almost certainly way harder than it sounds and would be a constant source of annoyance while the kinks were ironed out, I then begin to wonder whether AI is the answer. It’s the answer for everything else, after all.
And this actually does seem plausible, given how good copilot style programming assistance AI has gotten. You’d just need to train the AI on the specific codebase, something that Cursor does already, though I haven’t tried it yet to see if it actually “gets” a WordPress code base.
But I don’t think, for the moment at least, that AI is really the answer. And that’s because experienced developers bring some important horse sense into the game.
Horse sense to the rescue
It’s pretty easy to design a system that does something that is error prone and non-scalable from the get-go. If you talk to a developer who really understands the code base and what you might be trying to do with it, they can help you see if you’re really tackling the problem in the right way, with the right approach.
In other words: maybe you could get the count of the number of tasks associated with a project by counting the tasks associated with that project in the task table, but maybe it’s better to keep a running total that the system updates whenever tasks are added or subtracted from the project.
You want someone at least looking at this from a perspective that has the whole picture in view.
For the foreseeable future, this is how PeakZebra handles these things: by request. Your request to do X or Y is handled by a real, human programmer who is familiar with the PeakZebra code base as well as the WordPress platform (from a technical perspective).
It occurred to me that I was writing lots of blog posts and posting links to the posts on Bluesky and X. And there were even a couple of good souls clicking through to have a look at the proceedings. But on the blog pages (aka, pages like this) there was no call to action encouraging you to sign up to kept informed of when PeakZebra goes into early access.
In today’s interworlds, it’s probably too much to ask for someone to be curious enough to click on over to the home page, where there’s a dandy sign-up form. So I need to change the template that displays the single blog posts. Done. (Though, looking at it now, the right column needs some adjustment. We’ll get there.)
The confidence game
In general, I’ve been trying to shift my default frame of mind so that I tend to assume that things I’m doing will work as expected. For instance, if you land on a blog page on the site, you’ll give the piece a reasonable chance to hook you. And if there’s a call to action to sign up for updates, you’ll see the wisdom in doing so.
There’s a lot of talk among the startup crowd about launching the product before you’re ready. The supposition is that you don’t actually know yet what’s going to result in legitimate product/market fit. I can’t really argue with that, but I think it leads–at least for me–to a certain laziness about building things to a sufficiently finished point.
I’m learning to trust my instinct on what needs to be finished (and to what degree) before launching. Trusting that I had the right idea also makes it harder to turn away from the project when something shiny appears on the horizon. (Or, for that matter, when some big, not-very-helpful change occurs in one’s business environment. I’m mostly looking at you, Matt.)
Trust the workflow
I think I also need to trust my gut on having a rather different “agency like” workflow behind the core service. I can see a number of issues with trying to make it affordable to make alterations to one’s version of the application. But I also need to trust that I’ve got enough of it figured out that I can find solution for the problems that will inevitably crop up.
The point here is maybe not so much that I need to “become more optimistic” but to recognize that I’m mostly likely to be right in my business decisions and actions. Not infallible, but my best-laid plans actually don’t go awry very often–unless self-sabotage enters the equation.
OK, so what besides adding CTA forms to the blog pages have I missed? Well, a better sample on the front page, but that’s coming. Well, trial accounts, for one thing.
I’ve been thinking that my business model wouldn’t make it affordable to hand out free accounts, but it occurs to me that maybe the trial accounts should be spun up on a multisite instance of the application. While I don’t think it works to use multisite for paying customers (one of the advantages of the current setup is that you have your own instance and thus your entire database is completely separated from any other customer’s database. It’s vastly more secure.
Multisite is secure, I should add. And it’s plenty secure for a short trial period, after which you either get deleted or you upgrade to paid service and we move you to your own site instance.
It occurred to me that I’m so bad at thinking up witty little bits to post on Bluesky that I’d probably do better writing a five-hundred-word piece literally every day and then “skeeting” (as they say on Bluesky, though I have no idea why) the address and topic. I’d have something to say, sort of.
And writing at a steady pace (something I haven’t done in quite a while) means I can do something that’s more my style in terms of building in public. That is, I can get into the weeds on code and WordPress particulars and also talk about some startup decisions more or less as they happen.
The good
I’ve been working away on one version or another of PeakZebra for something on the order of three years now (depending on how you count). This is a terrible way to launch a solo bootstrap business, just in case you were wondering. I think people get problematically cultish about shipping as fast as possible sometimes, but for the most part I do believe it’s a good idea to come up with a business idea that’s relatively small and self contained, at least as far as creating it. Didn’t manage it myself, though.
But the good thing of late is that the vision is considerably clearer and, as I’m putting the pieces together, I’m pleased that some of the pieces that go back fairly far in that three-year period work just fine as I’m integrating them with new pieces. This wasn’t necessarily going to be the case because the framework I was developing for–WordPress Gutenberg blocks–was a moving target the entire time.
It’s funny, when fixing bugs in that older code (because, um, there were a few) to be reminded that, to take one small example, you used to have to enqueue any JS files you were going to use on the client side of your block. Nowadays you can just use a render.js file that you list in your block.json file. All sorts of other minor details have been streamlined in the interim.
And pieces are coming together. I have a test platform that, I guess because I think of it as a blueprint site, I call mrblue. I give my local sites dorky names. The offline version of this PeakZebra.com site is currently totally.local.
The less good
I spend a lot of time wondering whether I’ve gone down the wrong track with the idea of enabling companies to build internal tools on a WordPress platform. That’s in part because I more or less arrived at this goal within an almost entirely WordPress context and I didn’t really dig into all the options that are out there.
I was aware of most or perhaps even all of the no-code application builders that are used by people trying to build no-code startups, but I didn’t really take the time to see what kinds of services were specifically targeting the internal business market.
Setting aside the various things that you can do with customization in Salesforce, there are also quite a few companies that specifically target enterprise internal tools.
Checking these various products out has been kind of depressing, because some of them are very polished and very capable. At least one of them, Budibase, is open source.
So far, though, they are all really most suitable for enterprise use, and I’m more interested in the tiers below that. They are also, accordingly, a lot more expensive. I’m not trying to be the low-cost purveyor, but what I really think is the case is that these other products are really playing in a different product category. I genuinely don’t see PeakZebra tackling the enterprise world anytime soon.
The storm clouds overhead
Meanwhile, Matt Mullenweg seems to be trying his dead-level best to seriously undermine the WordPress economy. I’m not going to make this a forum for my read on the #wpdrama, but what I can say is that I’ve shifted my strategy for going to market with PeakZebra so that I can get closer or farther away from WordPress. More on that another time.
While your first encounter with PeakZebra may catch you a little off guard, especially if you’re coming from a WordPress background, the ideas behind it are actually very straightforward. Which is what makes them powerful, of course.
Halfway with Forms
Particularly in the WordPress world, there’s this notion of an add-on called a “forms package.”
A forms package lets you create forms, needless to say. These forms are presented to users on the front end of your site and when they fill them out and press the submit button…
Actually, that’s where the capabilities of a forms package begin to peter out. In the simplest instance, the data from the form will be plopped into an email in text format and sent to a pre-configured email address (your address, roughly speaking). What happens to the data at that point is your problem.
If all you want to do is toss the name and email into an email mailing service, then that’s likely to work just fine. Most of the larger such services are integrated enough with the dominant forms packages that they can pick up new entries without manual intervention.
There are also forms packages that offer the capability to dump all your form responses into a database table. While that’s a start–and it might even be ok if you only have one form active on your site–but since it literally dumps the data from every form into the same data table, what you typically wind up with is a jumble that you have to sort out by hand. It’s a feature that I don’t really believe anyone with more than one form actually uses.
Enter the Table
Out in the world beyond WordPress, there are several options for ad-hoc applications that start with a table. The original example of this is arguably Google Sheets, even though it’s a spreadsheet, not a database table, strictly speaking. A lot of people use it strictly for columns and rows of data, though. Plus it’s easy and automatic to connect a form (one form, and you can’t control what it looks like) to a table. A more purpose-built version of the same thing is Airtable, which gets an enormous amount of mileage out of good looks (though you can’t change them much) and support for a whole lot of bells and whistles (scripts, automations, widgets that aggregate data and chart it).
The Initial Insight: Known Tables
PeakZebra combines the forms package and better-structured, more “Airtable-like” tables. In a departure from other tools out there, PeakZebra starts with a set of pre-defined tables. This has a couple of advantages. First, it’s faster to get going (it’s also just plain faster) because you don’t have to create fields for obvious things like “city” or “email”.
Second, it makes it easy to tie form fields to the tables. So in PeakZebra, if you add a text field to a form, you can pick which table and which table column you’re connecting to that instance of the text field input. If you want “city”, you just select it over in the right-hand-side column with the various configuration options for that field.
A third, huge differentiator for PeakZebra is that using known tables means we can supply various templates for different kinds of applications and they will–because they are tied to the same underlying tables–be inherently interconnected.
Second Insight: Fields are Blocks
The pages you visit as part of a PeakZebra application are built with the WordPress block editor, using blocks.
Of particular instance, when (and if) you build custom forms as part of your application, each field and each button is a block. So you have enormous control over what your form looks like and how it performs.
Third Insight: It’s Not that It’s WordPress
It runs on WordPress, but what matters is that it runs on a WordPress that provides you with your own SaaS service. So you don’t have to “run” or “administer” WordPress. You just use your customized service. It’s SaaS, but ultimately it belongs to you.
There are plenty of long-time WordPress professionals who will tell you that WordPress is too complex for its own good. I don’t agree, but I’ll readily concede that it’s very confusing to get started with, even if it does offer a lot of power and flexibility.
Thus, while a PeakZebra instance is running on WordPress, the idea is that you’ll be largely unaware of this. You never log into the “admin” side of WordPress (unless you know your way around and want to do something unusual). If you opt to edit the pages of your applications, you’ll be doing so in the WordPress block editor, but in a cleaned-up version that prevents some of the confusions that have made some people less than thrilled about the interface.
In short, even if you’re the admin for your instance of PeakZebra, you don’t have to be the admin on the WordPress instance running behind the scenes. You show up to the website as a user. If you’re the admin, you show up as a user with access to PeakZebra admin functions (adding a new team member, for instance).
Thus
The core ideas that power PeakZebra are pretty simple at the end of the day: tie forms and tables together from the get-go, build the forms from standard block components, and use the strengths of the WordPress platform without forcing people to learn WordPress just to take advantage of the good stuff.
Gutenberg arrived on the WordPress scene five years ago by now, but plugins that implement more-than-basic blocks were relatively slow in coming. Still, five years: so you might think everyone would have it all figured out by now. But no. And plugins that implement more-than-basic blocks were relatively slow in coming.
For one thing, there’s a huge percentage of WordPress users who wish that Gutenberg had never happened. Especially among WordPress professionals who feel this way, they have come to the conclusion that Gutenberg blocks are trying to be something like Elementor or Divi–and that they are failing miserably at it. With Divi, they say, they get pinpoint control over positioning, gradients, and animations.
With blocks you have nothing but the bluntest of tools for positioning, gradient controls (only recently starting to appear) are confusing and inconsistent, where available at all. And just forget about animations–none to be had. That’s the argument.
There’s something to be said for their arguments: blocks arrived to the world in fairly rough shape. Eventually, they got to be pretty good at handling blog pages and, once you got used to some of the quirks, you could put together page designs fairly quickly, provided you weren’t trying to do anything that relied on pixel-perfect control.
Just as we arrived at that point, though, the roll-out of “full-site editing” came along. Now all of a sudden we were asking blocks to carry the weight for lots of things in themes that had previously been handled in PHP templates. Now everything including headers, footers, and sidebars were built with blocks.
Well, FSE was pretty shakey out of the gate, but it’s made steady progress. And there’s been another development as well: blocks have gotten a lot better, a lot more capable, and a lot more interesting. So let’s talk about the best WordPress blocks plugins.
Block variety
There are blocks (and groups of blocks) that I think are presently somewhat ahead of the curve. If you take some time to put them through their paces, you’ll see they show where blocks are headed.
So here’s my short list of the best block plugins that push you to think more broadly about what blocks can do (including things that are well beyond traditional page builders like Divi).
Greenshift Animation and Page Builder Blocks
I’m not a big fan of typical on-page animations, but they are a necessary tool in any web-builder’s toolkit and one thing that block skeptics are always lamenting is the lack of simple animations like fly ins. And it’s true that there are no animations for core blocks or any of the blocks in the more widely adopted block libraries like Kadence (no knock on Kadence, to which we’ll return in a bit).
With Greenshift, you get a bunch of new blocks over to the left of the editor, some of which give you new capabilities, some of which offer spiffier versions of some of the core blocks (from paragraph on up).
For any given Greenshift block, you’ll have some animation options. The text block (a much-fancier-than-paragraph option) gives you a number of options including looping through alternatives for a key word or phrase in your text.
The panel to the right gives you eight animation options for the replaceable section, including a nice one called zoom that sort of superimposes the new word over the old word. Additionally, you have control over the color of the replaceable section separately from the rest of the text–and this includes gradients.
On the advanced tab, you can also animate the entirety of the block, so that all the text can drop down even as the typewriter animation, to pick another option, types in the first word of the replaceable part. The effect here is way too busy, but the point is that you have a lot of options.
And the larger point is that the Greenshift group of blocks is a lot more of a Divi replacement than most of the Divi loyalists would care to admit.
Mindspun Payments
Mindspun is a startup that clearly gets the value of a block-based approach and they work in an area that makes enormous sense to tackle with blocks: the payment space. I say “payments,” but their blocks do a lot more than that, handling pretty much the whole stack of things you need to sell, in particular, digital products (including licensing and managing downloads).
If you think about it, a checkout page is a group of elements that break down readily into separate chunks (that is, blocks)–and also a place where the blocks need their individual functionality tied together into an overall package.
I like what I see enough that you’ll be seeing a Mindspun Payments installation right here on PeakZebra.com before long.
Block Visibility
This plugin doesn’t add blocks to your site, so you could argue on a technicality that it’s actually not one of the best WordPress blocks plugins. But all the same, it’s a good plugin for blocks–one that takes advantage of the architecture of blocks to add a “Visibility” panel to every block on your site. So if you only want something visible during, say, business hours, you just set it so that this is the only time this block (whatever it is) is visible. And you can place this setting on a group block to take care of whole section of a page.
I wanted to mention this plugin not just because it’s handy, but also because it’s an example of a block that behaves different ways in different contexts. I suspect we’ll see more and more of these.
Content Control
Here’s another plugin that adds a panel to existing blocks on the site. It gives you the sort of controls you’d want for a membership site, and gives them to you on a fairly fine-grained basis.
You can use it to drop blocks from a page (visually) on mobile devices, for one thing. But you can also restrict views based on user role, as I’ve done here. Mere subscribers will not see the paragraph block in my example page above.
It’s the kind of thing that’s perfect for a call to action that you want non-subscribers to see, but that people who’ve already subscribed will just see as a nuisance.
Custom Blocks Creator — LazyBlocks: Make your own best blocks
I’ve liked this tool since it first emerged. It gives you an interface to create blocks without having to know the full-blown block creation process. Instead, you can build blocks exclusively using some drag and drop controls and the PHP you already know how to code with. And you can do full-speed, heavyweight blocks with this.
The cool trick to it is that it hides all the JavaScript and React that would normally be associated with creating a block. Rather than code the controls that appear in the inspector panel, you pick them and configure them to name the things you wind up storing from them. To handle the data that the user adds to the block, you write code in PHP (or present it in template format). It’s pretty darned seamless.
One point about it that might make a difference in some instances: the PHP rendering magic is accomplished by creating dynamically rendered blocks, as opposed to blocks that are pre-rendered and stored as straight-up HTML. The traditional pre-rendered approach is inherently more performant, but that’s only going to matter in certain kinds of instances (high overall volume to the site, or some kind of process that makes rendering slow but could be handled without dynamic rendering).
For the most part, though, dynamic rendering just doesn’t inflict much of a performance price–not the sort of thing you particularly notice on a typical site and not the sort of thing that’s going to send your Lighthouse scores into the dumpster.
Code Block Pro
I discovered this very recently and I freakin’ love it. It displays your code samples as if you were viewing them with syntax highlighting in VSCode. Indeed, it uses the VSCode engine. It handles just about any programming language you can think of and offers a ridiculous number of VSCode themes for different colorways.
The point here is that it’s a block that brings an enormous bunch of capability to a specialized kind of display and means that no one else has to do all the heavy lifting to get it done for themselves–exactly what blocks are about.
Kadence Blocks
If you’re following the world of blocks, you may well already be familiar with Kadence Blocks, because there’s a fairly large group of block-based site developers who have chosen Kadence as their go-to set of blocks.
The Kadence package is pretty typical of a class of plugins out there that provide a whole set of blocks that more or less replace (or at least significantly augment) the WordPress core blocks.
I mention Kadence because it was out there early in providing lots of the fine-detail controls that were missing in core blocks. In the Kadence text block, you can alter settings not just for typeface and font weight, but also things like character spacing. Core blocks are, to some extent, catching up, but progress there has been uneven. And I don’t know whether the core blocks, with their emphasis on keeping things simple, will ever have all the controls for drop shadows and so on that Divi users are accustomed to. But the point is, block groups like Kadence (and others such as Greenshift) will fairly soon have all those bases covered.
Enter the Zebra
Blocks can do other, perhaps less expected things. In the context of this article, at least, I think they are the best WordPress blocks plugins for this very reason. And I’ve tried to do my part to push things along: the blocks I’m building with PeakZebra, for example, work with tables in the site’s SQL database, for example. And they handle display using React on the front end, so that it’s possible to have a table that interactively lists a table of people, for instance. Personally, I like the idea of bundling up the blocks and their presentation in extended themes or blueprints.
On the editor side of things, you can choose which columns to show, how many rows to show in the box, and what should happen when a row is selected.
Meanwhile, on the front end, the end user can shift the column order, sort by column, page through data without a page refresh, and so on. Like a modern web application, you might say…
The point is not that it’s got to be PeakZebra supplying you with blocks like these, but rather that these kinds of blocks are on the way. Maybe they’ll be custom to your particular needs or maybe they’ll be utility functions with broad application, but they’ll be doing things above and beyond text on the page.
What PeakZebra offers is more than a theme. Actually it’s a lot more, but the “lot more” actually is varies from one blueprint scenario to the next. And a given blueprint could actually look a lot of different ways. Yes, what you’d normally call the “theme” is tied pretty closely to what the site does, but it’s still possible to vary that theme in lots of different ways.
So how to show the differences among blueprints, while also showing what kinds of variations in look and feel are possible within a given blueprint. With two blueprints and basically no pre-set variations, that’s not really a problem.
But there will be more and more blueprints over time. So what’s the best way to get all those options up on the home page without creating total confusion and chaos?
Right now, I think it’s about having a top level choice of blueprint scenario without showing any thumbnails of page design. So first you choose whether you’re a paid newsletter client, a help resource client, a SaaS builder, a “real” contractor type builder, and so on.
I think maybe it drops down from that choice, but maybe it actually jumps to another page. I think I just decided it should jump, which should help keep us all sane.
And you know what? Isn’t this exactly the kind of scenario where the answer is a Custom Post Type? Let’s have a post for each… each what? Should it be one post per blueprint or one post per variation, grouped by categories that reflect the different blueprints.
This is the classic stuff of WordPress application development, which is probably worth discussing, but for the moment I’ll leave it that I think it’s probably one post per variation. Somehow or the other I’ve got to come up with a way to indicate which is the primary variation, but that seems doable, possibly just by using another category that reflects exactly that. Yup, that’s it.
I hope to have a stab at this new approach in the next few days. Specifically by November 10, which is my self-imposed deadline for my current group of tasks and projects.
I’ve gone back and forth a ridiculous number of times about what, exactly, PeakZebra should be. What was the offer? What was PeakZebra going to sell and how was it going to sell it. I’ve had to learn a lot of self discipline when it comes to avoiding the distractions of new shiny ideas and things.
As of this week, though, PeakZebra has a wonderfully clear vision: we sell LiveThemes.
A LiveTheme is like a traditional WordPress theme in that it provides a design template for a WordPress site. But it’s a lot more than that. It’s a site that’s fully configured to carry out a specific function. In other words, it does things.
Our first “site that does things” is a LiveTheme for running a free+premium newsletter. You can think of it as Substack without having to hand over 10% of your revenues, though it also has some additional cool features up its sleeve.
If you’re thinking about launching a newsletter, or if you’re running one on Substack or Beehiiv.com, I’d encourage you to take a look at the LiveLetter LiveTheme.
“Buying” a LiveTheme means having PeakZebra set up a preconfigured site for you. It’s got all the text and images and forms and payment gateways you need to run the business, but in a theme-like stand-in text format. You’ll want to replace most or all of the placeholders.
It’s a WordPress block theme (based on a Kadence theme), so it’s the “new era” approach to WordPress and you can change things to your heart’s content using the WordPress built-in editor.
If you don’t want the hassle or don’t want to be forced to learn WordPress right away, though, you’ve got options:
For $445 we’ll work with you to get all the placeholder text and images changed out to your liking. This usually takes a week or two.
Thereafter, you can subscribe to “request queue access,” which means that you can use our bespoke application to request a wide variety of changes to the site. You can request as many things as you like, we work on queue items one at a time. You’re sharing the queue with other clients, but our aim is that no request takes more than two business days before it’s filled. Given that this costs $70 a month, it’s a terrific value.
And you can pause the queue access subscription whenever and for as long as you like if you aren’t in need of changes.
We’ll be ramping up slowly so that we can keep a close eye and manage the queue response time (two business days!). This means we won’t take on more new clients than we can handle, so if you want to jump in sooner rather than later, you’ll want to be quick about it.
If you have questions, you can reach me directly at robert — at — warmhearted-tortoise-fa7261.instawp.xyz.
The early hurdles for PeakZebra mostly had to do with getting tables to display in a sweet, full-function way on the front end. My take is that we completely crushed that particular challenge.
The next hard thing was harder, though. It was the complex problem of how to create custom logic and computation within an application that was build from blocks. Since PeakZebra is all about building apps with Gutenberg blocks, the obvious thing was to reate a block, or group of blocks, that represented the logic flow.
That’s a lot harder than it may sound, though.
In the end, the solution was three initial blocks, featuring a back-end UI that let you select things like the piece of information you wanted to work with by presenting a list of possibilities, rather requiring you to remember the right field (and spell its name correctly).
The three blocks are:
Calculation — Perform some math on data elements, or combine some text strings.
Trigger — Make a comparison that determines whether actions need to be taken. You might compare a person’s age to the minimum age for legally buying alcohol in a given state or country.
Action — Do something that isn’t a calculation (since there’s already a calculation block for that). You might move some info to a task in the task table, for example. Or you might make a new entry in the calendar table.
There are a couple of further blocks in the works right now, but you can do a shocking amount with just the above (heck, Zapier pretty much does everything it does with just triggers and actions, right?).
We’ll be publishing a whole set of recipes for ways to make good use of these special blocks and we’re always ready to work with you to get the application you need.
I’ve known in the back of my head all along that, while there was a place for the multi-field form blocks I was building to capture things like customer names and addresses, the “pure” way of attacking my block-based application building project was to create a bunch of generic fields. This is what existing WordPress forms packages have done for years and it gives you more or less infinite flexibility.
Of course the situation with forms builders is a little different. They let you create forms and then the forms get dumped into an email or a per-form collection of data. You’re not really building an application, but rather a data collector, and something of a disconnected one.
What I knew I’d have to put together at some point was single fields that were not only Gutenberg blocks, but also fields that knew how to interact with each other. You can put any mixture of these fields anywhere you like on a page, drag a “submit” button out there to join them, and then all the collected data needs to be submitted to the correct parts of the underlying database.
Because, yes, there’s an underlying database. This is what gives you the magic application-building capabilities. And it means you aren’t just piling up disconnected data form entries, but that the data winds up in a relationship to all the other data you’ve collected.
I’ve built a couple of prototype single-field blocks in the past couple of weeks and, honestly, it’s cooler than I thought it would be. That’s because I’m free to use React components on the front end. I’m using a library of components from a company called MUI, and their stuff is just prettier and more versatile than you’re out-of-the-box HTML form elements. I’m not saying it’s not doing pretty much the same stuff, but there are all sorts of small flourishes that I frankly just plain love.
While these collections of fields do operate in the same basic way that forms do, there are some differences (in a good way). For one thing, you can collect data that’s headed off to different data tables in the same form and it’s completely seamless from the user point of view (actually from the designer’s point of view as well–you don’t have to do anything for it to work).
Since all these components use a REST API to talk to the WordPress backend, each field can, if it needs to, validate the input to a field by sending the proposed data input to the server to be looked at. So, to take a somewhat contrived example, normal client-side vetting for an email address just checks to make sure the basic format is right (there’s an @ character, there’s a .com or .whatever). But you could, if you wanted, send the email back to the server, which could ping the mail server to make sure it was really there. Not saying this is generally worth the trouble, but it’s nice to know you have the option to do some actual sanity checking as you validate field input.
I’m not quite sure when the individual field blocks will be ready for release, but I’ve been surprised by how well some of the trickier-seeming parts of this have been going, so I think we’re talking a small number of weeks. It’ll be pretty groovy to roll this stuff out.
