My Journey to Creating a WordPress Plugin With ChatGPT: 120 Hours of Work, No Prior Experience

I actually thought I could build a WordPress plugin with ChatGPT in just a couple of hours. Well, “a couple of hours” turned out to be 120. Assuming you plan on following in my footsteps, I strongly urge you to read this article in its entirety beforehand. It will genuinely save you hours – even days – of extra work.
The post My Journey to Creating a WordPress Plugin With ChatGPT: 120 Hours of Work, No Prior Experience appeared first on Themeisle Blog.

I’ll be honest: I actually thought I could build a WordPress plugin with ChatGPT in just a couple of hours. Or, at least, that’s what all the YouTube tutorials and Twitter threads led me to believe.

But let me tell you, those stories left out a few crucial details – about 120 hours’ worth of details, to be exact. Yes, that’s how long it actually took me to build the plugin from start to finish: 120 hours!

For context, I didn’t have any prior experience with plugin or WordPress development, but I decided to dive in anyway. And while I loved the challenge, it was a lot harder than I expected. Every step of the way, I hit one roadblock after another, many of which I didn’t even know existed. It was frustrating, but also a huge – huge(!) – learning experience.

Assuming you plan on following in my footsteps, I strongly urge you to read this article in its entirety beforehand. I’m not saying that as some sort of self-promotion. I’m saying it because it will genuinely save you hours – even days – of extra work. There are so many things that I stumbled across in this process that I had no clue were important until after the fact. Unfortunately, that led to countless revisions of code (filled with lots of frustration) that could have been prevented. By reading this, you won’t have that problem.




Table of contents

Who this is and isn’t for 🙋‍♂️

Depending on your background and skillset, you might be wondering if you’re “qualified enough” to do this. I’ll say this much:

While you don’t need to have any prerequisite coding knowledge, you do need to be enthusiastic about learning some code and the general process of developing a plugin. There are a lot of phases to get through, and often times, one phase has nothing to do with the other in terms of the skills (or even tools) you need to complete it. In short, be ready to learn – A LOT.

Depending on the nature of your plugin and your ultimate goals, it could easily take you a month or more to come up with a final product.

Having a strong eye for details and recognizing patterns will help quite a bit, as will knowing what PHP, JavaScript, and CSS do. You don’t need to know how to code with them, but understanding their purpose and how they are used will be an advantage.

If none of the above describes you – particularly the willingness to learn – and you’re looking for a quick-and-easy solution, then this isn’t for you. It’s neither quick, nor easy. But, it is possible if you put in the effort.

If you’re okay with that, then let’s get started.

Phase one: map out your plugin in detail 📝

The very first question you need to ask yourself – and answer – is what type of plugin do I want to build and what do I want it to do?

You might be tempted to rush through this so you can start actually building and coding, but I urge you to take your time with it. What you do here will lay the foundation for your prompts and will allow you to build in an organized manner, rather than adding things on the fly. To get through this phase effectively, consider the following:

What functions do you want your plugin to have?
What do you want the wp-admin side of it to look like?
Create wireframes or flowcharts to visualize the plugin’s workflow.
Map it out and describe it down to the tiniest details.
Decide if you want it for private use or if you want to make it available in the WordPress repository for public access.

Functions

Read the breakdown 👇🏻

Start by listing out every single feature you want your plugin to have. Don’t hold back here – write down everything, even if you’re not sure how to implement it yet. For example, when I was planning my shortcode-based plugin, I wanted it to be able to do the following:

Blur text
Scramble text
Add a tooltip to text
Grow or shrink text
Add a glowing background to text
Highlight text with a background color
Fade in text
Add a clickable audio link to a piece of text

Your list might be longer or shorter, but the key is to be as comprehensive as possible. Think about what would make your plugin truly useful and unique.

The wp-admin

Read the breakdown 👇🏻

Next, consider how you want your plugin to appear and function in the WordPress admin area. This includes:

Settings pages: What options do you want to provide? How will you organize them?
Menus: Where will your plugin appear in the admin menu? Will it have sub-menus?
Metaboxes: If your plugin interacts with posts or pages, will it need custom metaboxes?
Tables: If you’re storing data, how will you display it for the admin to review?

