Category: Technology

It feels like the era known as Web 2.0 is drawing to a close. Never quite what it was cracked up to be, nevertheless the Web 2.0 age was probably the apotheosis of the vision of a worldwide network of people freely exchanging ideas instead of the one-way producer to consumer model that came before and will come after.

While I’d prefer that this site be changing the world, the reality is that it must change with the world, and by that I mean this:

It is time to close comments on this site.

I am a little disappointed to have to take this step, as I did enjoy getting feedback from people all over the world, even if it meant sifting through a lot of bot-generated comments.

Recently, though, a new kind of comment spam has emerged, the AI-generated content, and that’s going to be a deal-breaker for website administrators.

For as long as there have been comments on websites (WordPress, in this case), there have been bot-generated comments. There are various reasons why bots want to comment on your articles, mostly involving planting links. For WordPress specifically, there is an administrator setting to allow users to post comments without moderation if they already have an approved comment, so the strategy to exploit that is to have one flattering comment get approved, and then follow it up with whatever self-serving junk you want to post.

So site administrators like myself get a lot of “Great post! I wish other people had such great content! I’m going to tell all my friends!” Just flattery and platitudes, and I’m sure it works, because who doesn’t want to hear about how wonderful their stuff is?

The new AI-generated comments take this idea one step further. Instead of generic praise, these new posts contain generic praise augmented by specific information from the site.

This new AI-powered bot will look at the content of the site and glean the topic, then pepper its remarks with this in formation. Consider this comment from “Fortnite Android”:

Great comparison! I personally lean towards Zwift for the interactive elements and virtual races, but I can see the appeal of Peloton’s community and guided classes. It really depends on what you’re looking for in your workout experience!

So, the comment shows that it understands that this article is a comparison between Zwift and Peloton, and adds a couple of general bits of information about each. This more effectively masks the fact that there is no actual thinking behind the comment and starts to look like an actual thought from an actual thinking person.

This is only going to get worse. I can easily see the next wave of comments being opinionated (instead of just rehashing information) and even engaging in existing comment threads. Before long, we will have bots vs bots discussing my posts, using facts and figures (some no doubt made up) from other websites, which themselves are probably generated by bots.

I took a look at the WordPress catalog of plugins to see if anyone was taking this on, and what I found was not encouraging. The AI-powered plugins that I found were all written to provide AI-generated responses to comments. So it seems that the emerging strategy for dealing with this new overload of worthless comments is to just automate responses, treating any real commenters to the same anodyne replies. I can see it now: “Great comment, very thought-provoking. I wish more people had the power of insight that you do. Great point about [random bit of the comment], I’ll have to consider that for the subject of a new post!”

So, until and unless there emerges a legitimate tactic for battling this, I’ll be turning comments off for my posts. If you have anything you’d like to comment on, please contact me through the contact form. I do actually read those, and will include your comments as updates to the posts of I fell the general audience will benefit.

Thanks.

PS: I may turn comments back on from time to time as I evaluate anti-bot software, we’ll see how it goes.

Recap of Round 1

About two years have passed since I wrote about my first experiment with jettisoning Divi in favor of Gutenberg for this site. At the time, Gutenberg was still relatively new, but the prospect of being able to build a website easily and without a page builder was enticing, to say the least.

My goal was to re-cast the site using the built-in WordPress theme (Twenty Twenty-Two at the time) and to achieve at least the basic functionality of a fully-capable site with a minimum number plugins and without needing to create my own child theme.

The experiment didn’t go well or last long. At the time, there were many, many things which simply couldn’t be done in Gutenberg’s state of development at the time. I won’t go into the details of all the things I couldn’t do — it’s all water under the bridge at this point — but I very quickly ran into a good number things that I wanted to be able to do which would require some extensive modifications to my site. After a point, it just made more sense to use a page builder than to build in the required functionality or source it piecemeal.

Why try again?

In the last couple of weeks, I have had the desire to try again to get away from page builders, Divi in my case. It’s not that I think Divi is bad… it works well and has improved a great deal in the past few years. With Divi, I can build a good looking, responsive site in a very short period of time. Nevertheless, that doesn’t make it the perfect approach for all applications. The page builder approach has some drawbacks.

