8 Mistakes I Made When Building My First WordPress Plugin Using AI (With No Prior Development Experience)

As the title of this article says, I have no formal development experience. Prior to taking this plunge into building my first plugin, the most coding I was capable of, was fumbling my way through some HTML and CSS.

But! I was damn enthusiastic about building a WordPress plugin, so I decided to see if all the fear mongering about AI replacing junior developers had any merit.

Could I really use AI to build a plugin?

Turns out, the answer is “yes.”

I used ChatGPT as my Batman and Claude as my Robin. However, as helpful as they were, I don’t think AI is going to replace junior developers anytime soon. The whole project still required considerable work on my part. Not to mention a strong willingness to level up my coding game. If it was an easy plug-and-play solution, then the article you’re reading right now wouldn’t exist.

I’ll begin by briefly telling you about the plugin I built, and then I’ll walk you through the mistakes that I made along the way so that you can avoid them.

Let’s get started!

Quick backstory about my plugin

The plugin I chose to build is designed to make the text on your WordPress pages and posts more interactive. I built the initial release with a total of eight effects:

• Blur text
• Scramble text
• Add a tooltip to text
• Make text grow or shrink in size upon hover
• Add a glowing effect to text
• Highlight text with a color
• Make text fade in
• Add a play-on-click audio snippet to text

I also built a settings area for users to be able to set default values for most of the effects. In addition, there is a documentation section that explains how to use everything, a change log, and a built-in contact form for help or feedback.

I initially tried building it by having the effects hook directly into the block editor. Despite making some progress with it, I eventually hit a wall of bugs that my lack of skill wasn’t able to get through. I then decided to switch to a shortcodes approach, which was much more do-able for a beginner like me.

Now that you have a general overview of what my plugin does and a bit of the backstory, let’s dive into the mistakes I made while building it and talk about how to avoid them.

✋ Note: If you want to read a more in-depth overview of how to build your first WordPress plugin, I wrote a separate article on that. It goes into much more detail about the entire process and complements what you’re about to read very nicely.

Mistake #1: Didn’t map my plugin out in detail beforehand

I was so enthusiastic about getting to the actual coding and building stage, that I rushed my way through the planning stage. This resulted in a lot of preventable frustration and wasted time.

The biggest overall aspect of this mistake was that I completely neglected the user settings area and solely focused on the front end effects. When I say completely, I mean I didn’t even think about it. So when I did finally realize that I needed one, all of my prompting for it was spontaneous and grossly incomplete.

In practice, it resulted in way too many unnecessary revisions because after each revision, I would notice some other thing that I overlooked. For example, you can see one of the earlier iterations I created below, where I attempted to squeeze all of the effects onto a single page. I probably could’ve gotten away with it if I only had four or five effects, but I had eight. Plus, if at some point I decide to add more, trying to have them all on one page would get out of hand.

Had I planned it out ahead of time, I would’ve went with the tabbed layout that I eventually used, right from the beginning. The overall process would have gone much smoother.

Here’s what I think works better

Once you decide on what you want your plugin to do on a broad-level, find existing plugins that do the same thing or that have some overlap. Install them on a dummy site using TasteWP and use them. But don’t just use them like a regular user. Use them like a UX researcher would use them. Make careful notes on how different things work.

What do you like? What would you do different?

After you perform this plugin testing, organize your notes. Then put together a detailed description of your prototype. Ask yourself how users will interact with it.

Will they use shortcodes? Will they add extra blocks inside the block editor? Will there be a settings area on the back end?

Cover all your bases.

Consider using wireframes to visually map out how users will navigate their way around your plugin. You can get free wireframes over at Figma.

When you finish the above, use your detailed description and possibly any wireframes you create, to give your first prompt to ChatGPT. My recommendation for the prompt is to start small and gradually build. This way you can more easily isolate and fix any bugs that come up.

Using my plugin as an example, if I was to do it all over again, I’d first give GPT a broad overview of what I want to do. I’d also mention the tools and scripts I want to use. Then I would begin building only the first effect along with the corresponding area for it on the back end. I’d test it to make sure it works. If all was well, I’d add the next effect, and so on.

Mistake #2: Ignored WordPress coding standards at the beginning

Another big mistake I made was that I didn’t realize how big of a gap there is between simply building a plugin that works and building a plugin that is worthy of submission to the WordPress repository. You might be surprised, but going from zero to functioning plugin is much easier and faster than going from functioning plugin to well-coded plugin.

To put this in real-number terms:

It only took me about two or three days to build a functioning plugin, but it took me another seven weeks of work before I got it to a point where I was able to submit it to the WordPress repository for consideration.

Even if your ultimate goal is not to submit your plugin and you only want it for yourself or a client’s website, you should still follow coding best practices. This will ensure that your plugin doesn’t cause other things to break on your site and doesn’t put an unnecessary strain on your site’s resources.

Here’s what I think works better

Make sure you tell ChatGPT (or Claude) right from the beginning that whatever code it generates should follow WordPress coding standards.

