In a recent update of OTL, one of the changes I made, in the interest of simplification, was to ditch a contact form and instead simply add a ‘mailto’ link in the main menu. I didn’t expect that adding a ‘mailto’ link in WP’s menu editor – as a ‘custom link’ – would be even a minor issue, but it was. …
Now, in light of my perhaps dubious configuration – in which WP is sibling to the wee bit of OTL content (as opposed to moving them into WP as static ‘Pages’) – I had two options as to how to display a consistent menu throughout the site (i.e., including in WP).
One option was to ‘include’ the OTL menu component in WP’s header.php; this is arguably the smartest, most efficient approach, since it would result in less code overall, a single menu file to maintain.
However, I opted to take a left turn onto Stubborn Street, just for the challenge of duplicating the OTL menu in WP: minimizing the differences in markup, and applying CSS to classes (common and not) to ensure consistency in the menus. (Notice that I contextualized this decision as a ‘challenge’ when ‘pointless exercise’ would also fit 😉
Anyway, the process exposed a peculiar, albeit trivial, issue: I discovered that in WP’s menu editor, the function providing for a ‘custom link’ would not accept a mailto link (at least not one obfuscated by translation to unicode).
I then discovered that in the WP menu builder, a ‘custom link’ doesn’t allow pasting in a mailto link; I could make such a link but once saved it would render as a non-functional non-link (empty, maybe I don’t recall).
Then I happen to discover that as long as there’s something in the URL field of the custom link, it can be added to the menu structure, and then I was able to edit the item and paste into its URL field the encrypted email address.
While there’s some satisfaction in this discovery, in the interest of efficiency and having a single component file to maintain, I will likely dump the WP menu and instead include the OTL menu.