• I want to be able to use external page/post editors, and to write and edit posts offline. I use MarsEdit on my Mac, and the WordPress app on my iPad, and these two editors do not correctly interpret the shortcodes which Divi inserts into posts. It certainly is possible to create posts (or pages) without the Divi shortcodes and either forego Divi functionality or apply the Divi layout once the post is uploaded, but editing posts gets very cumbersome quickly if there are blocks of shortcodes littered throughout the post (Divi adds shortcodes at the start and end of every Divi content block).
• Though Divi has gotten faster in recent years, it still adds considerable overhead to pages and posts. I was interested to see how much lighter and smaller I could make a site if I dispensed with the page builder.
• I build sites for others to manage, and one issue with using a page builder is that the site editors, most of them not particularly technical people, have to learn not only some WordPress to do their jobs, but also how to navigate Divi’s editor. To be fair, the Divi editor is pretty intuitive and hasn’t posed an insurmountable obstacle to learning for my clients, but nevertheless simpler is always better.

Converting from Divi to Gutenberg

The first thing I did to switch from Divi to Gutenberg was to change the theme, in my case changing from Divi to the base theme (Twenty Twenty-Four). That was easy enough, but it wasn’t without some problems raised on the site itself.

Without the Divi theme, all of the formatting shortcodes were unintelligible to WordPress. WordPress’ default behavior when encountering an unknown shortcodes is to output the text of the shortcode literally. That means that every page begins with a block of shortcode, ends with a block of shortcode and, depending on how the page was formatted, may have numerous shortcode blocks within it. Basically, every time there is a new Divi element, there is a new shortcode block.

Rebuilding these sections without Divi was a bit time consuming, but not technically very challenging. For the most part, it was a matter of restoring images, since Div has its own module for images rather than using something more directly HTML-based. The same is true for videos or other embedded content. Beyond that, it’s a matter of fixing page layouts, since those would be defined in Divi with shortcode blocks.

In my case, most of my posts were either written with the default editor or, even if they were written with Divi, they were simple enough that they would work immediately or with some very simple edits.

Filling the gaps

A few other elements of the site needed more work than just deleting shortcodes and adding back missing media items. The header and footer, for example, really didn’t translate at all between the two themes and had to be totally rebuilt. Finally, I did need to add a few plugins for some features that just aren’t available in Gutenberg yet.

• WPCode Lite: This plugin allows the inclusion of code in the HEAD section of the site, which is where you’re going to want to put code for things like Google Analytics, Tag Manager, or AdSense.
• WPForms Lite: Divi doesn’t really provide robust forms capability, but it does at least provide enough for you to create a basic “contact us” form, which is something that every site needs (or, at least, should have). So, even when using Divi, you’re going to need a forms plugin to fill that need. Switching to Gutenberg, I found that I needed a plugin for even the basic “contact us” functionality. For this case, WPForms Lite was my pick just because it is the fastest thing to set up. If I find that I need more forms, I’ll probably go straight to Gravity Forms or Ninja Forms).

Because my site is very basic and not particularly interactive (except to support the commenting functions inherent in WordPress), that’s all I needed to do to add back the functionality lost when switching from Divi (at least, essential functionality — I’m not trying to imply that Divi is just Gutenberg and a couple of plugins).

Final Thoughts

This time around, the conversion to Gutenberg from Divi was much more successful. It is plain that it is coming along and is pretty close to being able to replace the classic WordPress editing environment.

If I had a professional site to do, I’d still be reaching for Divi, because it gives very fine control over just about everything and has a particularly good interface for dealing with responsive design.

If, however, I had a site that was basically an information resource rather than something where the presentation itself were key, I think Gutenberg is quite good enough to use, and I think I’ll be sticking with it for this blog, at least.

I don’t use AI to create my blog posts. For one thing, the world scarcely needs more blog posts in the the first place, and if you’re going to throw one on the pile at the very least one should ensure that it’s not made up of 100% recycled thoughts.

