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

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.

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.

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
• 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.

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.”

Once your local environment is up and running, you’ll need to set up your plugin’s directory structure. A well-organized file structure is crucial for maintainable and scalable plugin development. Here’s how to get started:

• In your local environment (i.e., your hard drive), navigate to the WordPress plugins directory (usually wp-content/plugins/).
• Create a new folder for your plugin. Choose a name that’s descriptive but concise. I named mine “Funky Text Effects.”
• Inside this main folder, set up a basic structure that looks something like this:

funky-text-effects/
├── assets/
│   ├── css/
│   ├── js/
│   └── images/
└── funky-text-effects.php

If you plan on translating your plugin into other languages, you can also add a /languages directory in the main plugin directory:

funky-text-effects/
├── assets/
│ ├── css/
│ ├── js/
│ └── images/
├── languages/ (optional)
└── funky-text-effects.php

• Finally, create a .gitignore file in your main plugin directory, which will help you avoid committing unnecessary files to your Git repository. This was included in the initial prompt template to ChatGPT so it’s possible that GPT will automatically tell you to do it when you reach this step. However, it can be forgetful, especially once your thread starts getting too long. Hence why I’m mentioning it here as a reminder.

To install your scripts, you’ll need to use the command line interface – that’s Terminal on Mac or Command Prompt on Windows.

If you’re new to development, this might feel intimidating. But don’t worry, it’s not as scary as it looks! Not only that, but whenever you get stuck – and believe me, you will get stuck – ChatGPT will be right there to help you get unstuck. I also recommend using Claude as a backup option. Sometimes if you’re not getting anywhere with GPT, Claude can provide a breakthrough.

With that out of the way, let’s take a look at the tools you’ll almost certainly need, regardless of the type of plugin you’ll be building:

1. NPM (Node Package Manager): For various JavaScript tools.
2. Composer: For managing PHP dependencies.
3. WordPress Scripts: A collection of reusable scripts for WordPress development.

In the later stages, you’ll also need to install other tools for linting, etc. I’ll cover those when we get to them.

💡 I also recommend taking a look at this page. It contains a directory of all the various script packages you can install. Although you’re unlikely to understand a lot of what they do at this stage, there are some that are titled in a way that provides a hint at what they are used for. If any of them seem like they’d be relevant to your plugin, then ask GPT about them directly.

As you progress in your plugin development journey, you’ll get a feel for which tools you use frequently and which ones you can do without. Don’t be afraid to experiment and find the setup that works best for you and your plugin.

With all of the previous steps out of the way, it’s time to create a Git repository and commit your initial files to it. This step creates a snapshot of your project’s starting point.

I personally used GitHub because that’s what we use here at Themeisle so I already had an account there, but there are other platforms (e.g., GitLab, Bitbucket) as well. If you end up using a platform other than GitHub, don’t forget to adjust the prompt template in phase three.

In the interest of brevity, I’m not going to walk you through how to do this. Once you reach this step, ChatGPT can guide you through the process step-by-step, including what commands you’ll need to type into your Terminal / Command Prompt.

When committing your initial files, keep these points in mind:

• Review what you’re committing: Make sure you’re only including necessary files. Use your .gitignore file to exclude any temporary or generated files.
• Write a clear commit message: Something like “Initial commit: Basic project structure and configs” works well.
• Don’t worry about perfection: This is just your starting point. You’ll be making many more commits as you develop your plugin.

Again, ChatGPT will most likely give you guidance on the specific commands to use for this initial commit. If it doesn’t, just ask it to. Make sure to write that you need the exact steps based on your setup and Git platform.

By completing this step, you will officially kick off your plugin development project with a solid foundation for version control. From here on out, you’ll be able to track every change you make, experiment with new features safely, and collaborate with others if you choose to do so.

Do not be vague and don’t leave it up to ChatGPT

If you don’t give ChatGPT very specific instructions, it will start spitting out endless lines of code at you and often times the code won’t even be any different from what it already gave you. It’ll want you to “double check” that it’s correct, but all that does is waste time. There is nothing more frustrating than this:

What you should do instead, is give ChatGPT very specific instructions to not simply generate code, but to specifically isolate which lines of code it believes are causing the problem and show them to you. Tell it to explain how it plans to changes those lines and why it thinks these changes will solve the problem. Finally, ask it to tell you what the expected outcome should be after these changes are implemented.

