I made a WordPress Codex page: Plugin API/Filter Reference/wp link query args « WordPress Codex.
So I ran across an issue today when creating a custom admin menu and submenu items. I wanted to have a submenu item in the menu that linked to the main admin menu page, but did not have the same anchor as the parent. I kept running into this:
You can see that, since I’m currently on the Options page, both the submenu item for “Program Areas” as well as the submenu item for “Options” are both saying they are active. That’s because this is the way you expect to create submenu pages:
See? You declare the admin menu. Then you add the submenu. Makes sense, right? Everywhere you look, that’s how you will see it written. Even over here, where this guy was having the same problem.
But that will give you a submenu item with the first item in your submenu being a duplicate of your parent. There are even hacks where you create a menu item that’s just blank. So, great, here’s an empty tag in my menu. That’s a good solution, right? (Note, that didn’t work for me, either, but it did help in figuring out what did actually work.)
This is what you actually want to do if you want this:
See what I did there? I’m adding the submenu pages before the parent menu. For some reason, this short-circuits the tendency to create a submenu item with the same settings as the parent and allows me to have a submenu item with a different anchor link. This is the actual, working code from the project:
I’ll tell you a secret: up until a few months ago, user roles and permissions in WordPress were a vast, unexplored land of confusing terms (capabilities and — gasp — meta capabilities) and complex relationships. I didn’t know much, but I did know that if you were playing with new user roles or capabilities and messed up how you handled things, you could seriously break stuff for yourself or your site’s (or plugin’s) users. As a former Mirosoft Windows geek — who did support for Windows and applications running on Windows — it was a lot like the registry; sure, you can do some amazing stuff by hacking the registry, but if you break it, you’re screwed.
I also knew they could be incredibly powerful, especially if you wanted to create an environment where everyone isn’t an admin. Which, you know, should be like every site. Ever.
So, when I sat down to start writing my Book Review Library plugin, I was thinking about my target audience — two librarians who I worked with to hash out the specific features that they wanted for this new addition to a school website. They wouldn’t want — and shouldn’t have — admin access to everything. But if I didn’t make them admins, they wouldn’t be able to create book reviews, which were the thing they were asking for. Which is when I started looking at creating new user roles that would only be able to access those reviews and other areas that I thought they should be able to access.
And that’s the crux behind my new Pluralsight course — Master Your Domain: User Roles and Capabilities in WordPress. I wanted to go through the existing user roles system in WordPress, how you can leverage those existing roles to give site users access to only those parts of the site that they are going to be using, and how to extend those existing roles by adding new permissions (capabilities) to them or by creating new user roles. And here’s another secret: it’s really not that scary. If you get custom post types, you’ll get custom user roles and user meta, trust me.
Okay, so to commemorate the new course, I’m doing another giveaway for 1 month trial codes for Pluralsight. This time around, I’m limiting them to 5. Once I’ve given away 5, there will be no more (until I do another giveaway). Want a month of free Pluralsight so you can check out my new course? Sure you do. This time I’m using Rafflecopter and letting it deal with all the details and stuff. It’s pretty easy — follow me on Twitter, tweet about the course, then post a comment back here about what other WordPress-related topics you’d like me to cover. You can also follow Pluralsight on Twitter so you know about new courses and stuff.
New favorite WordPress function:
register_taxonomy_for_object_type(). Associate an existing taxonomy with an existing post type.
So, today the WordPress 3.8 Admin Help team met up in #wordpress-sfd — a fact that I would have forgotten entirely about had I not been at my computer coding at the time . Siobhan and one other made the meeting. That was fine. You may recall I mentioned something a while ago about getting involved in core development. Siobhan said she wouldn’t be able to be the team lead because she’s got lots of stuff going on until December, so a new team lead would need to be figured out. I proposed waiting until next week to make the decision. But I somehow found myself taking charge of things anyway, making decisions, asking important questions and ultimately I resigned to just being the team lead because probably no one else would jump up to do it anyway.
So, yeah. I’m now the team lead for Admin Help. I guess this means that I’ll wind up on the credits page if this gets integrated into core in some form or other.