Last modified: 2014-11-17 10:35:51 UTC
I would like to request a special variable {{SECTION}} where it would automatically include the section number of where the variable was put. This allows linking of editing sections directly.
There is already a link to directly modify a section next to the section header. Seems to fullfill the requirement.
The purpose is to allow the variable in the inclusion of templates. I think you miss the point here. Yes, the edit link at the section is there, but what if you wanted to create your own section edit link? The numbering would not be automatic, it would be manual. The way everything works now, there is a way to tack on to the end of the page, but there is no way to create a template or a link to insert somewhere inbetween.
(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)
*** Bug 6591 has been marked as a duplicate of this bug. ***
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
This would be a great variable. Please implement it!
This would be awesome - it would be so useful for templates!
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.
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.
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.
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.
Thanks for the information, Z-man. I'll change things accordingly. What is generally done about translations? Unfortunately, I only know english.
Created attachment 5681 [details] Additions to MagicWord.php to support the new variables
Created attachment 5682 [details] Additions to Parser.php to support the new variables (against 1.13.3)
Created attachment 5683 [details] Additions to MessagesEn.php to support the new variables (against 1.13.3)
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.
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).
Created attachment 5684 [details] This is a VERY cleaned up patch against current trunk
The current patch adds {{SECTIONNAME}} and {{SECTIONNUMBER}} variables to trunk. They should be pretty self-explanatory.
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?
Created attachment 5685 [details] Move closer to preserving existing numbering behavior
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
Thanks for the quick update! I'll work on these issues over the weekend.
Created attachment 5686 [details] Existing behavior duplicated, numbering still needs work
I retract that statement, 2 failures remaining to address.
Wow... 4 years ago... has it been that long? Thanks Kinsey!
Created attachment 5694 [details] Fixed existing behavior
Created attachment 5695 [details] Numbering now works properly (doesn't take into account template sections)
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.
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.
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.
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.
Created attachment 5717 [details] Hooks into template inclusion, processed before transcluding occurs
Created attachment 5718 [details] Effectively an extension at this point. It still needs polishing. Does not currently attach the T- to template header numbers.
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.
The scope of this bug has changed, somewhat. It is best implemented as an extension once bug 17131 gets implemented.
adding bug dependency on a different one
*** Bug 18398 has been marked as a duplicate of this bug. ***
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?
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. ***
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?
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.
How much should I donate?
Created attachment 7339 [details] 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.
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" );
Created attachment 7348 [details] fix a bug, correct opening and closing syntax Fixed a bug caused by debugging I had in the code.
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
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!
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.
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.
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
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.
