Only a few months after Pocket died, the girls started lobbying for another dog. At one point, Chris and I were even given a Christmas wishlist slideshow presentation featuring multiple dogs available for adoption. But, with our crazy lives, I kept saying no. Between building a new house, moving, and all the travel we had planned over the last two years, introducing a new creature to care for did not make sense.

Last December, when we wrote our company budget for 2026, we knew we wanted to rebuild our website and that we would need to hire a designer. We ended up shifting the marketing travel budget to subcontractors to pay for a designer. Which means that, for the first time since COVID, I will not be traveling to any conferences this year.

The nonprofit that I am on the board of, WP Accessibility Day, tried, as an experiment, to run a crowdfunding campaign for a sponsor booth at WordCamp Europe. We were hoping to run an accessibility help desk, raise accessibility awareness, and use funds to cover board member travel costs to WordCamp Europe. Unfortunately, while we received some traction, we didn’t get the response we needed to make it happen, so no WordCamp for me.

I’m bummed not to be going to any WordCamps this year, and definitely sad not to be going to WordCamp Europe in Poland. WordCamp Europe is my favorite WordCamp and a great way to continue expanding our reach in Europe. But when you’re bootstrapping, there’s not infinite money for all the things, and we’re definitely at a point where investing in a new website is the best use of marketing budget.

So I was sad not to be going to Poland in June, but a year with no travel also presented an opportunity…

Make the kids’ day and get a puppy!

I surfed around Petfinder, and one Monday, we surprised the girls after school with a trip to visit a litter of puppies at a rescue in Cedar Park.

The rescue hadn’t seen the mom, just the puppies, so we’re not completely sure what he is, but he’s the cutest little terrier mix with scruffy fur. He’s 16 weeks old now and 15 lbs, so he’ll be bigger than Pocket, but not by much.

Following our tradition of choosing “P” names for pets, the girls named him Pico… as in Pico de Gallo. 😆

Diesel seems pretty happy to have a dog sibling again, too. They’ve been playing together and sharing a bed, plus puppy training means lots of treats all day long for both of them, which he’s definitely not complaining about.

As far as the upsides of not going to Europe this year, a new puppy is a pretty good consolation prize.

The post WordCamp Europe Consolation Prize appeared first on Amber Hinds.

Addie’s is a sharpie drawing of houses in a neighborhood connected by string lights on a purple and blue watercolor background.

Vivi’s is a drawing of herself painting on a canvas that says, “I love you,” with a multi-colored striped background.

The post Addie & Vivi’s Art on Display at the Library appeared first on Amber Hinds.

The post Weekend View appeared first on Amber Hinds.

The post Modernizing Nostalgia appeared first on Amber Hinds.

My heart feels like it’s bursting with love and joy when I look at him.

The post Sweet Nephew, Wade appeared first on Amber Hinds.

Given how much Kadence has been focusing on accessibility and how far ahead they are than many other page builders in terms of accessibility, this is a fair question. He had a follow-up comment that he thought going full custom was slowing us down:

Honestly, that's a weird choice. Not about Kadence at all (I'm officially unbiased now)… Why not just build a flat file custom site with Loveable? If you can't build the perfectly accessible site with common WP blocks, only your own custom blocks, then why keep building in WP!?…

— :Cromwell: (@learnwithmattc) January 16, 2026

I started replying in X and realized it was long enough for a blog post… so here we are: a post about my thoughts on block libraries and page builders, and why we generally don’t use them at Equalize Digital (my company).

First, a Clarification…

We use and love core blocks! I’m all about core blocks, and if a website can be built with only WordPress core blocks, that is the best way to build.

This website is, in fact, built on the core Twenty Twenty-Four theme and uses only core blocks. When I launched it, I wrote on our company blog about how I rebuilt my site in 2 days and eliminated thousands of accessibility issues simply by moving away from my previous “off-the-shelf” premium theme and using a core WordPress theme and blocks instead.

Not only did switching themes help with accessibility, but it also significantly improved load times and performance. The coolest thing about using a core theme and only core blocks was that, when I needed to troubleshoot something on the site, I deactivated all my plugins, and my home page looked identical to how it looks with all the plugins active. You pretty much never see that.

So yes, we use core blocks. We just don’t use block libraries. If there’s something we need that core blocks can’t handle (say, tabs), our approach at Equalize Digital is not to look for a plugin to add that functionality; instead, we would code a custom block or a custom ACF block.

Why We Don’t Use WordPress Block Libraries… Anymore.

We used to use block libraries.

We were early adopters of building hybrid websites with the block editor. We were building websites for clients with blocks pretty much as soon as it launched in 2018.

