The issue is actually with the action hook wp_nav_menu_item_custom_fields. The error message you’re getting is not with the plugin itself, but rather with what appears to be a theme file.
The short explanation of the problem is that there’s a change in that action with WP 5.4. The way it is used in WP-Members 3.3.2 and earlier is incompatible with your theme’s use of that hook.
The short explanation of solutions is do one of the following:
- Switch themes (probably not really what you want to do).
- Roll back WP (alson not really what you want to do).
- Enable the WP-Members “clone menus” setting in the plugin’s main options tab (probably the best option).
- Swith to the WP-Members 3.3.3 beta release (which will probably be released this week or next). You can get it here at the bottom of the page and selecting “Development Version” from the “Previous Versions” list (yes, “previous versions” in this context does seem counter intuitive, but that’s the heading it’s under).
For you or anybody else that wants to understand the “why” detail of the problem, the full explanation continues below.
Until WP 5.4, the wp_nav_menu_item_custom_fields was not an “official” WP action hook. It came into being because there was no way to hook into customizing menu options without employing a custom walker (which is a complex process that ultimately replaces WP’s core load of the menu walker).
The problem with using a custom walker is that only one can be used. So if you had multiple plugins that wanted to hook into menu customization, only the last one loaded would apply the walker, thus breaking the system for the other plugins.
A group of developers who had menu options in their plugins generally agreed on 2 key points:
- WP really should have a core hook in it’s core walker, and
- it would be prudent for everyone involved to generally agree using the same hook name instead of putting a custom named hook into their plugin. That way one plugin wouldn’t be breaking another.
This went on for quite some time (a number of years, actually) where everyone was using this hook. It even had an “official” looking prefix tag of “wp_” even though it wasn’t in core. Because the plugins involved were open source, developers around the net when digging into how a plugin customized menus would discover the hook and write about it in their posts. People actually came to believe the hook was an official hook.
Finally, in WP 5.4, the development team for Core decided it was time to include this hook as an official hook in WP. It makes sense and there’s no reason that it should be there.
That long explanation is just the backstory so you can understand the hook and where it came from – it’s not actually the problem, but is necessary to fully understanding it. The addition of the hook officially should leave things all honky-dory, and all should be good in the world. Except that’s not always the outcome.
The “official” use of the hook can pass 5 arguments (what they are is not really important, just the number). In a case where a custom walker is employed, the number of arguments will be whatever the developer’s custom walker passes. In WP-Members and a number of other plugins, that number is 4.
That part by itself is not a problem. The problem arises if you have some new code built for the inclusion of the official hook that is demanding 5 arguments passed, but you also have some old code loading a custom walker passing less. THAT is what is happening here. Your theme is expecting 5 based on WP 5.4’s inclusion of the hook, but because you’re using a version of WP-Members written before this hook became official.
WP-Members 3.3.3 now checks the WP version and if it’s 5.4 or higher it doesn’t load the custom walker because it is not needed. The hook the plugin needs is in the core walker. It will still load it if WP is at a lower version, though. That part alone will solve 99.9999% of issues in transition.
As I mentioned in the short tldr; explanation, switching to the “clone menus” setting should be a short term solution (although you lose WP-Members’ setting for individual menu items that way) because it switches to the older process the plugin employed of switching entire menus based on login state, which was previous to the inclusion of login state settings for individual menu items in plugin version 3.3.0. Switching that setting on loads a different object for the plugin’s menu handling so the walker with the conflicting action hook isn’t loaded.
That’s it – that’s the explanation. It’s probably more wordy than necessary, but I generally over-explain these kinds of things. I simply hate it when plugin/theme developers go back and forth with a “it’s not my plugin/theme that’s the problem, it’s this other thing you have,” only to get that same response from the other developer. It happens all the time, and shows a general lack of either developer maturity or understanding of the actually issue and/or WordPress itself (or perhaps it’s pure laziness). And because I hate that kind of response, I go completely the opposite direction so that a full understanding of what the issue is can be transparent and understood. All that is to say, it’s not the plugin alone in this case; it’s an issue that is inter-related to the plugin, WP core, and the other item (theme?) and carries along with it some historical baggage. It will all be fully worked out within an update or two.