In my case, I decided on a main settings page with tabs for each of my shortcodes, a separate page for documentation, and also a page with a contact form in case users want to get in touch with me. This is what I came up with:

Unfortunately for me – but not for you because you’re reading this – is that I was so focused on the front end functionality of my plugin during the planning phase, that I completely neglected the wp-admin side of things.

This made it take longer than it would have if I planned it ahead of time because I kept having to revise the code when I realized that what I had was incomplete or had poor UX. If I mapped it out ahead of time, or better yet, if I used wireframes, then this phase would’ve went a lot smoother – which is a perfect segue to the next point.

Wireframes or flowcharts

Read the breakdown 👇🏻

As I just mentioned, this is something I personally didn’t do, but wish I had done. If you’re planning to build a more complex plugin, then this step is clutch. You don’t need to be an artist – even rough sketches can be incredibly helpful. Consider creating:

Wireframes of your admin pages and any front-end elements
Flowcharts showing how data moves through your plugin
User journey maps to understand how people will interact with your plugin

While doing this also takes time, in my opinion, you will have an overall net time save and a much smoother building process when you go into the coding stage with a precise detailed layout of your plugin.

If you’re not sure where to start, check out Figma’s free wireframe templates.

Combine everything and describe it in detail

Read the breakdown 👇🏻

Finally, take all of the above and write it out in excruciating detail. For each feature and interface element, describe:

Exactly what you want it to do
How you want it to interact with WordPress and other parts of your plugin

When thinking about how you want your plugin to interact with WordPress, the options aren’t limitless, but they are extensive. For example, depending on the type of plugin you’re going to build, you could:

Use shortcodes
Hook directly into the block editor
Add extra blocks
Add REST API endpoints
Include hooks
Create custom post types and taxonomies

If you don’t have the technical vocabulary to describe these exact mechanisms or understand – don’t panic! It’s perfectly okay. I listed these just to get you thinking about the overall concept. The main goal is to create as clear of a picture as possible of what you want to achieve. This way, when you’re prompting ChatGPT, it will take all of those elements into account when writing your code.

When I built my plugin, I initially attempted to hook directly into the block editor for the front end features. Despite making some early progress with it, I eventually hit an insurmountable wall. After about two days of relentless but fruitless troubleshooting, I ended up pivoting to shortcodes instead. This approach ended up being a lot more manageable for a first-timer like me. You might find yourself in a similar situation so keep this in mind.

The last thing I want to mention here is that these mechanisms are usually not mutually exclusive. Many plugins, even those developed by beginners, combine multiple mechanisms. In all likelihood, unless you don’t plan on having a settings area, you will also end up using a hybrid approach.

Private use vs public access via the WordPress repository

Read the breakdown 👇🏻

There’s one more decision you should make before moving on to phase two. That decision has to do with who you’re going to build this plugin for.

Do you want to make it only for yourself (or a client)? Or, do you want to submit it to the WordPress repository for approval so that it will be available to the general public?

Technically, you don’t need to absolutely make this decision just yet. However, in hindsight, I wish I would have done it earlier in the process. Hence why I’m recommending that you do it now.

The reason is because my goal from the beginning was to submit my plugin to the repository, but I initially built my plugin without following WordPress coding standards. I focused solely on functionality and getting it to a point where it worked without bugs.

As a result, I ended up having to do a lot of additional code tweaking to make my code fit the standards. Needless to say, this took a lot of time, and could’ve been avoided.

With that said, even if you plan on only building a plugin for private use, I would still recommend going by the coding standards. This will reduce the likelihood of your plugin malfunctioning with later WordPress releases. Process-wise, the main difference is that you won’t need to be as anal about non-functional aspects of the standards.

For example, when you make inline comments like // Use global default. you are required to put a period at the end. The period has no functional purpose, but if it’s missing, it’ll get flagged as an “error” according to the standards. For a private build, you can ignore this type of “error.”

Phase two: give ChatGPT a detailed prompt to begin development 🗣️

The main idea here is to give GPT an overview of your plugin with clear instructions. As a general suggestion, I would advise you to avoid trying to build the whole house at once. It’s better to take a brick-by-brick approach.

