EDITS.WS

Category: wptavern.com

  • WooCommerce Seeks to Improve Cart and Checkout Blocks Performance

    WooCommerce Blocks maintainers are asking the developer community to share feedback on any performance issues they are experiencing with the Cart and Checkout blocks.

    “We’re aware there is work to be done in this area and we want to improve,” WooCommerce developer Alex Florisca said.

    “We’re specifically interested in any performance related issues that may be stopping merchants or developers from adopting the Cart and Checkout blocks over the shortcode version.”

    The plugin’s repository has nine open issues categorized as related to performance. Most of them are not straight forward and require more research and testing. For example, an issue with running multiple blocks of product grids was reported as having increased response times of 4+ seconds. Contributors have proposed a few different ideas to address performance issues, such as experimenting with useSuspenseSelect to improve the perceived loading experience for various blocks and finding a way to track the performance of the Cart and Checkout blocks. Neither of these tickets have seen much movement yet.

    Store owners will not be eager to switch over to a checkout experience that is slower, so the WooCommerce team is seeking feedback that will help them make the cart and checkout blocks faster. So far, one user reported that due to a bug in a third-party plugin, he got a glimpse of what the block-based checkout adds to the JS asset payload.

    “I think this adds at least ~300 kB (compressed) JS payload (initial numbers, my measurement process is still ongoing),” Leho Kraav said.

    “We don’t plan to convert our classic theme to a block theme any time soon, but still, I feel uneasy about this direction.”

    Florisca followed up on this feedback with a few cursory benchmarks comparing the legacy shortcode checkout with blocks checkout and Shopify:

    Blocks Checkout Shortcode Checkout Shopify
    Total Payload 2.9MB 935kb 6.1MB
    Total Transferred 2.1MB 1.3MB* 3MB
    Number of requests 144 77 146

    “The number of requests has almost doubled for Blocks, which isn’t great so this is something that we can look into,” Florisca said. “I suspect the reason is because we rely on a few layers of abstraction on top – WooCommerce and WordPress, each with their packages and set ways of doing certain things. We can investigate if we can simply this.”

    The discussion on how to improve cart and checkout block performance is still open for more developers to give feedback, and investigations are ongoing. The good news is that WooCommerce maintainers are aware of how much weight the block-based checkout adds and are actively looking for ways to improve it for users.

  • WordCamp Europe 2023 Tickets Now on Sale

    WordCamp Europe announced the first batch of tickets on sale for the 2023 event that will be hosted in Athens, Greece, June 8-10. General tickets are € 50.00, a fraction of their true cost, which is heavily subsidized by sponsors. It includes admission to the two-day event, lunches, coffee, snacks, Contributor Day, a commemorative t-shirt, and an invitation to the After Party.

    WCEU is also offering micro-sponsorship tickets at € 150.00, which organizers say is closer to the real cost of attendance.

    Speaker applications are still open but will close soon in the first week of February. Applicants will be notified by the second week of March and organizers will announce the lineup in mid-April.

    WCEU is also seeking a host city for 2024. The minimum requirements are considerably less stringent than in previous years. Hosting the event is open to any team that has organized at least one successful in-person WordCamp in a European city in the last four years with a community that has been active during 2022. Organizers have also published an update to the selection process:

    For this year, we have tweaked the selection process to concentrate more on the local community and the city instead of deep knowledge about how to organise a successful WordCamp Europe.

    The selection of the WordCamp Europe 2024 host city will be based on the overall evaluation of the application, instead of ranking different parts of it. We don’t ask your team to prepare a budget for the whole event, but estimated costs for the proposed venue(s) should be available.

    Contributor Day registration for this year’s event is not yet open but will be free with the purchase of a conference ticket.

    At the time of publishing, only 257 tickets remain in this first round, but more batches will be released in the future. Register now to lock in your spot or sign up for email updates on the registration page to be notified of future ticket releases.

  • WooCommerce Blocks 9.4.0 Adds Support for Local Pickup

    WooCommerce Blocks version 9.4.0 was released with support for a new block-powered Local Pickup option under shipping settings. The feature plugin offers users early access to new blocks and improvements to existing blocks before they become available in WooCommerce core.

    Local Pickups introduces two new blocks: a shipping method toggle block that allows shoppers to select between regular shipping or pickup from a specified location, and a pickup location block that displays local pickup rates.

    image source: WooCommerce Blocks 9.4.0 release post

    These blocks can both be enabled and configured via a new local pickup settings page. Store owners can even rename Local pickup to something else, and optionally add a price for this option.

    It’s important to note that the new Local pickup blocks can only be used with the Checkout block. WooCommerce Blocks also introduces a change with this new Local Pickup experience that will support location-based taxes based on the pickup address, improving tax reporting. Previously, WooCommerce based local pickup taxes on the store address.

    WooCommerce Blocks 9.4.0 includes a handful of other small enhancements and bug fixes. Check out the release post for a more detailed look at everything that’s new in the latest version of the plugin.

  • WordPress Project Aims to Complete Customization Phase and Begin Exploring Collaboration in 2023

    WordPress Executive Director Josepha Haden Chomphosy published a summary of the project’s “big picture” goals for 2023. The goals fall into three major categories: CMS, Community, and Ecosystem.

    WordPress development will focus on completing the remaining tasks for Phase 2 (Customization), and will move on to begin exploring Collaboration in Phase 3.

    “As we prepare for the third phase of the Gutenberg project, we are putting on our backend developer hats and working on the APIs that power our workflows,” Haden Chomphosy said in her recent Letter to WordPress.

    “Releases during Phase 3 will focus on the main elements of collaborative user workflows. If that doesn’t make sense, think of built-in real-time collaboration, commenting options in drafts, easier browsing of post revisions, and programmatic editorial and pre-launch checklists.”

    The vision for the first two phases was “blocks everywhere” and Haden Chomposy said this will be updated for Phase 3 to be centered on the idea of “works with the way you work.”

    In addition to the Phase 3 APIs, Haden Chomphosy identified the following items as part of the CMS goals for 2023:

    • Openverse search in Core
    • Navigation block
    • Media management
    • Simplify the release process
    • PHP 8.2 compatibility (Core and Gutenberg)
    • Block theme development tools

    Under the Community category, WordPress will be focusing on planning the Community Summit, which will be held at WordCamp US in 2023, contributor onboarding, improving Polyglot tools, establishing mentor programs, revamping WordPress.org designs, and keeping pace with learning content. The project is also aiming to develop a canonical plugin program, which should be helpful as some Performance team contributors recently expressed that they don’t fully understand what the process is for canonical plugins.

    The Ecosystem category will focus on the WordPress Playground, an experimental project that uses WebAssembly (WASM) to run WordPress in the browser without a PHP server with many useful applications for contributors.

    WordPress contributors also prevailed upon Matt Mullenweg to consider having the project devote some time to working through old tickets and fixing bugs. Mullenweg said he is amenable to tackling one long-standing ticket (the kind that are stuck because of missing decisions or multiple possible solutions) each month in 2023.

  • #59 – Corey Maass on How To Use WordPress To Kickstart Your SaaS App

    Transcript

    [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

    Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, how WordPress can be used to get your SaaS app off the ground.

    If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL to most podcast players.

    If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you or your idea featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox. And use the form there.

    So on the podcast today, we have Corey Maass.

    Corey is a full stack developer who works with agencies and businesses, large and small. He specializes in advanced WordPress functionality and building products for, and using, WordPress.

    Over the last decade or so SaaS, or software as a service, apps have become more and more popular. Not only are we using our computers more, but with the rise of smartphones, we’re connected to our services all the time. There does not appear to be any corner of life where online platforms don’t have some presence. From email to taxis, fitness to food planning and delivery. You can find it all in a SaaS app somewhere.

    Now that many people are comfortable using SaaS apps, there’s been a deluge of new players coming into the market, but it won’t surprise you to learn that most of them fail to make an impact and shut up shop.

    Corey is on the podcast today to talk about why he thinks that building an MVP, or minimum viable product, app on top of WordPress is a good way to start your product journey.

    We talk about how WordPress comes bundled with many of the features that apps require. User login, roles, permissions, and the REST API. This means that you don’t have to reinvent the wheel for the things that WordPress already does.

    On top of that, the plugin ecosystem which surrounds WordPress, might enable you to short circuit the need to build all the features that your service needs. It may be that there’s an existing plugin, which does most of what you require, and is ready to go right away.

    Corey talks about how using WordPress in this way might enable you to see if there’s really a market for your app. And if there’s not, you’ve used less resources finding that out. And if there is, then you might have some revenue to develop the app in other ways.

    If you’ve toyed with the idea of creating a SaaS app in the past, but never quite got there, this episode is for you.

    If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast. Where you’ll find all the other episodes as well.

    And so without further delay, I bring you Corey Maass.

    I am joined on the podcast today by Corey Maass. Hello, Corey.

    [00:03:58] Corey Maass: Hey there.

    [00:03:58] Nathan Wrigley: Very nice to have you on. Corey, we’re going to talk today all about the capabilities of WordPress as a SaaS platform. But as we typically do on this podcast, it would be very nice if we could orientate the listeners, allow them to figure out what your credentials are, what your WordPress chops are, if you like. So would you spend a few moments just giving us a brief potted history of your relationship with tech and WordPress more specifically?

    [00:04:24] Corey Maass: Absolutely. Back in the late nineties in college, a roommate of mine introduced me to this internet thing and the first websites I saw were some of my favorite bands. And I was a aspiring musician at the time, and I said, well, I want to appear as famous as they are. How do I make one of these website things, and the rest is history.

    I taught myself basic web design, web development. That led to learning some programming, JavaScript and then ASP classic way back in the day. But around that time there was the new trend of SaaS apps. 37 Signals was popular talking about this. Forums like Joel Spolsky’s, Joel on Software. And I caught the bug because I’ve always had an entrepreneurial streak.

    So I said, oh, this internet thing, building software, but not selling a download, but selling access to a website. So, I started going down that path, building websites for clients, but also building SaaS apps to try to sell on the side. And then WordPress took off and for a number of years, WordPress was pretty much my day job. Doing development or website setup or what have you, and then building Sass apps. Not using WordPress for a number of years.

    And then suddenly the light bulb went off. One, the WordPress market was getting bigger and bigger, and I realized that there actually was money in it. So that led me to start building plugins, which I think is what had you and I talking last time. But also at some point it occurred to me that WordPress had matured enough and solved enough of the problems that I was encountering over and over building SaaS apps that I said, let me look at WordPress as a SaaS platform, and I’ve been doing it ever since. So now it’s been probably five years or something, and WordPress only continues to mature, and this conversation continues to evolve.

    [00:06:27] Nathan Wrigley: So you, in the last few years, you’ve joined together the idea of a SaaS platform, but with WordPress handling some of the basic things in the background, if you like. I say basic, I just mean some of the things that we are more familiar with in WordPress. So user management, obviously if you throw some other things like WooCommerce at it, you may be able to handle billing or subscription or whatever it might be, and getting people to the right page depending on whether they’re logged in or not. Is it basically the promise of that? You can cut out a whole body of work, which you would need to build, well potentially from scratch, each time you create your own new SaaS app?

    [00:07:04] Corey Maass: Yeah, I think that’s the way to think about it. So, when you’re solving problems for people online, these days it’s definitely more broad than it was five years ago and 10 or 15 years ago, of course. So if you’re building something that’s B2B, technically speaking. So if you’re trying to build an API or some sort of true service that other systems are going to talk to. WordPress is probably not the answer you want.

    The REST API is, has come a long way, but it’s not really what it’s meant for, right? But if you think of most B2C apps, business to consumer, most of these apps are websites that you’re signing into. Well, WordPress accommodates that. You’re clicking through from page to page. WordPress accommodates that. You’re taking billing, you’re handling subscriptions. WordPress with WooCommerce or Easy Digital Downloads, or Restricted Content Pro or any number.

    I’ve been paying more attention to the membership plugins lately, which are in some ways are specifically designed to handle exactly this problem. Users signing in and doing something, interacting. Interacting with the website. Interacting with each other, that kind of thing. One of the things that, an example that I pick up on a lot is, years ago when I was building apps regularly for clients, for friends, for myself. Over and over and over again, I had to implement some sort of user password reset. And it’s so mundane. Once you’ve solved it once, it’s boring to solve as a developer. But it’s crucial to every app.

    And I got to the point where I was like, I just don’t want to ever think about this stupid problem again. But I had to integrate the code, again every time over and over again. It’s like with WordPress, I never have to think about that. And there’s a plugin called Theme My Login, that’s one of my favorites that you drop in and users can register for your website and immediately get access to a slash dashboard, which you can change. But arguably that’s the first huge leap, you set up a basic website.

    You want users to be able to register and have exclusive access to a page that they don’t have if they haven’t signed in or haven’t paid or what have you. So, these kinds of plugins just solve all of these basic problems. The bottom of the pyramid, so to speak. So that you can get onto whatever problem, your unique problem, that your SaaS is going to solve. As opposed to spending days, weeks, months, tackling the not unique problems like user registration.

    [00:09:36] Nathan Wrigley: So what you are suggesting here, let’s just lay this out. The audience that you are suggesting this to, is people who want to get something shipped quickly. And really, if you are at the beginning of your SaaS app journey, you’re not quite sure yet whether the market even exists. You’re just trying to float a solution to something that you believe might be viable in the marketplace, but you’re not sure.

    So we’re creating a shortcut. We’re offsetting the billing, the user management and so on to WordPress, just as a, as a quick way of getting an MVP or a minimum viable product out there. Is that the idea? Just to sort of test the water? WordPress is a good bet for that, and then presumably at some point you would advise that if it turns out to be an out and out success, then maybe, at that point you might need to look at different tooling.

    [00:10:28] Corey Maass: Not necessarily. There was a time when I would’ve said that definitively, but WordPress has come a long way. Hosting has come a long way. Optimization has come a long way. So it’s definitely the scenario that I’m using WordPress the most. I’ve got a new idea, or I’m working with somebody and they’ve got a new idea and this is how I want to get it off the ground.

    But there are a number of companies, big companies, in the WordPress space that continue to work, use WordPress as the core of their SaaS app, and they’ve got plenty of customers. I think it really, when you get to that level of, if you see a, a good amount of success, then there’s going to be technical problems to overcome.

    And so it’s either ramping up hosting, server power or optimizing queries or rewriting certain aspects of your app. We can talk about that. I had to do that for one of mine, about a year ago. Or again, depending on the amount of user inactivity or user, user interactivity, how much and how often your users are using your app, you may find that it handles it just fine.

    [00:11:43] Nathan Wrigley: So right at the beginning you started talking about why you use WordPress. You mentioned a few plugins, which might assist you on this journey. So I think some of the ones that you mentioned were things like Easy Digital Downloads, WooCommerce, and so on. Whilst I don’t want to necessarily promote certain plugins, I’m just wondering if, given the experience that you’ve had, if you could give us some tips as to plugins that you have found to be helpful for particular problems that you’ve faced while you’ve been trying to build it. And then in a few moments we’ll get onto the subject of how you’ve had to amend WordPress to do things, let’s say more efficient.

    [00:12:20] Corey Maass: Sure. So these days, I actually use Beaver Builder for building pages out. Beaver Builder’s a page builder. Elementor is another good one. But I find that doubling down and knowing these tools well, helps greatly with being able to solve a variety of problems because they’re not a theme, so they’re not locked into a certain layout or that kind of thing.

    But most SaaS apps have a pattern called CRUD, create, retrieve, update, and delete. So if it’s Twitter, then you are creating tweets. You are retrieving tweets, meaning you’re viewing all of them. You can’t really update tweets, but you can update your profile, that kind of thing. And again, you can’t really delete tweets, but you could delete your account, and that kind of thing. Facebook, you can create posts, you can delete posts, your viewing posts, so your retrieving posts, that kind of thing.

    So, a lot, a lot, a lot of software comes down to that pattern, and so using something like, Advanced Custom Fields and there’s a great plugin called ACF Front End, I think it’s called, that essentially puts an ACF form on the front end. So that’s how users can create and update. You could also use Gravity Forms. Or there are a couple of other plugins, form plugins, that you can then put on the front end, for again, collecting data from users or letting users post data. Essentially insert data into the database. And then using something like Beaver Builder or Elementor that have post modules.

    So it’s like if I was recreating Twitter, I would create a form, and this obviously once I’m logged in, but I would create a form that said, what do you want to tweet? And that would insert it into the database as a post record. And then I would use Beaver Builder, me personally, but you could use Elementor or again, any number of page builders, with a posts module that says, okay, show all posts, meaning tweets, with the author of Corey. So then you’ve just created a way to create tweets and then for somebody else to go look at all of Corey’s tweets, that kind of thing.

    So thinking, breaking it down to these kinds of patterns and then looking at these different plugins on how to solve them. A lot of the time I’m able to find ways to quickly implement. And it, again, it doesn’t have to be quick, and this doesn’t have to be forever, but a lot of the time it can be where WordPress and these plugins can solve these problems so that my SaaS offers the, again, the unique problem or solves the unique problem that I’m, the whole reason I’m building it in the first place.

    To get back to your question about those other plugins in particular. If you only want users to sign in, I love the plugin called Theme My Login. Again, look at membership plugins. And then, if you want to charge, again, break down the problem. What are you actually, what do you want? Usually you want subscriptions, like that’s a SaaS pattern that most people are used to now. And what are users paying for? Usually they’re paying for access to a page or pages or content or some feature to interact with other users or something like that. And there are plenty of plugins that restrict content. Which is the way to think about that.

    And so there’s literally Restricted Content Pro as a plugin. Easy Digital Downloads, which is e-commerce, but they have an add-on for restricting content. WooCommerce is really more e-commerce, but can handle this kind of stuff. And then again, membership plugins that are, as people are setting up communities, as at least some people are trying to get away from social media and get back to more private communities without relying on Facebook groups or Twitter or what have you.

    Membership plug-ins have been mature for a while, but are, I’m seeing them become even more and more popular. And are designed exactly for this. So a user pays for access to features, pages, what have you. And that’s again, kind of the core of most SaaS apps.

    [00:16:24] Nathan Wrigley: I suppose that if you are thinking of building a SaaS app, you must have some kind of kernel of an idea of whatever it is that you are trying to solve. So, you’ve got this fabulous idea, and the most important thing at that point is to judge whether or not this idea A, can be built, and let’s assume that after sitting down and thinking it through and mapping it out, you’ve decided, yep, yeah, this has got legs. This can be built with the technology that’s currently available on the web.

    And then thinking, okay, is there an audience for this? Are there going to be enough people out there who are willing to open their wallet to make it worthwhile? And if you go down the SaaS route, you may very well be an incredibly adept developer, in which case this may be in your purview.

    But if you are not and you are just trying to figure out whether the market is there and you want to do that affordably, then WordPress seems like a fairly decent bet, just because of what you said. The fact that with 60,000 plus plugins in the WordPress repository and countless more that you can purchase, in many cases for a very small amount of money.

    It may be that you can get 90%, 80%, 70% of the features that you are trying to build, but without having to do much in the way of custom coding. It may be that you can’t get a hundred percent of the way there, and that would require some tweaking, which we’ll get into. But is that essentially it? You know, you might have to cut some corners or, on your roadmap, cut out some of the things that you really thought would be nice to have in and just go for the things which can be enabled quickly and affordably.

    [00:17:58] Corey Maass: Yeah, I think it just depends on what you’re trying to accomplish. I have a buddy who is non-technical, knows enough CSS to be dangerous, which he’s learned over times, specifically for this scenario. He wanted to create a mentor program, and so he needed scheduling for matching mentorees to mentors.

    So we found a plugin that did that, or did that well enough. And then put I think a membership plug in. I don’t remember how he handled subscriptions. But basically put WordPresses stylized user management in front of it. Limited access to features based on a user being logged in or a user paying. And then a little bit of CSS to make it look a little more integrated or little more branded or what have you.

    And that was kind of all he needed. It solved the problem. He was able to charge for it. He got some customers. And then at some point he did end up hiring a developer to add a few bells and whistles or whatever features he found that were missing. But yeah, it got him 70, 80% of the way. Arguably it got him a hundred percent of the way of solving the problem enough that at least users could start using it.

    [00:19:10] Nathan Wrigley: Yeah, I suppose that’s it, isn’t it? If he’s got a core body of users, and he’s determined that, in this case he can use a calendar plugin or whatever it may be, and it will get him the user base that he needs. Then he can start to use the revenue that’s generated from the, let’s call it the SaaS app, to invest in having something done bespoke.

    That’s really interesting. That’s kind of nice to know. I guess one concern, which I may have, and I’m sure you’ve come across this before. Is just the notion that if you did build this and you fully had the intention of it staying on WordPress for all time. Then you are of course very much dependent upon the plugins that you are using. The spaghetti of plugins being updated regularly.

    In many cases that would very much be the case. It’s updated frequently. It’s made secure, and any vulnerabilities and things like that are taken care of. But there is always that chance that the developer of a key part of your SaaS app may just decide to call it quits, and then you might be left hanging a little bit.

    [00:20:14] Corey Maass: And the scenario I’ve seen more often is a mature product. Meaning your own SaaS app evolves away from what the plugin that you purchased does. So I saw this with a very big company in the WordPress space, who long ago had built their platform on top of EDD, Easy Digital Downloads. But over time had hacked and slashed at it, so that they couldn’t update it anymore.

    And that’s just a decision they had to make at some point of whether they were going to keep going with EDD and just lean into the features that EDD had and forego the other features. Or most good, big WordPress plugins are well documented and have hooks so you can add function extra functionality, or figure out how to sort of hack around them, to a point.

    And then, yeah. They had to make the decision to just stop updating it, and there was discussion. Last I heard that they were going to maybe move to something custom altogether. But the idea being, one of my favorite phrases, we made the best decision we could with the information we had at the time, right?

    So starting out early. It solves all your problems. Go for it. And then down the road you can migrate away from it. You can code around it. You could build something custom, what have you. But yes, that is certainly a risk. I mean, it’s also a problem that a lot of apps have broadly speaking. So it’s, you know, if you’ve built an app that uses the Twitter or Facebook API, you’re putting yourself in their, their hands.

    Or if you are operating system dependent or even, something I’m seeing right now is, microchip dependent, right? If you build software for MacOS and it only works on Intel and, and they move to M1 or M2. So these are just risks that I think you assess over time.

    But what I like is, the point you keep emphasizing, that this is a, a way to solve the technical problem. What I think that a lot of SaaS founders, small and large, real and imaginary, don’t take into account and, I struggle with, and most of us struggle with, is that these days the technical lift of building an app often pales in comparison to the marketing.

    We hear about these wonderful, amazing stories, like Instagram selling for whatever it was, 8 billion after two months, and yada, yada, yada. Most SaaS apps fail. And so you, you want to build quickly with a low lift and then spend most of your time, like you said, trying to get it in front of customers, validating the idea, getting feedback from customers about what features they actually want, or now that you’ve built the features they want, does it actually solve the problem for them?

    All of that is arguably way more important than the actual platform you use. But that’s what brings me back to WordPress as a platform, is in fact often a great way to get something out the door. Even if it’s just a form to collect data and then a page builder or a theme of some kind to then show the data back to the user, if that’s what solves the problem.

    [00:23:36] Nathan Wrigley: It’s interesting because if there’s a body of people listening to this who are not building SaaS apps on WordPress, and they’re just building client websites, you’ve probably encountered that scenario where the client comes and they have incredibly grandiose expectations of what they want the website to do.

    And because you’ve been building websites for so long, you just know, you have an instinct which says, well, we could build all of that. But how about we just start here? Because I would imagine it’s quite unlikely that your staff are actually going to start using some kind of intranet solution that we build as WordPress. Or some messaging system that we build in the app. It’s much more likely that they’ll continue to use things like Facebook Messenger or WhatsApp or Slack or whatever it may be.

    And so over the years you’ve become accustomed to figuring out what is plausible, what is likely to work, and I think I feel it’s the same with SaaS apps. It’s very easy to come to the table. You’ve got your blank canvas and you throw everything at it, every idea, every permutation, every possible thing that the app could do, and then decide that’s what must be built.

    That’s it. Until that is all done, we’re not going to launch it. And I think history shows that you have to be much more agile than that. You have to be able to drill it down and say, okay, what’s the 10, 20, 30% of all of that, that we’ve decided upon, which is going to get us off the ground? And so that feels like where this goes. If you try to build everything, it’s probable that you’ll A run out of money, B run out of time, and nothing will be shipped.

    Whereas in your scenario, offset the uninteresting jobs that probably don’t need to be tackled because they’ve already been tackled by plugins or WordPress Core. And just concentrate on the things which are going to benefit your users. And frankly, you don’t know what is going to benefit your users.

    It’s always amazing to me when I open up a new SaaS app that I’ve never use before. And you think, oh, this will be perfect what I need. And you end up on support saying, does it do this? No, I wish it did that. And those companies that succeed tend to be, well in my experience, the ones who listen to their early adopters and quickly pivot their solution to satisfy them.

    [00:25:45] Corey Maass: Exactly. There’s obviously no harm in thinking through what your dream app does, all the features. You make a long, long list. But one of the things that drew me to WordPress plugins, and selling WordPress plugins early on, was a rather cynical observation that I made.

    I was building blogs for customers. I was building e-commerce websites for customers. And instead of writing another article, which is hard and work. Or instead of inserting more products, which is hard and feels like work. A lot of my clients would get in the WordPress plugin repo where all the plugins are free and go, oh, I could use a to-do list plugin and they’d install it.

    Or, it’s winter. I should install a plugin that adds snowflakes falling over my theme. And they would waste an unbelievable amount of time on what felt productive and felt free. And I was like, well, if people are people, we are all human, we are all valuable and we are all, don’t want to do the things that are hard.

    But I see all these people that are spending time just digging through the plugin repo, I’m going to start building and selling plug-ins, because the discoverability is amazing. And so I think you’ve touched on that for SaaS as well, which is, we generally shy away from the things that are hard.

    We also tend to skew towards our own genius. What we think is the best idea. Because we thought of it isn’t necessarily the features, or it isn’t ecessarily solving the problem that your actual paying customers have. The real strength, and the real challenge, comes more in that side of things. Marketing, sales, talking to customers, getting over your own ego, optimizing your own time, all that kind of stuff.

    [00:27:48] Nathan Wrigley: Yeah. It’s interesting the marketing piece you mentioned. Never ceases to amaze me how much of the overall budget needs not to be sunk into the development of the actual software, but in alerting people to its existence. A significant amount. And it’s not to be underestimated.

    And obviously if at the beginning you sink a hundred percent of your finances into the code, that’s great, but I guess you better be a really good word of mouth, somebody that can spread by word of mouth incredibly successfully. Because experience at least tells me that it’s very hard to gather an audience from a standing start.

    So we’re a WordPress podcast. We’re obviously very keen on WordPress, we think it’s amazing. But I’m guessing that there must be downsides to this. Let’s just talk about that for a moment. Any drawbacks to this system that you’ve encountered over time? Just some quick examples may be that, well, does it scale very well? Does WordPress tend to be doing a lot of things in the background that a leaner, more specifically custom-built solution may get you out the hole of? Just questions around that. Any drawbacks that you would alert people to if they do decide to go down this approach?

    [00:28:59] Corey Maass: A few years ago, I was tasked with building a food subscription website. So think Blue Apron or Freshly kind of website, if you’re familiar with those. And for better or worse was told that I had to use WooCommerce. And so I spun up a WordPress website, installed WooCommerce, got subscriptions going, customized the choose the meals that you want, and then check out. And that all was okay.

    But it turned out that, I think some of this has been changed, because this was a number of years ago but, WooCommerce was storing all of the data in a very WordPressy way, which was fine because it was a known pattern. But was not very optimal. And then for the business, because all of those meals were cooked every morning and then shipped out, all of the charges had to go through at the same time, at like two in the morning. And it turned out that WooCommerce subscriptions was built so that if you signed up for a subscription at 10:30 in the morning, it would renew at 10:30 in the morning. While we needed it to renew at two in the morning so that all of the orders went through, so then the chef knew how many dishes to make, and how many chicken dishes to make or whatever.

    And that’s the kind of risk that you run into, right? So if you are using a third party piece of software, WordPress, and then with plugins. And you are essentially building it to your, or bending it to your will, so that it’s doing things that it’s not necessarily meant to do. You’re going to run into issues.

    We found that our server didn’t have enough power to process all of these orders at the same time, because it’s essentially multiple threads need to be run at the same time. We wound up in that instance sticking with WooCommerce and WordPress for at least a little while longer.

    But switching off of a hosting company that really was most popular for blogs and delivering content and not necessarily running process, CPU power. And moving to a custom AWS set up. And we watched the CPU go from 80% all the time, to 3% all the time. So in that instance, we just needed to throw more metal at it.

    But again, we were definitely using a tool, at least slightly, in ways that it wasn’t meant to do. I also, during the pandemic, or at the beginning of the pandemic, my wife made the mistake of turning to me and saying, you know, my family plays this game called Mexican Train, in person all the time. Boy, I wish there was an online version. And she should just know better than to put that kind of idea in my head.

    So within a couple of months I had spun up the only interactive online version of Mexican Train, which was great for our family, but it’s a very popular game in retirement communities. And naturally during the pandemic a lot of people in retirement communities were isolating a lot more. The game became quite popular, because it spread word of mouth. And the first Christmas, I think I built it early in the year, and, and the first Christmas it peaked at like 2,600 concurrent games or something. Which, for me, I had never built anything that needed quite that much power.

    And it did eventually fall over. But initially I’d built it so that every time somebody played, all the other games, so four people are playing, basically all four games are sitting there pinging the server, looking for updates. That’s very inefficient because most of those pings don’t return anything, but the CPU still has to accommodate them. So I wound up switching to a pushing system. So I had to integrate with that. And originally I had built it so that the game itself, so when you’re signing into mexicantrain.online, that’s the website, the login screen you’re seeing is Theme My Login.

    All of the delivery of content, so like when you go to the My Games page and you see all of your games, that’s just Beaver Builder. And then the actual game I had to build, so it was quite a lift as far as development goes. But that was what that SaaS needed. But I built an app in a JavaScript framework called React that then talks to the server.

    Well, I built the initial version using the WordPress API. So my game talked to WordPress, functionality that was built into WordPress. And the API worked, until it didn’t. So, in that instance, again, too many people hitting the server too much. Aw, shucks, it was too successful.

    I had to revisit it after a year or two and build a custom API. Now I’m a developer. I have that luxury, right? But these are things that, I got enough of a version out the door. So, thinking about it from the perspective of a non-developer. I could have set up most of it except for the game itself.

    And the game is sponsored by donations. So I installed GiveWP, which is one of the bigger WordPress donation plugins. And I still used the free version. And so I got most of those sort of basic stuff using third party plugins out of the box. And then if I wasn’t a developer, I might have had to hire a developer.

    And so yes, I would’ve had to put some money into it. But they wouldn’t have had to build everything. And I also could conceivably hire different developers, or I could by using WordPress. So one of the things we haven’t talked about is because of the popularity of WordPress, you also have a lot more developers to choose from if you’re going to hire somebody.

    But anyway, if I wasn’t a developer, I would’ve had to hire somebody to build the game. And then down the road, presumably I would’ve proven that the platform was popular, hopefully in the form of donations, which would’ve been enough money to then hire somebody to rebuild the API, if I couldn’t have done it myself.

    You know? So there’s sort of this evolution of, as you’ve said. Try things, see if it’s popular, and then maybe hire somebody if you have to, you know, if you’re going to grow parts of the platform, parts of the app beyond WordPress.

    [00:35:40] Nathan Wrigley: It’s really interesting you mentioning about all of the very large number of WordPress developers. The developers I guess, go into different niches, don’t they? They might be experts in one field or another. Do you detect that there’s a lot of people doing this kind of thing? Building SaaS on top of WordPress. Or is it just you shouting into an empty room? What I’m basically saying is, is there a community, a subset of the WorldPress developer community who, like you, are interested in building SaaS apps on top of WordPress.

    [00:36:10] Corey Maass: There is a book called Building Web Apps with WordPress that came out from O’Reilly. So it’s popular enough that people are writing books about it. I’ve given talks on it at a few different WordCamps as far back as I think four or five years ago or more. And I’ve come across a number of people who are doing it, or are thinking about it or have done it. But it’s definitely not, and even Mullenweg has talked about it, but it’s not the most common use case.

    I think in part because people just don’t necessarily think about SaaS apps separately as much anymore. More and more websites do something. And so if they have functionality, maybe that people are paying for, and users are signing in to use the web app to do something.

    It’s a SaaS app. But that’s, again, I think more and more commonly just how people view websites. So it’s not necessarily something that people are thinking about or searching for. Except for, I think, as you’ve mentioned a few times, if you’re looking for no code now means something different. But if you’re looking for a non-developery way to spin something up quickly using third party software, then it still gets some attention. But to answer your question, no, I’ve never found a community. I’ve thought about starting one, but never have. Because I just haven’t gotten a sense that enough people are talking about it.

    Which is okay. Maybe at some point they will, or, you know, maybe some other better solution will come along and consistently solve the problems. But, right here, right now, I still find WordPress a great option.

    [00:37:57] Nathan Wrigley: It’s really interesting because curiously, there’s a great deal of overlap with something that’s going on in my world at the moment in that I have been working with a developer on a SaaS app. I won’t go into the details, but reached a point where a couple of years ago, the interest in it, from my point of view, I think probably, is best to describe it. It waned a little bit and so it went on the back burner and it’s never been revived.

    And as a couple of years have gone by, I’ve decided that, actually wouldn’t it be nice to revive this? And so with a couple of friends decided that, yeah, let’s give this another go. But actually, let’s just begin again, because I’ve noticed there’s significant things in what’s already been built that I would change.

    And guess what we’ve decided to do? We’ve decided to do the MVP inside of WordPress. Basically for pretty much all the reasons that you’ve suggested. We’re familiar with it. There are sometimes free, sometimes commercially available plugins, which will do a significant amount of the lifting. Will it be exactly what we would like from our roadmap? No. Will it be close enough to get us to measure whether there’s an audience for this? Yes, I think it will. And so, curious that this is actually playing itself out in my life at this moment.

    [00:39:19] Corey Maass: Nice, yeah. Depending on the problems you’re trying to solve, but I think that’s like most things, a bit of planning, sit down, design. I encourage everybody to do this. What is the all the bells and whistles version. We nerds are a big fan of what’s called the 80 20 rule.

    So what’s the 20% that needs to be solved now, today to prove the idea? And then see what plugins align with that. How they can get you there. Will it solve the problem? Do you need custom development? Are there features that just don’t have solutions or aren’t solved by any of the plugins you might want to use.

    And then go from there. See what you can do. The nice thing too about WordPress is you can start locally, which is free. Locally meaning on your computer, not locally in your town, although you can do that too. Most computers using software like Local WP, I’m a big fan of, and there’s a few others. Also InstaWP, which lets you spin up instances of WordPress online for free, for, you know, seven days or something, and then pay to keep them, or you can download them, I think, I don’t know.

    I definitely have been guilty of getting an idea and I needed to illustrate the idea rather than just write the idea down. So I spun up an instance of WordPress real quick. Installed a couple of plugins real quick, and then said, what do I need next? Or what would the next step be? Or, if I was a user, what would I expect to see next? All that cost me was a little bit of time. There’s kind of that advantage too, where it’s, you can use it for wire framing means something specific, but conceptually you can use it for wire framing ideas, which I think is crucial. Without it costing you anything.

    [00:41:04] Nathan Wrigley: Corey, if people listening to this, if they’re resonating with it and they’re thinking actually, do you know what, this is something that I’ve been doing for a while, or, I’m curious to get into the community that you said might need to exist. Where would be the best place to get in touch with you?

    [00:41:20] Corey Maass: Honestly, the place that I talk about this the most is Twitter. twitter.com/coreymaass, c o r e y m a a s s. Just start a conversation with me. I’d love to hear people who are interested in this. If this resonated with them, if they’ve tried it at all. Because again, I’ve run into people who have done it. I’ve heard about people doing it. A book exists. So there must be people talking about it somewhere.

    But I think it would be neat to have a community of people, or even just a network of people, helping each other out, solving some of these problems. Hey, does anybody have a good recommendation for a plugin that solves such and such a functional, or a problem that I have. Where should I start? Suggestions for hosting companies. I mean, there’s, there’s always information to be shared. And honestly, that’s one of my favorite things about the WordPress community is that it’s so open. So many people are talking to each other and willing to help each other. I definitely think there could be more conversation around using WordPress as a SaaS platform.

    [00:42:21] Nathan Wrigley: Corey Maass. Thank you for chatting to us on the podcast today.

    [00:42:25] Corey Maass: My pleasure.

    On the podcast today we have Corey Maass.

    Corey is a full-stack web developer who works with agencies and businesses, large and small. He specialises in advanced WordPress functionality and building products for, and using, WordPress.

    Over the last decade or so, SaaS, or software as a service, apps have become more and more popular. Not only are we using our computers more, but with the rise of smartphones, we’re connected to our services all the time.

    There does not appear to be any corner of life where online platforms don’t have some presence. From email to taxis, fitness to food planning and delivery. You can find it all in a SaaS app somewhere.

    Now that many people are comfortable using SaaS apps, there’s been a deluge of new players coming into the market, but it won’t surprise you to learn that most of them fail to make an impact, and shut up shop.

    Corey is on the podcast today to talk about why he thinks that building a MVP, or minimum viable product, app on top of WordPress is a good way to start your product journey.

    We talk about how WordPress comes bundled with many of the features that apps require, user login, roles, permissions and the REST API. This means that you don’t have to reinvent the wheel for the things that WordPress already does.

    On top of that, the plugin ecosystem which surrounds WordPress might enable you to short circuit the need to build all the features that your service needs. It may be that there’s an existing plugin which does most of what you require, and is ready to go right away.

    Corey talks about how using WordPress in this way might enable you to see if there’s really a market for your app. If there’s not, you’ve used less resources finding that out. If there is, then you might have some revenue to develop the app in other ways.

    If you’ve toyed with the idea of creating a SaaS app in the past, but never quite got there, this episode is for you.

    Useful links.

    37 Signals

    Joel Spolsky’s, Joel on Software

    Easy Digital Downloads

    WooCommerce

    Advanced Custom Fields

    ACF Frontend

    Gravity Forms

    Beaver Builder

    Elementor

    Theme My Login

    Restrict Content Pro

    Corey’s Mexican Train website

    GiveWP

    Building Web Apps with WordPress book

    Local WP

    InstaWP

  • Jetpack Revamps Mobile App, WordPress.com Users Must Migrate to Keep Using Stats, Reader, and Notification Features

    When Automattic launched a mobile app for Jetpack in June 2021, it was targeted mainly at users who were on a paid Jetpack plan, as it enables access to features like backups, restores, and security scanning. Most importantly, the app gave Automattic a more direct path for monetizing Jetpack, without adding more commercial interests into the official WordPress apps.

    This week Jetpack announced that it has revamped the app and is offering a more compelling reason for those using the free plan to migrate. As part of a longterm effort to refocus the official WordPress apps, features that require Automattic’s products (the Jetpack plugin or a WordPress.com account) in order to use them, will soon be removed. This includes the Stats, Reader, and Notifications features, which have been relocated to the Jetpack app.

    WordPress.com announcement for the revamped Jetpack app

    WordPress.com users and Jetpack users on the free plan who previously relied on these features will need to switch to the free Jetpack mobile app. All the features that are moving over from the core WordPress app will still be free in the Jetpack app.

    While most self-hosted Jetpack users may easily understand the need for the switch, this transition may be rougher for WordPress.com users who do not understand the history of the mobile apps and see it all as “WordPress.” They may not be aware that Automattic’s integrated products have been controversial features in the official WordPress apps for nearly a decade.

    The announcement on WordPress.com is confusing, as it presents Jetpack as just a new optional app and doesn’t convey the urgency of migrating if users still want access to stats, notifications, the reader, and any additional paid features.

    The post’s FAQ section describes the Jetpack app as “the premium mobile publishing experience for our super-connected world” and states that “the Jetpack app is free to download.” WordPress.com users who commented on the post found the words “premium” and “free to download” to be suspicious and confusing. They don’t understand the reason for two apps:

    “Do we have to change over? I only want to blog, I’m not technical and I don’t understand why you have done this or how to use it?”

    “So is WordPress now called Jetpack?”

    “If it ain’t broke, don’t fix it. This move is not in your users’ best interests so why is it being done? This smacks of the recent pricing debacle.”

    “I’m really disappointed by this decision. Why are you forcing us to use two apps? Your explanation of the differences makes no sense, and sounds like you made a decision for some reason you won’t tell us and you’re just trying to justify it. This is not user-focused at all.”

    Users are also concerned about data loss, as those who are migrating to the newly revamped app are advised to delete the WordPress app after installing the Jetpack app. The announcement states that “Managing your site across both apps is currently unsupported and may lead to issues like data conflicts.”

    One user asked if there are premium features in the Jetpack app that will carry additional cost, and if there is any advertising included within the app.

    “For clarity, the Jetpack app is free to use and doesn’t include in-app advertisements,” Automattic representative Siobhan Bamber said.

    “We’re still planning our 2023 roadmap, and it’s possible in-app purchases will be a part of our plans. The driving goal would be to offer features that bring most value to users, and we’re keen to hear any ideas or feedback. Any in-app purchases would be optional, with the currently free features remaining free to use.”

    In response to those asking about the differences between the two apps, Bamber said there will be a couple more posts on the WordPress.com news blog in the following weeks.

    Users will need to have the latest version of the WordPress app installed in order to automatically migrate their data and settings to the Jetpack app. This includes locally stored content, saved posts, and in-app preferences. The FAQ states that after users download the Jetpack app, they will be “auto-magically” logged in with all their content in place.

    “One good way to confirm whether your version of the WordPress app supports ‘auto migration’ is to tap one of the in-app ‘Jetpack powered’ banners,” Bamber advised users in the comments. “You’ll find these banners at the bottom of sections including Stats and Reader. If you tap the banner, you’ll only see the ‘Switch to the new Jetpack app’ prompt in versions that support migration.”

    The revamped Jetpack app has been presented to WordPress.com users as a more feature-rich way to publish to their websites, but it also lays the burden of choice on users to try to understand the difference between the two apps and select one for all the sites they manage. Many don’t want the inconvenience of switching to a new app. Based on the users’ responses, it might have been easier for them to understand that the official WordPress apps are removing all features require the Jetpack plugin or a WordPress.com account – instead of selling it as a new, shiny publishing experience.

    Migrating to the Jetpack app is the best option if you want to continue using the Stats, Reader, and Notifications features. In order to make it easy for users to choose the best path forward, future posts on WordPress.com should make it crystal clear what features users can expect in each app and when they will need to take action.

  • WooCommerce 7.3 Introduces New Products Block in Beta

    WooCommerce 7.3 was released this week with the new Products block now in beta. In December 2022, the Products block went into testing in WooCommerce Blocks version 9.1.0. It’s based on the Query Loop block and is intended to replace all of WooCommerce’s current product-displaying blocks.

    This first beta version of the Products block allows users to list products based on specific criteria and their layout in the list or grid.

    Version 7.3 also introduces three “commerce-adjacent” patterns for building WooCommerce store pages. These are patterns that do not tap into WooCommerce store data but allow store owners to customize the images and the links. These patterns were also tested in WooCommerce Blocks 9.1.0. They include an alternating image and text block pattern, a product hero with two columns and two rows, and a “Just Arrived” full hero pattern.

    image source: WooCommerce 7.3 release post

    This release also brings store owners a new multichannel marketing experience in beta. Under the Marketing menu in the admin, users can now view a list of recommended marketing extensions without leaving the dashboard. These can be installed directly from the Marketing page.

    Other notable features in WooCommerce 7.3 include Pinterest and Codisto extensions added to the onboarding wizard, a new warning banner when the tax settings have a conflict, and an improved UI for creating product attributes and uploading product images.

    Check out the release post to see the template changes and all the new actions and filters available for developers. The full 7.3 changelog is available on GitHub.

  • Lettre Newsletter Theme Now Available on WordPress.org

    Automattic has published its Lettre theme to WordPress.org. The company launched its newsletter product at the end of December 2022 using Lettre as the default theme. The self-hosted version of this block theme is for those who want to publish a newsletter using Jetpack.

    The theme puts the focus on the subscription form, which is the most important thing a newsletter landing page can do – make it easy for people to sign up. Beneath the form there is a link to read all the posts, followed by another subscription form. All of these elements in the home page design are blocks, making it easy for them to be removed or rearranged.

    Lettre comes with 15 block patterns for building different pages and designs, including about the author(s), a bold color signup, a two-column signup, various designs for the newsletter intro with light and dark background images, newsletter signup with media on the left, newsletter signup with logos for the background, a list of posts, an in-post article promo, three columns of text, and more.

    A live demo of the theme is available on WordPress.com. The menu items on the demo give a few examples of the different signup patterns in action.

    Lettre is designed to be used with Jetpack’s Subscription block, which uses WordPress.com’s infrastructure to manage emails and subscribers. If you like the design but are already using another newsletter service, the Jetpack Subscribe block can be replaced with any other block, including the shortcode block for newsletter services that haven’t yet made their subscription forms available via a block. Be advised, you may need to write some custom CSS to ensure that the subscribe form matches the original design.

    Lettre is one of the only themes in the WordPress Themes Directory that was made to be a newsletter landing page and certainly the only block theme dedicated to this purpose. Combined with Jetpack’s subscription feature, this is one of the most seamless ways to distribute a newsletter without all the extra steps of copying the content into a newsletter service’s editor. Lettre is available for free download from WordPress.org. I wouldn’t be surprised to see more themes like this pop up now that WordPress.com has launched its newsletter service.

  • New Video Explores Site Building Progress from WordPress 5.9 to 6.2

    WordPress 5.9 “Josephine” was released in January 2022, but that seems like ages ago when you compare the advances made in site building over the past year. Anne McCarthy, an Automattic-sponsored contributor who heads up the Full Site Editing Outreach Program, has published a short video that tours the important changes in WordPress over the past few major releases. The video also doubles as a preview of some of the features coming in 6.2.

    If you are using the Gutenberg plugin and have been tracking the relentless progress of the Site Editor, you will notice how limited the design options are in 5.9 and how much more consistent and expansive they are today. In 5.9 users users can only add a Front page template, and the site building interface is disjointed and less polished.

    McCarthy demonstrates how WordPress 6.2 will introduce smoother interactions with browse mode. It will also greatly expand the template options available for users to add and includes a new colorized list view.

    The Navigation block has had a long, rocky journey but seems to be reborn in 6.2. McCarthy showed how much more intuitive it has become with the new experience of editing navigation in the sidebar, and repositioning via drag and drop with live previews.

    The instant that Style Variations were introduced in WordPress 6.0, it seemed they were always with us. Looking back at 5.9 in the video, the Site Editor appears so bare without them. WordPress 6.2 will extend this even further with improved block style previews, a style book, and a new zoomed out view that makes it easy to see changes at a glance.

    Everything coming in 6.2 is converging towards better usability and more design options for site editors. The challenge here is to continue introducing new features without the interface becoming cluttered and chaotic. Many of these features are still being ironed out. For example, McCarthy mentioned that the Edit button is still a work in progress and may soon be relocated to be more prominent in the Site Editor.

    This video gives a quick visual summary of what is being done to wrap up the full-site editing phase of the Gutenberg project before contributors move on to Collaboration. It is worth a watch to see the site building progress that contributors have made in just one year.

    If you want to get involved in making sure all these features in 6.2 are ready for prime time, check out McCarthy’s latest FSE Testing Call: Find Your Style. It will plunge you into the new features of the Site Editor to perform a few tasks. It’s essentially a guided opportunity to explore the new interface while contributing back to WordPress, and you will earn a fancy testing contributor badge that will display on your WordPress.org profile.

  • Automattic Launches Blaze Ad Network for Jetpack and WordPress.com Sites

    Automattic is bringing Tumblr’s Blaze ad tool to WordPress sites with its launch today on WordPress.com and Jetpack. Blaze made its debut in April 2022, to the delight of Tumblr users who will gladly shell out cash to get people to look at their cat or promote a game they made. It’s an affordable way to attract new followers or just send out something funny into the universe, starting at $5/day.

    WordPress.com users can now to go to wordpress.com/advertising, select a site, and promote content with Blaze. Jetpack users have access to the ad network inside the WordPress.com dashboard.

    After selecting a post, users are taken to the design wizard where they can add an image, title, a snippet, and a destination URL. The URL can be the post or page or it can direct visitors to the main website.

    When Blaze first launched on Tumblr there was no way to target the promoted content – it just displayed to random users. Now there are a few more options. When promoting content from WordPress.com or a Jetpack-enabled site, users can narrow the audience by device: mobile, desktop, or all devices, select from a few main geographic areas (continents) or serve it everywhere. There is also a dropdown with topics of interest, but they are fairly general, e.g. Arts & Entertainment, Automotive, Business, Education.

    After selecting the audience, users can set the budget for the campaign, starting at $5 with a max daily budget of $50. With a minimum of $5/day for a week users can expect an estimated 5,900 – 8,000 impressions. For $25/day, users can expect 29,700 – 40,200, and up to 59,500 – 80,500 for $50/day. Site owners can monitor the success of their ads in the Campaigns tab.

    Content sponsored by Blaze will be promoted across WordPress.com sites and Tumblr pages, an audience that accounts for an estimated 13.5 billion impressions per month.

    Blazing has become somewhat of an art in the short time it has been available on Tumblr. It will be interesting to see how ads originating from WordPress.com and Jetpack go over with the Tumblr audience.

    Creating advertising content that works across the disparate audiences between WordPress and Tumblr-powered pages may be a challenge for some site owners. Tumblr users can only target audiences by location for blazed posts. It’s possible that WordPress’ additional targeting options can help funnel the ads to sites where they will be most well-received, but the announcement says ads will be promoted across WordPress.com and Tumblr.

    Blaze campaigns require approval to be in compliance with Automattic’s Advertising Policy before being published. They are currently moderated in approximately 30 minutes but this may change in the future as more users try out Blaze.

    Automattic is treading new ground in creating its own ad network that any user across Tumblr and WordPress can tap into. It’s a strategic move to extend access to the world of WordPress, given that it’s such a large audience, and it will be interesting to see how the company improves the targeting options to meet the challenges of serving both audiences.