Comments On Code

Posts on programming

Jan 04, 2018

Private means Private

Working with a longterm client today, I rediscovered an odd behavior in WordPress. Her business is seasonal, with varying locations and itinerary, so she needs to be able to turn pages on and off, adding or removing from the menu as necessary. She has been taught to set unneeded pages to "private." After doing so, that page was still visible in the menu and accessible even to logged out users!

It is easy enough for me to simply remove the page, and then later add it back in via the custom menu tools. However, this is a problem I wanted to solve in a way that didn't require extra steps every time a menu item needed to be made invisible. I started with looking for a plugin. Usually, behavior like this is a solved problem, and I expected to quickly find something and implement it. The only solutions I found either didn't work, or required accessing menu items directly to control their visibility. This client needed to be able to continue to perform the single action she was used to, without having to remember additional steps (who does?).

Google turned up some CSS solutions, which is less than ideal. The data is still being received, it just ends up being hidden. While the situation here is not particularly sensitive, there is no need to send data that isn't intended to be received.

Finally, I discovered a way to programmatically remove private items from the menu itself, following a stack overflow thread.

The reason (I think) that private or non-published items show up in menus is that the menu items are themselves posts and have their own post status. That means that in a situation where a page is marked private, the menu item for that page can still be set to publish, and is displayed. I wrote a filter callback for the wp nav menu objects hook which looks at the post_status for the object that the menu item stands for, and removes it from the menu if that object is private. - user jjaderberg

I edited the code a bit to suit my use case, and turned it into a simple plugin to avoid editing my client's theme files directly.

  function nmo_hide_pages_from_menu ($items, $args) {

foreach ($items as $item => $list) {

if (get_post_status ($list->object_id) == ('private') || get_post_status ($list->object_id) == ('draft')) {

unset ($items[$item]);



return $items;


add_filter ('wp_nav_menu_objects', 'nmo_hide_pages_from_menu', 10, 2);

The plugin is available on my business site Future development goals are to add plugin options, like whether to show items in menus to logged in users, or certain user roles.

Jan 27, 2016

The Joy of Troubleshooting

Troubleshooting code is one of my favorite things. No, really! I find great pleasure in taking something broken and making it work again. I am challenged to employ my personality traits of dog-headed persistance, logical analysis and puzzle-solving ability. Of course, with any worthy endeavor, there are frustrations. But, the exhilaration of finding that missing tag, or misspelled word, or rewriting a function with fewer lines of code, is satisfying. But the main reason I enjoy troubleshooting is that it causes me to learn more.

When I begin to learn a new language, one of the first things I want to understand are the tools to troubleshoot my programming. Throughout my schooling, the most frustrating language I learned was ASP .NET. Having recently picked it back up again, I realized why I struggled. The textbook we used placed troubleshooting at least two-thirds of the way through the text. We covered the text chronologically, so for many, many weeks, if I encountered a problem with my code, I was limited in what I could do to resolve it. More than once, I simply scrapped the page (which is also not easy to do in Visual Studio) and started again. I felt that I was being robbed of the learning that results from identifying and resolving an error, no matter how insignificant that error might have been.

Recently, I have had the pleasure of encountering a variety of problems to troubleshoot. A long-time client finally had a failure of an elderly WordPress plugin that hadn't been maintained in four years. While devising a new work around to solve the problem in the quickest and least expensive way possible, I also discovered the server was still running an ancient version of PHP. Note to self: when doing website maintenance updates, also check PHP version. I'm not sure if the plugin would run with the updated PHP, but access to this particular website is critical at this time, as the organization has an impending conference. We are still working out little kinks, but we are mostly back in business.

The other issue was an HTML/CSS bug in a website I regularly follow. I was able to help interpret what was going on technically to other users, and offer some workarounds until the site owner was able to repair the problem. While I didn't implement any coding myself, the exercise in interpretting technical issues for a non-technically literate audience was worthwhile. As a freelancer, I cannot take my users level of knowledge for granted, and am always challenging myself to explain things in as simple a manner as possible without insulting people's intelligence.

I'm not going to go into the technical aspects of trouble-shooting in this post (hint, Google is your friend!), but rather offer encouragement that finding your own solutions is rewarding beyond having a functioning website, function or script again. When people ask me how to get better at coding, my basic answer is to break stuff. Making mistakes is inevitable. Being able to fix them shows you are well on the path of mastering the skill.