These instructions will help it stay focused on the problem and will minimize spillover bugs where it might fix your one issue but cause new problems in the process.

Regular CSS versus BEM CSS

Related to above but specific to CSS, you should keep in mind that for any CSS snippets, ChatGPT will generate standard CSS, or what I call “classroom CSS” by default.

This is the basic CSS you’d learn when taking a beginner’s course on the subject. It’s easy to understand, and there is nothing technically wrong with it per se, but when developing WordPress plugins, it can lead to conflicts with other plugins or themes.

Instead, it’s better to tell GPT to use BEM (Block Element Modifier) methodology. BEM helps reduce the risk of CSS conflicts by providing a clear and structured naming convention. It ensures that your styles are more predictable and easier to manage, as each block, element, and modifier has a distinct, descriptive class name that minimizes the chance of unintended styling impacts. Additionally, BEM improves maintainability by making it easier to locate and update specific styles without affecting others.

I already included a mention of this in the example prompt in phase two, but I’m highlighting it here so that you always remember to give these instructions to ChatGPT for your CSS snippets.

Conditional loading versus global enqueueing

Another default behavior of ChatGPT’s has to do with enqueueing scripts. Don’t worry if you don’t know what this phrase means just yet. What matters is that you recognize it in your code when you see it. It’ll look something like this:

function enqueue_my_scripts() {
wp_enqueue_script('my-plugin-script', plugin_dir_url(FILE) . 'js/my-script.js', array('jquery'), '1.0.0', true);
}
add_action('admin_enqueue_scripts', 'enqueue_my_scripts');

In the example above, the code will globally enqueue a script for all admin pages, which is often unnecessary and can lead to performance issues. Unfortunately, that’s what ChatGPT will give you unless you speak up and tell it not to. To be clear, in some instances, this is actually completely appropriate, but in many instances, it’s not.

Therefore, as soon as you notice ChatGPT generate any code with the word “enqueue,” make sure you have a conversation about it. Ask ChatGPT if it makes sense to enqueue your scripts globally, or only on the specific pages where the scripts are needed – which is known as “conditional loading.”

Remind and remind frequently

ChatGPT has a propensity for being forgetful and this is even more so when you are using it to code. So while you might give it specific instructions, the probability of it following those instructions for the duration of your project is zero.

Sometimes it will even outright ignore what you ask it to do. If this happens, just be more stern and let it know that it’s not doing what you want:

On top of that, within a few interactions it will quickly default back to its standard behavior of trying to drown you in massive amounts of code that have nothing to do with the section of code you are trying to debug.

When this happens, simply hit the stop button on GPT’s output and remind it to follow your instructions. It also helps to copy and paste them into the chat window when you are giving the reminder.

And speaking of generating long lines of code…

Avoid having ChatGPT regenerate entire files for you

When you’re not used to working with code and feel intimidated by it, asking ChatGPT to regenerate the entire file for you after each code tweak might seem attractive at first.

All you have to do is “copy and paste,” right?

While it might seem tempting, it’s actually a bad idea. In the long run it’ll cause you more trouble. Not only will you waste a lot of time doing this – especially if you’re debugging your PHP file, which can grow to be quite long, but ChatGPT might introduce new mistakes into your existing code in the process. It’ll fix the problem you’re working on, but then it’ll accidentally tweak some other part of the file and break something.

It’s better to isolate the specific parts of the code that are causing the problem and only work on those.

Take it one bug at a time

Along the lines of the above, even if you have multiple bugs – unless they are very minor – only tell ChatGPT about one of them at a time. Fix each bug before moving on to the next one.

Pay close attention to the very top and very bottom lines of code snippets

When ChatGPT gives you code snippets, it will sometimes – but not always – encapsulate them by showing you the very top line of the overall file that you are working with, and also the very bottom line. Therefore, you need to be careful not to always simply copy and paste the entire snippet because this will make your code break.

⚠️ Pay close attention to the top line:

If it’s not relevant to the specific code snippet you are trying to debug, then ignore it.

The same goes for the bottom line, though this can be trickier to spot. It can sometimes be as simple as something like }); 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:

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.

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.

• 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