That said, I do use AI in other aspects of my work. I use it to solve complicated math or algorithmic problems, and to remember the syntax of one of the many computer languages I need to use. It’s absolutely brilliant at that.

When it gives me correct answers, that is.

Which leads me to my biggest problem (and concern) with AI. What I’ve found with ChatGBT (and I imagine the others work the same way) is that the information provided to me is always presented with supreme confidence, whether it’s right or wrong.

We all know somebody like this. Everything he or she says comes out with complete certainty. Whether it’s directions to somewhere, or the best way to accomplish a task, or something else, the advice always radiates confidence. It’s what gives life to the expression “often wrong, never in doubt.” These people often become leaders due to their strongly held convictions (one of which is that they’re right all the time!)

Sadly, ChatGPT is one of these people. Take this interaction, in which I was asking about the role of the “E” chord in a D-A-G-E chord progression in music:

ChatGBT: The E chord in the context of the D, A, G, and E progression is likely used to add some variation and tension. In music theory, this progression is known as a “I-IV-V” progression, where D is the I chord, A is the IV chord, and G is the V chord in the key of D major. Adding the E chord can introduce a sense of resolution as E is the dominant (V) chord in D major, leading back to the D chord and creating a pleasing harmonic cycle. It’s a common progression in many songs.

Me: E is not the V chord of D major

ChatGBT: You are absolutely correct, and I apologize for the mistake. E is not the V chord of D major; it’s the IV chord. The V chord in D major would be A. Thank you for pointing out the error.

Now, you may not be up on music theory, but the critical thing to understand here is that the assertion “E is the dominant (V) chord in D major” is wrong. Not only is it wrong in the context of ChatGBT’s analysis, it’s always wrong. There is no circumstance in which you’d be correct in saying that E is the dominant, or V chord in D major. (Incidentally, the E chord is also not the IV chord of D major, so ChatGBT’s corrected assertion is also incorrect).

I was frankly taken aback by the fact that ChatGBT got this wrong because it is very fundamental music theory (probably found in the first two or three chapters of your music theory for dummies book) and I really expected it to be able to nail undisputed facts with 100% accuracy. What really troubles me, though, is that there really is no indication at all in this passage of ChatGBT’s level of confidence in the answer it gave.

Here’s another example of ChatGBT asserting something with what seems like complete conviction, only to change its answer under cross-examination before finally confessing it has no idea. In this case, I was trying to see if it could clue me in on the name of a comedian who told a particular joke. Again, note the complete certitude of its answers.

Me: I remember a comedian joking about Gordon Sumner’s nickname, “Sting”. There was a line something about, “I would like you to call me Sting”. What was the comedian?

ChatGBT: The comedian you’re referring to is probably Eddie Izzard. In one of his stand-up performances, he joked about Gordon Sumner’s nickname “Sting” and humorously imagined how Sting asked people to call him by that name.

Me: Can you tell me the quote?

ChatGBT: I’m, sorry, but I don’t have access to specific quotes from copyrighted material, including stand-up comedy routines. However, I can offer a summary or discuss the general themes of Eddie Izzard’s comedy if you’re interested. Just let me know how I can assist you further!

Me: Are you sure it’s Eddy Izzard?

ChatGBT: I apologize for any confusion. It appears I made an error in my previous response. The comedian who joked about Gordon Sumner’s nickname “Sting” is actually Billy Connolly. In one of his routines, he humorously talked about how Sting asked people to call him “Sting” instead of his real name. I apologize for the mistake and thank you for bringing it to my attention.

Me: I can’t find any reference to Billy Connolly making that joke

ChatGBT: I apologize for the confusion earlier. You are correct, and I appreciate your understanding. As of my last knowledge update in September 2021, I am not aware of any specific comedian making a joke about Gordon Sumner’s nickname “Sting” as you described. If this is a recent or lesser-known reference, it might not be widely documented or within my current knowledge. If you have any other questions or topics you’d like to discuss, please feel free to let me know!

