I created a drop-down menu using css/html, placing it just under the Categories drop down. Let’s call this a “Proof of Concept”. It’s currently linking to tag pages.
Notes:
WP is finicky as hell. It doesn’t seem to adhere to strict standards, so getting the colors to work to even the point of legibility was a challenge.
I can’t use the typical drop down menu (ie Categories, just above the test) because that uses JavaScript and I have no idea how to implement JS in a WP environment.
That’s also why the menu opens on hover; on click requires JS
The expanded menu – at least in the preview mode – isn’t recognised by the page, so if the menu expands beyond the bottom of the page, it just disappears/isn’t accessible. This has me concerned about using it for very long lists.
It works though. 🙂
Brilliant! And you don’t believe how relieved I am to hear you say (again) that you are having issues with WP’s adherence to HTML / CSS standards, too. I mean, if something doesn’t instantly work for me I usually put it down to my own mistakes … (my own blog’s custom CSS area is a mess of disorganization, chiefly because I can’t seem to figure out which attributes / properties WP recognizes as “inherited” — and for what purposes — and which ones it doesn’t).
So, drop-down menus can be used for anything that doesn’t exceed the (remaining) length of the page. That would suggest a couple of things:
(1) Any and all drop-down menus we’re using should be placed fairly high in the sidebar, so as to allow the maximum available space for their expansion when opened. This, in turn, suggests we should be using drop-down menus only for relatively high-ranking menu / organizational items. Arguably member “About Me” pages are; members’ Halloween Bingo / Festive Tasks master update posts are not.
(2) Beyond the placing of the menu, how many lines (= page / post links) the drop-down menu can accommodate will, inter alia, depend on the font family and font size we’re using. (That’s a general matter of blog / site construction, of course.)
(3) Options once we exceed what a drop-down menu can achieve (summarizing what we’ve discussed before):
(a) A single, alphabetized index page with links to the various “About Me” pages, itself linked from the main sidebar menu.
(b) A single page bringing together brief, one-page member bios.
(c) An alphabetized overflow box — which does the exact same thing as option (a) (“index page”), BUT right from the sidebar menu, without first taking visitors to a separate page.
(For those who don’t know: an overflow box is a box showing only the top of its contents and with scroll bar at the side so as to allow you to scroll down all the way to the bottom. For use in the context of a menu, we’d just put a list with links to the target pages / posts inside that box.)
(d) If site members configure their “About Me” sections as posts, not pages, and tag them uniformly: An “About Me Pages” feed, linked from the sidebar.
Options (a) through (c) need to be curated manually over the entire life of the community (so must a drop-down list). Option (d) is self-administering as long as members use the right tag.
(4) The above applies in equal measure to every other “special purpose” post / page that members may want to create — reading game master update posts, etc.
Incidentally (and apologies; I could kick myself for not having thought of this before), we do have a pattern for drop-down menus to work from for WP purposes, because — with a tiny bit of optical tweaking — the 2019 Festive Tasks points reporting form works — it even still takes us to Google — off the BL-to-WP export version of my original 2019 post. For future reference: https://themisathena.info/24-festive-tasks-points-reporting-form
I’m not sure if I can adapt that google form or not – I’m pretty sure google uses JS somewhere in the form, but if it’s only in the Submit, I might be able to make it work; I’ll fiddle with that later today.
I could also kick myself, because I forgot to add a rather significant caveat to the hover menu: I can’t do an overflow on it in CSS without breaking the whole thing, so I can’t get a scrollbar.
No worries on either point. I’ll be quite happy to just use the points reporting form “as is” and for no other purpose — I mean, you’ve invested enough time and work on that already anyway! Just thought I’d share it as part of the resources to draw upon, in case we ever want to.
And I don’t think I’ve ever seen an overflow drop-down menu — I mean, it’s sort of the opposite concept, isn’t it? Overflow confines the content inside a given space and you scroll inside that space to get to the full contents / bottom items. Drop-down expands the contents downward, beyond the menu’s starting point …
I just tested it and it creates the menu so that it looks just like what we want – but it doesn’t work. I created one for Member Sites, and added mind and yours. But when you click on either one, it doesn’t take you anywhere. That’s where the onClick JS stuff comes in. 🙁
I’ll leave it there in the menu for a few hours, just so you and anyone else can experience its failure to perform. hehe
I have seen an overflow dropdown, actually, when used with CSS. Not often, but it should be doable. Just not, apparently, in WP. (I thought it would be useful in allowing us more scope for location of the menus.)
Sorry, it just occurred to me to clarify that what I mean by overflow is simply a scroll bar – so that if you drop the menu down, and the length of the menu exceeds the page boundaries, then you get a scroll bar.
Hmmm … maybe if we use it in conjunction with a “submit” button — i.e., essentially as a “regular” HTML-coded form?
We could, but the submit refers to an onClick JS that has to be in one of the files (html or php, I’m not sure which) and I’m a little at sea about it. I’d know where to put it if the site were flat (in the header of the page we’re working with), but on WP?
The google forms onClick JS will refer back to an address @google, which is why we can embed the forms on other sites. Everything is referred back to google.
But even if I could do it, I think that would overly complicate the menu, especially when we do have other options, even if they don’t look quite as nice (which might be fixable with a bit more patience on my part).
For author bios, I’m most inclined to an index page, OR telling everyone who wants their bio to be available that they have to use a specific “bio” tag, and then create a link to that “About us” feed on the menu.
Of the latter two, I’d prefer a “bio” tag so we can create a feed — for the simple reason that with a group as large as 40 people or more, anything involving manual intervention / updates is, at least periodically, probably going to involve a lot of time and effort.
Agreed; I like the tag option best. And it puts the power in the user’s hands: if they want an “About me” they can use the tag, or not if they don’t.
Yes — ditto for reading game master update posts etc.