Template talk:LoadBox

You can see examples of how this template might be used at User:Munin295/LoadBox test. —Munin295 · · 02:24, 11 May 2013 (UTC)

Curse sidebar

I like the general idea, but that Compact MHC schematic is interleaved with the Curse sidebar! That is, the grid is beneath the sidebar, but the tiles float above it. Also, this would basically be one circuit per box? --Mental Mouse 11:42, 8 May 2013 (UTC)

I got rid of the tables and they wrap now. –ultradude25 ᐸ Talk
Contribs 13:30, 8 May 2013 (UTC)

Thanks! Looks much better. --Mental Mouse 15:02, 8 May 2013 (UTC)

Thanks, I've got the sidebar turned off so didn't see that.

"one circuit per box?" -- It's whatever makes sense at that point in the article. For example, some of the circuit articles currently discuss multiple circuits in a single paragraph, so they might show all the circuits in a float=none LoadBox under the paragraph. Probably a good analogy is the choice between using one or more floated image thumbs or using an image gallery (and there's no reason a schematic gallery couldn't include an image too, not to reduce load time but just to keep it with the schematics if that makes sense). —Munin295 · · 15:51, 8 May 2013 (UTC)

TOC Limit didn't work

{{TOC limit}} doesn't hide TOC entries by their heading level, but by their depth in the generated TOC outline, and in wiki TOCs those don't necessarily match. So it wouldn't hide the level-5 headings I was using unless they were actually preceeded by h2, h3, and h4 headings.

But I switched to using p.mw-headline and that seems to work -- in the sense that it generates a good-looking box with a "Load content" js link, like I want, but doesn't clutter up the TOC with potentially dozens of schematic titles. I hadn't tried that previously because for some reason I thought the server would strip out .mw-headline from non-h# elements, but it didn't. : )

I've given the p's an id equal to the title, so it should still be possible to link to them if you want (but only someone who has examined the LoadBox template or the generated html would know that).

—Munin295 · · 03:39, 9 May 2013 (UTC)

Features requiring string functions?

So here's two features I'm thinking of adding, but they would both require using string functions (which may be slow):

Relative paths

Allowing paths to be specified as page=/subpage. This would require checking for an initial slash and then building the wiki links with {{PAGENAME}}.

Title defaulting to page or subpage

If the title isn't specified, it would check to see if the page parameter specified a subpage and use the deepest one. If no subpage was specified it would use the pagename. So, page=Namespace:Page/subpage1/subpage2 would produce title=subpage2, and page=Namespace:Page would produce title=Page.

Both of these wouldn't actually provide any additional functionality, but would just be conveniences for authors.

So, how bad are string functions? Obviously the whole point of this template is to reduce load times, so… avoid completely, or maybe worth it?

—Munin295 · · 05:38, 9 May 2013 (UTC)

Since these features wouldn't add functionality, only convenience, I decided to err on the side of not increasing server load and didn't implement them.

—Munin295 · · 02:01, 11 May 2013 (UTC)

Blocks and Items Template

Is this template going to be used for Template:Blocks and Template:Items? Or was the discussion in the Community portal about something else? –Goandgoo ᐸ Talk
Contribs
Edit count 02:43, 11 May 2013 (UTC)

I honestly hadn't thought of that (and we all were just talking about it!). It wasn't designed specifically for those, but I suppose it could. Here's one possibility:

Blocks 

View at: User:Munin295/Blocks/content [edit]

It's a little plainer than the current navbox. Right now much of the content of the redstone circuit articles is offloaded with {{LoadPage}} into article fragments because the schematics are taxing on the server. I created this template so that we could offload only the schematics instead of entire sections, so one of my design goals was to put as little load on the server as possible. But it probably wouldn't be too much to add some aesthetic options, the same way {{navbox}} does, if folks want.

—Munin295 · · 04:12, 11 May 2013 (UTC)

If you can add an option to center the title, I'd call that a close enough facsimile of the current navboxes. As long as the other admins are happy with it, I think this can be put into operation. -- Orthotope 10:12, 11 May 2013 (UTC)

Yeah I'm fine with it, setting the title bar to display none was quite clever and a nice simple solution until this can all be fixed properly, and now that the border is removed, it even almost fits in.

My only issue now is that it requires moving the content to a separate page. I think using noinclude we may be able to keep it together, which I'm going to test now. –ultradude25 ᐸ Talk
Contribs 10:30, 11 May 2013 (UTC)

Yep there we go User:Ultradude25/Blocks. All kept in one page.

User:Ultradude25/Blocks

–ultradude25 ᐸ Talk
Contribs 10:39, 11 May 2013 (UTC)

Oh and look at that I got it styled pretty similar to the actual navbox. –ultradude25 ᐸ Talk
Contribs 10:59, 11 May 2013 (UTC)

LoadBox's main div has its own default style attribute, and the style parameter may try to override that in the same attribute (for example, ultradude's example currently generates html: style="… border: 1px solid gray; … border-color: #CCC"). Do all browsers resolve such conflicts the same way? Maybe move the current defaults to a css class, which a style attribute can override, and make the style attribute only generate if style is specified?

EDIT: CSS does have rules to cover this situation (later overrrides previous), so it should be fine. (and I've changed LoadBox's default border to match other boxes on the wiki, which negates that specific example)

—Munin295 · · 14:53, 11 May 2013 (UTC)

If everything's on one page, we'd still have to keep it protected, because someone could just replace the LoadBox call with thousands of sprite templates (and will the various noincludes keep regular edits from creating the ripple slow-down?). If we split {{Blocks}} (et al.) into two pages, we can keep the LoadBox call protected on the main template page, but allow the content it loads to be edited by anyone without ripples (it could still be vandalized, but the vandalism won't be able to bring down the wiki).

—Munin295 · · 15:38, 11 May 2013 (UTC)

That's a very good point. In that case it would certainly be best to have the page separate. I believe the best way to execute this would be to move the pages to the /content sub-page with redirect, then replace the redirect with the loadbox template, which will be then locked sysop-only.

As per the CSS thing, that's the whole idea with Cascading Style Sheets. ;) –ultradude25 ᐸ Talk
Contribs 17:48, 11 May 2013 (UTC)

That's exactly the procedure I was thinking of; keeping the redirect avoids breaking everything during the transition. Putting it all on one page is a cute trick, though, and could work for some of the less-used navboxes such as {{Environment}}. -- Orthotope 18:11, 11 May 2013 (UTC)

Would it make sense to future-proof the {{Blocks}} revision as much as possible by moving the styling (including the float removal) to Common.css? We could wrap the LoadBox call in, say, a class="loaded-navbox" div to differentiate it from other kinds of LoadBox calls (e.g., schematics) and then apply styling by position or adding hang classes to the elements generated by LoadBox. This will allow admins to change/adjust the styling in the future without editing {{Blocks}} which would force the server to regenerate 100s of page caches. —Munin295 · · 20:00, 14 May 2013 (UTC)

As long as we're all happy with how it is right now, and are ready to apply it. –ultradude25 ᐸ Talk
Contribs 20:25, 14 May 2013 (UTC)

Looks good to me! Non-admin says let's do it!

Maybe just test the process on a less critical navbox first?

: ) —Munin295 · · 20:51, 14 May 2013 (UTC)

As I somewhat mentioned in my recent post on the community topic, my contribution to consensus is that this is good. —Kanegasi ☺C 21:11, 14 May 2013 (UTC)