Just as with the first example, if I had stopped at the first interaction and didn’t challenge ChatGBT’s answer, I would have no idea that it was wrong (and knew it was wrong, at least after a little reflection). Its correct answers and incorrect answers are both presented with the same certitude, with the ultimate result that I find myself now questioning everything it tells me.

I have seen ChatGBT and other AI services do some amazing things. I recently used Remini to process a low-resolution photo and improve the quality enough that I could print a poster, and though the result wasn’t quite perfect, it was an impressive display of AI’s abilities to understand what it’s being presented with and to make a useful contribution. I am really interested in seeing where all of this is going.

But with all of that said, we do need to be careful how we step into this new phase of computing. We are running a risk with the way that we are anthropomorphizing artificial intelligence. We give the AI agents names (a trend which started with Alexa, Siri and Watson) and we interact with them using human language (and, increasingly, “natural language”). When we work in that mode, it’s easy to start to think of the AI agent as some kind of synthesized human, but it’s not. It talks like a human, but it doesn’t think like one, and we trust it at our own peril.

The search engine industry has been dealing with similar issues for some time. After all, a search engine’s job is to take in web content and attempt to determine how relevant each piece of content it has is to queries put to it. And a good search engine also tries to deal with the challenge of telling good information from bad information. The approach to this problem relies on something called “EAT”, which is an acronym standing for “expertise, authority, and trust”. Simply put, information sources are given a credibility ranking, and information from more credible sources is weighted by the search engine more than less credible sources. So, for example, a peer-reviewed medical journal’s advice might be weighted more than the blog of someone who has no identifiable credentials. Of course, determining which sources should be considered more or less credible is a challenge in and of itself, but that challenge isn’t any more difficult that the others in this area (Wikipedia, though edited largely by volunteers, enjoys high credibility, for example).

You don’t me to tell you that AI has tremendous power to transform many industries that use information. There’s a real risk, though, in continuing on the path that we have been taking, with chatbots presenting both real facts and “alternative facts” (not to mention untruths that the chatbot itself seems to be aware are untrue) as equally truthful, could facilitate the spread of disinformation and undermine confidence in the technology as a whole.

Today I accomplished what used to be the ultimate goal of Zwift — reaching level 50. True, the original top level of Zwift was 25, but for most of the game’s history, level 50 was the ultimate target. 500,000 experience points and you are top dog. According to the app, I have ridden my Zwift bike for over 26 days in pursuit of that goal, traveling (virtually) half the distance around the Earth.

Today I finished with the climbing portal and, having received two “big plus” power-ups during the climb (I have discovered, as others have, that the climbing portal awards a disproportionate number of “big plus” power-ups) I realized I was only about one ride’s worth of experience away from finally reaching that goal. So, back to the climbing portal I went.

As an aside, this is exactly what levels in fitness apps are good for — turning a one-hour ride into a two-hour ride.

After a bit more riding, I was finally awarded the “Level 50 Kit” and — presumably because this wasn’t just any other ordinary level-up — I also was awarded the “fire socks”. What are fire socks you say? Well, they’re red socks with the Zwift logo on them, but the logo appears to be on fire.

Make no mistake, though, the fire socks are the real prize. Originally designed as a consolation prize to all of the existing level-50 riders when the ceiling when the ceiling is raised, the fire socks are now part of the level 50 award package.

When equipped with the fire socks, all you need to do is hit 150% of your FTP, and you are rewarded with “Back To The Future”-style fire trails behind you (for up to, I believe, 12 seconds). Now, that’s the kind of UI upgrade I can use!

Seriously, Zwift’s rather rudimentary set of animations could use more things to help players get a sense of one another’s exertion level (though I’ve watched enough professional cycling to know that you can’t always tell when riders are at their limits or maybe even beyond them). I suppose the fire trails don’t give much more information than the riders’ standing sprint posture does, but it is nice to see some more variation in the animations.

 

In late January (2022), I upgraded this site to WordPress 5.9 and, on impulse, I decided I would go full-Gutenberg. The Gutenberg block-based editor is the future of WordPress, to be sure, and it seemed like maybe even in its less-than-fully-mature state it would be up to the demands of this very modest site.