If you’re planning on submitting your plugin to the WordPress repository, then for good measure, also add that any indentations should be done using tabs and not spaces. GPT has a tendency to default to spaces, but this goes against the coding standards.

If you don’t nip it in the bud right from the get go, then you’ll have to deal with it later when you do your linting. Might as well do it correctly from the start.

Mistake #3: Allowed GPT to constantly regenerate entire code files

One thing you might be tempted to do when you have very little experience working with code is to ask ChatGPT to regenerate entire code files when you’re debugging. I was guilty of this, until I realized it was getting me nowhere.

It’s not necessarily an issue if you’re dealing with a relatively small JavaScript file that’s 50 to a 100 lines long. However, as your plugin gets more complex and your main PHP file starts growing considerably, then it becomes highly problematic.

For one, it takes GPT some time to generate that code. For example, let’s say you have a bug in a file that contains 800 lines of code. Now imagine the actual problem is found on only one of those 800 lines. Does it make sense to sit in front of your monitor for five minutes, watching GPT regenerate 799 lines that it doesn’t need to? No, it doesn’t.

And here’s the other problem:

As the length of your code grows, ChatGPT’s memory worsens. What ends up happening if you allow it to regenerate very long sections of code, is that it won’t only tweak the problematic lines you’re trying to debug, but it’ll also accidentally change other lines. So now you might fix the error you wanted to fix, but you’ll be stuck with some new error(s). If you continue going about it the same way, it will leave you in an endless loop of debugging. You’ll feel like you’re trapped in the Matrix. Neo won’t be coming to save you though. You must save yourself.

Here’s what I think works better

When you’re debugging, make sure to include very specific instructions to ChatGPT in your prompts to keep it laser-focused. After some trial and error, I found that telling it to do the following worked well:

• Please do not regenerate the entire file for me.
• Analyze and isolate the specific lines of code that you believe are causing the problem and show them to me.
• Explain what specifically about those lines you think might be the issue.
• Then explain how you are going to change the lines and what you expect the outcome to be as a result of the changes.
• Finally, please give me the updated lines in a code snippet so I can copy and paste them.

Mistake #4: Used plain vanilla CSS instead of BEM CSS

If there’s one broad takeaway I learned from using ChatGPT to build a plugin, it’s that ChatGPT loves to give you the most minimum viable code possible. Its operating principle is “if it works, then it’s good enough.”

To get better than good enough, you have to be vocal about it. This is why I emphasized earlier for you to instruct it to go by WordPress coding standards right from the start. However, this isn’t the only area where you need to speak up. You also need to do it with any CSS code that GPT generates for you.

I didn’t realize this until I was deep into my process and it was only because Claude pointed it out to me while solving a separate but related issue.

I had been using the default CSS that ChatGPT was giving me, which worked, but it was the standard CSS you’d get in a CSS intro course. To be clear, standard CSS isn’t “wrong,” but it’s not what you want when you’re building a WordPress plugin. Here’s why:

The problem with using standard CSS is that if you use a class called “body” or “sidebar,” then you might interfere with other elements of WordPress that also use the exact same class name (e.g., elements in your theme or another plugin). This is why BEM is a better approach, because it’s structured in a way where the class names are specific to only your plugin. Thus it prevents any potential clashing of code.

Here’s what I think works better

There’s not much to say here. It’s very straightforward. Once you reach the point where GPT is generating CSS code for you, instruct it to follow BEM (Block, Element, Modifier) methodology. I would also recommend that if you need to revisit your CSS at any point in the future, to include a reminder in your prompt that you are using BEM.

Mistake #5: Assumed that there was only one global linter

Of all the mistakes on this list, this one is probably the most embarrassing. It felt like such a common sense “duh” moment when Claude brought it to my attention that the reason I wasn’t making any progress on lintingLinting is the process of analyzing your code to flag programming errors, bugs, stylistic errors, and suspicious constructs before the code is executed. my JavaScript file was because I was using the linter that I had used for my PHP file.

The most frustrating thing was that I wasted hours going back and forth with ChatGPT about this and it said nothing. It clearly saw that I was using a PHP linter on a JavaScript file, but for whatever reason didn’t feel the need to point it out. Instead, it just tried to endlessly get me to fit a square peg into a round hole:

The reason I ended up eventually asking Claude is because I was clearly getting nowhere with GPT. I only wish I had asked sooner because Claude spotted the problem right away.

Here’s what I think works better

This is another straightforward one: make sure you use the proper linter for each of your files. The three that I ended up using were:

• PHP_CodeSniffer with WordPress-Coding-Standards for PHP linting.
• ESLint for JavaScript linting (learn more).
• StyleLint for CSS linting (learn more).

Mistake #6: Enqueued my scripts globally

Remember what I said back in the CSS section about GPT’s operating principle being “if it works, then it’s good enough?”

It applies again here.