At that point, we used block libraries available via WordPress.org, because, to be honest, we didn’t know how to build custom blocks, and core blocks were incredibly limited (still are).

For years, we sped up our website builds and added cool features without code by using block libraries (and occasionally page builders like Elementor). Back then, most of our revenue came from small businesses or nonprofits, and the goal was to build websites as fast as possible, then maintain them on monthly retainers. Block libraries helped make that possible and allowed us to build nice-looking websites for under $20k.

So what changed?

A few devs ruined it for everyone.

Here’s the short story, without naming names:

• Library A was bought by a hosting company, which then deprecated it and wanted people to switch to a renamed version that was basically the same, but used different class names, which would have required us to edit all our custom styles.
• Library B changed its CSS class names during an update, breaking all our custom styles.
• Library C, on update, changed the loading order of its stylesheet so it loaded last, which meant it loaded after our theme stylesheet and thus overrode all our custom styles.
• Library D was abandoned and then removed from dot org due to security issues, which we had to patch in the version on our website because it was used in too many places to remove and was no longer supported.

There are amazing block libraries that do what they do really well, and I put Kadence up there. But basically, A, B, C, and D ruined it for everyone.

No one wants to test a plugin update and realize they have to redo a ton of work or spend hours on support with the plugin dev before they can push updates live — especially for stupid reasons like CSS class name changes that break backward compatibility.

To put it frankly, after those experiences, I don’t trust third-party devs who know nothing about my website or my priorities to not F my website up. 😂

Enterprise websites require a lot more attention to detail.

The other factor in our decision not to use block libraries is that, over the years, we shifted from building small-business websites to enterprise websites and web applications for government, higher education, large publishers, health care clients, and the like. Projects were no longer $15k; instead, they were $60k–$140k+—essentially enterprise WordPress.

In the land of enterprise WordPress, where accessibility, security, legal compliance, performance, and conversion optimization really matter, you have to be a lot more picky about what goes on the site. Every plugin introduces risk: extra code to monitor, potential accessibility barriers, new security risks, performance overhead, and UX decisions you don’t fully control. At scale, those trade-offs compound quickly, so the question isn’t just “Does this plugin help us build faster?” but “Does it meet our standards, integrate cleanly with our stack, and help our clients meet their legal, business, and user experience goals over the long term?”

Increasingly, block libraries never felt worth the trade-offs or loss of control, especially because they are the foundation of the website.

If something goes wrong with a block library, it can require significant rework.

When you build your website with a block library, you use components that are central to how your pages look and are interacted with. Things like accordions, tabs, layout blocks like columns or grids, maybe even basic components like button links, headings, or image galleries are controlled by the library. These components are typically used everywhere on the website.

If that library is abandoned or you decide you don’t want to use it anymore, you’re now signed up for huge amounts of work to remove or replace the components across potentially hundreds or more pages. The entire site may need to be rebuilt even if you didn’t change the theme. (This is no different from if you decided to switch away from a page builder.)

If you, instead, build your pages with only core blocks or custom/ACF blocks, there’s less inherent risk of needing to rebuild because:

1. Those blocks are not controlled by a company that has totally different priorities than you do.
2. Even if you rebuild, it’s easy to migrate your custom block code between themes or restyle core blocks in a new theme.

Not wanting to rebuild lots of old content during your next redesign is one of the reasons I advocate for only using core blocks in blog posts, and definitely never building them with a page builder. I’d also say it’s safest to make rules like only using core container blocks (columns, grids, etc.).

There is a Line

I’m not saying there is no place for block libraries. I’m also not saying that everything on websites should be custom.

Some things are not worth maintaining.

For certain complex functionalities, such as forms, e-commerce, CRM, payment gateway, or API integrations, etc., it makes total sense to buy a plugin rather than maintain them yourself.

Features that are deeply intertwined with security or legal compliance, or that add mission-critical platform functionality to your website, are typically better achieved by buying a plugin rather than custom coding. Companies (or individuals) who work on these plugins full-time will be much more in tune with ongoing platform changes, and keeping up with all of that in custom code is rarely a good use of your time or budget.

These plugins benefit from dedicated development teams, regular updates, broader real-world testing, and community feedback. In these cases, the website is far more likely to remain stable, secure, and compatible over time with the addition of a third-party plugin rather than with something coded once during the initial build and never updated.

The thing is, block libraries don’t pass this test. If your tab block is coded once and doesn’t get updated, it won’t break your website. If you do need to make slight padding or margin changes or add the ability for a different design inside the tabs, that’s trivial work. It’s not the same as maintaining compatibility with the Stripe checkout API.

The best use case: non-mission-critical websites.