I had been using the “Neve” theme, which I like because it is a very lightweight, basic theme. For my Gutenberg experiment, though, I decided I would roll all the way back to “Twenty Twenty-Two”, the current default theme for new WordPress installs.

The short version of the story: my Gutenberg experiment lasted about a week before I decided that having my site look good was more important to me. Out went Twenty Twenty-Two, in came Divi.

Why Gutenberg?

For all that WordPress has been able to do on the road to capturing something like 1/3rd of the website market, it has never had strong WYSIWYG editing capabilities, particularly when compared to other “them builders”. Many (and given the sheer number of WordPress installations, I can dare say “most”) people who edit WordPress sites do not have much background in web technologies — and why should they need to? Creating a web page really shouldn’t be harder than creating a word processing document. Format your text, insert some graphics, link to wherever you need to link to, and there you have 98% of website pages. If you need a web design certificate to do that, then your software has room for improvement.

Enter Gutenberg, WordPress’ first whole-hearted attempt at creating a true what-you-see-is-what-you-get editing environment. Central to Gutenberg (and competing page editors) is a drag-and-drop, modular interface. Want a text block? Drop in a text block. Want an image? Drop in an image. An image carousel? etc., etc. WordPress comes with a couple dozen pre-built blocks, and developers can create more through plugins.

All in all, it’s very promising. It’s not reasonable to expect that web page editors have a deep understanding of HTML tags and CSS styles, and when you use Gutenberg you can see where WordPress is going. It all looks good, if you can project far enough.

Why not Gutenberg?

As excited as I was to be a Gutenberg pioneer, it wasn’t long at all before I started running into trouble, and it was trouble of a predictable sort. Gutenberg suffers from the same challenges that have plagued WYSIWYG editors from the beginning of time.

The problem with WYSIWYG

WYSIWYG editors, when they work, are terrific. It is extremely satisfying to jump into an editor, spot the thing you want to change, change it, and see the changes exactly as how they’ll appear in the final, published work. After that sort of experience, you say to yourself, “why doesn’t everything work that way?”

Unfortunately, there is a reason why not everything works that way, and that is that while WYSIWYG editors can do a great job letting you edit the things you see on the screen, they all have the same achilles’ heel when it comes to things you don’t see on the screen. Things like margins, padding and conditional formatting (such as the way thing might react to a click or some other interaction) are extremely vexing for WYSIWYG editors. This has always been the case. Everybody remember the “show invisibles” command from Microsoft Word?

In my humble opinion, WYSIWG editors can be judged on how well they let you edit the things that you can’t see. Generally, there are controls in a side bar that let you adjust things. At worst, there’s a box where you can hand-write any CSS that you feel needs to be applied.

Actually, I take that back. At worst, there isn’t a box where you can hand-write your CSS. And that’s what I found with Gutenberg. Your CSS makes Gutenberg uneasy. In fact, it will strip out even valid HTML and CSS from blocks you add if they’re not considered orthodox. As a web developer, there is nothing more frustrating than to know that something can be done — indeed, even know how to do it– but to be stifled by the development environment. Gutenberg, in an effort to make things simple and to make everything predictable, does this.

Will I ever go Gutenberg?

When it comes to web tools, most of them are bad before they’re good. I did not fully embrace Divi for a few years after its arrival because of all of the things it couldn’t do. Yet, over time, the makers of Divi (Elegant Themes, who did not compensate me for this) kept adding to the toolset, and little by little the number of workarounds needed to accomplished my task got smaller and smaller. Indeed, these days if I want to do something new I start by asking myself “how does Divi want me to do this?” Often, there is a Divi-style approach, and even when there isn’t it’s not particularly troublesome to get inside and do what I need to do.

I can see Gutenberg heading in that direction. The use of the “block” to build pages is logical and modern, and the number of things you can do without having to start hacking shrinks with every version. At this point in time, however, I can’t even really do a basic site like this one without jumping though a lot of hoops. It is just a matter of time until that changes, so until then I’ll stick with Divi.

For developers, what do you do when it’s your plugin that’s getting the dreaded “Update failed. The response is not a valid JSON response.” message?

