jylee wrote:

(In reply to comment #1)

There is already a link to directly modify a section next
to the section header. Seems to fullfill the requirement.

The reason for this is if you were to put the {{SECTION}} variable on a
transinclude page or template, you can create an edit link. For example:

This section is considered as a stub. You can help Wikipedia by expanding this
section (link to the edit button)

robchur wrote:

*** Bug 6591 has been marked as a duplicate of this bug. ***

marco wrote:

I would use this variable for a link in Sysop votes on dewiki...every sysop vote
is a == == section...it would be nice to fetch this ID. Marco

lordtbt wrote:

This would be a great variable. Please implement it!

danielfolsom wrote:

This would be awesome - it would be so useful for templates!

nyphbl8d wrote:

It seems that no one has implemented this yet. I'm going to poke around and see if I can generate a relatively clean patch to provide this functionality, since I need this feature for what I'm working on.

nyphbl8d wrote:

Looking at the code in Parser.php, it is not possible to add this the way normal variables are parsed, since they seem to be completely context insensitive. However, I think I can add it to the formatHeadings function. It might be more prudent to put it in doHeadings, but that would require a complete rewrite of the function to parse the document line by line instead of doing its preg_replace calls on the document as a whole. I'll get back after some experimentation.

nyphbl8d wrote:

It appears, upon further consideration, that formatHeadings would also have to be rewritten. It is possible that the two functions can be combined in the future, but for the moment, I will be focusing my efforts on doHeadings.

nyphbl8d wrote:

I have successfully completed the patch. Tomorrow, I will work on cleanup. I have defined two new variables: SECTNAME and SECTNUM. This took more effort than I would have liked, but at least it's functional. :D

Just a note, magic word names are generally not abbreviated even if they are a bit long, though you can add abbreviated aliases in the messages file.

nyphbl8d wrote:

Thanks for the information, Z-man. I'll change things accordingly. What is generally done about translations? Unfortunately, I only know english.

nyphbl8d wrote:

Additions to MagicWord.php to support the new variables

attachment MagicWord.diff ignored as obsolete

nyphbl8d wrote:

Additions to Parser.php to support the new variables (against 1.13.3)

attachment Parser.diff ignored as obsolete

nyphbl8d wrote:

Additions to MessagesEn.php to support the new variables (against 1.13.3)

attachment MessagesEn.diff ignored as obsolete

nyphbl8d wrote:

I have attached the three required patches to enable this new feature. The diff is against release 1.13.3. If the diff needs to be against a different version, please let me know and I will update them accordingly.

(In reply to comment #17)

I have attached the three required patches to enable this new feature. The
diff is against release 1.13.3. If the diff needs to be against a different
version, please let me know and I will update them accordingly.

Preferably, diff against the latest SVN version, and use the "svn diff" command to generate the diff (or the Create patch option in TortoiseSVN). This also puts the whole thing in one file and makes the patch easier to apply (because right now, the filenames don't match: Parser.orig.php vs. Parser.php).

For a guide on how to check out MediaWiki using SVN, see http://www.mediawiki.org/wiki/SVN

Whoops, accidentally changed this bug from ASSIGNED to NEW; changing back.

nyphbl8d wrote:

Thanks for the input, Roan. I'm already in the process of revising the patch for trunk, and making things a lot cleaner (removing for loops, converting join to implode, etc).

nyphbl8d wrote:

This is a VERY cleaned up patch against current trunk

attachment sectionvars.diff ignored as obsolete

nyphbl8d wrote:

The current patch adds {{SECTIONNAME}} and {{SECTIONNUMBER}} variables to trunk. They should be pretty self-explanatory.

nyphbl8d wrote:

Changing the summary to something slightly more accurate.

(In reply to comment #21)

Created an attachment (id=5684) [details]
This is a VERY cleaned up patch against current trunk

Tim, can you review that?

nyphbl8d wrote:

Move closer to preserving existing numbering behavior

attachment sectionvars.diff ignored as obsolete

Some comments from testing, haven't really looked at the code in detail:

*{{SECTIONNUMBER}} should probably return 0 rather than nothing when used before the first section header
*The number returned by {{SECTIONNUMBER}} is not the number used for section editing, but the number used by the TOC. For section editing, the sections are just numbered sequentially, regardless of what heading level it is, except for sections from templates, which are prefixed with "T-" and are numbered sequentially based on other sections from that template (so its possible to have multiple sections with the same "T-" number if they're from different templates, or the same template transcluded multiple times.) This is annoying in other areas as well, bug 16276. In any case, the numbers outputted won't work for section editing unless all sections are the same level and none are from templates.
*SECTIONNAME doesn't trim whitespace from the start/end of the section name
*SECTIONNAME doesn't take into consideration sections created using <h2> and the like in the wikitext, while not the normal way to create section headings, its not prohibited and does work.

When making changes to the parser, you should run the parserTests.php in the /maintenance directory. Its normal for some to fail, so you'll want to run it before and after your changes to determine if any of the failures are caused by your changes. When running it after applying the patch, I get an E_NOTICE (twice),
PHP Notice: Undefined offset: 12 in C:\xampp\htdocs\w\includes\parser\Parser.php on line 1169

This also causes some new test failures:
Running test Handling of sections up to level 6 and beyond... FAILED! - http://pastebin.com/f23f8d867
Running test Fuzz testing: Parser14... FAILED! - http://pastebin.com/f6cb2b8ed

The above 2 seem to be the same problem, the regex used assumes sections won't have more than 6 "=", but MediaWiki allows just ignores them and adds them to the section name. This also seems to check only 1 side of the section header, so ===Section name== will be treated as <h3>Section name</h3>, rather than <h2>=Section name</h2> as it currently does. It also seems to treat "=" in the middle of the section name very oddly, "=Test=n===" and "=Test=n==" both produce an <h3>, when neither of them should (they should both produce an <h1>). This seems to be related with the other test failure:

Running test Invalid header with following text... FAILED! - http://pastebin.com/f3d044be6

The text that's parsed in each test can be found in maintenance/parserTests.txt

nyphbl8d wrote:

Thanks for the quick update! I'll work on these issues over the weekend.

nyphbl8d wrote:

Existing behavior duplicated, numbering still needs work

attachment sectionvars.diff ignored as obsolete

nyphbl8d wrote:

I retract that statement, 2 failures remaining to address.

jylee wrote:

Wow... 4 years ago... has it been that long? Thanks Kinsey!

nyphbl8d wrote:

Fixed existing behavior

attachment sectionvars.diff ignored as obsolete

nyphbl8d wrote:

Numbering now works properly (doesn't take into account template sections)

attachment sectionvars.diff ignored as obsolete

nyphbl8d wrote:

I just did a quick test, and it seems like my code has no issue dealing with template sections. I'd say this is ready for a review.

nyphbl8d wrote:

Reading through Mr.Z-man's comments, there are two section numbers for each section. The one generated by the TOC, and the one in the source document. Right now, {{SECTIONNUMBER}} generates the numbers as seen in the TOC. To generate numbers as they would appear in the source document, I would have to rework quite a bit and change the location of the call.

nyphbl8d wrote:

As per my conversation with TimStarling on IRC, I am reworking this as an extension, since it's better not to hack the parser into tiny little pieces, Office Space style. I have current functionality reimplemented, and I am working on source header number for edit link functionality. The new format for this is going to be [[Section::*]] where * can be one of: Name, Number, SourceNumber.

nyphbl8d wrote:

What I'm about to attach is just about all I can manage at the moment. To have template section numbers work properly for edit links, one of two things needs to happen: either include the patch I'm attaching to add the hooks to template inclusion (or some cleaned up variant thereof), or to expose mHeadings to the outside world somehow. As it is, mHeadings contains the information I want, but having the prefix "m", it is technically an internal/private member with no outside accessor. The hooks in the patch are more than likely not in the right place, but work for the moment.

nyphbl8d wrote:

Hooks into template inclusion, processed before transcluding occurs

Attached:

nyphbl8d wrote:

Effectively an extension at this point. It still needs polishing. Does not currently attach the T- to template header numbers.

attachment sectionvars.php ignored as obsolete

nyphbl8d wrote:

Just to explain a little more thoroughly, all the section number replacement works without the template hook patch except for the template numbers. [[Section::SourceNumber]] will remain untouched if the patch is not applied and it is in a template. [[Section::SourceNumber]] DOES work for non-included pages, so user-generated edit links will work for the local page.

nyphbl8d wrote:

The scope of this bug has changed, somewhat. It is best implemented as an extension once bug 17131 gets implemented.

nyphbl8d wrote:

adding bug dependency on a different one

• Bug 18398 has been marked as a duplicate of this bug. ***

skizzerz wrote:

*** Bug 18398 has been marked as a duplicate of this bug. ***

IRP wrote:

It doesn't appear that anything has been done yet. When I try to use it on http://en.wikipedia.org/wiki/Template:Emptysection, nothing happens. What text am I supposed to add?

nyphbl8d wrote:

This has not been merged in. There is still work to be done to enable full support for source numbers, though work for TOC numbers is pretty much complete. It is unlikely you will be able to use this on wikipedia for a good while, still. I hope to find time to complete the rest of the necessary work this summer when I have more time. If you want to finish the work, please do so :). The related bug to get a hook into template inclusion is what is required. Once that is done, I need to make sure everything still works as expected and put everything into a proper extension.

• Bug 12434 has been marked as a duplicate of this bug. ***

• Bug 9240 has been marked as a duplicate of this bug. ***

IRP wrote:

Will this get done in a relatively short amount of time if I hire a developer to do this? Who is willing to do this and how much will you charge?

happy.melon.wiki wrote:

In the spirit of free software development, Kinsey has already committed a huge amount of (her? 50/50 chance, sorry if I guessed wrong) time for free. While I'm sure she'd be delighted if you offered a financial incentive, it probably wouldn't get this functionality deployed on WMF significantly faster. The feature requires at least one hook to be added into the core software, then the feature itself needs to be compiled into a complete extension. Then it needs to be reviewed by a senior developer for code integrity and performance: deploying extensions on the larger WMF wikis, particularly enwiki, usually requires extensive optimisation. Ultimately the decision to install the extension is made by Brion. The WMF end of the chain is where the bottleneck lies; if you want to buy quick action, offer to donate to the Foundation if those stages are expedited.

IRP wrote:

How much should I donate?

nyphbl8d wrote:

Extension-like, bug fixed, still no source or template support

Uploaded a new patch with a little extension polish (now shows up in Special:Version) and a bug fix involving the Section::Name variable. Name was being evaluated too early and it was possible to replace it with source data instead of rendered data. Just as a refresher, source numbering doesn't currently work properly because I don't have a hook to the right point in the parser. There may be new hooks available since I haven't touched this in a year, so I'll look into that.

attachment sectionvars.php ignored as obsolete

nyphbl8d wrote:

Oh, and just a FYI, you need the following line at the bottom of LocalSettings.php to make this extension work:
require_once( "$IP/extensions/sectionvars.php" );

nyphbl8d wrote:

fix a bug, correct opening and closing syntax

Fixed a bug caused by debugging I had in the code.

Attached:

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

sumanah wrote:

Kinsey, thanks for writing this. I added the "need-review" keyword to indicate that your code awaits review. You might just want to apply for commit access and commit your extension to Subversion to get review faster, per https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment . Sorry for the wait!

nyphbl8d wrote:

Thanks for the update after all this time. My need for this extension is waning, but it seems to be a useful feature so I'll jump back in and see if I can get everything working the way it needs to be. I have all next week off and ever so much to get done, but I'm sure I can find time for this as well.

nyphbl8d wrote:

This extension seems to still work as expected on current trunk as of rev 105797. I'm now looking at the work that needs to be done to get this in SVN and ready for deployment.

sumanah wrote:

Kinsey, I appreciate your time working on this. If you want to chat with other developers about what it takes to get your extension in Subversion and ready for deployment, our IRC channel is usually populated https://www.mediawiki.org/wiki/MediaWiki_on_IRC . If you're actively working on an extension, it's pretty easy to get commit access: https://www.mediawiki.org/wiki/Commit_access_requests#Requesting_commit_access

Thanks.

*** Bug 30296 has been marked as a duplicate of this bug. ***

*** Bug 33477 has been marked as a duplicate of this bug. ***

Please, consider the implementation of {{SECTIONLEVEL}} too.
It should return the number of equal signs in the section title.

In addition, if also {{PARENTSECTIONNUMBER}} could be developed, it will serve as an elegant solution to bug 11415, which appears to have got a growing number of votes.

Note that parent section number may not be {{SECTIONNUMBER}} - 1

sumanah wrote:

Kinsey, thanks for your work on this. If you need help or guidance, please feel free to let us know on IRC or on the mailing list: https://www.mediawiki.org/wiki/Communication

My review:

• First of all, all PHP development should happen with error_reporting set to E_ALL | E_STRICT, otherwise you may miss problems like "Undefined variable: updatestatus in D:\Projects\MediaWiki\extensions\SectionNumber.php on line 82". Or "Notice: Undefined variable: hdepth in D:\Projects\MediaWiki\extensions\SectionNumber.php on line 87"
• This extension works correctly only when page contains no transcluded sections, otherwise the numbers go out of sync with those in section edit links.
• strpos( $parser->mTitle->mPrefixedText, 'Special:' ) === false works only on English-language wikis, use Title's functions that work with namespaces.
• Overall, the system that relies heavily on action (and retrieves it using an undocumented variable!) is extremely fragile.
• This extension's syntax ([[section::name]] and [[section::number]]) is non-standard and should be replaced with magic words.

After six years, any news on this?

Change 665553 had a related patch set uploaded (by BrandonXLF; owner: BrandonXLF):
[mediawiki/core@master] Add {{SECTION}} magic word

https://gerrit.wikimedia.org/r/665553

There are several ways the behaviour of the magic word can be implemented since templates can have sections.

Implementation	Ignore templates headings	Previous heading ID	Magic word's section ID	Previous heading ID not in child frame
Image
Doesn't need a new magic word that returns the page the section ID is for	✔️	❌	❌	❌
Section ID always allows the editing of the content around it	✔️	❌	✔️	✔️
Allows creation of edit link from template to the section its transcluded into (required for primary use case)	✔️	✔️	❌	✔️
Section ID allows for the editing of sections inside the template	❌	✔️	✔️	✔️

The first option seems like the best choice since it's consistent with the way magic words like {{FULLPAGENAME}} work. It would also later be combined with the third option along with the addition of magic words like {{CURRENTFULLPAGENAME}}. The fourth option also looks good but it requires a new magic word with odd behaviour, it's worse than combining the first and third options in terms of functionality, and its logic is more complex.

To help developers and product managers with prioritisation, please provide example use cases for how one could leverage this specific technical feature if it existed. How would this help those who edit, review, or otherwise contribute to the wikis? What kind of workflows or reader features are currently not possible or would become better if this existed? Please be prepared for other solutions to be considered as well.

One use case is in a 2005 comment: it would facilitate creation of custom edit buttons inserted via templates and such.

I saw that, but I was looking for something a little more zoomed out as that is still just an internal mechanism and not a use case. Like, how do you see that used in an article? Are there problems from back then that needed this that we still haven't solved and/or that you'd like to see solved in a better way using this mechanism? What would be custom about it? Would it still be localised and be accessible? Would the default one appear as well still? Who benefits from this and why?

As an active editor myself I can certainly imagine creative ways to use this, but ultimately we're not building Photoshop. Templates and gadgets can already do everything Photoshop can do if you try hard enough, but this task is asking Wikimedia mission funds to be spent on the deployment and indefinite maintenance of a feature (It isn't just a one-time cost either, every day developers spend significant time debugging and updating features all over the place that need updating and changing based on other changes elsewhere etc, software is a living organism). I think having one concrete example, not theoretical, would be good to have before that's done. 🙂

One major use case would be the {{Empty section}} and {{Expand section}} templates at the English Wikipedia. The templates would be able to use this magic word in edit links by adding &section={{SECTION}] to the links. This would make it easier for editors to help expand these sections and not have to navigate to them by scrolling through the editor for the entire page. See this section on the Village Post.

Couldn't a JS module / gadget extract the section id from the DOM and either add (a) the right edit link (b) update an edit link stub with the section id? In the HTML, all sections have section ids / editsection links. So, all the template needs to do is add a span/div/$tag tag with some attribute/class that the JS can inspect and update the link with the section id.

As a workaround a js solution can indeed be used. But this requires building a custom gadget for each use case or some big onwiki infrastructure to have room for flexibility. Few wikis will be able to do it because of lack of technical expertise. Also JS solution is prone to jumpiness, failures to load on slow internet, etc. Not to mention people who might have js disabled.

In T3605#6851298, @BrandonXLF wrote:

One major use case would be the {{Empty section}} and {{Expand section}} templates at the English Wikipedia. The templates would be able to use this magic word in edit links by adding &section={{SECTION}] to the links. This would make it easier for editors to help expand these sections and not have to navigate to them by scrolling through the editor for the entire page. See this section on the Village Post.

Same here. We'd be waiting for this feature since a lot on it.wiki for the template {{Sezione vuota}}. For some time we hardcoded the section id in the template instance (like {{Sezione vuota|4}}); but this is not feasible, since the section id may change in time.

I would like to say that Variable function will be complex for us. But it will be good if that function is available on gadget section of a wiki. I sympathize with {{Krinkle}}. So media wiki has not to need this function. But if there a Captcha function on a wiki that will be more useful for us. Thank you

I wanted to create such a request, and found this one presearching. For me, there is completely different reason for this magic word. If we add editing templates (update, rewrite, fix, add links, ....) or some others ({{Current}}), they should look differently at the article top or in some section. The magic word allows to check, if the section number is 0, the template is relevant to the article, otherwise to specific section.

@IKhitron Not sure if you still have the need to know if a template is in the article lead, but on EN WP there is a module that tests for an Infobox being in the lead section.
You may be able to adapt that for your case.
See Module:Is infobox in lead

Thank you.