Problems and issues
Might be worth moving the discussion of problems and solutions here? That way, it doesn't get parsed every time the template is served.
Some random thoughts:
Maybe trying to get all these pages into one menu is over-ambitious. Remember, there is a Category system which achieves the sledgehammer stuff of indexing everything added to it.
HTML will never be able to do drop-down menus on its own. However, CSS3 should be able to handle them. I'm not sure how far it has progressed, but I expect the popular browsers will have some functionality by now. It might be worth trying to see if they can cope.
steelpillow 16:32, 15 May 2010 (UTC)
- Makes sense. Done. Ciaran 14:07, 17 May 2010 (UTC)
 Updating requires too much manual work
We need a script that will check which pages are not in any of the boxes. The obvious way to do this is to maintain a table of all the articles and which boxes they're in. Checking could be done at any time by downloading the list of current articles and running the script to check which current articles aren't in the table. Then we add those. Then review the table. Then another script would generate Template:navbox based on the table.
 Archive of previous problems, solved
- FIXED. Or at least, I have the fix. If we use external links instead of internal links, this problem is avoided. A follow-on problem is that the external links look different, but this can be solved in MediaWiki:Common.css by using:
- #bodyContent a.external[href ^="http://en.swpat.org/wiki/"]
- This can be used to apply a style only to external links that point to en.swpat.org, so we can make them look like internal links (which they are). Ciaran 14:04, 18 August 2010 (UTC)
- FIXED (FULLY) I've done that now, the external links idea and a CSS style to stop those links looking like external links. Ciaran 09:15, 22 November 2010 (EST)
 Possible solutions and technical improvement
- Use an <iframe> ? They're not allowed currently, but maybe that tag can be enabled.
- Does MediaWiki use templates for the HTML files, for which we could patch it (and remember to apply the patch each time we upgrade the software, and check for breakage)?
- If there are some key links you want "always to hand", these can be added to the sitewide navigation menu - that's what it is for, and where most visitors will expect to find them. steelpillow 13:50, 3 June 2010 (UTC)
- Add your suggestions!
- Two navigation systems is my current plan, but reason it's progressing so slowly is that I'm trying to make a system that won't have the problem of updating things multiple times. I want to keep the current "no intermediary page" navigation mode of navbox. It's possible that I'm overestimating the importance of this, but from looking at the page view spikes when we get mentioned on Slashdot etc., and then seeing how few people bother looking at any other page on the wiki, I want to work on making it as easy as possible for people to see the other page names.
- My thinking is, if we're to have two systems, they should give the users two different ways to search. With categories, there's no (visual) space constraints, and you can find an article by multiple paths. With the navbox, I want each article to be in only one place (well, with a handful of exceptions).
- To fix the AJAX problem, I'm wondering now if I could write a new plug-in based on the CategoryTree plug-in... Ciaran 13:42, 8 June 2010 (UTC)
Bilksi -> Bilski
- Thanks for that. steelpillow 11:40, 23 May 2010 (UTC)