Bazalgette: Diary of a WordPress Plugin – Part 2

This is the second part of my development diary of my new plugin, Bazalgette. If you don’t understand what this is about, please read Part 1.

Day 10

It’s been a while since Day 9 and Day 10, I’ll admit. I’ve had some vacation and I had to temporarily pivot to making some changes to another plugin. But now I’m back and committed once more.

I’ve taken pen to paper (metaphorically, it was more fingers to keyboard) to plan out the next stage of the plugin – processing the sub-menus. There are words I need to identify in the sub-menu titles (and in various ways – part of a word, a word on its own, etc.) and then perform 1 of 3 actions – move elsewhere, delete or just leave. Which action is performed will be directed (eventually) by the settings page.

So, for now, I’ve plotted out an array that will store all of this default data and can then be manipulated by the eventual settings screen. I’ve also worked out how to do the various search methods too, depending on the key-word.

Need an example? So, if I’m looking for “add-on”, it might be anywhere in the title, but something like “home” needs to be the entire title (so it doesn’t get confused with any title that may contain the word). Equally, “help” needs to be a complete word somewhere in the title – so it can’t be part of anything else but may not be by itself. In this case “Get help” would trigger it but “Helper” wouldn’t.

I wrote the code and, I’ll admit, it took me some time to debug – lots of trimming, searching in haystacks and multiple conditions. But it’s working now. Well, deleting sub-menus anyway.

Day 11

Sometimes it’s not all about code but sitting down and planning. And this was one of those times. I have a list of search words to look for, I have some code that can interpret them in different ways and I know how I want to filter them. Now I need to connect all those dots together. I turned to a spreadsheet to do so and even had it generate the eventual array code that I needed (inc. all the spacing for it).

The result is a lot more now being removed and it being done how I want it to, rather than a few tests.

So, the code was done and is now even looking for the menu options now that will, eventually, be moved. At this point I need to pause this bit, as this is where it gets tricky and I need to be mentally ready for this! Meantime, I’ll turn my attention to other areas of code that need attention.

Sadly, my time was cut short by a security vulnerability being raised for one of my other plugins, which meant I needed to urgently turn to that. Once that was done, I returned to Bazalgette.

Day 12

Back to it. The first thing I’m going to do before I restart the coding is to look at the output on my test site to see if all the sub-menus that should have gone, have gone – either due to an issue with my code or because there was a use-case that I forgot about.

One of the things I have noticed is that some sub-menus felt the need to add “NEW” or “NEW!” to the end of the names of new features. Often these had HTML wrapped around them to make them stand out but, due to my new code, that had gone. As a result, you ended up with menus that might say “Payments NEW!”, which looks odd (and, yes, that’s a genuine example). So, I now strip any such instances. Fun fact, this didn’t work at all because I found that some menus have HTML characters in them, so I wasn’t identifying the space before the word correctly – they were   instead. So, I decoded them using the relevant PHP command, only to find that doesn’t convert that to space, but to a different character instead. So, I do my own decoding of that one, but leave the PHP command to everything else.

Anyway, when looking through the new output, I did notice one of the keywords not being picked up. It’s not obvious why and a bit of debugging shows that not only is the code attempting to remove that specific sub-menu, despite it still being there after the event, but the WordPress function isn’t returning a failure to do so. Right now, my debugging is per-issue and pretty sub-par, so I’m going to next spend some time putting something half decent in place, which I can scale up in future to the logging that I wish to eventually implement.

And… it happened again. My changes to the my other plugin, which had reported as a vulnerability, weren’t acceptable to the security team reporting it. Sigh. So, I ended up having to recode another solution, as well as spending time to make sure it was satisfactory before wrapping up and moving on. It was.

Oh. And something happened at work that was rather a distraction.

Day 13

I’ve now added some prelimary debugging into the code. It’s not complete and, I’m sure, as I try unravel the unexpected outputs that prompted this I’ll find more debugging to add. The idea is that I keep it in, but just do different things with it, depending on my requirements. Eventually, this output will go to a lot that users will be able to view and even report to me with any reports off oddities.

So, one of the examples is for the WPForms menu, which doesn’t appear to be deleting the “Addons” sub-menu. Here’s the output I get for this…

> Processing menu "WPForms"

>> Processing sub-menu "All Forms"

>> Processing sub-menu "Add New"

>> Processing sub-menu "Entries"

>> Processing sub-menu "Payments<span class="wpforms-menu-new">&nbsp;NEW!</span>"

>> Processing sub-menu "Form Templates"

>> Processing sub-menu "Settings"

>> Processing sub-menu "Tools"

>> Processing sub-menu "<span style="color:#f18500">Addons</span>"

>> Processing sub-menu "Analytics"

>> Processing sub-menu "SMTP"

>> Processing sub-menu "About Us"

Sub-menu removed.

>> Processing sub-menu "Community"

>> Processing sub-menu "Upgrade to Pro"

Sub-menu removed.

Sub-menu removal did not work.

There are 2 things here. First of all, related to that sub-menu, I absolutely expect that HTML wrapped around it to be why it’s failing here. But that will take some more digging to confirm. But, for the last sub-menu, I’m also seeing a failure to remove it. Yet, looking at the output, it’s gone. I need to work out what’s happening here. What it does, though, is give you an early idea of this preliminary structure.

At the moment the embedding is manual but, before I go to far, I want to strip this out of the debugging text and pass as a parameter instead. Here’s the result…

Processing menu "WPForms"

    Processing sub-menu "All Forms"

    Processing sub-menu "Add New"

    Processing sub-menu "Entries"

    Processing sub-menu "Payments<span class="wpforms-menu-new">&nbsp;NEW!</span>"

    Processing sub-menu "Form Templates"

    Processing sub-menu "Settings"

    Processing sub-menu "Tools"

    Processing sub-menu "<span style="color:#f18500">Addons</span>"

    Processing sub-menu "Analytics"

    Processing sub-menu "SMTP"

    Processing sub-menu "About Us"

        Sub-menu removed.

    Processing sub-menu "Community"

    Processing sub-menu "Upgrade to Pro"

        Sub-menu removed.

        Sub-menu removal did not work.

Anyway, after giving the code a long, hard Paddington stare for a short while, I realised why some of the sub-menu removals weren’t working – if the name triggered multiple search terms, it would try it more than once. So, this was occurring because it had already been deleted. So, I fixed that and improved performance at the same time.

After much gnashing of teeth over why certain sub-menus weren’t being detected, I realised I had a typo in my search terms, and not code at all. Sometimes, the most obvious issues can be the hardest to track down.

Final wrap-up on the logging – I added a global that would trigger all the output to go to Query Monitor. Here’s an example of what it then looks like…

I need to be more consistent with my use of full stops but, otherwise, I think that’s it – all I need to do is make sure I add more log information as I add more code.

The next big thing for me to do is the movement of sub-menus, which is also the hardest part of all this. I need my brain to be firing on all-cylinders and no distractions – my family are away this weekend and my brain works best in the morning, so will make use of a quiet Sunday morning to get this coded. For now, I’m going to add some easy wins to the code, including some logging of the result of the menu move (even if the move itself is not yet implemented).