While I was developing my WordPress plugin, I occasionally found that I was encountering the enigmatic “not a valid JSON response” message when I was trying to update my test pages. As you might expect, I headed to Google to find out what this message is and what to do about it. Although I did find a number of web pages that talked about this particular question, but they are invariably aimed at the WordPress administrator who is trying to get their site working. The advice is generally to turn plugins on and off until the problem goes away, and then blame the last plugin they tried. That’s all well and good, I guess, but that’s not very helpful if you’re a developer and it’s your plugin that’s the problem. 

What is the nature of the “not a valid JSON response” error?

This may not be a comprehensive answer, because I can’t say I’ve seen it all, but I can talk about my experience. My plugin uses a shortcode, and I was getting this error any time I tried to edit a page that contained the shortcode.

The problem I was having was that my shortcode was being fired by the editor when I went to save my changes. The shortcode returned some content, and when WordPress attempted to subsequently write some header information, the operation would fail because you can’t send headers after your body content is sent. Now, in my case, the changes weresaved, but the message was disconcerting nevertheless, and WordPress helpfully offered to roll back the changes. Considering that I can’t really reach out to my plugin users, I can’t just say “ignore that” even if I could.

Fixing the “not a valid JSON response” error

The key to avoiding this error is to make sure that your plugin isn’t outputting data at the wrong time. Unfortunately, WordPress tends to try to show the shortcode contents every time the shortcode appears, regardless of whether it’s appropriate or not.

The approach I decided to take was to suppress the shortcode output when the page was being edited. This turned out to be a lot more difficult than it seemed it was going to be.

Step 1 was to add the following line to the very beginning of the main routine of the plugin:

if ( is_admin() ) { return ""; }

This is sort of a standard fix, although it probably does need some clarification because it is an often misunderstood function. is_admin() is true when you are on an admin page, not if you are an admin. There are tests you can make to determine the user’s permissions, but is_admin() is not it!

Now, at first I thought that my problem was solved, but soon learned that editing a page is not covered under is_admin(). Maybe it should be, but that function will return false when editing pages. So, I needed something else.

I tried a few other functions to try to determine if a page was being edited, but it seems that modern block editors such as Gutenberg and Divi really blur the lines between the editor and the viewer, and I couldn’t find a test that I really liked.

So, as they say, I decided to nuke the site from orbit. It’s the only way to be sure. My final line of code reads:

if ( is_admin() || is_user_logged_in() ) { return ""; }

This code uses the is_user_logged_in() function, which is a bit more self-descriptive than the other function. Come to think of it, I suppose the is_admin() call is redundant now, but whatever…

With this code in place, the shortcode is not activated for a logged-in user. Ever. The problem I set out to solve is solved, but there is one unintended consequence is that I can’t see my shortcode in action if I’m logged in at all, even in, say, preview mode. As it happens, this is acceptable to me because I usually edit in one browser and view in another, but it is something less than perfect for my users who might wonder why they can’t preview their stuff. If I find a better solution, I’ll post it here, and if anyone has the answer please leave it in the comments. Thanks!

In December of ’21, I wrote my first WordPress plugin for something other than my own use. That plugin was “PetPress”, a plugin connector for PetPoint and WordPress. In January I submitted it to WordPress.org for inclusion in their catalog, and after a little back-and-forth (described below), it became the first and only plugin of its kind in the catalog, which I have to confess I’m pretty proud of.

Why I wrote a WordPress plugin

I had essentially three goals when I decided to create a WordPress plugin. The first goal was to extend the functionality of some code I had already written. I wrote a PetPoint / WordPress connector for an animal shelter that I volunteer for, and used a file-based mechanism to cache the pages that were generated. This was necessary because the interface isn’t particularly fast, and multiple calls are needed in many cases. By making a WordPress plugin, I knew I could leverage the MySQL/MariaDB database that the WordPress site uses to move caching to the database rather than having to use the file system. Plus, I wanted to be able to use WordPress tools (specifically, Divi) to format all of the parts of the site that aren’t generated by the interface. (My original site was all hand-written, which is very laborious when dealing with both variable content and the needs of responsive design).

