@tamerax – Hmm, wouldn’t be related to jQuery on the front end as we don’t have any front end JavaScript to conflict.
Honestly with only this one report and our testing on PHP 7.4 & PHP 8 I’m not sure what the issue could be without more info.
Happy to look into it but with only that info nothing stands out.
@tamerax – Here is the entire list of changes, though 95% of it was code styling/standards tweaks to pass PHPCS scanning rules we added.
https://github.com/JunglePlugins/User-Menus/commit/6d516c935464b7ab6f294f0c196535bb35af9c02
@tamerax Ahh the one unaccounted change is the update to the Freemius SDK, though it went from x.x.1 to x.x.2 so that shouldn’t be anything major since we very minorly use it in the first place.
Otherwise pretty innocuous update.
@danieliser Thanks. I would be happy to help try to narrow it down. Not sure what info you would need.
I have a staging server that is currently being worked on but once we are done with that, I can try to replicate the issue there and send you some access info so you see what is going on.
Otherwise, if there is some information I can send you now, please let me know what.
Thanks for the quick reply.
Can you clarify exactly what broke.
The only changes I see in our code that could do anything wonky would be that we started sanitizing more echoed code to cover scanner tests, but in 99% of those changes it was static internal content that wasn’t really a security issue.
But when we were testing one of these changes did mess up saving in the admin, but it was corrected and all tests passed afterwards.
Just went line by line over all the front end changes, there is only one line that changed in the front end, where the change wasn’t related to spacing, or converting array() to short [] array syntaxes, and it only pertains to the redirecting of Login/Logout/Registration links you added:
https://github.com/JunglePlugins/User-Menus/commit/6d516c935464b7ab6f294f0c196535bb35af9c02#diff-a68ae20cf68595098f60d01bbd20991aab6dfc3903b2d47bfb2f2544fa9e6f13R103
So if you have those types of links, maybe try removing them and seeing if the issue goes away, of so we can at least narrow in.
Hi,
i hope this will help
with version 1.2.5 and lower , hiding the parent menu will also hide all it’s submenus.
after the 1.2.6 you need to apply who can see link rule to parent menu and it’s submenus otherwise only the parent will be hidden.
@medtr – Hmm, happy to test it but having reviewed every line changed earlier today, I didn’t see anything that could have changed how menu item exclusion was handled.
Will set up a test.
@danieliser ,
when parent menu menu has 1 or 2 submenu it works normal.
but when it have 3 or more submenus, only the parent will be hidden.
Please check this behavior , i’m waiting for your test result
Thank you
Sorry I haven’t added anything yet as I didn’t have a chance to do more testing but for me, it is basicly making it so none of the sub menu items are hidden. Everything is showing all the time.
I am using a megamenu if that helps.
I have the same observation as Medtr. I have to hide all submenu items for the hidden parent item. This is behaviour is different in 1.2.6
In addition, I came across a fatal error when I save my menu:
“Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0 .”
If this is not resolved, I’ll have to reinstall the previous version. Where can I get the previous version 1.2.5?
Thanks
@francoc30 – Appreciate the extra details, will be looking into the front end issue today further.
You can always find older versions via the https://wordpress.org/plugins/user-menus/advanced/ page.
That said can anybody set up a clean test not using a mega menu. There is a known issue in WP core for years I want to make sure none of you are running into causing issues.
Specifically large menus can send so much data for all the items & each items extra field data that it overloads the server. 99% of the time this appears to act like its just not saving some data, but what is really happening is WP is truncating the extra length of the data resulting in unsaved data along the way.
I’ve never seen it error though @francoc30, and that error seems very unrelated to our plugin as we don’t use OB (output buffering) at all, but WP core does for some reason i’ve never really worked out, and the error indicates that it tried to capture output buffering inside a function rendering output buffering. TBH I’ve been writing PHP for 15 years, never seen that haha.
Can you duplicate that error reliably every time you save, and only with the new version? If so does that happen with big menus only?
@danieliser, Thanks for the prompt reply.
I don’t use mega menu. But even with 1.2.5 saving my menu usually take a much longer time then with other stuff. I don’t recall having this error before.
One interesting thing, even with this error, any changes made are actually saved. I am not a developer so do not know the significance of the error.
One more piece of observation: my site is bilingual. I don’t experience error on the English menu. It happens only with the Chinese menu. But then again, both were fine with 1.2.5
I am still on WP 5.7.2 I wonder if 1.2.5 will work with WP 5.8?
When I install the previous version 1.2.5, do I just install it over the 1.2.6 or I have to deactivate 1.2.6 first? I don’t want to lose my setup and menus.
@francoc30 – That makes more since now, the Chinese characters are not all UTF8 compatible, and may be getting eaten in some fashion or another by the sanitization functions built into WordPress.
That said I didn’t see any other mentions of similar so for now just a thought.
Just install it via Plugins -> Install -> Upload. WP will do the rest.