Unless you tell ChatGPT otherwise, when it comes time to enqueue your scripts (or styles), it will do so globally. This is exactly what happened to me. Unfortunately, I didn’t spot it until I used the plugin checker tool provided by the WordPress development team. In hindsight, I should’ve used it much sooner than I did, but I’m getting ahead of myself. I’ll talk about that mistake in a bit.

Anyway, if you’re wondering what enqueueing your scripts globally means, in layman’s terms, it means that your JavaScript and CSS files will load on every single page of whatever WordPress site has your plugin installed. I do want to mention that there are some instances where this is actually necessary. So it’s not a hard “never do this” rule. However, in many cases, it’s the equivalent of using a sledgehammer for a nail; effective yet unnecessarily forceful and wide-reaching.

In practical terms, it’ll harm whatever site is using the plugin by over-allocating the site’s resources in a wasteful manner. As a result, the site might experience increased load times, which then leads to frustrated users. If it’s bad enough, it could even hurt the site’s search engine rankings.

Here’s what I think works better

Unless a script genuinely needs to be enqueued globally, the proper way to do it, is to use something called “conditional loading.” This method involves loading your scripts only where they are absolutely necessary. For instance, if your plugin affects only post pages, then you make sure your scripts load only on those pages.

You can achieve this by using conditional tags in WordPress. For example, use is_single() to check if a WordPress single post is being displayed, and then enqueue your script. Here’s how it might look:

function enqueue_my_plugin_scripts() {
    if (is_single()) {
        wp_enqueue_script('my-custom-script', plugin_dir_url(__FILE__) . 'js/my-custom-script.js', array('jquery'), null, true);
    }
}
add_action('wp_enqueue_scripts', 'enqueue_my_plugin_scripts');Code language: PHP (php)

The above snippet checks if the page being loaded is a single post and only then enqueues the JavaScript file. This approach ensures that your scripts are loaded only when needed. It makes your plugin more efficient and reduces the potential for conflicts with other parts of the WordPress site.

If you’d like, you can learn more about enqueueing scripts in the WordPress developer handbook. We also have an older post on conditionally loading scripts that you can check out. Otherwise, as soon as you spot ChatGPT generating any code that contains the word enqueue, make sure you go back and have a conversation with it about using conditional loading.

Mistake #7: Didn’t minify my scripts

Minifying your scripts is technically optional. It’s really just a way to optimize your plugin’s performance. Therefore, I wouldn’t categorize it as a true mistake in the same way as the rest of this list. Nonetheless, it’s beneficial and it is something that I overlooked on my initial build. It wasn’t until I began dealing with the enqueuing problem above that I came across it and decided to implement it.

Having said that, minification is something that can absolutely be done later on in your process. After debugging and linting would make sense to me. Therefore, I’m not going to include a “what I think works better” section here. Instead, I’ll just share this resource where you can minify your JavaScript files and your CSS files.

Mistake #8: Waited until the end to use the official plugin checker

If you decide that you’d like to submit your plugin to the WordPress repository for review, then you’ll need to complete a checklist of action items beforehand. One of the items on that checklist is to install and use the development team’s official plugin checker:

The mistake that I made is that I waited until I was done with everything to do this. I looked at it as a formality, rather than something genuinely beneficial. I figured that between the linting, debugging, and testing that I did, that I would get a clean result. Well, let’s just say that I thought wrong.

The flaw in my thinking stemmed from the fact that different tools check for different things. It’s similar to the mistake I made with assuming there was a global linter. This plugin checks for very specific things, but those things wouldn’t necessarily come up as red flags during the other processes I had already completed.

Luckily, most of what showed up after the tool finished its scan was easily fixable. However, there was one elephant in my code that I hadn’t addressed: the globally enqueueing scripts!

Here’s what I think works better

As you can imagine, it would’ve been a lot more helpful if I discovered the enqueuing problem earlier in the process. At this point I had already removed all the testing and linting files from my plugin directory, and I was getting it ready for submission. Dealing with this meant that I had to re-do all of those previous steps after I tweaked the code.

So one final time – here’s what I think works better. Run the plugin checker when you’re either linting or debugging instead. This way you can address whatever comes up much earlier, and when you do run it one final time, it will indeed be a formality.

Final thoughts

I hope that reading through my mistakes was insightful. If you’re a seasoned developer then probably not. Then again, I’m not expecting too many seasoned developers to read this. I mainly wrote this as a way to help others who are thinking about building their first plugin without any formal training.

It’s a long journey, but it is extremely rewarding. If you’re on the fence about it because you don’t think you’re capable, I encourage you to give it a shot. I guarantee that even if you don’t succeed right away, you’ll still learn a lot. Plus you can always come back to it later. You already have a bigger head start than I did from reading this article, so get to it! And when you finish, be sure to drop a comment below so I can check out your plugin.

Have you tried building a plugin using ChatGPT or similar AI tools? How did it go for you? Did you make similar mistakes? What are some other things you’d tell beginners to keep an eye out for? Let us know in the comments!

…

Don’t forget to join our crash course on speeding up your WordPress site. Learn more below: