Munky Mobile MenuHow I came to write a mobile device menu plugin for WordPress.
Updated 24/01/2024 – I noticed the menu wasn’t working on PHP 8.x so I’ve fixed it.
It all started with me minding my own business and having no intention of writing a WordPress menu plugin.
A couple of years ago during one of the COVID lockdowns, my partner, daughter-in-law and her friend (both in lockdown with us) were finding themselves stuck for things to do. With Netflix and whatever other streaming services on offer exhausted, they wanted something to help pass the time. They decided between them that they would like a website to blog and review products they’d bought.
Never having ventured into web-master territory before they asked if I could set things up for them. So I did. I got them a domain name, sorted out hosting and setup a fresh WordPress installation for them. They looked at various themes and opted for the Activello theme by Colorlib. They were happy, for the most part, with the default appearance so I didn’t expect to have to do much work. I’d knock out a quick child theme, design them a simple logo and CSS a few changes they wanted to make. All went well.
OK, but what does this have to do with a WordPress menu plugin?
Well, a theme update a few months later knocked out the burger menu on mobile devices. The burger menu was still sat there happily in the top-left corner, it just didn’t do anything. I looked at the code to find the problem which turned out to be a Bootstrap update. Colorlib was packaging a local version of Bootstrap with the Activello theme and they’d updated the Bootstrap without updating the theme code (data-toggle/data-bs-toggle). I sorted the problem via my child-theme and got the burger menu working again.
Going forward to Autumn/Winter 2022/23 and I had decided to update the look of this site using the Activello theme from Colorlib. No sooner had I finished (literally the same day) Colorlib released another update to Activello again breaking the burger menu fix I had put in place. I removed my fix on both sites but the burger menu still didn’t work properly. The burger menu now opened but immediately snapped shut again.
This time I got around the issue by writing a function into the child themes of both sites. The short version is I used wp_dequeue_script to dequeue the packaged JQuery and Bootstrap, then wp_enqueue_script to add in JQuery and Bootstrap from their CDN (Content Delivery Network) sources. A quick re-write of my original child theme code and the burger menu was working yet again.
OK, but what does this have to do with a WordPress menu plugin?
I’m getting there, stick with me. Hey, Munky has a number of sub-menus, especially under Video Games. When the burger menu was open, navigating the sub-menus took up a lot of screen real estate and I wasn’t happy with it.
My goal was for an unobtrusive menu, maybe still accessible from a burger button but placed in a more comfortable position than having to stretch a thumb to the top of the screen. Fixed to the bottom seemed sensible, centered for use by the left and right handed. The burger would stay put while the page scrolled so it was always accessible, include a bit of CSS to extend the WordPress footer so the burger can sit at the bottom without obscuring any footer elements.
I thought there must be a way of incorporating a suitable mobile menu so I started looking through the WordPress plugin repository for something more to my needs. Menu plugins, mega menu plugins, accordion menus, collapsible side menus, floating menus, but nothing that really achieved what I wanted. I decided I’d have to make my own menu, at this stage though it wasn’t a plugin.
I initially added the Munky Mobile Menu into my child theme and intended to leave it at that. Then I thought about some of the other websites I maintain and how it could be useful to have this type of menu, plus some other features such as Call-to-Action, and maybe a search box, available for future use on some of those sites. A useful feature would be to “collapse” the menu into just a menu. I should add a way to remove those search features and Call-to-Action buttons if needed. The simplest way I could think to do all of this was via a plugin.
OK, but what does this have to do with a Wor… Oh! Finally?
I have coded a couple of bespoke WordPress plugins previously. Nothing complex. For example, one of the sites I maintain for a business likes to have a traditional style site map available for visitors. They update content and add/remove/change their services fairly regularly so maintaining a site map can get time consuming. I wrote a plugin for them that, when activated, retrieves a list of services, etc. and compiles them, formatted accordingly, into a WordPress page. The plugin can then be deactivated until next time it is needed. It reduces the process down to a couple of seconds with minimal human interaction needed.
Surely a mobile menu plugin shouldn’t be too complex? Well, no, not really, except this is me and if there’s a long way round for working on my own ideas you can guarantee I’ll go there (see above for evidence).
Off I go on a learning curve…
One thing I had never done with a plugin was create a settings page in the Admin panel. I’d never needed to, so I took myself off on a little research adventure through the WordPress documentation. While I was doing so I found myself heading down a rabbit hole into the realm of WordPress Boilerplates. What’s a Boilerplate? Well, the simplest description is it is a template used to keep a level of uniformity to a process. In this case it was a Boilerplate template for creating WordPress plugins. OK, that sounds great I thought, except there seems to be a whole bunch of different Boilerplates to achieve the same goal. Still, I chose one and went with it.
I opted for the WordPress Plugin Boilerplate originally created by Tom McFarlin and now maintained by Devin Vinson. My first impressions were that whole thing seemed a little bloated; not just this Boilerplate but the majority of them. Still, I went to work with it.
My public facing code fell into it with relative ease and required very little tweaking. Adding settings into the WordPress Admin pane took a lot more work. While the public facing side had a lot of information on how to apply my code I found the admin side to be a bit lacking on detail. It did provide the WordPress hooks so I could figure out the rest myself with a little help from DuckDuckGo.
What if I needed to use the plugin elsewhere?
I wanted to make my menu plugin as flexible as possible, accommodating the need for brand specific details such as logo, brand colours and brand fonts. Brand colours was easy, just drop in a WordPress Iris selector. The font was a little more difficult. How could I provide users a way to add their custom font into the font selection dropdown? I chose to do this via CSS @import and @font-face with a JSON file to populate the dropdown selector, accessible to the user by way of adding two small files to the theme/child theme folder.
Initially I included a small collection of Google Fonts but then found out that Google Fonts falls foul of GDPR. I left the code in place but commented it out. Instead I’ve added the ability to include Google Fonts via the custom font code with a warning to EU/European web admins regarding its use.
Changes should be immediately previewable so I threw in some Javascript to carry out that function. I’ve included a Support section with some basic installation/usage instructions. There’s nothing difficult to it. The plugin installs in the usual way and can be added to a site either through a text widget with the shortcode or by incorporating the do_shortcode function in footer.php.
I have no doubt the code could be made more efficient by someone more knowledgable on the subject, I felt a little lost around the whole Boilerplate scenario but I needed to give it a go.
The plugin can be downloaded below for anyone interested. It has not been submitted to the WordPress Plugin repository because, well frankly, it’s more faff that I can’t be arsed with 🙂