For personal or business websites that are not mission-critical (where a bit of downtime or layout oddities after an update don’t truly matter, or sales aren’t happening on the site), an off-the-shelf theme, block library, or page builder is just fine.

Most small, local businesses don’t need a fancy custom design. They need something that looks generally professional, is findable in search, and allows people to get key information about their business and how to contact them. This is especially true for companies that get most of their business via Google Maps or review sites like Yelp. Think websites for restaurants, hair salons, churches, single-location brick and mortar businesses, or small nonprofits with very tiny (or essentially zero) budgets.

These websites are ideal use cases for a page builder or a block library. They typically don’t have a large budget for either the initial build or ongoing maintenance, and so custom isn’t possible. In many cases, the people building the sites may not even be developers. They also don’t need the same attention to detail to achieve their goals.

If custom isn’t possible (or necessary) and a desired feature doesn’t exist in WordPress core, then a block library can help fill the gap. I say this to make it clear that I don’t think block libraries are all bad. Block libraries play an important role in the WordPress ecosystem. If I were building these types of websites, I would probably be using a block library like Kadence.

How about the Equalize Digital website?

So why don’t we use block libraries at Equalize Digital?

We’re not an enterprise company yet (working on it!), but we treat our website like an enterprise site because we need it to always be available for sales. We don’t run autoupdates, and we question everything we put on the site.

I really don’t want my website to look “off” or broken. We sell to enterprise organizations, and we need to communicate trust. Increasingly, I care deeply about performance optimization because we make sales on our website every day.

I want our site to look polished, not have increased load times due to bloat from a library loading code on every page for blocks we’ll never use, and to funnel people through to a checkout with as little maintenance on our end as possible.

We’re a small team doing a lot of things. I don’t want to test updates on staging and see new “features” added that I didn’t ask for or that require us to go back to the dev for support before we can run updates on live – all things we’ve seen with past block libraries.

Does it slow us down during the initial build to have to create blocks from scratch? Yes.

But in the long run, it speeds things up because it gives us fewer things to test during routine updates and a lot more peace of mind that things will stay as we have built them, without surprises.

The post Why We Don’t Use Block Libraries at Equalize Digital appeared first on Amber Hinds.

The post Zara’s Thirteen Birthday appeared first on Amber Hinds.

1. Start blogging weekly.
2. Create (and stick to) healthier habits around exercise, sleep, and sugar.
3. Be on a path toward profitability in our business that doesn’t require excessive work hours.
4. Ride in a hot air balloon.

It’s December 27th, and I’m writing the first blog post I’ve written since January 13th, and I’m here to say that I failed every one of those goals.

I did, in fact, turn 40 in March.

But I can’t say I accomplished any of the things I hoped to achieve before or around then.

It’s the time of year when many people write “year in review” posts, and since I’m strapped into a car, driving from Texas to Iowa to visit family for the holidays, it’s the perfect opportunity to reflect on 2025, my failed goals, and my hopes for 2026.

What Happened?

I’ll start with my last goal, riding in a hot air balloon, because it’s both the easiest and also the most aggravating to explain.

The hot air balloon vendor stole our money.

Long story short, for my birthday in March, Chris booked a hot air balloon ride with the only vendor he could find in Central Texas. I was going to celebrate with a glass of champagne up in the clouds.

This seems like it should have been the easiest goal to check off. Alas, the day before my birthday, we got a text from the vendor that it was too windy to be safe to go up, and we would need to reschedule. No problem — I want to survive the hot-air balloon ride — so we coordinated child care for a different day later in the month and rescheduled.

What ended up happening was that it was always too windy and “not safe,” even when the weather said there was no wind. The balloon’s operator repeatedly cancelled bookings, never answered his phone, and took weeks to reply to a text or email. He refused to refund the ~$600 Chris had prepaid, and in May, he even told us he was moving to Albuquerque, New Mexico, and that we could go there to get our ride. 😡

This is a pattern that we saw reported in other online reviews of his business around the same time. We attempted a chargeback with our credit card after we gave up on rescheduling, but by then the chargeback window had already closed. So he got our money, and I still haven’t ridden in a hot air balloon.

There aren’t any other hot air balloon companies in our area, so I had to give up on this dream for now, and it’s going to stay on my “someday” bucket list when we can fit it into a trip away. 😥

I still haven’t figured out a good balance between work and life.

The first two goals on my list were weekly blogging and better health: more sleep, more exercise, and less sugar.

First, the good:

I ran a 5k in February, pretty much without stopping, and I was really proud of myself.

It took effort to be capable of running a 5K, and Chris and I happily claimed our participation medals.

Now the reality…

