spherical

Just completed the v1.4 Update. I think you’ll like it.

Got an update coming that cures the sub-menu issue all the way back to WP 3.5. V1.4 of the plugin will be up in a day or so.

Need more info on #1. When the window is wide enough that Ozh’ menu is all on one line, nothing has ever dropped behind it, so I’m unsure what you are seeing.

Which “top portion of the page”? There is a headline/label as in: “Dashboard” that used to drop behind Ozh’ menu when there were too many menu headers and/or the window was too narrow. I’ve fixed the vertical placement when the window is narrowed to the point where the “Settings” and one additional menu (if installed) would cause a wrap to a second line.

I’ve also fixed the vertical placement when the window is narrowed to the point where WP’s abbreviated tablet/mobile menu activates. With it being taller, Ozh’ menu was getting stepped on by the Toolbar and with Ozh’ menu wrapping, too, the page was even farther under the menus.

Ok. Jumping through the deactivate plugins hoop, and deactivating all of the site-specific plugins on one domain, nothing changed. I then turned to Network Activated plugins. I got to Jetpack and first decided to deactivate modules within it first, as opposed to the whole plugin. That this issue is related to posts, I deactivated Shortcode Embeds and WP.me Shortlinks. Problem went away!

To narrow down to which one, reactivated Shortcodes. Still no problem. Deactivated Shortcodes and reactivated Shortlinks. Still no problem. Reactivated Shortlinks. Still no problem. Huh?

I’m back to where I started and the first Save Draft now returns to Edit Post; not New Post. Go figure. Might be that Jetpack config needed a kick.

What happens to me in 4.2.2 is the first time I hit Save Draft the page refreshes to a New Post screen. I was less than happy that my initial edits got wiped, but checking the Edit Posts page I found that the Draft had been saved and closed; replaced by a New Post. Opening the saved post, performing edits and hitting Save Draft from then on works as expected. This happens with three different themes running on different sites in a Multisite Sub-domain install. I have since ensured that this doesn’t do any more damage than described above by Selecting All and Copying to clipboard before hitting the button.

I have some time now, so will slog through the tedious process of disabling plugins to see if one has an issue with v4.x.x

Works here.

Still not sure why people insist on disabling the Toolbar. It has a LOT of valid uses. Back when it was the Admin Bar, that was a different story altogether. YMMV.

Need more information:

• Themes activated in both front end and back end
• Other plugins running

Something is preventing the CSS from loading. I had an issue with this when I set access Deny rules for certain file types/extensions in .htaccess. The CSS for the menu is in a .php file: adminmenu.css.php

If you are preventing access to .php files in /wp-content and subdirectories in a certain way, this file cannot be accessed.

Sounds like it may be a php version issue.

Have you tried an earlier version of Ozh Admin Drop Down Menu as a debugging step?

Running a backend theme?
Have you tried switching from the frontend theme you are using to one of the ones supplied with WordPress: TwentyTen through TwentyFourteen?

Running WordPress 4.0?

Running WordPress 4.0?

Yes. See my post, above. One thing keeps breaking other things. Gotta tell you something.

Yes, the secondary menu icons do not and, as far as I know, cannot have unique icons per-entry. Plugins place their menu entries into the menus. With so many plugins, there is no way to be able to accommodate them all as being unique, so a generic icon is used.

I figured that you were running Admin Menus Fixed, as the screen shot matched mine when I narrowed the browser window far enough to create the second level bar. I looked into trying to accommodate this, but there just isn’t a way that I can come up with that would be practical. It would require a bunch of code just to sense the wrap happening in these rare cases. The menu wrap happens, whether Admin Menus Fixed is running or not. It just scrolls with the page; having displaced the content section down when it happens. In order to have the menu bar fixed, a finite location needs to be specified in relation to the Toolbar. I could set a large offset to accommodate the wrap, but then it would be a useless empty area for the many users whose menu doesn’t wrap.

Like I said, that’s a lot of icons in the main menu. I’m not even sure that that many entries would fit in the default WordPress vertical sidebar menu. What are all of those pushpins?

Seeing as how you’re using a menu editor, I would suggest in this case, that it would be best to consolidate and group similar functioning menu entries into a few sub-menus and thereby trim the number of entries in the main menu, such that the wrap doesn’t happen. As a benefit, plugins and functions would be easier to find, as they would be pooled together according to their use.

Ok, thanks for the screen shots. That’s a lot of icons.
By any chance are you also running Admin Menus Fixed plugin?

As far as changing the dropdown secondary icons, they are called in the Admin Drop Down Menu code and only include unique icons for default WordPress functions. All others use the cog.png. Would probably be a big project to modify them and I would guess that it would involve modifying the plugin code; which would then break when a new plugin version is released.

How did you perform the update?
What are the contents of: /wp-includes/version.php ?

I’m having difficulty parsing the terminology. Can you provide screen grabs of the various situations, so we can see what you would like to do?