Let’s say you were to build my plugin as an example.

Even though it has eight effects, I would recommend telling GPT that you want to start with one effect. Almost as if you were building a one-effect plugin instead of an eight-effect plugin. Then check to make sure the effect works – including the back end settings area. Fix any bugs, and once everything looks good, add the next effect. Then just follow this process, one by one.

The reason for doing it this way is that it makes it easier to fix any bugs that might be introduced into your code as your code grows in complexity. If GPT generates all of your code at once and lots of things aren’t working, it’ll be much harder to fix.

You still want to give GPT a broad overview of your overall vision for the plugin, but end the prompt by focusing on some specific thing first.

To save you some time, I’ve created an example template you can give ChatGPT to get you started.

The sections in brackets [X] require your input to complete. You may or may not have to edit it further, depending on the kind of plugin you plan to build.

If you don’t understand everything in the prompt, don’t worry, I didn’t either. You’ll learn as you go through the process.

My prompt 🤖

I want to build a WordPress plugin called [name] that does the following:
[General overview but don’t give GPT the specifics yet]
I’d like it to work via [Refer back to the section “combine everything and describe it in detail” from phase one; think about how you want your plugin to function – if you’re not sure, then you can delete this part].
I would also like to create a settings menu in wp-admin so that users can [Explain what you want your settings menu to look like and do, including any specific UI/UX considerations; if you create any wireframes, upload those as well]
I plan on using the following tools for this process:
– Docker and/or Local by Flywheel Choose one or use both); which causes your code to break because it closes off a parent snippet that’s not meant to be closed off yet.

After a while you’ll get better at figuring it out, but when you’re starting your plugin development journey, if you notice a lot of things break after you add a snippet, try deleting that very last line to see if it “magically” fixes everything.

The console is your best friend

If ChatGPT tries to debug the same problem with no success and you find yourself going in circles, ask it to add console.log lines to the sections of code it believes are causing the issue. Then open up the console as you recreate the bug. It will explain what happened. You can then screenshot this explanation and give it to ChatGPT so it can figure out how to fix it.

To access console in Google Chrome, right click on the page and select Inspect:

When the console doesn’t give you answers, check your database

The console is excellent and will often give you the answers you need. However, on some occasions, it will only confirm what you are experiencing, but without really giving you any sort of direction on how to fix it.

For example, when I was trying to add a typing effect to my plugin, the default preview speed of the effect in the wp-admin was set to 23 milliseconds. I spent an insane amount of time revising my PHP and JavaScript files to try to fix the issue, but to no avail.

Console confirmed that it was loading at 23, but beyond that, it didn’t give me any other valuable information:

Eventually, I checked the database, and realized the faulty value was coming from there:

I switched that 23 to 60, which is what I wanted, and it solved the problem.

If you end up using Local by Flywheel, you can access your database easily through the interface by clicking on the Database tab:

Once you gain access, a good place to start looking is the same place you saw me looking in the screenshot above: wp_options. Most of the time your plugins settings will be found there.

⚠️ However, it’s also important to point out that the bigger underlying issue here was that my code was actually missing activation instructions. When your plugin is first activated, it should check if certain settings exist in the database. If they don’t, your plugin should add them with your intended default values. This ensures that every new installation of your plugin starts with the correct settings. I learned this the hard way so that you don’t have to.

A fresh thread can give you breakthroughs

As your code grows and your thread with ChatGPT gets longer and longer, it will be prone to make mistakes or forget things. At a certain point, it’s a good idea to start a new thread. Upload your main plugin files to the new thread and explain to ChatGPT what you are doing and where you left off.

Here’s an example prompt you can use:

I was working on debugging a WordPress plugin with you in another thread but I think the thread got too long and you were starting to get confused. Let’s start fresh.

Take a look at the plugin files here and let’s try to troubleshoot [describe your bug].

Also, and this is VERY IMPORTANT, when generating new versions of code snippets in an attempt to troubleshoot, please don’t just generate the snippet, but also provide an explanation on which lines you changed from what is already present. Also, explain the rationale behind changing those lines, and what we can expect to see with the changes you’ve made.