I still haven’t built a good habit around exercise, but the 5k was one milestone that feels like it should count for something. Though I’ll admit I haven’t gone for a run or done any meaningful exercise since October, so I still have a ways to go toward making exercise a regular practice.

I still spend way too many hours at a desk, fueling late-night work sessions with chocolate, cookies, and brownies to stay awake, and I don’t exercise regularly.

I also didn’t meaningfully improve the amount of sleep I got. In 2025, I averaged 6 hours and 46 minutes of sleep per night, only 10 minutes more than my 2024 average of 6 hours and 36 minutes. And as the publication dates on posts show, I didn’t even manage monthly blog posts, let alone weekly ones.

The biggest blocker to these goals continued to be the number of hours I work, which brings me to goal number 3: balancing work and life was a giant fail.

Hours in 2025

As I reflected on this year, I looked back at my time reports in Toggl (our time-tracking software). Here’s what I found:

In 2025, I clocked 2,562.11 hours. That’s an average of 50.24 hours per working week and 10.63 hours per business day.

We have 16 company closure dates for holidays, but I worked about half of those days when we were closed rather than taking the time off. I took one 3-day vacation in June and a 5-day vacation in July. Generally, I “paid” for time off by working more in advance and/or after a vacation or holiday.

I considered this goal a complete failure because not only did I not work less in 2025, but I actually worked 302 hours more than I did in 2024. Here’s what my time looked like for the year:

Why I Work so Much

Over the past few years, I have intermittently looked back on my time, trying to figure out what to cut out and whether there are things I’m doing that are less efficient. I keep wondering whether I suck at time management or delegation, and if that is why I’m working so many hours.

I spoke with a female founder I admire earlier this summer, sharing my frustration about time. She told me she doubted that time management was the issue. It’s not an inability to manage time or a lack of delegation; I’m in a phase of business where I’m simply doing a lot with few resources.

Looking back at a few years’ worth of clocked hours, this is clearly the case. I keep adding more to my plate without taking anything else off to make room.

The Trajectory of My Work Hours

Here’s a look at how my yearly work hours have changed since I started tracking time in 2014.

Key milestones from this timeline:

• In 2016, Chris joined me in the business, and I started working “full-time.” Prior to that, I was working part-time while primarily raising the girls, and he supported us as a chef.
• In 2017, our third daughter was born, and I didn’t take maternity leave because we couldn’t afford for me to take leave. We also moved cross-country to Texas that year.
• 2018 was the first year we had full-time childcare, making it easier to take on more hours.
• In 2019, our fourth daughter was born, and by then we had a larger team, so I took a short 6-week maternity leave (meaning I worked fewer hours in 2019 than in 2018).
• In December 2020, we launched Accessibility Checker. That year was the first year I clocked around 2000 hours (the truest equivalent to full-time work: 40 hours x 50 weeks).
• 2021-2022 Accessibility Checker was one of our offerings, but our business was primarily funded by new website development projects, not software revenue, and we let Accessibility Checker take a back seat. We didn’t release new features regularly and weren’t aggressively marketing, so I didn’t work much more than a full-time job’s worth of hours.
• In March 2023, we raised a pre-seed investment from Emilia Capital to grow the product side of our business, and I began working more aggressively to market it. This is when you see my work hours jump considerably over 40 hours per week.

Growing scalable, recurring revenue is hard.

We built Accessibility Checker because we wanted scalable, recurring revenue that didn’t require a human to deliver it. Services are more expensive to deliver, and team members have long been the largest line item on our P&L. Chris and I realized early on that our best retirement plan is to build a business we can sell, and service businesses are far less sellable, with far lower multiples.

With that in mind, we teamed up with our lead developer, Steve, to create a new business with a greater emphasis on product.

The initial development of Accessibility Checker, branding, and website development for Equalize Digital was funded by a small-business loan. The loan allowed us to turn down client work for a few months while we kept paying our team to work on this internal project. The initial build also coincided with COVID, and we received PPP funds that helped pay the team when client work didn’t resume as expected.

This initial funding allowed us to launch the product and brand that was central to our plan to build more scalable, recurring revenue; however, as anyone who has launched a WordPress plugin will tell you, it’s not “if you build it, they will come.”

Growing brand recognition and gaining a user base for a software product takes a lot of hard work. And here’s the catch: if you don’t have piles of money to pay yourself and your team while you’re growing the product, you have to do double the work — service work to keep the lights on and work to grow the product.

Taking an investment was incredibly helpful. It allowed us to hire a full-time developer for the product (not client work), so we could release new features faster and invest more heavily in marketing. But it wasn’t large enough to fund the entire company for the number of years it might take the product to get to that point. Which means we’ve been able to reduce service work, but not eliminate it entirely.