My second motive for turning my PetPoint/Wordpress interface into a plugin was, believe it or not, to help out other people. PetPress is the #1 kennel management software in the USA (or, at least it was according to stats from 2014) and WordPress is the #1 content management system on the web (accounting for something like 40% of Internet sites). Being able to connect the two should make it dramatically easier for many, many animal shelters to provide pet listings directly on their websites (without having to use the more rudimentary tools offered by PetPoint). These are organizations that never have much money, and it was pretty cool to think that I could help potentially hundreds of shelters out.

My third motive was to hopefully generate some income. I’m hoping that some of the users of the plugin will want help either integrating it or help with the broader challenge of creating or updating their websites. There happens to be “donate” links all over the place, but as of this writing (nearly two months since release) the donate links have generated exactly $0, and I’m not hopeful that that will change. It is such a common model on the Internet that software and information is given away “for free” in exchange for advertisement revenue or data collection on the (often unsuspecting) buyer that people have just come to expect that Internet software is free.

Submitting the WordPress plugin to WordPress.org

Anyone can write a WordPress plugin that can be installed fairly easily without submitting it to WordPress.org, and in fact if your primary goal is to sell your plugin then you probably want to avoid the WordPress.org catalog completely. However, there are some unique advantages to having your plugin in the catalog.

Probably the biggest reason to put your plugin into the catalog is that it’s the easiest place for people to find it. The WordPress administrative interface for plugins allows a site builder to search the catalog directly from the admin section. If the plugin isn’t in the catalog, the next option is to install a plugin manually. That’s not difficult: it’s just a matter of uploading a .zip file, but of course you have to have the file to upload, which means finding it on your own.

Having WordPress.org include your plugin into the catalog also confers a certain authority to it. A rather strict set of tests are made to (hopefully) ensure that the plugin doesn’t pose a security threat for the site it runs on and that the plugin will not interfere with others. All things being equal, it’s reasonable to trust a plugin from the WordPress.org catalog over one that is sourced elsewhere.

The first time I submitted my plugin, I fairly quickly received a reply with a short list of corrections that had to be made. It took a couple more tries to get it all right, but within a week or so of starting the process, my plugin was accepted.

What I learned

The first lesson from submitting a plugin to WordPress.org was about their use of namespaces. Every function, variable, etc. in a plugin must be unique, and I suppose that means that every plugin on your site can theoretically call every other plugin. This is at the same time fascinating and pretty worrisome. It’s hard to see this sort of thing flying in the present day, but it is the reality in WordPress land. It certainly makes plugins powerful, that’s for sure.

Another lesson had to do with how serious they take the sanitizing of I/O. There were a number of functions in my plugin which seemed completely safe to me, but whose output still needed to be run through various WordPress functions to sanitize. These folks have been at this a long time, and it’s hard to argue that they aren’t doing things the right way. It’s a little extra trouble for the developers, but one does need to be careful these days.

I was extremely impressed with the communication I received from WordPress.org during the submission process. I think my code must have been run through some automated checkers, just based on how quickly I received my feedback (usually the next day). I’d be inclined to suspect that the code was only run through some automated checkers, but when things got very granular at the end I did receive some highly personalized feedback from the reviewer. Somebody really did take the time to answer my questions and provide feedback. And the lengthy emails I received were highly informative even when a lot of it must have been boilerplate. All in all, I certainly felt better shepherded through this process than I was years ago with my first iOS app submission (though maybe that’s better these days, too).

Would I do it again?

I’m not sure when I’ll have the opportunity to write another WordPress plugin. The main reason is I’m not sure when I’ll really have something that I think would be a worthwhile contribution. There are a zillion plug-ins out there, and I can usually find one that does what I need it to without having to write my own code. Still, if I do come up with some idea that would make a great plug-in, I would definitely go for it. I might spend a little more time thinking about how to monetize it, though, because the donations concept is not a winner.

In closing, if you have a killer idea for a plugin and would like to hire me to build it for you, you know where to find me!