It’s funny how updating the changelog makes you see how much time passed between the last time I worked on it.

I released the 1.9.6 version on May 18th, 2019. And version 2 finally saw the light of the day today (November 22nd, 2020). The actual work on the refactor started somewhere in March when we were all in lockdown mode. I’m not sure if that was the catalyst that caused me to start working on it, but it doesn’t matter.

I finally sat down, wrote the to-do list, made a branch, and began working on it.

I say that I’ve refactored the plugin, but in all reality, it’s more of a rewrite. Sure, the functionality is there. When you make a purchase on WooCommerce, order or invoice can be created in the Solo service, and an email with that invoice will be sent to the customer.

That’s kinda the core domain of my plugin. Everything else is bells and whistles.

What did I change?

Everything. Well, almost everything. The plugin started to get big, and unwieldy. The previous version followed the old plugin boilerplate by Devin Vinson and Tom McFarlin. While it did a good job, it was lacking in a structure that I got used to writing at my work.

I’ve been reading a lot about domain-driven design, and I wanted to follow that mindset when writing my code. Identify the core domain, and try to separate my business logic into separate subdomains.

Adding tests

Along with that, I wanted to write automated tests for the plugin. I know what the benefits of following test-driven development are. So if I wrote tests, I knew that my code would be more resilient to bugs.

I do have some tests, but in that regard, I kinda failed. Writing integration tests for WordPress is very hard. Writing unit tests, as it turned out, not so much. Thanks to Brain Monkey library. But writing tests first, without coding something is still a struggle to do for me. I am improving tho. Current code coverage is around 41.81% according to codecov.

A good thing is that, when testing out the wp-browser library for writing tests, I’ve learned quite a lot about testing. Especially acceptance tests.

Architecture changes

I’ve also rewritten the entire architecture and structure of the plugin. I’m using dependency injection, PSR-4 autoloading, PSR-12 coding standards, and other cool PHP features.

Parts of the architecture were influenced by Alain Schlessera’s Workshops. Being at his workshop kinda triggered my downward spiral into writing proper object-oriented PHP.

I also added a separate database table so that I can track the orders correctly, and if things executed as they should.

Privacy changes

The thing I’m really proud of and happy that WordPress has solved is privacy handling. There are available hooks you can use for exporting or deleting data from the database. In my case, the data is related to customers, so I wanted to make sure that it’s easy to retrieve or delete this data.

You should check the Plugins handbook on privacy, it has tons of useful explanation.

PHP changes

I’ve upped the minimum required PHP version to 7.3. Why?

Because it’s the right thing to do.

PHP 8 is planned for November 26th this year (source), and supporting versions that are at the end of life makes little sense. 

I hope that this will encourage people to update their PHP versions on the websites and reap the benefits of it (like security and speed).

Also, servers running newer versions of PHP consume less electricity, and that is beneficial to the planet (less CO2 emitted).

Settings page changes

Besides PHP changes, I’ve also decided to freshen up the options page. And what best tool to use than Gutenberg components. 

Because Gutenberg is built with React, I thought to myself: well I can then reuse its components and create a settings page with it!

It turns out that it’s not that complicated. It is JavaScript, so there are quirks. Especially handling async calls, checking if the store is ready, components mounted, etc.

I had great help from a tutorial by Hardeep Asrani on this subject.

The downside of it? When you are automating all the things (like I do), you get into some bugs.

Like the one where I cannot translate my settings page due to the fact that I’m using Webpack to bundle my assets (WP-CLI issue).

I hope that the solution for this will come along so that the translations work as intended. Hope this won’t be a dealbreaker for my Croatian users.

Why did it take me so long?

Life happens. Lockdown didn’t help, or the fact that Zagreb was hit by a pretty big earthquake back in March. All this caused me to develop slight anxiety issues. I like to think I’ve resolved them now tho 😊 .

Plus things have been busy at work. The team and I had tons of interesting ideas, we had a lot of clients so I was super busy with working on my 9-5 job.

Also, there was the issue of taking on too much. Sometimes you have this great big idea, and you start working on it, polishing it to perfection.

We all strive to deliver the best product possible, no? Well, there’s a downside to chasing perfection.

What I’ve learned

Never try to do too much. Collect all the feedback you can. Mine came from the support questions. Things weren’t working as they should and I wanted to fix them.

I also learned a lot, from the last update. And wanted to apply those changes as well.

What this causes is a long release time. Things are never perfect. Never really done.

Refactoring should be done in small chunks. Write tests first. This forces you to write testable and clean code.

Collect features and bugs and organize them. Try to solve them like you were working on a client project.

I find the agile method powerful in this regard. Write user stories for your features and issues, try to assess how complex they are. Assign story points, and try to create sprints. 

After each sprint, you can release a new version. This will provide you with continuity and structure.

Having an MVP is a must. You need to have a start, or your product will never see the light of day. I already had a start, but the lack of work on it, plus lack of managing it, meant that the code started to rot.

I started piling technical debt that was haunting me with every user support question.

The future updates

Now that I got the next major version out of the way, I can close tons of support questions and tackle the next ones.

There are a lot of improvements that I need to test. But I hope this time I’ll be smarter, and do it in a more manageable fashion.

There’s always room for improvement. Until then I hope, if you use my plugin, you’ll enjoy it. And I hope it works. If not, open up a support topic 😄 .