Which brings me back to why I’ve been working so many hours the past few years:

I’m working two jobs: delivering services for clients and trying to grow a product company.

This year was particularly intense because we decided to increase revenue opportunities by adding courses and another WordPress plugin. I created and launched two courses this year:

• Screen Reader Testing with VoiceOver in May
• Screen Reader Testing with NVDA in August

I also supported Chris as he created a course on selling accessibility services and worked with the team to develop our ArchiveWP plugin, both of which launched in November.

We added all these things without eliminating anything else, which meant adding more hours to our work weeks to get them done.

Successes

All this effort is not for naught on the business side. We have seen incredible growth, particularly on the product side. Accessibility Checker has become an ever-larger share of our revenue.

Here’s a graph showing the growth in Accessibility Checker’s active install count, as reported by WordPress.org. This is the user base for our free plugin:

Noteworthy details from the chart above:

• We had slow but steady growth in the plugin’s first three years, when we did less marketing.
• We had reached 2,000 active installs around the time we closed our investment and were already seeing faster growth before then.
• I haven’t dug into this deeply, but in 2024, I worked fewer hours than in 2023, and you can see the growth that year was slower. It took 70 extra days to get from 4,000 to 5,000 than it did to get from 3,000 to 4,000 (in the prior year when I was working more). This could be a coincidence, but it’s an interesting note.
• There was rapid growth in installations from April 2025 onward, going up 4,000 installs this year alone.

We more than doubled our active installs this year, rising from 4,000+ to over 9,000. At our current growth rate, we expect to hit 10,000 installs in a few days. We also grew Accessibility Checker revenue by 44.3%.

This growth is fantastic and shows the results of a lot of hard work by our entire team, not just this year, but in prior years, which set the foundation for this year’s growth.

I’d be remiss if I didn’t note how great this is — obviously, all those work hours have been delivering something meaningful. So while I may have failed at my personal goals, I met or exceeded my business goals.

Which brings me to 2026…

What Does 2026 Look Like?

I’ll be frank: this year was exhausting. To work the hours I do and be present for the girls, I usually take an evening break around dinner or to drive them to activities, then sit back down for a second shift late at night. But more often than not, I barely feel present, and Chris is doing the bulk of the parenting and household management.

More than once this year, I’ve had people remind me to put my own oxygen mask on first. I was less engaged with WP Accessibility Day, the conference I co-lead, for the first time not running an organizing team, and stopped co-hosting the WP Product Talk podcast. That bought me some time, but not much, and it certainly didn’t leave time for personal goals. (Also, it sucks to stop doing something you enjoy.)

Every December, our team gathers to plan next year’s goals and budget. This year, I put a lot of effort into reflecting on our marketing initiatives and trying to figure out what works and what doesn’t. (More on this in a future post.) I told the team I want to work less in 2026, but I’ll admit I struggle to figure out what that looks like.

Do I stop creating the long-form content that brings people to the website, but that takes many hours to produce? Do we stop the podcast? Do we increase our marketing budget so more of that can be delegated? If so, where does that money come from?

We experimented with reducing our virtual meetups from two to one per month at the end of this year, which cut our workload but also reduced the number of new people added to our email list each month. It’s a bit scary to think about cutting marketing efforts, because I worry that it could limit growth.

I finally finished reading Thrive by Arianna Huffington this year.

I started it when it first came out, but gave up on it a few chapters in. Last spring, I found myself wondering if there might be some helpful advice hidden in there and picked it back up. But I ended it with the same impression I originally had, however many years ago: it’s easy for a billionaire who already has a booming business to tell us to work less and sleep more. It also doesn’t offer any practical guidance on how to bootstrap a business in a 36- or 40-hour workweek. Would HuffPost be what it is today if Arianna hadn’t worked all those late nights?

I’m starting to wonder whether I need to choose between pushing hard to rapidly scale the product side of the business and having a normal work life. Perhaps it would be better to focus on the service work that pays and let the product grow at whatever rate it grows organically?

I don’t know yet what 2026 looks like. I started this section with a question that I can’t fully answer, which may make this blog post anticlimactic and incredibly aggravating to read, but this is my truth today.

I still have the same goals that I wrote at the end of 2024. I want to be more present for the girls and more intentional about my own well-being. I’m just not sure how to get there yet.

The post 2025 Failures and Successes appeared first on Amber Hinds.

Zara’s goal is to sell 1600 boxes. This is just a small percentage of that goal. 😅

The post Cookie Season is here… appeared first on Amber Hinds.

