Last modified: 2009-02-01 07:29:27 UTC
When using the '+' new section button (or passing section=new to index.php) to create new sections, I believe the new section is always a second-level heading (first-level being the page title). It'd be handy if we could somehow specify a different heading level for newly created sections (say, third-level). A magic word would work, I guess, but even just being able to pass some value to index.php would be great.
Fixed in r25396.
I believe the intend was to have the ability to set the header level anytime user uses + link to add new section. I can imagine it like: Level: [Dropdown h1-h6] Subject/header: ___________________________________________ [textarea for content] However the r25396 patch is also useful and should remain as well.
(In reply to comment #1) > Fixed in r25396. Don't think I like the idea of abusing a message for this purpose...
(In reply to comment #3) > (In reply to comment #1) > > Fixed in r25396. > Don't think I like the idea of abusing a message for this purpose... How is it message abuse? Where else should a global setting be stored? The reasoning behind it was that the H2 heading (==...==) was hardcoded and should be "customizable" - and that felt like a job for a system message to me. I have qualms with the "dropdown" idea as it allows users to choose, which might not be desired behavior (I certainly don't need my users creating H6 headings all over the place). In the event that a dropdown was added, I would personally need a $wgAllowUserSpecifiedNewSectionHeadingLevel global or some such thing to turn it off. I would argue that section additions need to be consistent (i.e. no user customization) otherwise the TOC will be all wonked out with unintended sub-sections when all the user wanted to do was leave a "new" section - the dropdown will just confuse people. Not having it as a system message would make it difficult to customize.
> Where else should a global setting be stored? Shouldn't it go in something like $wgEditSummaryHeadingLevel? I don't think a drop-down would be useful, but maybe people would like a [+] next to section [edit] links on talk pages (settable in preferences?) that would create a new section with a heading level one below that of the parent section (for a discussion subtopic, which seems like the only place the drop-down would be useful).
(In reply to comment #5) > > Where else should a global setting be stored? > Shouldn't it go in something like $wgEditSummaryHeadingLevel? > I don't think a drop-down would be useful, but maybe people would like a [+] > next to section [edit] links on talk pages (settable in preferences?) that > would create a new section with a heading level one below that of the parent > section (for a discussion subtopic, which seems like the only place the > drop-down would be useful). Interesting idea - but it's straying from this particular bug's scope. Can we close this one out and start a new thread for investigating your suggestion?
(In reply to comment #6) > (In reply to comment #5) > > > Where else should a global setting be stored? > > Shouldn't it go in something like $wgEditSummaryHeadingLevel? > > I don't think a drop-down would be useful, but maybe people would like a [+] > > next to section [edit] links on talk pages (settable in preferences?) that > > would create a new section with a heading level one below that of the parent > > section (for a discussion subtopic, which seems like the only place the > > drop-down would be useful). > > Interesting idea - but it's straying from this particular bug's scope. Can we > close this one out and start a new thread for investigating your suggestion? > Ok, I've created Bug #12115 for subtopic headings. I still think a configuration setting would be more appropriate than a system message for this bug, however.
Why? That moves the setting outside of wiki\sysop permissions and moves it in to filesystem realm. It doesn't make sense.
Things like default user options, which this reminded me of, go in the configuration, but I see your point.
*** Bug 12115 has been marked as a duplicate of this bug. ***
