Last modified: 2008-04-06 17:59:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3600, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1600 - Remove section markup inside heading text when using "section=new"
Remove section markup inside heading text when using "section=new"
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
unspecified
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-26 16:54 UTC by Mark Clements (HappyDog)
Modified: 2008-04-06 17:59 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch for EditPage.php in HEAD (1.28 KB, patch)
2005-12-11 11:56 UTC, Brion Vibber
Details
trims whitespace and =s from summary (663 bytes, patch)
2007-09-24 16:57 UTC, Alexander
Details
trims whitespace and =s from summary, anchored (676 bytes, patch)
2007-09-24 17:22 UTC, Mark Clements (HappyDog)
Details
trims whitespace and =s from summary, anchored, stricter (679 bytes, patch)
2007-09-24 17:35 UTC, Mark Clements (HappyDog)
Details
trims whitespace and =s from summary, anchored, stricter (680 bytes, patch)
2007-09-24 17:51 UTC, Mark Clements (HappyDog)
Details
Updated patch against current head, same regex/trim() function (682 bytes, patch)
2008-03-24 18:32 UTC, Chad H.
Details

Description Mark Clements (HappyDog) 2005-02-26 16:54:59 UTC
I often mistakenly use the heading markers when filling in the headline in a
'post a comment' box, which results in the == appearing twice in the code, and
therefore on-screen. The software should detect this and remove == if found at
both ends of an edit comment.
Comment 1 Brion Vibber 2005-12-11 11:56:25 UTC
Created attachment 1169 [details]
Patch for EditPage.php in HEAD

Patch to trigger edit conflict on 'section=new' when the previous edit's
username and comment string match; this should get most dupe posts.
Comment 2 Brion Vibber 2005-12-11 12:18:06 UTC
Applied to HEAD.
Comment 3 Brion Vibber 2005-12-12 02:42:55 UTC
*** Bug 2360 has been marked as a duplicate of this bug. ***
Comment 4 Mark Clements (HappyDog) 2005-12-12 12:10:22 UTC
This patch is fixing a different bug to the one stated, so I'm reopening it. 
Perhaps it's because my original post is not clear enough.

The problem I was referring to is that when I post a new comment (i.e. add a new
section) I will often enter "== Title ==" (minus quotes) into the
subject/heading box.  This results in the following string being entered into
the wiki markup (again minus quotes): "== == Title == ==", which then needs to
be fixed.

The suggestion is for the software to spot this situation and not add the
heading tags if they are already at both ends of the subject string.
Comment 5 Rowan Collins [IMSoP] 2005-12-12 17:53:25 UTC
(In reply to comment #4)
> This patch is fixing a different bug to the one stated, so I'm reopening it. 
> Perhaps it's because my original post is not clear enough.

I think your description was descriptive enough, but the summary line seems to
have got off the point (I've changed it now).
Comment 6 Casey Brown 2007-09-18 02:05:57 UTC
Unneeded change requested from early days of software, this capability is no longer really needed anymore (and everyone has adapted to the current situation, I can't remember the last time I saw something like this happen...).
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-09-18 02:24:15 UTC
Agree this is probably not needed.
Comment 8 Brion Vibber 2007-09-18 14:49:32 UTC
To be honest, I make this mistake sometimes. :) Reopening.
Comment 9 Alexander 2007-09-24 16:57:11 UTC
Created attachment 4149 [details]
trims whitespace and =s from summary
Comment 10 Mark Clements (HappyDog) 2007-09-24 17:22:52 UTC
Created attachment 4150 [details]
trims whitespace and =s from summary, anchored

Modification to previous patch, so that the regex is anchored to the start/end of the submitted string.  Original patch would mangle headings such as "$Foo == $Bar instead of $Foo === $Bar!".
Comment 11 Mark Clements (HappyDog) 2007-09-24 17:35:40 UTC
Created attachment 4151 [details]
trims whitespace and =s from summary, anchored, stricter

A stricter version, with fewer false positives (for example, it won't alter titles with = symbols on just one side, e.g. "=Text").

Also moved trimming out of regex and into separate trim() statements to stop it matching multiple equals signs separated by spaces.

I could make this stricter, e.g. it always removes the same number of = from the start and end (e.g. "=== test ==" becomes "= test") and it doesn't modify the special case of a title that is purely made up of = symbols, if requested.

Finally, a question - does this display correctly in the summary preview, or is it only applied on save?  I haven't been able to test as I don't have HEAD setup on this machine.
Comment 12 Alexander 2007-09-24 17:42:08 UTC
(In reply to comment #11)
> Finally, a question - does this display correctly in the summary preview, or is
> it only applied on save?  I haven't been able to test as I don't have HEAD
> setup on this machine.

It removes =s on preview.
Comment 13 Mark Clements (HappyDog) 2007-09-24 17:51:15 UTC
Created attachment 4152 [details]
trims whitespace and =s from summary, anchored, stricter

Fix typo
Comment 14 Chad H. 2008-03-24 18:32:22 UTC
Created attachment 4755 [details]
Updated patch against current head, same regex/trim() function
Comment 15 Brion Vibber 2008-03-24 18:41:58 UTC
Woohoo! :) Applied in r32376
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-06 17:59:44 UTC
Reverted the white-space-stripping part of this in r32863, as my commit message says:

Partial revert of r32376: don't strip whitespace from summaries.  If you do, that means that the default "/* Section name */ " summary loses its trailing space if you hit preview before submitting, which is noticeably inconsistent and annoying.  Maybe trim it on save, but I don't know if there's any point.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links