Blog
Source: Scott Meyer’s Basic Instructions comic.
As it happens, in my senior year of college, I took a year-long coordinated studies program called Computability and Cognition. We studied the mathematics, logic, computer theory, cognitive science, philosophy, and ethics behind artificial intelligence, including what were then very early models of modern Large Language Models. Mind you, the average smart thermostat today has more processing power than my school’s whole computer department had back then. But the principles, *and problems* of AI were substantially in place even then.
So does that mean I completely embrace AI? Nah. Run screaming from the room? Yeah, not that either. Instead I find that it’s a useful tool for things I actually trust it to do.
In addition to tasks outlined in Scott Meyer’s comic, above, AI helps me outline, research, catch typos, and find better words & phrases. It’s very useful for summarizing Zoom calls with clients. It’s very handy for tedious jobs like grinding through massive error logs when I adopt a new client’s website, as well as summarizing the hundreds of (mostly redundant) status messages I get. It’s also convenient for analyzing and debugging code in client websites that other people built. But in general, I like to do things the old-fashioned way, by hand, unless or until I thoroughly trust my ability to automate it. (In other words, I use AI pretty much the same way I’ve always used non-AI.)
Bottom line: whether or not I use AI, I take full personal responsibility for any code I may add to a client’s website as well as any content I publish here or elsewhere (the good, the bad, and the em dashed.)
Burglar Alarm by O.B.McClintock Co. in Scandia, Minnesota — by Flickr user Lorie Shaull.
So the intertubes are all abuzz about reports of newfound vulnerabilities in open-source software.
For instance, consider this breathless headline: WordPress Tightens Bug Bounty Scope After Monthly Security Reports Nearly Double to 773
Sounds awful. But to see why I’m less concerned, see what I think is the key paragraph in that post
“Last month I mentioned we had a record 450 security reports to the WordPress HackerOne program. August ended at 773,” WordPress Security Team rep John Blackbourn wrote in Post Status Slack on Tuesday. “Unmanageable numbers of low severity reports means that today we’ve had to make changes to the scope of the program.”
— Source: TheRepository (emphasis mine)
I’m just going to keep saying that AI now lets almost anybody (and everybody) pour through open-source code and find and report vulnerabilities. That’s a HUGE improvement over the old status quo where only black hats and “state-sponsored entities” had the incentive to do that level of manual code review. Because black hats and “state actors” could directly exploit or sell them on the dark web.
So the big, big questions I’ve got would be
1) What percent of those 773 reports were duplicates?
2) What percent of the non-duplicates found score higher than low priority in terms of real-world exploitability?
3) What percent have NOT already been patched in recent updates?
4) How many versions back has the vulnerability existed?
Those are all important questions. Because I’m… pretty sure if I threw any random batch of open-source code at Claude or Codex, it would come up with *some* kind of vulnerability somewhere either in the code or in one of the libraries or dependencies it calls. It probably wouldn’t take that many tokens and very likely would work with the free version.
And since, unlike previous manual grinds by bounty hunters or black hats, it would be cheap and easy enough to report the problem, I’d probably do that instead of looking for a way to capitalize on it on the dark web or as a “state actor.”
But also, since it now really is cheap or even free, chances are that if everyone else is looking, then I’m not even going to be the first person to find and report it.
So, again, the raw number of 773 reports isn’t the issue; it’s how many are unique and how many are critical. (Answer: not that many.)
Even if I wasn’t feeling generous to WordPress, or to any random developer, I still wouldn’t be surprised if they updated their bounty program to weed out what may eventually boil down to “spam” vulnerability reports.
Could I be wrong? Absolutely. Maybe John Blackbourn just doesn’t want to admit that every single one of those reports is really a high-priority, critical vulnerability. If so, then, sure, yikes! They’ll need to get on that.
But even then, it still doesn’t change my overall point! Odds are extremely low that another 773 critical vulnerabilities will be found and reported. Because that’s how low-hanging fruit works. There will almost certainly be some more. But critical vulnerabilities are a finite resource. And so there are going to be diminishing returns.
And it still doesn’t imply that each of those initial vulnerabilities will be that hard to patch. Many or most are easily fixed once identified.
And the next vulnerabilities will take even longer to find, while likely still being easy to patch.
AND it’ll become just as cheap, and just as easy, for developers to start running the same AI prompts on their own code before it’s released.
That’s why I’m both concerned about the risk of vulnerabilities in the short term (next 1-3 months) but optimistic about the future (2027 and beyond) Not because no one will ever code another bug or that no one will ever find another. But because finding and reporting them (or finding them in our own code) will be easy enough that the window for exploitation and the incentives to do so are about to become quite a bit smaller.
Roger Montti, on Search Engine Journal, lists “6 Reasons Why Cloudflare’s EmDash Can’t Compete With WordPress” in this article, but really only needed one reason to explain why EmDash probably can’t compete with WordPress. (Assuming Cloudflare’s announcement wasn’t just an April Fools prank to begin with.)
1. EmDash Is Not User Focused
There are over 2,700 words in that announcement, and the only part that arguably has direct importance to actual users like bloggers, businesses, and other publishers is the part about plugin security. The rest of the content is developer- and coder-focused and not user-focused at all.
Montii said it here
I mean, sure, a lot of professional developers seem similarly interested in allowing users to interact with WordPress via change requests. And it’s true that ever since Gutenberg rolled out, core WP documentation increasingly includes the line “just open theme.json in your favorite IDE and…”
But here’s the thing: the PC took off because people wanted to run their own applications. Particularly their own spreadsheets, because spreadsheets were insanely faster and less expensive than sending batch requests to corporate mainframe sysops.
And it’s the same with websites. Roughly 450 million WordPress site owners flocked to WordPress because whatever its shortcomings (and there were plenty in 2005) it was insanely faster and less hassle than rawdogging posts, pages, menus, and sidebars in HTML. It’s great that the founders of Sucuri and Yoast are moving to programmatic solutions for their websites, but they can do that because they’re successful and very sophisticated senior programmers.
Meanwhile the other 99.997% of WordPress site owners *aren’t* senior programmers.
For all the fussing about rogue plugins and “bloated” themes, virtually all WordPress sites run fine. Under genuinely atrocious owner and server conditions! Because, in spite of the additional UI/UX barriers Gutenberg introduces, or the additional “bloat” Elementor introduces, you don’t have to know VStudio, or vim, or Markdown to add a blog post or update your product catalog. People will put up with a lot if it means they can own their own stuff.
We’ll see if EmDash takes off. And if it’s actually easier for end users to own and operate? Awesome, I’ll jump on board. But I haven’t really seen anything that suggests they’re thinking about end users.
Grumble, grumble, gripe, gripe.
‘Beautiful Honey Comb’ photo courtesy of Flickr user Robert Schmidt
After nearly 15 years working with WordPress, and more than 13 years supporting other people’s websites, I end up doing a lot of really cool stuff.
So I just thought I’d mention what my workday was like today. So today I…
- Attended my weekly business networking meeting
- Moved two sites to new hosting after major cleanups
- One of the sites I cleaned up was a local business site that was built with a Russian version of WordPress. So I first converted that back to English.
- Added Google Tag snippets to another site for a marketing client
- Cleaned up several client’s contact form notifications because their SMTP2Go mail relay servers now require authenticated senders. (I’ll do the rest tomorrow.)
- Helped another user log into a site after their employer reassigned them back to it
- Posted a newsletter for another client
- (Finally) deleted a site I’d been temporarily hosting after their original webmaster died unexpectedly, after never giving the client either hosting or domain-registration acccess.
- (Late last year I helped the client recover their domain name and setup temporary hosting after reassembling the site from an… interesting backup)
- Revised the “join” page for a chamber of commerce website so there were “join” links for each membership level.
- Logged into the chamber’s GrowthZone/ChamberMaster site and tracked down the correct URL for the “join” forms.
- I added accessibility “title=” tags to each of the new links on the chamber site.
- Answered a Reddit user (not a client) who asked about how to moderate aggravating comments on blog posts.
- Consulted with another old client who needed to update their new(ish) logo on their 3rd-party appointment calendar.
- Consulted with another client who asked for help with a QR code to a now-dead domain that (I think) is/was controlled by the client’s parent company
- Agreed to help yet another client refocuse the homepage and two interior pages on their main website rather than build them a new “mini” site. (I don’t do SEO but I know enough to know their main site has way more authority and cross links than any new site they might build with AI.)
- Logged into Google Search Console after a client’s marketer added me so I could find out why Google claimed it couldn’t index the site. Answer? There wasn’t a sitemap and Google had last indexed the site back when the landing page only said “under construction.” I generated and submitted a new sitemap and now Google should quickly figure out the site is actually live.
- Gave another client advice about how to track down their domain registration so we can point their domain name at a new server they’d like to move to.
- Emailed two clients about transferring their websites from their temporary locations on my development servers. (I don’t host client sites; see the note about the other webmaster who died unexpectedly!)
Yes, this was a busier day than usual. And yes, there’s more I could have / should have / wish I could have done. That’s what tomorrows are for, I guess.
But it wasn’t that much busier than usual.
What do you need done for your website? Tomorrow, I mean. Or later in the week.
Short answer: no. Longer answer: probably not.
There are different levels of “learning WordPress.” Not to sound like clickbait but “the last answer may suprise you.”
If (but maybe only if) you’re going to code plugins, themes, and blocks then yes, you’ll need to learn to code.
If you’re going to routinely build sites for others, then while many WordPress professionals make their living without ever learning to code, it’s very useful to have a good understanding of CSS, and at least a passing understanding of PHP and JavaScript.
If you’re just going to work with WordPress rather then, as a professional, I tell clients that if they ever need to use HTML, CSS, (let alone PHP or Javascript) then I’ve failed to do my job for them.
Possibly surprising answer: no matter how much you intend to code, and no matter how much programming experience you have, you should first actually learn WordPress deeply and then learn how to code for it. In my experience as a site restoration, repair, and support professional I’ve been asked to work on sites where programmers fire up their IDEs and start coding before learning how WordPress actually works. This results in, at best, redundant effort and, at worst, unworkable, overengineered, insecure results that need to be trashed and rebuild from scratch. Bottom line: learn the trade, then learn the tricks of the trade.
But in general, tens millions of people have built perfectly servicable WordPress without ever writing a line of code. Hundreds of millions more site owners and/or their staff use WordPress ever day without knowing how to code.
3,717 days! Almost every day since switching from building new WordPress sites to maintaining, refurbishing, and updating old ones, I’ve logged into my InfiniteWP console and backed up and updated all my maintenance clients’ websites.
The reason I chose IWP all those years ago is that it is self-hosted and doesn’t have per-site charges. There are other self-hosted maintenance consoles, but MainWP is the big one. MainWP is now more actively developed, while the IWP devs seem satisfied to keep the motor running.
The reason I prefer self-hosting vs. cloud-based consoles is that there are no additional per-site charges. This means that in addition to various clients, it’s no problem giving pro-bono site maintenance to non-profits or even friends and family.
And giving back is still one of the things that makes me most proud of the WordPress community.
It must be that time of year again. A client sent me this scan with a short, to the point question.
“Is this junk or is this a legit renewal for us?”
Client to remain nameless
As always, my short, to-the-point answer is no, this is not a “legit renewal.” As I’ve been saying since at least 2021, if you read the fine print you’ll see that paying these… people… any amount of money for a “website listing” will not renew your domain registration.
If you peer even closer at their fine print and type the URL to their extremely obscure website you’ll see the following
When you purchase your Domain Listing, you are receiving a global landing page for your company or organization’s information, and being listed beside some of the top domains in the USA!
From their website’s “About Us” page
All initial Domain Listings are created using information that is publicly available. If your Domain Listing does not contain all of the information listed above, It’s probably because your information was not publicly available and/or because we were unable to locate the information when creating your Domain Listing.
M’kay, so for nearly 300 freakin’ dollars you can get a “landing page” with… the same information Google, Bing, Yahoo, ZoomInfo, Dunn & Bradstreet, your state Department of Revenue, the Small Business Admistration, Yelp, Facebook, and others probably already provide for free. Not to mention your own website is a “landing page!”
And by the way, you don’t have to take my word for it. Try searching “domain authority” website listing invoice and see how many people will tell you the same thing. In terms much less polite than I will.
On the r/Wordpress subreddit someone asked
Help needed. I need to install an old backup
User sghokie on Reddit
I have a jetbackup file from 2017 that I took from my old site. I was trying to bring it back up. I built [a test server on Amazon.] I can start the restore but I get a lot of errors. I was able to fix a few by fixing old syntax issues. I don’t think this is the best way. What do the experts here suggest?
There are all sorts of reasons to restore an old version of WordPress from a backup. Historical, curiosity, nostalgia, recovery after disaster, even legal reasons. The good news is that WordPress core developers historically bent over backwards to preserve compatibility. But over time server, programming language, and general technology advances to a point where you can’t just run a restore script.
Here’s my somewhat edited answer to their specific question but it can be generalized to most older versions that don’t simply restore themselves.
Versions of WordPress from 2017 may not be compatible with modern versions of PHP. If you can dial PHP back to version 5.6 on your existing server then try that first. That version was most common in 2017 and so WordPress and all your plugins (including your backup/restore plugin) should work with that.
Otherwise you might try downloading Local by Flywheel, the desktop server app, from LocalWP.com. That’s quite configurable and, since it runs on your desktop, you can access the file system, access the database (with the Adminer database admin console anyway), run debuggers, etc. You might be able to piece things together that way.
If you’re trying to do a restore with the Jet (Jetpack?) plugin, you might try downloading WordPress 4.7 (released in 2017) and a 2017 version of Jetpack. (Version 4.9 or 5.0 were released in 2017.) Spin those up on your server. Then try your import again.
Then, you’ll want/need to inch your way forward. First, bump your version of PHP forward to the highest mark you can without throwing errors. Then, try updating WordPress core, then theme and plugins, etc.
There’s a very good chance your theme won’t be compatible with newer versions of PHP. Same for some plugins. Others will have simply disappeared. You may find you need to manually install newer versions if you can find them, or move or delete them from the your site’s theme or plugins folders.
Bottom line I’ve managed it for clients in the past. You just have to approach it like an old piece of furniture or art that needs to be restored. If you’re trying to do it yourself and find yourself running out of gas you can always contact us for a phone or Zoom call. We’ve got a lot of experience fixing older or broken websites and we’d love to help with yours.
Short answer? Real WordPress is free, open-source, created and distributed by a not for profit foundation, and distributed to individual tens of millions of personal web servers around the world.Meanwhile, the for-profit, deceptively named WordPress.com is a social-media-style company like Twitter or Facebook, with terms of service that let the owners freely collect and sell your information.
Do you need to worry if the for-profit “wordpress.com” company starts selling their user’s data to the highest bidders? Not if you use the open-source and real WordPress software that’s freely downloadable from the non-profit WordPress.org.
So… what’s the difference? It ought to be pretty simple.
The real, open-source software is called WordPress and it’s downloadable from a non-profit organization called “WordPress.org.” You download the software and run it on your own account with a hosting company like SiteGround.com, MDDHosting.com, Cloudways.com, or Kinsta.com. (Note: those are examples of hosting companies, I don’t have commercial/affiliate relationship with any of them.)
So what’s confusing? The man who developed a free, open-source content management system later set up a company that offered limited, heavily modified trial versions of his free software on his company’s cloud infrastructure. Since his company has access to and at least partial control over his customers’ websites it’s possible for him to sell their personal information or allow GTP-style AI programs to train on his customers’ content.
Even the folks at Lifehacker confuse the two
As it happens, WordPress [ed – the commercial .com company] and Tumblr are preparing to do just that. As first reported by 404 Media, the parent company for both sites sites, Automattic, has a entered into a deal to sell user data from Tumblr and WordPress to AI companies like Midjourney and OpenAI. The AI companies intend to use the data to train their systems.
Source: LifeHacker: Tumblr and WordPress Are Selling Your Data to AI Companies
This is true only of the for-profit version and I’m sorry (but not surprised) they weren’t more clear. Unlike the for-profit version, if you have a real, legitimate WordPress software runs that runs on your hosting company servers, your data is your data! Obviously if your site is public then anyone can take a look. That’s fine, of course — it’s the whole point of having a website! But if you’ve got private pages or if you limit access only to those you give access to? That’s your version of WordPress, not anyone else’s.
The short answer is maybe blogging helps random strangers find one of your posts on the internet… but that’s not the best reason for blogging. Blogging instead establishes your authority, credibility, and availability.
The chance of getting freelance work from random search (eg “web developer near me”) is pretty low vs the odds that they find you through a referral. In other words they’re more likely to find you after a former client tells them “I worked with them and they did a great job.” Think about it: what’s the first thing most people do when they get a recommendation. They search for the person or company name, right? And when they find you and your site, your posts help reinforce that recommendation, confirming that you’re who they’re looking for and that you know what you’re doing. (Pro tip: a testimonial is a very good blog post.)
But also, blog posts really can at least fractionally increase the chance you’ll get found from “cold” searches because each post is a single-topic solution to somebody’s specific problem. And search engines want to give specific answers. So, for instance, if you’re a plumber and someone searches for “fix leaking shower fixture,” and you happen to have a post specifically about leaking shower fixtures, search engines will tend to put your answer above someone else’s post about fixing leaky faucets in general.
And finally, if you post somewhat regularly vs your competition, search engines seem to rank you higher than an otherwise similar individual or business who doesn’t blog or who doesn’t blog as often. Regular posting is a direct way to let Google know you’re still in business.