[If generating CSS, don’t forget to remind ChatGPT to follow BEM (Block Element Modifier) methodology.]

Don’t be afraid to use your brain

The more complex your plugin, the greater the potential for GPT to mess up your code. While it does help you debug, at times you’ll find it’s better to figure out the solution on your own. To be honest, this happened to me quite a lot, especially in the later stages of my build where my main PHP file had grown to over 500 lines (with later versions exceeding 1,000).

Depending on your familiarity and comfort with reading code, this could be a deterrent, but if you are decent at pattern recognition and spotting inconsistencies then you can get by.

I’m certainly not a skilled programmer, though I do have an understanding of what various programming languages do and some familiarity with code, which helped me.

Still, even if you’re a total noob, you can look at the lines of code that GPT thinks might be causing the problem. Then find an identical element in your code that is working properly. Compare its code to the code of the broken element and try to see what’s different about it. Often times this will solve the problem:

Keep backups of your plugin files (optional if using Git)

While using Git provides a powerful way to manage and revert changes to your code, it’s never a bad idea to keep manual backups as well. Whenever you hit a milestone with your code, I suggest saving a copy of your main code files in another folder:

This can serve as an additional safety net, allowing you to easily revert to a previous better version if you encounter serious bugs while continuing to build.

Don’t give up easily, but know your limits

There might be some functions or tweaks that you simply won’t be able to implement no matter how hard you try. Be prepared to adjust your expectations and work around them. This doesn’t mean give up if you hit a wall. However, it does mean that if you’ve made 100 attempts and spent hours (or days) trying to achieve something with no success, then it’s probably either not possible or outside the capability of both you and ChatGPT.

Lastly, if you’re wondering whether you should debug or lint first, to my understanding, there’s no clear cut answer. I debugged before I linted, but you can either default to ChatGPT’s preference as you go through the process, or tell it which one you want to do first.

Phase six (optional): testing 🔬

If you’re building a relatively simple plugin and you’re confident in its functionality based on your own manual testing then you don’t necessarily need to take this step. I say that because it still requires a lot of work to code these tests, and in the same way that you won’t get a working plugin out the gate with ChatGPT, you are also unlikely to get a functional test with no bugs present.

Simply speaking, there’s a trade-off here between time investment and practical value.

In my own experience, I was able to successfully build one test that checked whether or not my plugins were able to perform their main functions when a user interacts with them – but it took me an entire day of debugging!

From a practical standpoint, I had already manually checked my plugin’s functionalities, but it was nice to see that the test confirmed everything was working.

If you’re going to attempt to build a more complex plugin than I did, or if your plugin’s functions will be focused on the back end (where you can’t manually check whether they are working or not), then taking the time to properly run tests is worth the manual labor.

Types of tests

Read the breakdown 👇🏻

Depending on the complexity of your plugin, you may want to consider different types of tests, such as:

Unit tests: These tests focus on verifying the functionality of individual components or methods within your plugin.
Integration tests: These tests check how different parts of your plugin work together, ensuring the overall functionality is as expected.
End-to-end (E2E) tests: These tests simulate user interactions with your plugin, from start to finish, to ensure it behaves as intended in a real-world scenario.

The specific tests you write will depend on the features and complexity of your plugin. If you’re unsure where to start, I’d recommend focusing on unit tests for your core functionality first. Then expand to integration and E2E tests as needed.

If you or ChatGPT continue to get stuck, the WordPress developer community has an extensive resource on testing that you can check out. You can either look through it yourself or copy sections of it and feed them to ChatGPT as it continues to help you debug.

Tools to consider

Read the breakdown 👇🏻
Yoast PHPUnit Polyfills: This Composer package provides compatibility with the latest version of PHPUnit for older versions of PHP, ensuring your tests can run consistently across different environments.Terminal command: composer require yoast/phpunit-polyfills
MySQL: The MySQL database server is a common requirement for many WordPress plugins, as they often need a database to store and retrieve data.Download link: https://dev.mysql.com/downloads/mysql/

I used both the Yoast PHPUnit Polyfills and MySQL as part of my testing setup.

Additional tools you may want to consider:

