Page MenuHomePhabricator

[[Section::...]] variables
Open, LowPublic

Description

Author: jylee

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz1605

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:15 PM
bzimport set Reference to bz1605.
bzimport added a subscriber: Unknown Object (MLST).

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

jylee wrote:

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.

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?