While I don’t love what Instagram has become, it is still incredibly easy to log in and publish an image and a short caption in minutes from your phone. Logging into a WordPress website in a mobile browser to publish a blog post is considerably more annoying, especially when you have two-factor authentication set up (as I do). There are several extra steps to log in, and the WordPress mobile experience (especially in the block editor) leaves a lot to be desired, given that some settings and sections disappear entirely in portrait mode on mobile.

I wanted to stop using Instagram, but I still want the ease of posting photos on the fly. This led me to try the WordPress mobile app for the first time.

I love that WordPress has mobile apps that intend to make it easy to publish “anytime, anywhere.” The intent is exactly what I needed. Unfortunately, the reality is that the WordPress mobile app (or at least the Android app) fails to achieve that goal.

TLDR; Why the WordPress Android App is a Failure

I don’t say that the WordPress app is a failure lightly. In fact, I give it a lot of passes for its limited functionality as a “website builder” because I don’t think anyone in their right mind should be building a website on a mobile device (though I know people do).

I have zero expectations that the WordPress app would support building complex pages, so my complaints have nothing to do with that.

Instead, I say the WordPress app is a failure because its limitations make it impossible to complete the task most central to WordPress:

It’s impossible to publish simple blog posts — posts with only a featured image and one paragraph of text — within the WordPress mobile app.

This post describes my experiences and frustrations with the WordPress Android app, including known bugs that have existed since 2018, making it impossible to publish an accessible, properly coded post via the app.

Problems With the WordPress Mobile App

XML-RPC

WordPress mobile apps rely on XML-RPC to connect to WordPress rather than the WordPress Rest API. XML-RPC is a protocol that allows a client to execute remote function calls over the Internet — it’s like an early version of an API.

There are a lot of security concerns with XML-RPC, and for this reason, many WordPress hosts disable it. If you decide to use the WordPress mobile app, you may have trouble getting it to function with your website, as I did.

Setup Difficulties

My blog is hosted in a managed WordPress hosting account at GoDaddy. A toggle in my site settings allowed me to enable XML-RPC on my site. Unfortunately, toggling that on didn’t actually enable XML-RPC for my site; the site continued rejecting connection attempts even when that was turned on.

I went back and forth with GoDaddy support for several days about this, with lower-level reps telling me nothing could be done. They said, this was a security feature that could not be turned off for my site. If I had been a typical website owner, I would have abandoned the WordPress app in frustration at that point.

Luckily, since I have gotten involved in the WordPress community, I’ve made friends at hosting companies and I’m not a typical website owner. I reached out to one of my friends who works at GoDaddy and had them escalate my ticket to someone with the authority to adjust rules on the server until the XML-RPC requests were accepted. It took about a week of testing and back and forth with advanced support reps before I could even log into my site in the app.

Lockouts

Once or twice, I have gotten too overzealous in how quickly I’m working in the WordPress app, either uploading images from my phone or typing a blog post, and the quantity of the XML-RPC requests throws a security flag at GoDaddy, which results in my IP address being blocked from even viewing my website.

This happened in December when I first started working on this blog post:

When this block occurred last month, I was uploading images for this post to the media library. GoDaddy reported there were “over 500 connections in a 15-minute window” before the security system kicked in and blocked me.

I had to switch to a mobile hotspot and my computer to be able to see my website, let alone log into it until GoDaddy’s advanced support team unblocked my IP the following day.

XML-RPC or Overzealous Security?

Now, it’s entirely possible that my hosting plan with GoDaddy is partially to blame for the issues I had initially setting up the app and the IP address block. Perhaps their security rules are too strict. Indeed, if I had a dedicated server rather than a shared hosting account, I could fine-tune all these rules if I wanted to.

But this is a non-monetized blog — I don’t even track traffic to the site. I don’t want to pay much for hosting and am not interested in fiddling with server settings. In this respect, I am like most WordPress users with hobby blogs or small business sites: people looking for affordable and easy hosting.

And so, I don’t think the issue here is solely a problem with the particular hosting plan I have at GoDaddy. The problem is that the app uses XML-RPC in the first place.

If you Google WordPress XML-RPC because you want to learn about it or because you are trying to troubleshoot why the WordPress app won’t connect to your site, all the top results warn that XML-RPC can be a security risk and talk about how to turn it off.

What impression does that leave for a non-technical site owner of the WordPress app, which relies on XML-RPC? Certainly not that it’s a trustworthy tool.

The fact that the app has not been upgraded to the Rest API and still relies on a less secure, legacy framework is problematic not just from a security standpoint but also from a user experience standpoint.

If we want WordPress to compete with social media and to “put the power of web publishing in your pocket,” as the app promises, it needs to be mindlessly easy for ordinary people without technical ability or fancy hosting plans to set up. Anything else is a failure.

Inability to Upload Multiple Images at a Time

A basic thing I want to be able to do in the WordPress Android app is upload photos from my phone. Being able to upload images from my phone directly through the app saves me from the multi-step process I was previously taking of emailing photos to myself and then uploading them from my computer.

I can upload photos in the app, but only one at a time.

If I select multiple images to upload at once, maybe one or two of them will upload. More often than not, they all fail, and I’m presented with the error message displayed above, “8 files not uploaded. We couldn’t complete this action.”

There’s a Retry button. It also never works.

I then have to hit the upload button on each image one at a time to get them all uploaded. These errors exist regardless of if I’m at home on my WiFi or at the park on mobile data. I’ve never once been able to upload more than one image at a time.

I haven’t dug into why multiple image uploads fail. I suspect it could be because multiple image uploads are not processed in an orderly queue and are instead attempted all at once, which either overloads the server or throws an XML-RPC security flag and gets them blocked.

I’m not sure that the reason why it doesn’t work matters. All I know is that, as a user, I find this annoying. It doesn’t make the app feel workable or like a viable competitor for the Facebook or Instagram image upload experience.

Janky Error Messages and Poor Documentation

You might be annoyed when encountering an error, but if it is clearly explained with a quality error message or good documentation, you will be pointed toward fixing the problem.

Bad Error Messages

The WordPress mobile app lacks descriptive error information. Many of the error messages in the app are ambiguous and not helpful. In some cases, they are wrong.

Here are two examples

In the first image, the error message says, “6 files not uploaded, 6 successfully uploaded. We couldn’t complete this action.” This is incredibly confusing as there are actually eight images that failed to upload and one that was successfully uploaded. The image counts are wrong for some reason. There’s also no explanation about why the uploads failed.

The second image shows an error message when attempting to connect equalizedigital.com to the WordPress mobile app. The error says, “The site at this address is not a WordPress site. For us to connect to it, the site must use WordPress.” The red text used for this error fails color contrast for accessibility and so does the white/light blue combinations on the Retry and Continue buttons.

Of course, the Equalize Digital website is a WordPress website, so this error message is incorrect. The app cannot connect for some other reason. It returns this incorrect error message without links to documentation or other information about how a user might resolve the problem.

This is likely an abandonment point for users before they even get started.

Limited Documentation

Poor error messages can be overcome by detailed documentation. How often have you had a problem with an app, googled it, and found the answer in the documentation?

Google is my go-to when I have an issue I can’t figure out, but alas, the WordPress mobile apps have very limited documentation. There’s the Mobile App Handbook, which is more about how to get involved on the mobile app team and has incorrect information about how to get started that references needing a WordPress.com account (not true). There’s no troubleshooting information here.

The WordPress.com Mobile App docs have some information on troubleshooting, but this is not perfectly relevant as it’s intended for the Jetpack app, which is a fork of the core WordPress app.

The App Support URL on Google Play goes to the most useless page ever, with no support or documentation information.

Even if the user notices the Documentation link below and visits the documentation page, there’s no information to be found. A search for “mobile app” or “mobile” in support docs returns information about how to use the customizer.

All of this adds up to more failures that block WordPress mobile apps from being usable by the masses.

No Support for Custom Post Types or Taxonomies

When I wrote about moving my Instagram posts to WordPress, I discussed debating importing the posts into a custom post type. For many users, that would have made a lot of sense. Luckily for me, I decided to just use a category on my blog.

Why is this lucky? Because it’s impossible to edit or publish posts in custom post types in the WordPress mobile apps. Had I setup my Instagram posts anywhere other than my blog, I wouldn’t have been able to continue posting there in the mobile app.

There have been GitHub issues open requesting custom post type support for over 10 years:

• Android app: support custom post types GitHub issue
• iOS app: support custom post types GitHub issue

The Android issue was created in 2018, and the iOS issue in 2013! Custom post types are a huge part of what took WordPress from being a blogging platform to a full-fledged content management system. Without custom post type support, WordPress mobile apps are unviable editing tools for any business website and also many personal websites.

There’s also a GitHub issue from 2013 requesting support for custom taxonomies and custom fields. This is a blocker for me as I have a Locations taxonomy on posts, which I cannot set when posting from the mobile app.

That the WordPress iOS and Android apps don’t support custom post types after 12+ years is unfathomable to me.

Doesn’t Respect ! is_admin

I imported my Instagram posts into my blog, but I didn’t want to show them in my main blog feed. To hide them, I added a simple function to my theme’s functions.php file.

/** Remove shorts category from the blog **/
add_filter( 'pre_get_posts', 'amber_exclude_shorts_category' );
function amber_exclude_shorts_category ( $query ) {
	if ( $query->is_home && ! is_admin() ) {
		$query->set( 'cat', '-272' );
	}
	return $query;
}

This code snippet adds a filter that modifies the query fetching blog posts to display on the main blog page and removes any posts in the category with an ID of 272 (my shorts category). There is a limitation, ! is_admin that tells the filter not to change the query in the WordPress admin, only on the front end.

This works perfectly on the website and browser-based admin experience. In the mobile app, however, the query also hides all posts in that category from the editor. Here’s how my published post looks in the app:

The most recent posts are from December 28, December 1, and November 12 of this year before jumping back to July 18, 2022. In contrast, here’s my published posts list as it appears in the browser:

In the browser, I can see published posts in the Shorts category, too. The most recent posts are January 2, December 28, December 14, December 7, December 1, November 15… and more.

Why does this matter? It matters because the second I publish a post or save it as a draft, it’s impossible to edit it in the app because I can’t find it.

There could be any number of reasons that a theme or plugin developer might use ! is_admin to restrict their code to the front end of the website only. For the mobile app not to respect that is a significant oversight.

Preview Links Don’t Work with 2FA

I have 2-Factor Authentication setup on my blog, which requires me to enter a code from Google Authenticator before I can log in. This is an important security measure that most of us would agree website owners should have enabled. Yet the WordPress mobile app hasn’t accounted for it when it comes to preview links.

When I click the preview link on any post in the WordPress mobile app, it opens the post in a new window; it doesn’t recognize that I’m already logged into the app or site. Instead, I am given the challenge screen to type the code from my authenticator app. This wouldn’t be a problem, except I can’t press the Verify button to submit the code.

The WordPress app blocks the button from being pressed with this error: “Links are disabled on the preview screen.” This effectively blocks me from being able to preview any blog post in the app; I have to open my browser and log into my website if I want to preview a post before publishing it.

No Way to Add or Edit Alternative Text

Many of the issues that I reported are annoying or something that I don’t like but was willing to overlook given my very basic blogging needs. OK, fine, I won’t preview posts or edit them once published. I will only upload one image at a time… those were things I could work around. But here’s what killed the WordPress app for me:

There’s no way in the WordPress mobile app to edit alternative text in the Media Library.

I kept noticing, after the fact, that there was no alternative text on my featured images. Alternative text describes an image to someone who is blind or has low vision and uses a screen reader. I have blind friends in the WordPress and web accessibility community, and when I post images on my blog, I want them to be able to access them, too.

I got incredibly frustrated by repeated discoveries of images missing alternative text on my blog when I knew I had typed the alt. I typed the alt text 2-3 times on one post, trying to figure out why it wasn’t publishing on the front end or saving in the Media Library.

The WordPress Android app has a field on the image edit screen after you upload an image for editing alternative text. This field is a black hole. It doesn’t save anywhere or sync to the WordPress Media Library.

In 2018, someone opened a GitHub issue reporting that alt text from WordPress websites cannot be viewed in the app’s media library. It was determined that the XML-RPC endpoint for media items doesn’t include an alt. Meaning: the WordPress mobile app wouldn’t be able to save alt text without someone first fixing something in core WordPress.

XML-RPC suckiness strikes again.

I’m not sure why, but a ticket to fix this issue with XML-RPC was not opened until June 2023 — five years after the issue was discovered. That ticket was closed as fixed ahead of WordPress 6.4 and another was opened for adding an update media endpoint. That ticket is still open.

As it stands today, seven years after someone first reported that the alt text wasn’t working in the mobile app, it’s still not working.

You can add alternative text to images inserted into posts (that works because it saves the text in the post content, not in the Media Library). However, there is no way to add alternative text for images fetching alt from the Media Library.

The WordPress Mobile App Isn’t Worth It

When I first decided to try the WordPress app, I was excited. I thought it would be an easy way to replace Instagram and write simple posts with one or two images and a short paragraph of text. I thought it would make posting on the go and in the moment easier.

I was wrong. The WordPress app is hard to set up. There’s not much documentation, and it has features that are so limited that the app is barely usable for even the most basic purpose. As I was brainstorming this post, I was thinking about titling it, I tried the WordPress Mobile App, So You Don’t Have to.

The mobile app feels like beta software. It has a decent visual appearance, and not much else going for it. Given it’s 12 years old and can’t even be used to write a simple blog post with an accessible featured image, I’d say that counts as a failure.

Trying the mobile app is not worth your time. If you want to edit your website on mobile, you’re way better off logging into your site in a mobile browser. That also has its challenges, but nothing like I saw with the app.

The post The WordPress Android App is a Failure appeared first on Amber Hinds.