WP_Mock: This is a testing framework specifically designed for WordPress development. It allows you to mock WordPress core functions, which can be particularly helpful when writing unit tests.Terminal command: composer require 10up/wp_mock
Codeception: This is a comprehensive testing framework that supports unit, integration, and end-to-end (E2E) testing. It has a WordPress-specific module that can simplify the testing process for WordPress plugins.Terminal command: composer require codeception/codeception
WP Browser: This is a Codeception module that provides a high-level API for interacting with WordPress during E2E tests. It can help you simulate user interactions and test your plugin’s functionality in a more realistic environment.Terminal command: No direct terminal command, as it is a module within Codeception
PHPUnit Parallel Runner: If you have a large test suite, you can consider using the PHPUnit Parallel Runner to speed up the testing process by running tests concurrently.Terminal command: composer require brianium/paratest

Phase seven (optional): submit your plugin to the WordPress repository 🥳

If you’ve made it up to this point, then you’ve ascended the proverbial plugin mountain successfully. The only thing left to do is plant your flag so that it joins the other 59,650 plugins in the WordPress repository.

That has its own separate process, which is accompanied by a checklist on the Add your plugin page:

Read the Frequently Asked Questions.
Comply with all of the Plugin Developer Guidelines.
Ensure you have permission to upload your plugin to WordPress.org for others to use and share.
Your plugin, including all its libraries, and any other included assets are licenced as GPL or are GPL compatible.
You do a final round of tests with the Plugin Check plugin, and you resolve any indicated issues (excluding what you think are false-positives).


Plugin Check (PCP)

Author(s): WordPress Performance Team and Plugin Review Team

Current Version: 1.1.0

Last Updated: August 28, 2024

plugin-check.1.1.0.zip

You might think that after all the debugging, linting, and testing you did, that the plugin they ask you to use won’t pick up anything. However, as a first-time plugin developer, you will likely have a few outstanding issues left to resolve – especially if you don’t remove the testing files from your build before running the check.

To proceed, go to ToolsPlugin Check:

Then check off all five categories and run the check:

You can then feed those outstanding issues to ChatGPT and resolve them. When you’re finished, run the check again to ensure a clean result. Do it as many times as you need to. Once you get a completely clean check (excluding false positives), you can submit your plugin to the WordPress development team. Then wait patiently for them to review it.

Final thoughts 🧠

While it is a fun and rewarding process to build a plugin with ChatGPT, it is by no means a quick process. You need to put in a lot of sweat equity to make a decently working final product. In the end though, you’ll appreciate all the new skills that doing this project will teach you.

Here are a few things that I learned (and you might too):

I learned how to navigate my way around my hard drive using Terminal commands and also learned other commands related to the process of building a plugin.
I’m now fairly comfortable with both Docker and Local by Flywheel, both of which I never used before this experiment.
I’m also familiar with lots of developer tools and scripts that I never even knew existed prior to this.
I’ve taken some classes in the past with Free Code Camp and Codecademy, and though both were great, I feel like I got a lot more hands-on knowledge by completing this project.
Related to the above, I now have a lot of random coding nuggets of information that will come in handy if I work on something similar again.
The gap between zero to working plugin is much smaller than the gap between working plugin and submission-ready plugin. I got a working version of my plugin done within a few days, but it took me another few weeks before I worked out all the tweaks to make it good enough to submit to the WordPress repository.

Overall, this was one of the coolest activities that I’ve done in a long time. Thanks for taking the time to read. If you end up using any of this information to build your first plugin, please drop me a comment below. I’d love to check out your final result.

Free guide

4 Essential Steps to Speed UpYour WordPress Website

Follow the simple steps in our 4-part mini seriesand reduce your loading times by 50-80%. 🚀

Free Access

Was this article helpful?
Yes

No

Thanks for your feedback!
Yay! 🎉 You made it to the end of the article!

You can check also:

Martin wrote his first e-book and built his first website using Weebly to market it and sell it in 2013. After making his first sale, he knew he was onto something. A few years later he made the switch to WordPress and from then on he became a full on WordPress addict. When he’s not WordPress-ing, you can find him doing pullups, handstands, drinking matcha, and of course, writing.

Reviewed By: Karol K




Table of contents

 


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *