User talk:Cacycle/wikEd

wikEd
Home Discussion Help
Installation
Installation Customization Images
wikEd diff
wikEd diff library wikEdDiff wikEd diff Online Tool wikEdDiff extension
Program code
Current version wikEd Greasemonkey bundle Greasy Fork diff library wikEdDiff wikEd dev Installation template
Project
User box Navigation box Documentation
Gadgets
Guide List English: Description Code
Translations
Guide Example Afrikaans Arabic Bengali Chinese (simplified) Chinese (traditional) Croatian Czech Dutch Esperanto Finnish French Galician German Hebrew Hungarian Italian Japanese Korean Kazakh Lower Sorbian Malay Norwegian New Norwegian Persian (Farsi) Polish Portuguese Romanian Russian Sicilian Slovak Slovene Spanish Swedish Turkish Upper Sorbian Urdu Vietnamese
t e

This is the discussion page for wikEd, a full-featured in-browser text editor that adds enhanced text processing functions to Wikipedia and other MediaWiki edit pages. Feel free to leave your comments, suggestions, and bug reports at the end of this page.

Archives

Archive 1

.

Frequently we prefer that the first row (and, less frequently, the first column) of a table to be wiki-ized as headers, i.e., with '!' delimiters instead of '|'. Do you have a way to make this happen by editing the rich text appropriately? If not, here are some suggestions:

1. If a cell is all bold, give it header style.
2. If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
3. If the variable wikEdWikifyTableHeaderCol = true then header-ize first column

I like #1 the best, but of course this is your wikEd invention!

Tom.ngo 03:16, 2 October 2007 (UTC)[reply]

Thanks for the suggestion. I am thinking about a "if the first row or the first cell is bold" rule. Cacycle 12:19, 2 October 2007 (UTC)[reply]

I would personally prefer #1 - if a cell is all bold, give it header style. Tom.ngo (talk) 21:55, 19 December 2007 (UTC)[reply]

I know that this is supposed to be available for all MediaWiki wikis, but the requests I'm asking now is specific to

Tricky, but I'll try... Cacycle (talk) 13:44, 11 February 2009 (UTC)[reply]

I am a devout user of

I will try to implement this, it might take a while though. Cacycle (talk) 17:56, 24 May 2009 (UTC)[reply]

Hi! I've got a feature request for you. Hope it hasn't been up for discussion before (boy was that ToC long – didn't dare to cast an eye on the archives too..!) Sometimes, in navboxes for instances, there are lists contained in a single table cell (e.g., Template:Beta blockers, delimited by various methods involving a bullet. Could you make the sort function sort these single-line lists somehow? Also, if possible, normalization would be neat to ensure that the method used for separating the entries (I guess " • " is the most common version) is consistent for a given line. Sometimes there is a bullet first on the line, where it's not supposed to be, sometimes people forget the   or add double spaces after the item, etc. Sometimes this can make editing the list a minor nightmare.

For now, I sorted the Template:Beta blockers by replacing the bullet stuff with newlines, opening up another WikEd tab and sorted the newly-created lines, then re-replaced the newlines with the bullet goo and pasted back in the first tab. Not so practical. :) W n C? 11:35, 23 February 2011 (UTC)[reply]

A workaround is to replace "• " with "•\n" (regex mode) then sort it afterward undo the replacement. Now I've been asked to add extra sort method (sort by last name, date, link title) to Dab solver, it would be nice to have a more powerful sorting interface. — Dispenser 04:25, 2 March 2011 (UTC)[reply]

The sort button can now sort lists in a single line, please see the wikEd help for details. Have fun, Cacycle (talk) 21:42, 6 March 2011 (UTC)[reply]

Oddly, single-line sorting doesn't seem to work for me now anymore (Safari 5.0.5, OS X 10.6.7). It just seems to mess around with the whitespace. Tried it on Template:Peripheral vasodilators. Doesn't help if I replace the  • with e.g. {{•}}, either (though I do think WikEd could clean the ampersand mess up though, but maybe that's just wishful thinking. ;) ). W n C? 12:55, 16 June 2011 (UTC)[reply]

Happens first time, every time. Suppose I change from blogg to blog (UTC), where 'blogg' is at the end of the line. It works fine unless the regular expression button is pressed. Then an extra, blank line is inserted. Same with changing \w\wogg to blog. Text in the middle of the line works fine with or without regular expressions. Firefox 3.615 on Windows Vista, my only gadgets are Navigation popups and WikEd. Chris the speller ^yack 19:00, 8 March 2011 (UTC)[reply]

I see this too and I will check into this. Cacycle (talk) 07:44, 9 March 2011 (UTC)[reply]

Just to let you know that this is still a problem, and it effectively stopped me from cleaning up an article with a very long list. I can let the article wait, or do a whole lot of deleting lines by hand. Chris the speller ^yack 00:34, 25 June 2011 (UTC)[reply]

I omit this bug by adding "\n" at the end of the RegExp "Find" field and at the end of the "Replace" field. But it works only if You know and want to find expressions at the end of line. If that expressions are not only at the end You can add (\n?) to "Find" field and $1 (in the simpliest case) to "Replace" field. BUT: that doesn't changes the fact that I'd love that bug to be removed... q;) Vinne2 (talk) 19:10, 13 August 2011 (UTC)[reply]

The problem still persists and is rather annoying... However, while this doesn't work right in Firefox 23.0.1, there is no problem in Chrome 29.0.1547.57. GregorB (talk) 14:22, 21 August 2013 (UTC)[reply]

Chris the speller, Vinne2, GregorB: Fixed in 0.9.126. Cacycle (talk) 14:45, 7 May 2014 (UTC)[reply]

Seems to be fixed in version 0.9.127 - please could you check? Thanks, Cacycle (talk) 14:43, 27 May 2014 (UTC)[reply]

Hello! I'm using the WikEd, which is integrated into the German Wikipedia on Firefox 4.0 and Windows XP. I know the following two problems:

• When I remove a term which is framed by ''', the cursor will skip the last '''.
• The cursor also sometimes skips an entire line, after removing a term, which is framed by square brackets for instance.

I experience the same bug in the English Wikipedia. It is easily reproducible. Access the article Ermine_Street and try removing words out of any tag letter by letter. See what happens. --Aetas volat. (talk) 09:16, 29 April 2011 (UTC)[reply]

I will try if I can fix the first problen (it's a really tricky one). The second one seems to be a strange Firefox bug. Cacycle (talk) 21:19, 8 May 2011 (UTC)[reply]

Aetas volat.: Can you check if this is still a problem in the current version 0.9.127? Thanks, Cacycle (talk) 14:40, 27 May 2014 (UTC)[reply]

• wikEd version: 0.9.99 G; browser: Firefox 6.0; no JS errors in the console; skin: Vector; addons and other scripts: several, but problem persists when they are all disabled.

When I edit the page Template:Navbox with columns (unprotected copy at User:Ucucha/sandbox), a few empty comments get removed before I make any change to the wikitext. See the revert here. This can be reproduced by editing the page and clicking "Show changes"; it will show that these two comments are removed. This no longer happens when I disable wikEd and it does happen when I disable all other scripts and browser add-ons I have. Ucucha (talk) 23:17, 22 August 2011 (UTC)[reply]

Fixed in version 0.9.100 Thanks for reporting, Cacycle (talk) 11:42, 4 September 2011 (UTC)[reply]

And thanks for fixing it. Ucucha (talk)

Had to roll this back in 0.9.100a, but will hopefully be able to finally fix it soon. It is actually not a trivial problem... Cacycle (talk) 07:18, 7 September 2011 (UTC)[reply]

See diff for reverted change: https://en.wikipedia.org/w/index.php?title=Virtuti_Militari&diff=next&oldid=448390843. ''' -> '' bug has probably been fixed in https://en.wikipedia.org/w/index.php?title=User%3ACacycle%2FwikEd.js&diff=530918046&oldid=527239693. At the moment it's either wrong image highlighting for: {{Infobox box | image = [[Image:Virtuti Militari Grand Cross.jpg|250px]] | caption = text | lower = [[Polonia Restituta]] }} or disappearing comments in <table style="<!-- -->"></table>... Cacycle (talk) 22:13, 6 May 2014 (UTC)[reply]

Page corruptions were: https://en.wikipedia.org/w/index.php?title=User_talk:Piotrus&diff=prev&oldid=448428447, https://en.wikipedia.org/w/index.php?title=Virtuti_Militari&diff=next&oldid=448390843 Cacycle (talk) 22:16, 6 May 2014 (UTC)[reply]

• Firefox+Wiked: «Alt-Shift-S» works OK for saving, both focus on textarea or page
• Chrome:
  • Without Wiked: the hotkey works.
  • With Wiked:
    • Hotkey «Alt-S» works if focus is on page and outside textarea.
    • Hotkey «Alt-S» does not work if focus on textarea.

Can this be fixed? Or possible can submit bug request for Chrome? --StasFomin (talk) 14:14, 2 February 2012 (UTC)[reply]

StasFomin: This seems to be a Chrome or MediaWiki problem. Under Firefox, the hotkey events do fire when editing inside wikEd's iframe. This is not the case under Chrome. The hotkeys do work if you have the focus outside the iframe. Cacycle (talk) 18:22, 6 May 2014 (UTC)[reply]

Hello, when I copy text from MS Word 2010 or 2007, and then when i publish it, this sentence : Normal 0 21 false false false FR X-NONE AR-SA apperas on the top of my text. You can see that here

my version is : 0.9.102 Sorry for my english, I hope you understand the problem. thanks.

Better link to show the problem: [1] jcgoble3 (talk) 17:58, 20 March 2012 (UTC)[reply]

jcgoble3, Rabah201130: Fixed in version 0.9.127. Sorry for the delay and thanks for reporting. Cacycle (talk) 09:55, 27 May 2014 (UTC)[reply]

1. When you try to search for a regular expression from the history drop-down list, it won't work if it contains a space. However, if you replace that space with a new space, it works. Example: search for the history in Regular expression mode. Now search for something else, then try to search for the history again by selecting it from the drop-down list. It won't work. Replace the space between the and history with another space. Now it works again.
2. When replacing text at the end of the line in Regular Expression mode, an extra new line is inserted after the replacement.

--V111P (talk) 01:41, 25 March 2012 (UTC)[reply]

V111P: I have finally fixed both problems. For the second problem I reverted the "setEndNode testfix" introduced in version 0.9.99 (March 03, 2011). Cacycle (talk) 10:08, 7 May 2014 (UTC)[reply]

Thank you, Cacycle. --V111P (talk) 00:33, 10 May 2014 (UTC)[reply]

What exactly does the "fix dashes" function do? It doesn't seem to do much of anything related to dashes (for example it doesn't change spaced hyphens to spaced en dashes). It does, however, make totally unnecessary and annoying whitespace changes. Is its function supposed to be at all similar to dashes.js? —danhash (talk) 15:01, 10 April 2012 (UTC)[reply]

Currently, it does the following:

• convert html character entities into actual dash characters
• remove spaces around em dashes
• convert -- to em dashes
• convert hyphen next to lone number into a minus sign character
• convert minus or en dashes to dashes with spaces
• convert dashes to en dashes in dates

Functionality from User:GregU/dashes.js could be added, but inter-language compatibility would be very important. Cacycle (talk) 16:42, 8 July 2012 (UTC)[reply]

Can I get clarification on:

convert hyphen next to lone number into a minus sign character

This means "-([0-9]+)" → "−$1" (in regex, ignoring the quotes), right?

convert minus or en dashes to dashes with spaces

Does this mean "([^ ])[−–]" → "$1 –" and "[−–]([^ ])" → "– $1" (i.e. "dashes" means "en-dashes")? If so, the first replacement should have a " " instead of a space (0x20) per the MOS. Also, unspaced en-dashes are appropriate for some ranges of dates and other numbers.

convert dashes to en dashes in dates

What exactly does this mean?

Thanks. Any progress on this? It would be nice to not have to manually fix dash issues.—[AlanM1(talk)]— 15:16, 15 April 2013 (UTC) (edited —[AlanM1(talk)]— 23:22, 8 June 2013 (UTC))[reply]

Here is the code as of 0.9.125: Cacycle (talk) 18:37, 6 May 2014 (UTC)[reply]

// convert hyphen next to lone number into a minus sign character
var regExp = new RegExp('([' + wikEd.letters + '\'"”\\]>] ) *(\\u2212|–)(\\d)', 'g');
obj.plain = obj.plain.replace(regExp, '$1\u2212$3');

// convert minus or en dashes to dashes with spaces
var regExp = new RegExp('([' + wikEd.letters + '\'"”\\]}])( | )*(\\u2212|–)( | )*([' + wikEd.letters + '\'"“\\[{])', 'g');
obj.plain = obj.plain.replace(regExp, '$1 – $5');

// convert dashes to en dashes in dates
obj.plain = obj.plain.replace(/(^|[ \(\|])(\d\d(\d\d)?)(\u2212|-|–)(\d\d)(\u2212|-|–)(\d\d(\d\d)?)([ \)\}\|,.;—]|$)/gm, '$1$2–$5–$7$9');

I tried wikEd 0.9.105 Deutsch in http://de.memory-alpha.org which does not use Wikias GUI editor. The skin is called "Wikias new look" = Wikia.js/css. Pushing the close editing toolbar button has no effect. I am using Firefox 15.0.1 on Linux. It works on Wikias monobook. Matthias M. (talk) 12:41, 6 October 2012 (UTC)[reply]

Button now grayed out for skins that are not fully compatible with wikEd. Cacycle (talk) 19:11, 6 May 2014 (UTC)[reply]

I've been doing some editing, and the two remaining issues below are, I'm guessing, really just a variation of one problem - that pasting into the Edit Window inserts either an extra space, or a line break. All the other issues above seem to have been resolved. — Maile (talk) 21:25, 17 December 2012 (UTC)[reply]

1) Inserting into a table or into an Infobox - either Paste insertion, Toolbar link insertion, Toolbar Template citation insert - inserts a line break to the left of it, placing the insertion between the left-hand margin and the pipe character that begins the next entry space on the line below where it was supposed to insert

2) Inserting a citation into the body text from the drop-down "Templates" selection on the toolbar inserts an extra blank space to the left of the insertion. It doesn't matter which cite template is inserted.

3) Inserting a citation from the drop-down Template on the toolbar Instead of inserting where my pointer is, clicking the "Insert" button causes it to jump to the top of the section, in the margin to the left of section header, and inserts the citation there

Adding #3 today. Mentioned in above sections as one of the original issues, but I've only again used the feature with regularity in the last few days. — Maile (talk) 13:31, 6 January 2013 (UTC)[reply]

Please see

MediaWiki talk:RefToolbar.js#Insertion of blank / wikEd compatibility. Cacycle (talk) 13:29, 7 May 2014 (UTC)[reply

]

Hi, Cacycle. I was wondering, is it not possible to make UpdateTextarea() and UpdateFrame() to also update the cursor/selection position? Then everyone would be able to create user scripts compatible with WikEd. Is there any way at all to get the cursor/selection position (in number of characters from the start of the text - like with selectionStart/End in the normal textarea) in WikEd? --V111P (talk) 00:01, 15 January 2013 (UTC)[reply]

That's incredibly difficult and complex... Cacycle (talk) 19:13, 6 May 2014 (UTC)[reply]

Below the article editing area (selected with Alt-Shift-G) is the standard gallery of special characters and wiki markup codes that can normally (without WikEd enabled) be clicked on to insert those characters at the current cursor position. However, with WikEd enabled, the insertion always occurs in the last position of the cursor in the article editing area, even if the cursor is currently in the Subject/headline or Edit summary textboxes. This occurs on Win7Home, FireFox 15.0.1. —[AlanM1(talk)]— 08:24, 29 January 2013 (UTC)[reply]

Hello. On the following diff, wikEd fails : https://en.wikipedia.org/w/index.php?title=Haramain_High_Speed_Rail_Project&diff=540944989&oldid=499112591

In the console, it says there is an issue in wikEdDiff.js at line 652 (title = decodeURI(title);) : URIError: malformed URI sequence @ https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript:652

I am using wikEd by importing it through my monobook.js file : importScript('User:Cacycle/wikEdDiff.js');

I am using a fairly recent version of firefox, in a Linux environnement.

Regards, Freewol (talk) 10:22, 7 March 2013 (UTC)[reply]

• Date: 2013-04-23 21:03:04 UTC
• wikEd version: 0.9.114c G (April 21, 2013)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.22wmf2
• Gadgets: Gadget-modrollback.js, Gadget-Cat-a-lot.js, Gadget-HotCat.js, Gadget-modrollback.js, Gadget-searchFocus.js, Gadget-GoogleTrans.js, Gadget-popups.js, Gadget-HideFundraisingNotice.js, Gadget-ReferenceTooltips.js, Gadget-defaultsummaries.js, Gadget-citations.js, Gadget-wikEdDiff.js, Gadget-wikEd.js, Gadget-edittop.js, Gadget-externalsearch.js, Gadget-dropdown-menus.js, Gadget-addsection-plus.js, Gadget-CommentsInLocalTime.js, Gadget-RegexMenuFramework.js, Gadget-contribsrange.js
• MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbarBase.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: https://bits.wikimedia.org/geoiplookup, User:Endo999/GoogleTrans.js, User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js, User:Gary_King/comments_in_local_time.js, User:Pathoschild/Scripts/Regex_menu_framework.js, User:AlanM1/scripts/persondata.js, User:AlanM1/scripts/hideHotcatMarkers.js, User:Anomie/linkclassifier.js, User:Cacycle/diff.js, User:Pilaf/include/instaview.js
• URL: https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=new
• User/skin.js: https://en.wikipedia.org/wiki/UserAlanM1/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserAlanM1/common.js
• Error console: ____ (Firefox: Tools → Web Developer → Error console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
• Problem description: Search/replace adds an extra newline before replaced string.
• Steps to reproduce:
  1. Edit the section below with WikEd
  2. Click the "Find ahead as you type" button (with the binoculars on it) if necessary to the "unchecked" state.
  3. Click /R/ if necessary to the checked state to indicate the search is a regex. Type "([0-9]{1,4})-([0-9]{1,4})" (without quotes) in the search box.
  4. Type "$1–$2" (without quotes) in the replacement box. Note that the middle char is an endash, not a hyphen. It can be inserted from the Wiki markup list below the edit window or holding the Alt key down while typing Num-0Num-1Num-5Num-0 (on the numeric keypad).
  5. Click the "Find next match" button, which should highlight "1992-93 NBA..."
  6. Click the "Replace next match" button to replace the hyphen with an endash.
  7. Click the "Find next match" button. "31-10" should be highlighted.
  8. Click the "Replace next match" button to replace the hyphen with an endash.
  9. Click the "Find next match" button. "19-7" should be highlighted.
  10. Click the "Replace next match" button. In addition to replacing the hyphen, it incorrectly inserts a newline before the 19. Sometimes, it inserts the extra newline afterwards instead.
  11. Click the "Find next match" button. "28-13" should be highlighted.
  12. Click the "Replace next match" button to replace the hyphen with an endash.
  13. Click the "Find next match" button. "16-10" should be highlighted.
  14. Click the "Replace next match" button to replace the hyphen with an endash. It works correctly, and no extra newline is inserted, apparently because of the two extra spaces after "16-10".
  15. Click the "Find next match" button. "31-10" should be highlighted.
  16. Click the "Replace next match" button to replace the hyphen with an endash.
  17. Click the "Find next match" button. "17-9" should be highlighted.
  18. Click the "Replace next match" button. In addition to replacing the hyphen, it incorrectly inserts a newline before the 17.

—[AlanM1(talk)]— 00:25, 24 April 2013 (UTC)[reply]

Extra newline test section

AlanM1: This is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 15:25, 6 May 2014 (UTC)[reply]

AlanM1: Fixed in 0.9.126. Cacycle (talk) 14:38, 7 May 2014 (UTC)[reply]

Currently, the A-Z sort feature breaks multi-level bullet lists. The double (**), triple (***), and so on bulleted items do not stay under their parents.

It would be nice if WikEd sorted each level of a bullet list, keeping the branches under their respective parents.

How feasible is this? The Transhumanist 02:55, 21 May 2013 (UTC)[reply]

Is it possible (if so, how to?) use

You should add the following to your common.js :

mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript');

Ruslik (talk) 19:18, 5 June 2013 (UTC)[reply]

• Thanks Ruslik! :  } --
  talk) 16:52, 6 June 2013 (UTC)[reply
  ]

I've added it to User:Kevjonesin/common.js but I haven't seen any icon or sidebar link show up (even after refreshing my page cache). How do I activate/access it? --

talk

)

What do you mean by "icon or sidebar link"? Ruslik (talk) 18:45, 6 June 2013 (UTC)[reply]

On Wikipedia I have an icon to toggle the WikEd interface on and off up in the right corner of pages. And the preceding common.js Cropbot entry in my common.js had added a "crop" link to the sidebar so I thought that maybe that was plausible as well. Adding the code you gave me to my common.js has had no affect. I'm still getting the standard editing environment when editing in Commons. --

talk) 18:54, 7 June 2013 (UTC)[reply

]

I had used incorrect (bash script) syntax to exclude comments. It's working now for me as well.

talk) 00:47, 7 May 2014 (UTC)[reply

]

• Date: 2013-12-15 10:00:11 UTC
• wikEd version: 0.9.122 G (December 13, 2013)
• Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Linux x86_64)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.23wmf6
• Gadgets: Gadget-wikEdDiff.js, Gadget-wikEd.js
• MediaWiki scripts: Common.js/secure_new.js
• Scripts: https://bits.wikimedia.org/geoiplookup, User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js
• URL: https://en.wikipedia.org/wiki/User_talk:Cacycle/wikEd
• User/skin.js: https://en.wikipedia.org/wiki/UserHunsu/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserHunsu/common.js

• Steps to reproduce: Try to delete {{fi}} (end space included) in my sandbox. The problem is I delete the space then I delete the end line between lien web and |url. Normally I delete the space the } then } and so.

• Request : is there a way to get Automatic syntax highlighting rather then undo/redo option. I don't really use this option. My idea is to let us choose between thse two options.

Thanks for your work. Hunsu (talk) 10:11, 15 December 2013 (UTC)[reply]

Hi Hunsu, I cannot replicate your problems deleting "{{fi}} ". Please could you give me step-by-step instructions? Also, I am not sure what you mean by highlighting vs. undo/redo. wikEd does not implement any undo/redo, it just highlights in a way that is compatible with the browser's built-in undo/redo functionality. If you want an alternative highlighter, you could use the still experimental VisualEditor (Wikipedia references) or User:Remember the dot/Syntax highlighter (both are not compatible with wikEd). Cacycle (talk) 15:24, 16 December 2013 (UTC)[reply]

1. Put the cursor just before {{lien web
2. Use the delete button to delete {{fi}} (space included)

When you click on delete button you delete the space (normal) but the second time you click on delete button you don't delete } but instead you delete the \n between {{Lien web and | url. Why the cursor jumped there?

How do you tested it?

For the request I have thought that WikEd implements its own undo/redo so I suggested to choose between automatic highlighting and undo/redo. Hunsu (talk) 19:09, 17 December 2013 (UTC)[reply]

HunsuThis is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 14:37, 6 May 2014 (UTC)[reply]

Is cursor position that change when pasting is related to this? It happens to me when editing templates. Hunsu (talk) 09:19, 7 May 2014 (UTC)[reply]

Hunsu: This might be fixed in the current version 0.9.127, please could you check it? Thanks, Cacycle (talk) 09:41, 27 May 2014 (UTC)[reply]

No it's not fixed yet. It's hard to reproduce. I have tried to remove this content, so I placed the cursor at the beginning and started using delete button. Here's what I got. I couldn't remove all the text because the cursor jumped to the end. Try to reproduce it. Hunsu (talk) 12:12, 1 June 2014 (UTC)[reply]

The new red redlinks are great! Thank you.

One improvement: If the link target starts with # then it is an internal one.

• You might look for missing headlines, but fragment ids may be defined by anchor template as well, and it could be a single section which is edited.

However, internal links might get a different colour, e.g. green.

Greetings --PerfektesChaos (talk) 20:51, 16 December 2013 (UTC)[reply]

There is another challenge. Files which are located on Commons are not recognised on current project.

Therefore, any File: or Image: or any wgNamespaceIds yielding 6 should be ignored. They might get any non-blue non-red colour.

For German Wikis e.g. this requires to ignore /^(#|file:|image:|datei:|bild:)/i wikilinks.

Best wishes --PerfektesChaos (talk) 19:35, 17 December 2013 (UTC)[reply]

HNY!

Meanwhile I have collected one more case: subpage ups and downs.

To keep the overview: No target check in the following special cases

1. # fragment
2. (page title itself, might be superfluous when accessing # fragment)
3. /subpage (ignore or needs to be resolved for full title)
4. ../traversing (ignore or needs to be resolved for full title)
5. /^(file|image|datei|bild):/i namespace 6
6. :interwiki (already implemented, as far as I took it from the colours)

Successful 2014 --PerfektesChaos (talk) 19:21, 9 January 2014 (UTC)[reply]

I also like the new feature and want to give a very big thank-you to the developer of wikiEd! --Trustable (talk) 16:26, 19 December 2013 (UTC)[reply]

PerfektesChaos: I think that all point work just fine in 0.9.125. I was not able to test ../traversing as it seems not to be possible in MediaWiki. Do you have more infos on this? Cacycle (talk) 14:35, 6 May 2014 (UTC)[reply]

Thank you for these improvements; I will check them thoroughly as soo as possible.

Relative links are possible here; check [[../sandbox]] which leads you to User talk:Cacycle/sandbox.

There is also [[/Archive 001]] which yields to /Archive 001 and the same with a trailing slash: [[/Archive 001/]] → Archive 001.

Note that such subpages are not enabled in all namespaces; this might be disabled in main space but working in any other.

Greetings --PerfektesChaos (talk) 20:24, 6 May 2014 (UTC)[reply]

• Date: 2014-02-25 20:16:52 UTC
• wikEd version: 0.9.122c (December 16, 2013)
• Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 (Linux i686)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.23wmf14
• Gadgets: Gadget-popups.js, Gadget-HotCatsMultiCustomEdit.js, Gadget-LiveRCSiteConfig.js, Gadget-MoveResizeAbsolute.js, Gadget-RenommageCategorie.js, Gadget-Popups.js, Gadget-sortInterWiki.js, Gadget-QPreview.js, Gadget-WikEd.js, Gadget-BandeauxPortails.js, Gadget-HotCatsMulti.js, Gadget-LiveRC.js, Gadget-RevertDiff.js
• MediaWiki scripts:
• Scripts: https://bits.wikimedia.org/geoiplookup, User:Leag/popups-strings-fr.js, User:Lupin/popups.js, User:Leag/wikEd-fr.js, Mediawiki:Gadget-HotCatsMultiLang.js, User:Hunsu/LiveRCparam.js, Utilisateur:Arkanosis/xpatrol.js, Utilisateur:Rabah201130/WikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js
• URL: https://fr.wikipedia.org/wiki/Laurent_Delahousse
• User/skin.js: https://fr.wikipedia.org/wiki/UtilisateurHunsu/vector.js
• User/common.js: https://fr.wikipedia.org/wiki/UtilisateurHunsu/common.js
• Error console: none (Firefox: Tools → Web Developer → Error console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
• Problem description: try to replace something in this page using replace all option. the spaces in Infobox (juste before the | will be deleted).

. Hunsu (talk) 20:25, 25 February 2014 (UTC)[reply]

Moved from [2]. MER-C 10:35, 26 February 2014 (UTC)[reply]

I consider this a feature, not a bug. The spaces at the beginning of the line are not required and not part of any style recommendation. The button is specifically made to clean out unnecessary spaces. If you want to keep those spaces, you have to use the button only on selections around that section. Cacycle (talk) 09:11, 5 March 2014 (UTC)[reply]

How can I replace all the occurrences of a word without using that button? Hunsu (talk) 21:58, 5 March 2014 (UTC)[reply]

Sorry, I misread your report. I will check into it. Cacycle (talk) 13:13, 7 March 2014 (UTC)[reply]

Hunsu, MER-C: This seems to be fixed in the current version 0.9.125. Please could you confirm this? Thanks, Cacycle (talk) 13:05, 6 May 2014 (UTC)[reply]

Yes, Thanks. Hunsu (talk) 09:14, 7 May 2014 (UTC)[reply]

I noted a problem (insertion of the signature at the wrong location here at VPT. User:Technical 13 asked a good question; when I removed wikEd the problem disappeared, when I reinstalled it the problem reappeared. Needless to say (no not needless, so I will say it) I love having the capabilities of WikEd, so I don't want to remove it, but I would like to have the ability to paste text, and add a signature using the icon. It only happens with Firefox. --S Philbrick(Talk) 00:31, 28 February 2014 (UTC)[reply]

Sphilbrick: This is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 12:55, 6 May 2014 (UTC)[reply]

Thanks for the status,Cacycle. At least it means I'm not doing something stupid, which happens often enough.S Philbrick(Talk) 13:00, 6 May 2014 (UTC)[reply]

This might be fixed in the current version 0.9.127, please could you check it? Thanks, Cacycle (talk) 09:42, 27 May 2014 (UTC)[reply]

See for example this. --Rezonansowy (talk • contribs) 13:41, 8 March 2014 (UTC)[reply]

Works fine for me - maybe it is related to one of your other scripts? Please could you complete the bug report (especially relevant error console messages)? Thanks, Cacycle (talk) 09:29, 9 March 2014 (UTC)[reply]

Cacycle, try looking at it from a non-admin account. Syntax highlighting only works for me when I have edit rights for the page; e.g. it doesn't work on protected pages here on Wikipedia, but it does work on protected pages on Wookieepedia, where I have admin rights. However, before I was promoted to admin at Wookieepedia, it didn't work there either. Here's my debug info from the example page cited by Rezonansowy:

(P.S. The error report form is out of date, because Firefox no longer has an "Error console" option under "Web Developer"; it is now called "Browser Console".) jcgoble3 (talk) 21:30, 13 March 2014 (UTC)[reply]

Jcgoble3: This has been fixed in 0.9.125, read-only pages are now highlighted. Thanks for reporting, Cacycle (talk) 12:48, 6 May 2014 (UTC)[reply]

Thanks! It works perfectly for me now. jcgoble3 (talk) 19:11, 6 May 2014 (UTC)[reply]

Minor edits are a bit of a hassle to save. You have to select "minor edit", then either click save or click focus back to the edit summary and hit return (since selecting the checkbox takes focus away, at least for me.)

A button to "Save page (minor edit)" or similar would simplify things, rather than requiring multiple steps.

Can this be done with a custom button instead? I guess I could figure out how to make JavaScript set the minor-edit flag and then save, but that doesn't seem like a great way to do it. E4FZq (talk) 02:09, 12 March 2014 (UTC)[reply]

Actually, hitting Enter/Return with focus on the minor edit checkbox also submits the form (the same applies to the watch page checkbox). I use that shortcut all the time by typing in my edit summary and hitting Tab-Tab-Space-Enter (I need two tabs to get to the minor edit box, since I use User:Svick/SectionInput.js, which, when combined with wikEd, inserts its section box between the wikEd summary box and the minor edit checkbox in the tab order; you would probably only need one tab.) jcgoble3 (talk) 02:30, 13 March 2014 (UTC)[reply]

Also, Alt-Shift-i focuses and toggles that box. Maybe I could add a persistent lock feature to that checkbox (e.g. triggered by Shift-click)... Cacycle (talk) 10:36, 13 March 2014 (UTC)[reply]

Tab-space-enter does work for me. Thanks! (In fact, now I remember using that in the past. I think it stopped working at some point from a browser or OS bug, and I forgot I could do that.) Ctrl-alt-i works too. Safari doesn't focus the checkbox if I do click on it, so I still need to go back to the keyboard if I click, but it focuses it doing either of the above so I can hit return. More of a browser problem than a wikEd problem, obviously... You also need "All controls" selected in the Shortcuts tab of the Keyboard prefpane on OS X to focus things like checkboxes at all, which I already had but isn't the default.

A persistent lock would definitely be useful for doing lots of minor edits in a row or for people who mostly do minor edits. (Especially since it seems like the pref for doing that disappeared at some point, but maybe I'm wrong on that.) E4FZq (talk) 15:55, 13 March 2014 (UTC)[reply]

E4FZq: OK, so I will not add this to wikEd for the time being. Could be something for an extra gadget though. Cacycle (talk) 12:24, 6 May 2014 (UTC)[reply]

Thanks for your March 7th update. However, since then I've noticed that when I click "Preview" I'm only taken to the preview (on top) for a split second before jumping to the edit box below it. In the grand scheme of things this is no biggie, but it was more convenient to read the preview first without having to scroll up every time (especially when editing a long section). Is this fixable? The "Go to editing area" link is still next to the red "This is only a preview...", but my screen jumps to the edit window automatically and I have to scroll up to read the preview (and see what I've misspelled :-)). I'm using XP and FF 27.0.1, and don't have anything in my preferences affecting the edit window. Thanks for any help and all the best, Miniapolis 21:34, 13 March 2014 (UTC)[reply]

Forgot to mention that the preview behaves normally when I switch WikEd off. Thanks again and all the best, Miniapolis 15:14, 14 March 2014 (UTC)[reply]

Miniapolis: I cannot reproduce this. Does it still happen? Please could you give a full error report in that case (see top of the page). Thanks, Cacycle (talk) 12:20, 6 May 2014 (UTC)[reply]

It seems that strike is being deprecated in some circles in favor of delete. Cacycle, how do you feel about the change (which I don't like, FYI) and changing WikEd to go along with it? The tag s is 9.1 times as popular as del. (911% more popular in marketingspeak; 5,840,886 for <s> vs 641,205 for <del> using Special:Search) --Elvey (talk) 01:12, 20 March 2014 (UTC) (edited)[reply]

Elvey: It's two different things that just look the same. As it is not widely used on article pages, I guess it doesn't matter much which button wikEd has, <del> could always be added manually. So, until we have a new button image for <del> we will continue with <s>. Cacycle (talk) 12:17, 6 May 2014 (UTC)[reply]

Right. (And someone was misinterpreting the W3C; this use of <s> hadn't really been deprecated.) Thanks. --Elvey (talk) 15:47, 6 May 2014 (UTC)[reply]

Hi Cacycle. We've encountered a problem with wikEd's NBSP→SP replacement on skwiki recently. We don't have that "use HTML entity" policy like here on enwiki and literal character form is preferred, so it's quite serious issue – editors using wikEd (as a gadget opt-in available in user prefs) are just silently crippling articles, containing non-breaking spaces (between numbers and units, around range dashes, inside dates, between prepositions and words, and so on...).

I understand, that there are design issues with full NBSP char support, as you've stated several times here. But anyway, I can imagine a better workaround alternatives, than current "silent" replacement by plain spaces:

• to replace them by   entities (inside the pre-filter code before passing markup to the editor)
  • and optionally replace all   back into literal chars in post-filter (an opt-in for environments where literal form is preferred)
• to replace them by some macro markup, that will be displayed and preserved by wikEd and substed back into NBSP chars on saving

Do you see any of these approaches feasible? Regards, --Teslaton (talk) 18:51, 21 March 2014 (UTC)[reply]

Hi Teslaton, unfortunately, there is no reasonable and foolproof way to support the actual nbsp characters in rich text editing. They are not even supported in the standard textarea (i.e. they get consistently converted to blanks in Firefox without wikEd! See Mozilla bugs 359303 and 613223). It is time for your wiki to adjust policies to reality! That said, I have changed the upcoming wikEd release 0.9.126 so that existing nbsp characters are automatically converted to their character entities. I have also added a customization option to convert all &nbsp; to the actual characters when switching to the textarea or saving/previewing (var wikEdConfig = {}; wikEdConfig.nbspToChar = true; see User:Cacycle/wikEd customization). I do not recommend to use this setting. Cacycle (talk) 11:40, 6 May 2014 (UTC)[reply]

Until recently wikEd treated these as different characters. I recently upgraded Firefox to 27.0.1, and it now treats them as one character, so if you use Firefox find function, searching for "’" will also find "'", and vice versa. Also, wikEd's "Find next match" box will treat them as the same character. But if the "Search field is a regular expression" button is depressed, they are treated as separate characters by wikEd. This provides a way to find either one character or both characters, so it is not altogether a bad situation, but we might want to document this somewhere for new users, or for users who upgrade Firefox and encounter this. My guess is that the Firefox change was in late fall 2013 or thereabouts. Chris the speller ^yack 17:16, 29 March 2014 (UTC)[reply]

Chris the speller: Yes, nothing we can do about it because wikEd uses the standard browser's search. Cacycle (talk) 12:07, 6 May 2014 (UTC)[reply]

• Date: 2014-05-03 17:28:26 UTC
• wikEd version: 0.9.124a G (March 08, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Win32), (IceWeasel 20.0)
• Skin: vector (detected: vector_new), (Monobook)
• MediaWiki: 1.24wmf2
• Gadgets: Gadget-rightsfilter.js, Gadget-HotCat.js, Gadget-toolserver-integration.js/de, Gadget-toolserver-integration.js, Gadget-wikEd.js, Gadget-HotCat.js, Gadget-Rechtschreibpruefung.js, Gadget-bkl-check.js, Gadget-contribsrange.js, Gadget-rightsfilter.js, Gadget-PB.js, Gadget-revisionCounter.js, Gadget-markAdmins.js
• MediaWiki scripts: Common.js/relative.js, Wikiminiatlas.js, Onlyifediting.js
• Scripts: [...], User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
• URL: https://de.wikipedia.org/w/index.php?title=Wikipedia:Importw%C3%BCnsche&action=edit&section=new&preload=Wikipedia%3AImportw%C3%BCnsche%2Fpreload&editintro=Wikipedia%3AImportw%C3%BCnsche%2Feditintro&nosummary=1
• Error console:

TypeError: wikEd.clearSummaryImg is null

https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400

Line 3538

• Problem description: Doesn't save/preview edited text if parameter "nosummary=1" is given, for URL above the preload without the user-filled parameters is saved or lost if clicked on preview. Multiple affected users with Monobook to Vector and Firefox, IceWeasel and IE 11 using all the url above or [3].
• Steps to reproduce:
  • Click on a Editlink with nosummary=1 as provided above
  • fill in values for template
  • save or preview (changes should be lost)

--se4598 (talk) 17:38, 3 May 2014 (UTC)[reply]

Will check into it, Cacycle (talk) 22:45, 5 May 2014 (UTC)[reply]

Hmm, I cannot reproduce your problems (under 0.9.125c). Do you still have this problem under 0.9.125c? If yes, it could be caused by another gadget - what happens if you disable the other gadgets? Thanks for your help - Cacycle (talk) 22:55, 5 May 2014 (UTC)[reply]

se4598: This error has already been fixed in 0.9.125. Thanks for reporting, Cacycle (talk) 12:02, 6 May 2014 (UTC)[reply]

• Date: 2014-05-03 22:39:27 UTC
• wikEd version: 0.9.124a G (March 08, 2014)
• Browser: Chrome/34.0.1847.131
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf2
• Gadgets: Gadget-UTCLiveClock.js, Gadget-wikEd.js, Gadget-dropdown-menus.js
• MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
• URL: https://en.wikipedia.org/w/index.php?title=Virginia_Tech_massacre&action=edit&section=1&summary=/*%20Attacks%20*/%20
• User/skin.js: https://en.wikipedia.org/wiki/UserD'Ranged 1/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserD'Ranged 1/common.js
• Error console: No error messages related to wikEd.js; one error message for a Chrome Extension emoji:

Uncaught SyntaxError: Unexpected reserved word chrome-extension://fbgkphlalcbmifhkabdbodaghlhfcbbd/emoji.js:32

Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-resolution: 144dpi)

• Problem description:

When using the wikEd interface, a file shows up as a redlink; however, it is a valid, existing file:

[[File:Norris WestAJ Map scale.jpg|thumb|Aerial photo showing location of [[Campus of Virginia Tech#Norris Hall|Norris]] and [[Campus of Virginia Tech#Ambler Johnston Hall|West Ambler Johnston]] Halls]]

Removing the other parameters of the link results in a bluelink; there might be something about the way the link includes information for the photo that makes wikEd think it's not a valid file:

[[File:Norris WestAJ Map scale.jpg]]

However, removing the internal links doesn't fix the problem; the following still shows as a red link:

[[File:Norris WestAJ Map scale.jpg|thumb|Aerial photo showing location of Norris and West Ambler Johnston Halls]]

I've now noticed that by copying and pasting [[File|...]] links in the article, more of them become red, when they were blue before.

• Steps to reproduce:

Open

Virginia Tech massacre#Attacks

for editing.

Note the color of the link for the first photo in the section is red even though it is a valid file.

Find another "[[File...]]" link that is blue and copy and paste it back into the article; its color may change to red.

— Preceding unsigned comment added by D'Ranged 1 (talk • contribs) 23:28, 3 May 2014 (UTC)[reply]

It sounds like wikEd only discovers whether the file page exists at the English Wikipedia. File:Norris WestAJ Map scale.jpg is at Commons and {{#ifexist:File:Norris WestAJ Map scale.jpg|found|not found}} returns: not found. For comparison, File:Example.jpg is here and {{#ifexist:File:Example.jpg|found|not found}} returns: found. A check on Media instead of File would work in wiki code. {{#ifexist:Media:Norris WestAJ Map scale.jpg|found|not found}}: found. {{#ifexist:Media:Example.jpg|found|not found}}: found. {{#ifexist:Media:No such file.jpg|found|not found}}: not found. PrimeHunter (talk) 11:23, 5 May 2014 (UTC)[reply]

Fixed in 0.9.125c through an additional Commons API call. Thanks for reporting, Cacycle (talk) 22:41, 5 May 2014 (UTC)[reply]

This just recently appeared. On Wikia Message Walls, the WikEd editor pops up, but can't be used. This has previously just not appeared, which works fine. Only appearing in the Thread namespace. I.E. http://randomtime.wikia.com/wiki/Thread:2633 shows a WikEd box, but http://randomtime.wikia.com/wiki/Message_Wall:RanomTime doesn't. 77.100.160.16 (talk) 22:28, 4 May 2014 (UTC)[reply]

Thanks for reporting, I am working on it. Cacycle (talk) 09:43, 5 May 2014 (UTC)[reply]

Fixed in 0.9.125c. Cacycle (talk) 22:41, 5 May 2014 (UTC)[reply]

• Date: 2014-05-06 20:45:26 UTC
• wikEd version: 0.9.125c G (May 05, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Win32)
• Skin: monobook (detected: monobook)
• MediaWiki: 1.24wmf2
• Gadgets: Gadget-revisionjumper.js, Gadget-revisionjumper.js, Gadget-HotCat.js, Gadget-revisionjumper.js, Gadget-afchelper.js, Gadget-ImageAnnotator.js, Gadget-popups.js, Gadget-revisionjumper.js, Gadget-HideFundraisingNotice.js, Gadget-wikEd.js, Gadget-JSL.js
• MediaWiki scripts: LAPI.js, Tooltips.js, TextCleaner.js, UIElements.js, ImageAnnotatorConfig.js, Common.js/secure_new.js, AjaxSubmit.js
• Scripts: User%3ALegoktm%2Frescaled.js, User:Cacycle/wikEd.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Writ_Keeper/Scripts/teahouseTalkbackLink.js, User:Writ_Keeper/Scripts/googleTitle.js, User:Equazcion/SkipFileWizard.js, User:Ryan_Vesey/sidebar.js, User:Kephir/gadgets/rater.js, User:Timotheus_Canens/afchelper4.js, User:Technical_13/Scripts/NoThanks.js, https:/api.php, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
• URL: https://en.wikipedia.org/wiki/Heart_(radio_network)#Programming.2Fpresenters
• User/skin.js: https://en.wikipedia.org/wiki/UserNthep/monobook.js
• User/common.js: https://en.wikipedia.org/wiki/UserNthep/common.js
• Error console: Use of getUserData() or setUserData() is deprecated. Use WeakMap or element.dataset instead.
• Problem description: Whenever I click on a section link e.g. from either my watchlist or an archive search from somewhere like VPT then the page loads, takes me to the right place then 'bounces' to the top of the page. I've disabled all scripts, reset preferences and it does appear to be WikEd that is the cause as it's only when I disable it that the problem does not occurs. Nthep (talk) 20:56, 6 May 2014 (UTC)[reply]

User:Nthep: wikEd scrolls down to the edit area, without wikEd, you always stay at the top of the page. One of your many scripts seems to scroll back to the top after wikEd has scrolled down. Cacycle (talk) 14:53, 8 May 2014 (UTC)[reply]

Cacycle: With the same gadgets as you are using, I cannot reproduce this. The error console warning is not related to the problem. Strange. Cacycle (talk) 15:07, 8 May 2014 (UTC)[reply]

Thanks for the reply. I've disabled all scripts, cleared the cache and I still get the same behaviour - click on a section link in my watchlist, page loads to righ place then back to the top. I'll have to try against any prefence settings to see if that is the cause of the conflict. Nthep (talk) 15:11, 8 May 2014 (UTC)[reply]

Confirming that I had the same problem, and just disabled WikEd; the problem disappeared. (I have not checked the HotCat combination.)--S Philbrick(Talk) 16:28, 8 May 2014 (UTC)[reply]

Ok, I've now tried against all gadgets set in preferences and there is one causing a conflict. I get the problem when both WikEd and HotCat are enabled. Disable one and no problem. Nthep (talk) 16:02, 8 May 2014 (UTC)[reply]

Yes, I've been getting this probably since upgrading FF to 29.0 (and same with 29.0.1). I find with WikEd disabled I get close to (but not right at) the section. With HotCat disabled I get to exactly the right place. See

WP:VPT#Redirect not working right which might be related. I suspect FF 29 actually. Thincat (talk) 22:03, 9 May 2014 (UTC)[reply

]

For anyone arriving here later than me, the party's moved on to Wikipedia:Village pump (technical)/Archive 126#Section_links_not_working_properly. Thincat (talk) 22:26, 9 May 2014 (UTC)[reply]

Fixed in 0.9.126b by improving the detection of view and restore deleted pages preview pages (their textareas do not have an id, name, or class). Please update with Shift-Reload. Thanks to Lupo who figured this out. Cacycle (talk) 23:03, 9 May 2014 (UTC)[reply]

Finally it works... (wikEd version 0.9.126c). Cacycle (talk) 23:31, 9 May 2014 (UTC)[reply]

Many thanks for sorting this out. The "jumping to top" and "not moving exactly to section" problems have both been solved for me even with both gadgets enabled. (It didn't happen to me before FF 29!). Thincat (talk) 23:46, 9 May 2014 (UTC)[reply]

r talk:Mitch Am When I have syntax highlighting enabled, any selected text appears in bold, which I find very difficult to read. Is it possible to add a customization so that selected text is not bold? I've looked at the customisation, and changed a couple of colours already, but I can't find one for "selected text". Thanks, Mitch Ames (talk) 13:34, 7 May 2014 (UTC)[reply]

Which browser and browser version are you using? It is a browser bug, the 'bold' is actually a text shadow that should not be visible in selected text. Cacycle (talk) 13:42, 7 May 2014 (UTC)[reply]

Mitch Ames: I have added Konqueror and Opera support to the upcoming 0.9.126 version. Cacycle (talk) 13:56, 7 May 2014 (UTC)[reply]

I'm using Firefox 14.0.1. Mitch Ames (talk) 14:02, 7 May 2014 (UTC)[reply]

Ouch. Time to update I guess. Nothing I can do for you... (of course you could customize the following css: '.wikEdFrameBodySyntax': 'height: auto; min-height: 100%; width: auto; background: transparent; margin: 0; padding: 0; padding-left: 0.25em; overflow: auto; font-family: monospace; text-shadow: white -1px -1px 0, white -1px 0 0, white -1px 1px 0, white 0 -1px 0, white 0 1px 0, white 1px -1px 0, white 1px 0 0, white 1px 1px 0;' (remove the text-shadow part). Cacycle (talk) 14:13, 7 May 2014 (UTC)[reply]

Mitch Ames: I have removed text-shadows altogether in 0.9.126a. Cacycle (talk) 14:47, 8 May 2014 (UTC)[reply]

OK, thanks for your help. Mitch Ames (talk) 06:01, 10 May 2014 (UTC)[reply]

If I have syntax highlighting enabled, when I paste text into the edit box (that I have copied from something with formatting information) wikEd leaves the text selected and displays the toolbar with the [W][T] buttons. Is there a customization to disable this "feature". Most of the time I just want to paste the plain text, ie close the toolbar. The problem is that normally pasting does not leave the pasted text selected, so muscle-memory has me pasting and then immediately typing what I want to be after the pasted text. With the wikEd "feature" this overwrites the (selected) text that I just pasted! Very annoying. Being able to turn off that feature would be helpful. Thanks, Mitch Ames (talk) 13:47, 7 May 2014 (UTC)[reply]

It is on my list, thanks for reporting. Cacycle (talk) 14:14, 7 May 2014 (UTC)[reply]

Fixed in 0.9.126a, the selection is only displayed while hovering over the button box. Cacycle (talk) 14:44, 8 May 2014 (UTC)[reply]

Thanks. Mitch Ames (talk) 06:02, 10 May 2014 (UTC)[reply]

I use WikEd and the MonoBook theme. Presently within the Firefox 29.0 browser under Bodhi Linux.

Recently—soon after I noticed that a new "Expand view" button had been added to image file pages—I went to edit an article and found my WikiEd interface reproportioned (smaller editing field with more displayed below) and an active search box floating above the editing field and obscuring a portion of it.

Have there perhaps been some global changes to the wiki interface which are conflicting with WikEd?

--

Could you please submit a detailed error report (see top of page)? I cannot reproduce your problems - it is probably related to other gadgets, beta features, or preferences settings. Thanks, Cacycle (talk) 09:19, 8 May 2014 (UTC)[reply]

Pardon the delay, I've not been on wiki much recently.

Screenshots from editing 'full window mode' on User_talk:Cacycle, via Google Chrome Version 35.0.1916.114 running under Bodhi Linux 2.4:

• Example of floaters (Wikipedia logo and search box) when first entering a pages editing mode in WikEd's full window mode ...

http://www.enlightenment.org/ss/e-538b5338353705.21238230.png

• After cycling 'full window' mode off/on (floating search box and language settings)...

http://www.enlightenment.org/ss/e-538b5831a4c259.88285034.png

• JS console ...

http://www.enlightenment.org/ss/e-538b5584a8a012.85818392.png

• WikEd bug report ...

http://www.enlightenment.org/ss/e-538b56fb597e75.42372592.png

This—floating elements—happens every time I attempt to use the full window mode to edit.

• Example of floaters, editing Talk:List_of_captive_orcas ...

http://www.enlightenment.org/ss/e-538b4e9ae94f76.37829669.png

• JS console, editing Talk:List_of_captive_orcas ...

http://www.enlightenment.org/ss/e-538b524b3b0004.07486581.png

• WikEd bug report image, editing Talk:List_of_captive_orcas ...

http://www.enlightenment.org/ss/e-538b50b48f0796.73195563.png

The floating search box is functional and the rest of the page (not obscured by floating elements) seems to function normally.

--

Kevjonesin: Fixed in 0.9.128, thanks for reporting. Cacycle (talk) 16:00, 8 June 2014 (UTC)[reply

]

[p.s.— When I pressed "preview" from full mode it briefly flashed the the preview at normal scale and then settled back to full window editing mode, rather than dropping into normal aspect and staying so to review the preview as it had previously. Not a big problem, but I thought I'd note the change.] --

talk) 21:16, 8 June 2014 (UTC)[reply

]

Hi, I tried to add a personalized button following your examples in my common.js on Wikidata, but for a reason I don't understand this does not work (I made it work once, but cannot reproduce). It's supposed to replace a string like Q1 with {{Q1}}, but for a reason I don't understand this does nothing. What did I do wrong ? (the div example does not work either). Thanks in advance. TomT0m (talk) 16:12, 9 May 2014 (UTC)[reply]

TomT0m: Did you clear your cache after changing your common.js (Shift-Reload)? The DIV button works for me when I use your code. Cacycle (talk) 18:44, 9 May 2014 (UTC)[reply]

Check your browser console for errors (e.g. subst_template is undefined). Cacycle (talk) 18:48, 9 May 2014 (UTC)[reply]

TomT0m: Works fine after fixing that. Better use the following code to use the word under the cursor as template name:

<nowiki>
wikEd.GetText(obj, 'selection, cursor');
if (obj.selection.plain != '') {
    obj.changed = obj.selection;
}
else {
    wikEd.GetText(obj, 'focusWord');
    if (obj.focusWord.plain != '') {
        obj.changed = obj.focusWord;
    }
    else  {
        obj.changed = obj.cursor;
    }
}
</nowiki>

Cacycle (talk) 18:59, 9 May 2014 (UTC)[reply]

Sorry, corrected the error and switche to your new code to handle the selection, cleared the navigator cache (both shift-ctrl-R and remove the file in the cache of firefox), but still does not work. I get those errors in firebug console :

TypeError: document.getElementById(...) is null

...ntById('c-u-rfx').onmouseover = function () {showMenu('opt-user-rfx',findPos('c-...

index....7132816 (ligne 337)
TypeError: element is null
	

if (!element.getElementsByTagName('a').length) return false;

2
index....7132816 (ligne 188)

TomT0m (talk) 23:19, 9 May 2014 (UTC)[reply]

TomT0m: It works fine for me when I use your exact code from https://www.wikidata.org/wiki/User:TomT0m/common.js. Please try to disable all other gadgets. Please post a bug report form (see top of page) if that doesn't help. Cacycle (talk) 19:43, 8 June 2014 (UTC)[reply]

Sorry, maybe a stupid question but I don't know any help:

I use wikEd with an own Wikimedia installation together with Semantic Mediawiki and Semantic Forms. Problem: every form has an field with free text at his _end_:

{{{standard input|free text|rows=2|cols=80}}}

• wikEd scrolls automatically every form to his end when it is edited with forms. The cursor is going to the free text field to the end of a long form. So it is necessary to scroll up every time going to edit form modus
• 'cols' are ignored
• There are some problems with the layout.

How is it possible to disable the automatic scrolling to the free text field? Or is is possible to disable wikEd selective for Semantic forms?

Thanks a lot! --Tom Jac (talk) 17:33, 22 May 2014 (UTC)[reply]

Please could you give me a link/account to that installation so that I can reproduce, test, and fix it? You can use Special:EmailUser/Cacycle. Thanks, Cacycle (talk) 09:30, 23 May 2014 (UTC)[reply]

This is a general problem of wikEd (as in Wikipedia). The focus/cursor jumps always to the input field. Thus, the page scrolls up. In normal editing this is visible too: The lemma name is hidden. When the editing field is further down - like with http://www.mediawiki.org/wiki/Extension:Semantic_Forms, it is very disturbing (free text input field at the end of a formular).

When editing without wikEd the edit box has no focus. One must first click inside it to edit. No focus/cursor inside the edit box would be the solution - perhaps optional. Thanks a lot. --Tom Jac (talk) 07:08, 6 June 2014 (UTC)[reply]

Tom Jac: Fixed in current version 0.9.128b by turning off autoscrolling and textbox focus for Semantic Forms. Thanks for bringing this up. Cacycle (talk) 18:13, 8 June 2014 (UTC)[reply]

Works fine. Thanks a lot for fixing this - and for wikEd! --Tom Jac (talk) 17:04, 11 June 2014 (UTC)[reply]

Often when I am editing, I'm copying text from a Word file that I've created. I want to transfer the text without any formatting, so I right-click and choose "Paste as plain text". I still get the pop-up for converting text, which I then have to dismiss. Is there a way to disable the pop-up when using "Paste as plain text"? My browser is Google Chrome (latest version). Thanks!—D'Ranged 1 VT^alk 03:04, 1 June 2014 (UTC)[reply]

I can no longer re-create this problem; if it happens again, I'll re-post. Thanks!—D'Ranged 1 VT^alk 18:02, 7 June 2014 (UTC)[reply]

User:D'Ranged 1: Fixed in version 0.9.128, thanks for reporting. Cacycle (talk) 16:07, 8 June 2014 (UTC)[reply]

Another thing - I often turn off "Find ahead as you type", select a text area that I want to apply changes to via search and replace, click "Replace all matches in whole text or selection", and then return to the find/replace box to enter the next change for the same area of text. The problem is as soon as I start typing in the find box, "Find ahead as you type" is re-activated and I lose my text selection. Cannot tell you how frustrating this is! Thanks!—D'Ranged 1 VT^alk 03:12, 1 June 2014 (UTC)[reply]

User:D'Ranged 1: Strange, it works fine for me. Please could you paste a bug report (see top of this page)? Thanks, Cacycle (talk) 16:44, 2 June 2014 (UTC)[reply]

I can't reproduce the problem; maybe I was doing something wrong. If it happens again, I'll make sure I can re-create the problem before posting. As a side note; I had this page on my Watchlist; so I caught your "notify" edit. Two things: You didn't actually notify me; you just linked to my page. (You used square brackets instead of curly braces.) Also, I'm given to understand that you can't retroactively add the {{User}} notification template to a post; it must be included before you save the post for the first time. I haven't tested that yet. Thanks!—D'Ranged 1 VT^alk 18:06, 7 June 2014 (UTC)[reply]

Wikipedia:Notifications. Cacycle (talk) 15:58, 8 June 2014 (UTC)[reply

]

And thanks to your post, I learned that linking to my user page sends a notification as well as using the notification templates. Thanks!—D'Ranged 1 VT^alk 05:07, 9 June 2014 (UTC)[reply]

• Date: 2014-06-01 12:12:55 UTC
• wikEd version: 0.9.127 (May 26, 2014)
• Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Linux x86_64)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf6
• Gadgets: Gadget-popups.js, Gadget-HotCatsMultiCustomEdit.js, Gadget-LiveRCSiteConfig.js, Gadget-MoveResizeAbsolute.js, Gadget-RenommageCategorie.js, Gadget-Popups.js, Gadget-sortInterWiki.js, Gadget-QPreview.js, Gadget-WikEd.js, Gadget-BandeauxPortails.js, Gadget-HotCatsMulti.js, Gadget-LiveRC.js, Gadget-RevertDiff.js
• MediaWiki scripts: Common.js/edit.js
• Scripts: User:Leag/wikEd-fr.js, Mediawiki:Gadget-HotCatsMultiLang.js, User:Hunsu/LiveRCparam.js, Utilisateur:Arkanosis/xpatrol.js, Utilisateur:Rabah201130/WikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js, User:Cacycle/wikEd.js
• URL: https://fr.wikipedia.org/w/index.php?title=Saison_1_de_The_Walking_Dead&action=edit&section=8
• User/skin.js: https://fr.wikipedia.org/wiki/UtilisateurHunsu/vector.js
• User/common.js: https://fr.wikipedia.org/wiki/UtilisateurHunsu/common.js
• Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
• Problem description: This version adds non breaking spaces after "«" and before "»"
• Steps to reproduce: Try to save a page that contains this characters without even make any changes. example. Hunsu (talk) 12:19, 1 June 2014 (UTC)[reply]

Ok, I will modify the script to remove it as on French Wikipedia we don't have a policy about adding html code inside wikitext. I left you a message about the other bug. Hunsu (talk) 06:20, 5 June 2014 (UTC)[reply]

Hunsu: I am not sure what you mean by "I will modify the script to remove it". Please see above under User_talk:Cacycle/wikEd#Non-breaking_space_chars_.E2.80.93_ways_of_preserving.3F why it is technically impossible to conserve non-breaking space characters when using rich text editors like wikEd. There you can also find the wikEd settings to turn off the automatic conversion to &nbsp; at the cost of a high probability of losing the non-breaking property of those spaces. Cacycle (talk) 15:59, 8 June 2014 (UTC)[reply]

Hi Cacycle,

Unfortunately, the "nbspToChar" option does not help us here. The old behavior (replacing unicode non-breaking spaces by spaces while preserving existing &nbsp; entities) was a better compromise for frwiki. Indeed:

• On one hand, normal editors not supposed to insert non-breaking spaces as unicode characters, because as you said yourself, they "are not even supported in the standard textarea (i.e. they get consistently converted to blanks in Firefox without wikEd!)". However, a bot added such non-breaking spaces in many places where they are normally inserted automatically by the MediaWiki parser (for instance after "«" and before "»"). This was supposed to be an experiment to see how quickly they would be transformed into normal spaces. But now wikEd is inserting &nbsp; in these places.
• On the other hand, "&nbsp;" entities are sometimes intentionally inserted in wikicode. They should not be turned into non-breaking spaces, because they would eventually be removed by other tools...

Would it be possible to add an option to get this behavior?

Thanks,

Orlodrim (talk) 07:16, 15 June 2014 (UTC)[reply]

Here is a possible way of implementing this, without changing the default behaviour: [4]. Could you please apply this patch? Thanks, Orlodrim (talk) 17:14, 4 July 2014 (UTC)[reply]

Orlodrim: Wouldn't that change all intentional "&nbsp;"s to nbsp characters (\xa0)? I do not think that it will be possible to make wikEd compatible with nbsp characters (at least not in an intuitive and transparent way). Cacycle (talk) 14:41, 7 July 2014 (UTC)[reply]

No, I just make the conversion of '\xA0' to "&nbsp;" optional. When the option is disabled, non-breaking spaces (not written as HTML entities) are converted to normal spaces when the page is saved, but "&nbsp;" entities remain unchanged (example). This is what wikEd was doing a few weeks ago. Orlodrim (talk) 18:11, 7 July 2014 (UTC)[reply]

Cacycle: Hi, do you still have some concerns about this proposal? Orlodrim (talk) 21:07, 7 September 2014 (UTC)[reply]

Cacycle: Sorry to insist, but without this option, I have to maintain a patched version of your script for the French Wikipedia, and this not practical in long term. Could you please apply the change or tell me if you see something wrong about it? Thanks, Orlodrim (talk) 11:45, 1 November 2014 (UTC)[reply]

Orlodrim: I am right now adding real nbsp support to wikEd, please give me some time. Cacycle (talk) 22:19, 5 November 2014 (UTC)[reply]

Hi there. I have used wikEd by just enabling it in preferences. It worked fine until yesterday when my account was actually renamed from

LeoFrank: Please try deleting the following Wikipedia cookie: wikiEditor-0-codeEditor-enabled. If that doesn't work, please provide more details by posting a bug report (see top of this page). Cacycle (talk) 16:01, 2 June 2014 (UTC)[reply]

Resolved

I posted the below earlier on Village Pump (technical) and see no response over there. But I can no longer edit with WikEd, as of just a few hours ago. Who is doing what to it? — Maile (talk) 22:19, 5 June 2014 (UTC)[reply]

What's going on with WikEd, the edit window and Reftoolbar 2.0?

Just started happening, and was not happening a couple of hours ago. WikEd is involved. If I try to edit as usual with WikEd installed, text in the edit window is splayed outside the borders of the edit window, as a transparancy overlay on the rest of the page. I can type in a blank edit page, but part of the bottom portion of the Reftoolbar displays briefly and then disappears entirely. It will not allow me to "Save Page" or "Preview". Right now, I have WikEd turned off in order to do this post. However, not all of the Reftoolbar is showing. What's going on all of a sudden? NoScript was disabled, so that was not the conflict. Windows 8 Firefox 32.0 — Maile (talk) 18:42, 5 June 2014 (UTC)[reply]

Maile: Firefox 32.0 is an experimental alpha version of the browser, the current version is 29.0.1. Do you experience the same problems with the regular version too? Cacycle (talk) 16:26, 7 June 2014 (UTC)[reply]

No problems on my side using 32.0a1 and refToolbar. Please could you post an error report (see top of this page)? Thanks, Cacycle (talk) 16:32, 7 June 2014 (UTC)[reply]

Perhaps you can suggest how I can get either 29.0.1 or 32.0a1 I did not download 32.0 on my system. It was downloaded by a computer support technician who insisted no other version was available. — Maile (talk) 17:38, 7 June 2014 (UTC)[reply]

I made a typo. I have 30.0 version of Firefox. Is that still experimental? — Maile (talk) 17:50, 7 June 2014 (UTC)[reply]

Yes.

talk) 18:15, 7 June 2014 (UTC)[reply

]

• Well...I uploaded 29.0.1 Firefox, and the beta version is gone. Just to make sure, I also rebooted my system. I'm still having the same issues, so I'll fill out a bug report. — Maile (talk) 18:47, 7 June 2014 (UTC)[reply]

User:Maile66: Thanks a lot. Please could you click Ctrl-Logo to get the automatic form data and post it here? That would make tracking this down much easier for me. Cacycle (talk) 09:55, 8 June 2014 (UTC)[reply]

I'm collapsing the details above, because it isn't happening in the same way. And this might be something I should just wait out for a few days. As of this morning, I'm not having the same issues with WikEd. I can check WikEd in Gadgets, and have no problems. WikEd does not seem to be activated in this edit window, even though it's checked in Gadgets. However, I have no problems in editing. And the Edit Toolbar looks a bit different, but that might not be related to WikEd. So, I think I'll just wait a few days and see what happens. — Maile (talk) 13:57, 8 June 2014 (UTC)[reply]

• Putting a Resolved template at the top of this thread. It resolved itself. Have no idea what it was. — Maile (talk) 15:30, 10 June 2014 (UTC)[reply]

According to

Helder.wiki: TemplateData Editor is a component of VisualEditor and as such it cannot be compatible with wikEd. You have to decide if you want to either use VisualEditor or wikEd. Cacycle (talk) 15:26, 7 July 2014 (UTC)[reply

]

Helder.wiki 15:37, 7 July 2014 (UTC)[reply

]

Helder.wiki: But as far as I can see, it only works together with (and makes sense for) VisualEditor. I am not sure how that could be made compatible with wikEd. Cacycle (talk) 15:41, 7 July 2014 (UTC)[reply

]

Helder.wiki: OK, I think I see what it does. I will check into this. Cacycle (talk) 15:49, 7 July 2014 (UTC)[reply

]

The TemplataData editor works with Monobook, I have to disable wikEd, though. Paradoctor (talk) 17:16, 26 September 2014 (UTC)[reply]

• Date: 2014-06-14 03:34:34 UTC
• wikEd version: 0.9.128b G (June 08, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf8
• Gadgets: Gadget-revisionjumper.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-CommentsInLocalTime.js
• MediaWiki scripts: RefToolbar.js, Common.js/edit.js, Common.js/secure_new.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEd.js, User:Gary/comments_in_local_time.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js
• URL: https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=new
• User/skin.js: https://en.wikipedia.org/wiki/UserLeoFrank/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserLeoFrank/common.js
• Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
• Problem description: My account was moved to this name from
  Abhishek191288
  . In the old account name, I was able to use wiked with no problem. In the new one I am not able to. I even tried another browser (chrome), but in vain. FWIW, I just logged in using the old id and it worked perfectly fine with the old name, but not this. On the wiked icon on top of the page, I see the following error message Incompatible script or gadget: Code Editor - wikEd 0.9.128b G. I have a screenshot of the problem. If there is anyway, I can send it, please let me know.
• Steps to reproduce: Just edit any page and wikEd does not work.

Please help. — LeoFrank  ^Talk 03:44, 14 June 2014 (UTC)[reply]

User:LeoFrank: Please go to User:LeoFrank/common.js and disable the code editor manually using the [/*] button. I will fix this asap. Cacycle (talk) 17:25, 24 June 2014 (UTC)[reply]

I have disabled the script by commenting out the code. — LeoFrank  ^Talk 04:52, 25 June 2014 (UTC)[reply]

Cacycle, thanks a lot. WikEd is working fine now. 11:16, 6 July 2014 (UTC)

Fixed in 0.9.130. Cacycle (talk) 14:27, 7 July 2014 (UTC)[reply]

Here's a bug report:

• Date: 2014-06-14 07:35:17 UTC
• wikEd version: 0.9.128b G (June 08, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf8
• Gadgets: Gadget-citations.js, Gadget-wikEd.js, Gadget-dropdown-menus.js
• MediaWiki scripts: RefToolbar.js, Common.js/edit.js, Common.js/secure_new.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEd.js, Wikipedia:AutoEd/complete.js, User:D%27Ranged_1/script/CustomRefToolbar.js, User:Ohconfucius/script/MOSNUM_dates.js, User:D%27Ranged_1/script/SnipManager.js, Wikipedia:AutoEd/core.js, Wikipedia:AutoEd/unicodify.js, Wikipedia:AutoEd/isbn.js, Wikipedia:AutoEd/whitespace.js, Wikipedia:AutoEd/wikilinks.js, Wikipedia:AutoEd/htmltowikitext.js, Wikipedia:AutoEd/headlines.js, Wikipedia:AutoEd/unicodecontrolchars.js, Wikipedia:AutoEd/unicodehex.js, Wikipedia:AutoEd/templates.js, Wikipedia:AutoEd/tablestowikitext.js, Wikipedia:AutoEd/extrabreaks.js, Wikipedia:AutoEd/links.js, User:Pathoschild/Scripts/Regex_menu_framework.js, User:Ohconfucius/script/MOSNUM_utils.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
• URL: https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=new
• User/skin.js: https://en.wikipedia.org/wiki/UserD'Ranged 1/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserD'Ranged 1/common.js
• Error console: (commented out)
• Problem description: See above.
• Steps to reproduce: See above.

Hope you can fix these! Thanks!—D'Ranged 1 VT^alk 08:04, 14 June 2014 (UTC)[reply]

User:D'Ranged 1: Thanks for posting these bug reports.

1: That is simply how your browser works, I do not think that scripts can force the browser to reflow the text (at least not without side effects)

2: I have filed this Mediawiki bug: bug 67412

3: I am working on that.

User:D'Ranged 1: Fixed in 0.9.131. Cacycle (talk) 15:47, 7 July 2014 (UTC)[reply]

Cacycle (talk) 14:25, 2 July 2014 (UTC)[reply]

Thanks! #2 seems to be fixed now as well. (Sorry, it's still broken after I've placed focus somewhere other than the text editing area.) As for #1, my browser doesn't do this when I'm not using wikEd; there's something in the tool that's causing the browser to see spaces as non-breaking spaces, I suspect. Another possibility is that wikEd treats line end/carriage return differently, perhaps putting a soft carriage return after the line break?

One more request: could you please make the Find ahead as you type button default to deselected? It's driving me nuts! My most frequent use of the search and replace function is to do global search and replace; every time I preview my changes, I have to remember to click the button before I start the next global search and replace. I would rather imagine that most folks use this function as a global tool, not as a Find ahead tool; I could be wrong. Regardless, it either needs to be off as the default or remember the last state it was in when returning from a document preview. If it makes any difference, this happens only when I use the regular preview button, not the wikEd magnifying glass. Thanks!—D'Ranged 1 VT^alk 17:23, 7 July 2014 (UTC)[reply]

• Date: 2014-06-14 20:05:27 UTC
• wikEd version: 0.9.128b G (June 08, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf8
• Gadgets: Gadget-imagelinks.js, Gadget-popups.js, Gadget-HideFundraisingNotice.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-externalsearch.js, Gadget-CommentsInLocalTime.js, Gadget-metadata.js
• MediaWiki scripts: Common.js/secure_new.js
• Scripts: User:Cacycle/wikEd.js, User:Gary/comments_in_local_time.js, User:Technical_13/Scripts/admin_eye.js, User:Technical_13/Scripts/Gadget-pageCount.js, User:Technical_13/Scripts/Gadget-BugStatusUpdate.js, User:Technical_13/Scripts/Teahouse.js, User:Technical_13/Scripts/ACC_WikiLove.js, User:Theopolisme/afch-rewrite.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Technical_13/Scripts/Gadget-watchlistCleaner.js, User:Jackmcbarn/editProtectedHelper.js, User:Equazcion/OneClickArchiver.js, Wikipedia:WikiProject_User_scripts/Scripts/CloseAFD.js, User:King_of_Hearts/closexfd.js, User:Technical_13/SandBox/Gadget-codeAnchors.js, User:Technical_13/SandBox/Gadget-codeBacklinks.js, User:Technical_13/SandBox/ACCHelp.js, User:Technical_13/SandBox/Gadget-extraTabs.js, User:Technical_13/SandBox/Gadget-listStyles.js, User:Technical_13/Scripts/Teahouse_WikiLove.js, User:Technical_13/Scripts/Teahouse_IRC.js, User:Technical_13/Scripts/Gadget-codeAnchors.js, User:Doug/closetfd.js, User:King_of_Hearts/closeffd.js, User:King_of_Hearts/closecfd.js, User:King_of_Hearts/closerfd.js, User:Doug/closemfd.js, User:Technical_13/Scripts/Gadget-codeBacklinks.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
• URL: https://en.wikipedia.org/w/index.php?title=Special:ComparePages&page1=Template%3AHidden+begin&page2=Template%3AHidden+begin%2Fsandbox
• User/skin.js: https://en.wikipedia.org/wiki/UserTechnical 13/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserTechnical 13/common.js

Apparently the unified wikEdDiff button doesn't work to show the differences between pages on Special:ComparePages. This would be an invaluable tool to a  Template editor like myself and I'm wondering if this support is on the todo list. Thanks. — {{U|Technical 13}} ^{(e • t • c)} 20:06, 14 June 2014 (UTC)[reply]

Technical 13: I have added Special:Compare support to wikEdDiff 0.9.21. Thanks for bringing this up - Cacycle (talk) 17:09, 24 June 2014 (UTC)[reply]

Ctrl-click on http://www.example.com in the edit textarea indeed opens the same URL. However:

1. In the edit textarea, enter e.g. {{cite web|url=http://www.example.com}}
2. Click on the [T] icon
3. Ctrl-click on the URL entered in the first step
4. wikEd opens a new tab https://en.wikipedia.org/w/www.example.com, which returns a 404

This is Windows 7, Firefox 30. I'll try it in Chrome shortly. GregorB (talk) 09:59, 21 June 2014 (UTC)[reply]

Same behavior in Chrome 35.0.1916.153. GregorB (talk) 10:17, 21 June 2014 (UTC)[reply]

GregorB: Fixed in 0.9.129. Thanks for reporting, Cacycle (talk) Cacycle (talk) 15:50, 24 June 2014 (UTC)[reply]

Thank you! GregorB (talk) 16:31, 24 June 2014 (UTC)[reply]

Encouraged by your last message I'd like to share an observation on one of the strings used in translationd: in Polish wikipedia user page is 'Wikipedysta:X' ('User:X') but his talk page is 'Dyskusja_wikipedysty:X' ('User_talk:X'). As you see using simple postfix '_talk' in translation is not enough (I guess that the same goes with prefixes); of course because of leaving English-language back-end intact everything's working just fine, so this might be seen as minor to no issue at all. konrad (talk) 14:56, 21 June 2014 (UTC)[reply]

Thanks for that note, I will try to fix that asap. Cacycle (talk) 09:38, 23 June 2014 (UTC)[reply]

konrad: you can now use '_talk', 'talk_', and '$1_talk'. Cacycle (talk) 12:54, 4 July 2014 (UTC)[reply]

wikEdDiff bug report: diffs

• Date: 2014-06-26 12:01:05 UTC
• wikEd version: 0.9.129 G (June 24, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322; rv:11.0) like Gecko (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf9
• Gadgets: Gadget-imagelinks.js, Gadget-popups.js, Gadget-HideFundraisingNotice.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-externalsearch.js, Gadget-CommentsInLocalTime.js, Gadget-metadata.js
• MediaWiki scripts: Common.js/IEFixes.js, Common.js/secure_new.js
• Scripts: User:Cacycle/wikEd.js, User:Gary/comments_in_local_time.js, User:Technical_13/Scripts/admin_eye.js, User:Technical_13/Scripts/Gadget-pageCount.js, User:Technical_13/Scripts/Gadget-BugStatusUpdate.js, User:Technical_13/Scripts/Teahouse.js, User:Technical_13/Scripts/ACC_WikiLove.js, User:Theopolisme/afch-rewrite.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Technical_13/Scripts/Gadget-watchlistCleaner.js, User:Jackmcbarn/editProtectedHelper.js, User:Equazcion/OneClickArchiver.js, Wikipedia:WikiProject_User_scripts/Scripts/CloseAFD.js, User:King_of_Hearts/closexfd.js, User:Technical_13/SandBox/Gadget-codeAnchors.js, User:Technical_13/SandBox/Gadget-codeBacklinks.js, User:Technical_13/SandBox/ACCHelp.js, User:Technical_13/SandBox/Gadget-extraTabs.js, User:Technical_13/SandBox/Gadget-listStyles.js, User:Technical_13/Scripts/Teahouse_WikiLove.js, User:Technical_13/Scripts/Teahouse_IRC.js, User:Doug/closetfd.js, User:King_of_Hearts/closeffd.js, User:King_of_Hearts/closecfd.js, User:King_of_Hearts/closerfd.js, User:Doug/closemfd.js, User:Technical_13/Scripts/Gadget-codeAnchors.js, User:Technical_13/Scripts/Gadget-codeBacklinks.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
• URL: https://en.wikipedia.org/w/index.php?title=User%3ATechnical_13%2FSandBox&diff=cur&oldid=prev
• User/skin.js: http…

First, your bug report form seems to be a little off... Second, wikEdDiff wouldn't load on the last diff "&diff=cur&oldid=prev" for my user sand box User:Technical 13/SandBox. It shows shows the source of the page starting at the pp report instead. — {{U|Technical 13}} ^{(e • t • c)} 12:02, 26 June 2014 (UTC)[reply]

Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - Cacycle (talk) 14:54, 29 June 2014 (UTC)[reply]

• See Wikipedia:Village pump (technical)/Archive 127#Another new bug today - don't know the terminology where Maile66 reports the same issue. Any diff of my sandbox actually shows the issue, but here's a specific one that doesn't have a lot of changes. — {{U|Technical 13}} ^{(e • t • c)} 12:50, 2 July 2014 (UTC)[reply]

I get the same results as Technical 13 on his link above. Also, I get same result just doing a diff on his above post. The error shows in the window opened with the little toggle arrow below the diffs. Just started happening yesterday. Go to the article Page → History → Compare Selected Revisions. Windows 8.1, Firefox 30.0, Skin Modern. — Maile (talk) 14:55, 2 July 2014 (UTC)[reply]

• Cacycle, the script is showing the diff of the HTML instead of the wikitext... here is a composed screenshot of the results. — {{U|Technical 13}} ^{(e • t • c)} 15:20, 2 July 2014 (UTC)[reply]

Technical 13: thanks. Strange, it actually works fine for me. Maybe an incompatibility with another gadget? Will check into this. Cacycle (talk) 15:43, 2 July 2014 (UTC)[reply]

• If I can be of any more assistance, I know my way around the error console and would be happy to test things. I'm using the latest version of FireFox btw (since the useragent string above doesn't specify). — {{U|Technical 13}} ^{(e • t • c)} 16:03, 2 July 2014 (UTC)[reply]

Technical 13: Mhm, works fine for me, even with your common.js code and gadgets, under different skins, and under FF, MS IE 11, and Chrome. Maile: could you post an error report for your browser, gadgets, and scripts? Cacycle (talk) 16:20, 2 July 2014 (UTC)[reply]

• Screenshot of my error console and details of the network request might help? — {{U|Technical 13}} ^{(e • t • c)} 16:47, 2 July 2014 (UTC)[reply]

Technical 13: interesting, in the Request URL at the very top there is a "#" that does not belong there... I will check into it tomorrow. Cacycle (talk) 22:07, 2 July 2014 (UTC)[reply]

wikEdDiff bug report: diffs for Maile66

• Date: 2014-07-02 16:57:53 UTC
• wikEd version: 0.9.129 G (June 24, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Win32)
• Skin: modern (detected: monobook)
• MediaWiki: 1.24wmf10
• Gadgets: Gadget-imagelinks.js, Gadget-popups.js, Gadget-revisionjumper.js, Gadget-HideFundraisingNotice.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-dropdown-menus.js, Gadget-metadata.js, Gadget-JSL.js, Gadget-RegexMenuFramework.js
• MediaWiki scripts: Common.js/secure_new.js
• Scripts: User:Cacycle/wikEd.js, User:Ucucha/HarvErrors.js, User:GregU/dashes.js, User:Equazcion/OneClickArchiver.js, User:Ucucha/duplinks.js, User:Ohconfucius/script/MOSNUM_dates.js, User:Shubinator/DYKcheck.js, https:/api.php, https://tools.wmflabs.org/xtools/api.php, User:Pathoschild/Scripts/Regex_menu_framework.js, User:Ohconfucius/script/MOSNUM_utils.js, Wikipedia:AutoEd/core.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
• URL: https://en.wikipedia.org/wiki/Loyal_Valley,_Texas
• User/skin.js: https://en.wikipedia.org/wiki/UserMaile66/modern.js
• User/common.js: https://en.wikipedia.org/wiki/UserMaile66/common.js
• Error console: Copy and paste error messages related to wikEd.js- don't see any
• Problem description: script is showing the diff of the HTML instead of the wikitext.
• Steps to reproduce: Page → History → Compare Selected Revisions.

Hope this is what you are asking from me. — Maile (talk) 17:06, 2 July 2014 (UTC)[reply]

Maile: Thanks a lot. I will look into it. Cacycle (talk) 21:51, 2 July 2014 (UTC)[reply]

Technical 13, Maile: I have fixed this in wikEdDiff 0.9.23 by removing the '#' from the hrefs of the bold old/new version links on top of the diff table. Something on your computer (add-on, script?) is inserting this character on your system, but not on mine. Would be interesting to figure out what is responsible for this... To update, please refresh wikEdDiff.js code to version 0.9.23. Cacycle (talk) 10:00, 3 July 2014 (UTC)[reply]

Cacycle, Technical 13, On my system, it now shows the toggle arrow below the diffs. But when I click it, absolutely nothing happens - no window, no nothing. However, as of yesterday afternoon/evening, WikEd does not seem to be working for me. I've unclicked it in Gadgets, and my edit window view is the exact same without it as it is with it. — Maile (talk) 11:54, 3 July 2014 (UTC)[reply]

• That is because the change that Cacycle made has changed the request URL to "Request URL: http://en.wikipedia.org/w/&action=raw&maxage=0" for all pages when clicking on the wikEdDiff button. — {{U|Technical 13}} ^{(e • t • c)} 12:02, 3 July 2014 (UTC)[reply]

Technical 13 Are you saying this is why WikEd stopped working for me? — Maile (talk) 12:21, 3 July 2014 (UTC)[reply]

• I'm unclear about why wikEd itself is not working for you at the moment, but it is possible (although wikEd itself is working for me). Have you made any other javascript related changes on your account such as editing your common or skin .js or changing gadgets or beta features? Either way, I do not have time to dig right now, I'm going to meet my ex for a "date" with my 3 yr old daughter for the next several hours. — {{U|Technical 13}} ^{(e • t • c)} 13:00, 3 July 2014 (UTC)[reply]

• I also thought it might be a .js, but this started yesterday afternoon and no .js changes happened yesterday. There was a .js add on my skin on July 1, so I reverted it today to see if it was the problem. Apparently, that's not what is causing this. No changes in gadgets, and I don't use any Beta features at all. — Maile (talk) 13:08, 3 July 2014 (UTC)[reply]

Technical 13: please could you email me your html code of the diff page during run time (using F12 - Inspector - Copy inner HTML of <html>)? Thanks, Cacycle (talk) 12:22, 3 July 2014 (UTC)[reply]

• Cacycle, I think I know what you want, but it will have to wait a few hours if you want it from me per my comment above to Maile66. I'm unsure if that user will be able to get you what you are requesting or not but am guessing it will just have to wait until I am free unless you can find another techy editor with the issue to do it. It "may" be best to just revert these parts of wikEdDiff to the version it was at before adding the Special:ComparePages modification I requested until I can get that for you. If you just want to move this version to a separate subpage or what not I can disable the gadget and load that version directly in console or via vector.js (which is where I do most my testing so if I completely screw up I can just change skins and fix it). — {{U|Technical 13}} ^{(e • t • c)} 13:00, 3 July 2014 (UTC)[reply]
• Just as a note to both of you, I tested to see if my NoScript could be the problem. Disabling it had no effect. I still don't have WikiEd in my edit window, but if I have it enabled on Preferences, I do have the WikEd logo at the top of the page - just nothing else.— Maile (talk) 21:42, 3 July 2014 (UTC)[reply]

• Ahh... Maile66, I have a guess as to what happened. When you tried to ctrl click to get the above report, you must have accidentally single clicked the icon as well, which means that icon are probably gray because you toggled wikEd off. Simply click that gray icon once and it should turn it back on. — {{U|Technical 13}} ^{(e • t • c)} 23:18, 3 July 2014 (UTC)[reply]

• Oh, for goodness sakes! That took care of it. We still have the Diff issue, but WikEd is back in my edit window. Thanks. — Maile (talk) 23:34, 3 July 2014 (UTC)[reply]

Technical 13: where does the [restore this version] texts/links on top of the diff table in your screenshot come from? I don't have them, even with all gadgets enabled and your common.js. Cacycle (talk) 09:52, 4 July 2014 (UTC)[reply]

Technical 13: I have finally figured it out, the problem is caused by Twinkle with custom preferences. Cacycle (talk) 10:09, 4 July 2014 (UTC)[reply]

• [restore this version] does indeed come from Twinkle. I just got up, do you use IRC at all? ##T13 ^connect is my channel if you want to pop in and give me your email to send that package with the HTML.

<table class="diff diff-contentalign-left">
				<colgroup><col class="diff-marker">
				<col class="diff-content">
				<col class="diff-marker">
				<col class="diff-content">
				</colgroup><tbody><tr style="vertical-align: top;">
				<td colspan="2" class="diff-otitle"><div style="font-weight: bold;" id="tw-revert-to-orevision"><a href="#"><span style="color: Black;">[</span><span style="color: SaddleBrown;">restore this version</span><span style="color: Black;">]</span></a></div><div id="mw-diff-otitle1"><strong><a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;oldid=615282897" title="">Revision as of 08:04, July 2, 2014</a> (<a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;action=edit&amp;oldid=615282897" title="">edit</a>)</strong></div><div id="mw-diff-otitle2"><a href="/wiki/User:Kitchen_Knife" title="" class="mw-userlink">Kitchen Knife</a>  <span class="mw-usertoollinks">(<a href="/wiki/User_talk:Kitchen_Knife" title="User talk:Kitchen Knife">talk</a>&nbsp;| <a href="/wiki/Special:Contributions/Kitchen_Knife" title="Special:Contributions/Kitchen Knife">contribs</a>)</span></div><div id="mw-diff-otitle3"> <span class="comment">(<a href="#wikEd_bug_report:_.28Please_add_short_title.29">→</a>‎<span dir="auto"><span class="autocomment">wikEd bug report: ____ (Please add short title)</span></span>)</span></div><div id="mw-diff-otitle5"></div><div id="mw-diff-otitle4"><a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;diff=prev&amp;oldid=615282897" title="" id="differences-prevlink">← Previous edit</a></div></td>
				<td colspan="2" class="diff-ntitle"><div style="font-weight: bold;" id="tw-revert-to-nrevision"><a href="#"><span style="color: Black;">[</span><span style="color: SaddleBrown;">restore this version</span><span style="color: Black;">]</span></a></div><div id="mw-diff-ntitle1"><strong><a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;oldid=615288095" title="User talk:Cacycle/wikEd">Revision as of 08:50, July 2, 2014</a> (<a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;action=edit&amp;oldid=615288095" title="User talk:Cacycle/wikEd">edit</a>) (<a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;action=edit&amp;undoafter=615282897&amp;undo=615288095" title="&quot;Undo&quot; reverts this edit and opens the edit form in preview mode. It allows adding a reason in the summary.">undo</a>)</strong></div><div id="mw-diff-ntitle2"><a href="/wiki/User:Technical_13" title="User:Technical 13" class="mw-userlink">Technical 13</a>  <span class="mw-usertoollinks">(<a href="/wiki/User_talk:Technical_13" title="User talk:Technical 13">talk</a>&nbsp;| <a href="/wiki/Special:Contributions/Technical_13" title="Special:Contributions/Technical 13">contribs</a>)</span> </div><div id="mw-diff-ntitle3"> <span class="comment">(<a href="#wikEdDiff_bug_report:_diffs">→</a>‎<span dir="auto"><span class="autocomment">wikEdDiff bug report: diffs: </span> RE</span>)</span></div><div id="mw-diff-ntitle5"></div><div id="mw-diff-ntitle4"><a href="/w/index.php?title=User_talk:Cacycle/wikEd&amp;diff=next&amp;oldid=615288095" title="User talk:Cacycle/wikEd" id="differences-nextlink">Next edit →</a></div></td>
				</tr><tr>
  <td colspan="2" class="diff-lineno">Line 961:</td>
  <td colspan="2" class="diff-lineno">Line 961:</td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>Message from webpage</div></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>Message from webpage</div></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>---------------------------</div></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>---------------------------</div></td>
</tr>
<tr>
  <td class="diff-marker">−</td>
  <td class="diff-deletedline"><div>== <del class="diffchange diffchange-inline">wikEd</del> bug report: <del class="diffchange diffchange-inline">____ (Please add short title)</del> ==</div></td>
  <td class="diff-marker">+</td>
  <td class="diff-addedline"><div>== <ins class="diffchange diffchange-inline">wikEdDiff</ins> bug report: <ins class="diffchange diffchange-inline">diffs</ins> ==</div></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>* Date: 2014-06-26 12:01:05 UTC</div></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>* Date: 2014-06-26 12:01:05 UTC</div></td>
</tr>
<tr>
  <td colspan="2" class="diff-lineno">Line 980:</td>
  <td colspan="2" class="diff-lineno">Line 980:</td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div><span class="before-localcomments">: Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - <a href="//en.wikipedia.org/wiki/User:Cacycle" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="User:Cacycle">[[User:Cacycle|Cacycle]]</a> (<a href="//en.wikipedia.org/wiki/User_talk:Cacycle" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="User talk:Cacycle">[[User talk:Cacycle|talk]]</a>) </span><span class="localcomments" style="font-size: 95%; white-space: nowrap;" timestamp="1404053681019" title="14:54, 29 June 2014 (UTC)">10:54 am, 29 June 2014, last Sunday (4 days ago) (UTC−4)</span><span class="after-localcomments"></span></div></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div><span class="before-localcomments">: Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - <a href="//en.wikipedia.org/wiki/User:Cacycle" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="User:Cacycle">[[User:Cacycle|Cacycle]]</a> (<a href="//en.wikipedia.org/wiki/User_talk:Cacycle" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="User talk:Cacycle">[[User talk:Cacycle|talk]]</a>) </span><span class="localcomments" style="font-size: 95%; white-space: nowrap;" timestamp="1404053681020" title="14:54, 29 June 2014 (UTC)">10:54 am, 29 June 2014, last Sunday (4 days ago) (UTC−4)</span><span class="after-localcomments"></span></div></td>
</tr>
<tr>
  <td colspan="2" class="diff-empty">&nbsp;</td>
  <td class="diff-marker">+</td>
  <td class="diff-addedline"><div><span class="before-localcomments">:* See <a href="//en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)%23Another_new_bug_today_-_don%27t_know_the_terminology" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Wikipedia:Village pump (technical)/Archive 127#Another new bug today - don't know the terminology">[[Wikipedia:Village pump (technical)/Archive 127#Another new bug today - don't know the terminology]]</a> where <a href="//en.wikipedia.org/wiki/Template:U" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Template:U">{{U|Maile66}}</a> reports the same issue. Any diff of my sandbox actually shows the issue, but <a href="//en.wikipedia.org/wiki/Template:Diff" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Template:Diff">{{Diff|User:Technical 13/SandBox|prev|614509806|here's a specific one}}</a> that doesn't have a lot of changes. — &lt;span class="nowrap"&gt;&amp;#123;&amp;#123;U&amp;#124;<a href="//en.wikipedia.org/wiki/User:Technical_13" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="">[[User:Technical 13|Technical 13]]</a>&amp;#125;&amp;#125; &lt;sup&gt;(<a href="//en.wikipedia.org/wiki/Special:EmailUser/Technical_13" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="">[[Special:EmailUser/Technical 13|e]]</a> • <a href="//en.wikipedia.org/wiki/User_talk:Technical_13" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="User talk:Technical 13">[[User talk:Technical 13|t]]</a> • <a href="//en.wikipedia.org/wiki/Special:Contribs/Technical_13" style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)" title="Special:Contribs/Technical 13">[[Special:Contribs/Technical 13|c]]</a>)&lt;/sup&gt;&lt;/span&gt; </span><span class="localcomments" style="font-size: 95%; white-space: nowrap;" timestamp="1404305441021" title="12:50, 2 July 2014 (UTC)">8:50 am, Yesterday (UTC−4)</span><span class="after-localcomments"></span></div></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"></td>
</tr>
<tr>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>== WikEd breaks valid HTML ==</div></td>
  <td class="diff-marker">&nbsp;</td>
  <td class="diff-context"><div>== WikEd breaks valid HTML ==</div></td>
</tr>

<!-- diff cache key enwiki:diff:version:1.11a:oldid:615282897:newid:615288095 -->
</tbody></table>

Hope that helps you find a work around to fix this bug if you haven't already found one. — {{U|Technical 13}} ^{(e • t • c)} 11:52, 4 July 2014 (UTC)[reply]

Technical 13, Maile: I have now fixed Twinkle compatibility with wikEdDiff version 0.9.24. Thanks for your help! Cacycle (talk) 12:45, 4 July 2014 (UTC)[reply]

Yes! Everything is fine now. — Maile (talk) 12:47, 4 July 2014 (UTC)[reply]

I noticed that a user's edits were breaking valid HTML in a section other than the one that they were editing. That user is claiming that wikEd was the culprit; see User talk:Kitchen Knife#Altering talk page discussions. Please investigate. --Redrose64 (talk) 16:59, 28 June 2014 (UTC)[reply]

FYI I'm using FireFox. --Kitchen Knife (talk) 19:00, 28 June 2014 (UTC)[reply]

Kitchen Knife: I have tried hard, but I could not reproduce that problem. What happens if you try to edit https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Trains&action=edit&oldid=614378869? Would you mind posting a bug report (see top of page)? Thanks, Cacycle (talk) 14:46, 29 June 2014 (UTC)[reply]

Opened it with your link, saved it, no prroblem. Opened saved version type some garabge at foot off the page and got the problem.--Kitchen Knife (talk) 16:33, 29 June 2014 (UTC)[reply]

Of those two edits, the first removed several threads and one post to another thread; the second broke a </small> tag and also a

HTML comment. --Redrose64 (talk) 17:32, 29 June 2014 (UTC)[reply

]

I opened an old version then saved it. That was the first edit. The second edit I made a chage. The difference is that I didn't make an edit first time. I suspect that making a change myself set some kind of edit flag which caused the editor act differently. I went to revert but someone got there seconds before me.--Kitchen Knife (talk) 17:43, 29 June 2014 (UTC)[reply]

If you open an old version of a page, click "edit" and save without making changes, what you're doing is reverting to that old version, hence this message when you're editing. --Redrose64 (talk) 19:12, 29 June 2014 (UTC)[reply]

Yes I know but from the point of view of the editor. It only has to write out the input buffer. If a change is made then the out put has to be created by parsing the new file. It involves a lot more software than just saving a copy of what was opened--Kitchen Knife (talk) 19:58, 29 June 2014 (UTC)[reply]

I still can't reproduce this. Kitchen Knife: Please could you post a bug report by Ctrl-clicking the wikEd logo on top of the edit page, copy the text here, and fill in the details? Thanks in advance - Cacycle (talk) 09:09, 2 July 2014 (UTC)[reply]

wikEd bug report: ____ breaking valid HTML

• Date: 2014-07-02 12:00:50 UTC
• wikEd version: 0.9.129 G (June 24, 2014)
• Browser: Mozilla/5.0 (Windows NT 5.1; rv:30.0) Gecko/20100101 Firefox/30.0 (Win32)
• Skin: cologneblue (detected: cologneblue)
• MediaWiki: 1.24wmf10
• Gadgets: Gadget-wikEd.js
• MediaWiki scripts: RefToolbar.js, Common.js/edit.js, Common.js/secure_new.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEd.js, User:TheDJ/sharebox.js, https://s7.addthis.com/js/250/addthis_widget.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js, https://ct1.addthis.com/static/r07/core142.js
• URL: https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=56
• User/skin.js: https://en.wikipedia.org/wiki/User:Kitchen_Knife/cologneblue.js
• User/common.js: https://en.wikipedia.org/wiki/User:Kitchen_Knife/common.js
• Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
• Problem description: ____ (See Above)
• Steps to reproduce: ____ (See Above!)

--Kitchen Knife (talk) 12:02, 2 July 2014 (UTC)[reply]

Kitchen Knife: Thanks a lot! I made a sandbox for testing this issue here: User:Cacycle/sandbox. Can you also reproduce the bug when editing this sandbox page? If so, do you also see it after reverting your changes and then switching to the vector skin (in order to disable your sharebox script)? Thanks for your help - Cacycle (talk) 15:28, 2 July 2014 (UTC)[reply]

Breaks under both conditions.--Kitchen Knife (talk) 18:13, 2 July 2014 (UTC)[reply]

OK, I can absolutely not reproduce this. Maybe it is related to a broken browser add-on. Do you use Greasemonkey? What happens if you disable all browser add-ons? What happens if you use another browser (such as Chrome)?

The problem seems to be an interaction between the Editor and Ginger switch either off and it is fine. If I open the file that produces the bug and save immediatly no problem but if I wait about ten secons Ginger does it's thing changes a bit of higlhlighting and a save without and added characters causes the problem. See 2 images.--Kitchen Knife (talk) 23:03, 2 July 2014 (UTC)[reply]

Kitchen Knife: I will submit a bug report to Ginger for which we need more details. Which version of Ginger are you using? Free, basic or premium? What happens if you update to the current version (3.5.89)? Even with Ginger basic installed, I cannot reproduce this, as for me, Ginger needs to be invoked manually by F2 before it suggests text changes. Also, it adds spaces, but does not shuffle the ! and < around as it does for you. Cacycle (talk) 10:36, 3 July 2014 (UTC)[reply]

Ginger's (broken) automatic highlighting might theoretically cause this problem - but I do not see any Ginger highlighting for me. Cacycle (talk) 10:56, 3 July 2014 (UTC)[reply]

I have that version plus 2.0.0.69 extension in Firefox, no support without that.--Kitchen Knife (talk) 12:46, 3 July 2014 (UTC)[reply]

Kitchen Knife: Thanks. Just to be sure: you have the current version 3.5.89 installed and the Firefox add-on is version 2.0.0.69? Mine actually is version 0.1 (!?). Do you use free, basic, or premium? What do you mean by "no support without that"? Cacycle (talk) 13:31, 3 July 2014 (UTC)[reply]

You need to go into addons, go to get addons and search for ginger. That will come up with an old version of the addon 2.0.0.50 install that and then check for updated. I'm not sure what this addon does that the other doesn't but it should start working automatically in FireFox for things like FaceBook at el. I have tried to get an explanation from Ginger but their support is very dimb and the scripts do not cover it's existance or it's function. I'm using Free and I am logged on. --Kitchen Knife (talk) 16:25, 3 July 2014 (UTC)[reply]

Ginger has a major design flaw and always breaks the undo/redo history (because of direct DOM manipulation). Also, it corrupts certain text highlighted by wikEd ("<tag><!-- -->" → "<tag<!>-- -->"). Therefore, wikEd now detects an active Ginger add-on and disables itself. Please disable this add-on if you want to use wikEd. Cacycle (talk) 21:27, 3 July 2014 (UTC)[reply]

Thanks for your effort my lack of grammatic ability means that if it a choice between wikied and Ginger then ginger will win.--Kitchen Knife (talk) 19:37, 5 July 2014 (UTC)[reply]

• Date: 2014-07-03 17:46:32 UTC
• wikEd version: 0.9.129 G (June 24, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 (Win32)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf10
• Gadgets: Gadget-revisionjumper.js, Gadget-defaultsummaries.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-CommentsInLocalTime.js
• MediaWiki scripts: Common.js/secure_new.js
• Scripts: User:Cacycle/wikEd.js, User:Gary/comments_in_local_time.js, User:Salix_alba/TDSkell.js, User:Equazcion/OneClickArchiver.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
• URL: https://en.wikipedia.org/w/index.php?title=2014_kidnapping_of_Israeli_teens&curid=43055548&diff=613710252&oldid=613709316
• User/skin.js: https://en.wikipedia.org/wiki/UserDovid/vector.js
• User/common.js: https://en.wikipedia.org/wiki/UserDovid/common.js
• Error console:

GET https://en.wikipedia.org/w/&action=raw&maxage=0 404 (Not Found) index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript&0.9.129:1115

• Problem description: On any diff page I go to, clicking the delta button results in a small gray box with a horizontal bar running thorugh it, but no content. This was working for me until recently, been a month or so since I used the functionality, so i don't know the exact break date.
• Steps to reproduce: Open any diff, scroll past the standard side-by-side dif boxes, click teh delta button to open the wikEdDiff content.

Dovid (talk) 17:54, 3 July 2014 (UTC)[reply]

Dovid: Thanks for reporting this. We are already working on it, please see above. Cacycle (talk) 21:16, 3 July 2014 (UTC)[reply]

Fixed Twinkle compatibility with wikEdDiff version 0.9.24. Cacycle (talk) 12:41, 4 July 2014 (UTC)[reply]

Great to see more active updates being applied! Anytime an update is made to the .user.js version, Greasemonkey tells me there's a new version, and I have to click through a simple pop-up to install it, and that in and of itself is fine. The annoyance here is that once an update is made to the script, I have to click through that update popup on EVERY SINGLE FREAKING WIKI I VISIT! I mean literally, I'll get notified about the update on (this is an example) Wookieepedia, and install it. Then a few minutes later I click over to the Star Wars Fanon Wiki, and get the popup again. Then I visit here and get it again. Go to Commons, same thing. Go to Meta, same thing. Click a link to the French Wikipedia, same thing. In short, I get the update popup every time I visit literally any MediaWiki wiki anywhere on the Internet that I haven't visited since the last actual update, which means that instead of being notified about, and installing, the update once, I have to do it sometimes in excess of a dozen times per update. The actual wikis involved are irrelevant; it happens on all MediaWiki wikis everywhere.

Is this normal Greasemonkey behavior to require you to redownload the same update over and over again for every single subdomain you visit, or is something in wikEd causing this? If the latter, I would greatly appreciate it if you could fix it. — Preceding unsigned comment added by Jcgoble3 (talk • contribs) 04:01, 4 July 2014 (UTC)[reply]

Jcgoble3: Sorry for that, I did not update the Greasemonkey bundle to the newest version in time. It should work now. Cacycle (talk) 09:48, 4 July 2014 (UTC)[reply]

Still happening. I note that the Greasemonkey popup gives the version number as 0.9.130a, but the icon in the upper right displays the version number in the tooltip as 0.9.126c GM (May 10, 2014). I wonder if the difference in version numbers could be causing this? (Also, I was slow to respond because I did not get a ping notification for your reply here. :/ I don't know what caused that; I do have both web and email notifications enabled for that.) jcgoble3 (talk) 02:32, 7 July 2014 (UTC)[reply]

Jcgoble3: If the version number in the tooltip still says "0.9.126c GM (May 10, 2014)", then you have not actually updated wikEd to the new version. What happens, if you manually update by going here? Cacycle (talk) 15:09, 7 July 2014 (UTC)[reply]

I tried the manual update. GM popup says version 0.9.131, after update the tooltip remains "0.9.126c GM (May 10, 2014)". Despite the lack of a change to the tooltip, upon visiting other wikis following the manual update, I did not receive an automatic update alert. I opened the GM "manage scripts" page, and interestingly I now have wikEd listed twice. The first one is titled simply "wikEd", and is this version of the script. The second is titled "wikEd 0.9.131" and is the current version of the script (permalink). I have disabled the older one, and we'll see what effect that has. jcgoble3 (talk) 04:23, 8 July 2014 (UTC)[reply]

Please go to Tools - Add-ons - wikEd (no version number) - remove. I have also filed a bug report for this under GM bug 1951. — Preceding unsigned comment added by Cacycle (talk • contribs) 09:24, 8 July 2014 (UTC)[reply]

Done. Thanks for the help. jcgoble3 (talk) 23:50, 8 July 2014 (UTC)[reply]

I can't believe nobody suggested this, which means it's already been suggested, which means there's a reason you can't do it, which means I shouldn't request it.

But I'm going to request it anyway:

I have no idea what most of the editor buttons do. The icons, like all icons, are near-meaningless; and as with Firefox, you don't think enough people are literate to make it worth having text labels.

Now, while that is true in the United States, a few people here still know how to read and would appreciate pop-up hints when hovering over a strange picture.

ONE MORE OBSERVATION:

Every single word processor manages to do WYSIWYG table editing, but at Wikipedia, it's exceeeedingly complex and dam near impossible. Yeah, hey, well no problem. Verdana♥Bøld 20:26, 4 July 2014 (UTC) — Preceding unsigned comment added by Verdana Bold (talk • contribs)

Verdana Bold: Thansk for your comments. Please see wikEd help for more details about wikEd. wikEd also has a table editing mode ( button). Please see wikEd help on WYSIWYG why WYSIWYG is actually not a good idea for wikis. Also, since all wikEd buttons have an axplanatory pup-up title, you are probably talking about the standard edit toolbar. Cacycle (talk) 10:05, 5 July 2014 (UTC)[reply]

Hi, this edit [5] introduces a JavaScript Warning in Firefox:

Date: 20/07/14 14:50:44
Warning: SyntaxError: 09 is not a legal ECMA-262 octal constant
Source: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
Line: 4153, column: 23
Code:
  if (currentVersion < 009127000) { 
------------------------^

Apparently, even if it says "syntax error", it doesn't prevent the script from loading. Probably because it's just a warning. --Ciencia Al Poder (talk) 12:55, 20 July 2014 (UTC)[reply]

I'm getting this error too, WikEd isn't working for me since this appeared 88.108.90.164 (talk) 16:39, 1 August 2014 (UTC)[reply]

Thanks, it has been fixed in 0.9.132a. 88.108.90.164: this cannot be the cause of wikEd not working for you. Would you mind posting an error report (see top of thispage)? Cacycle (talk) 11:36, 25 August 2014 (UTC)[reply]

When this script is loaded, I get three copies of this warning in the console: Use of "insertTags" is deprecated. Use mw.toolbar.insertTags instead. It seems the script should have a dependency on module 'mediawiki.action.edit', which contains the JS file where the function is defined.

If I open an EMPTY PAGE on Google Chrome 36 and click on I get the error Uncaught NotFoundError: Failed to execute 'setStartBefore' on 'Range': The node provided is null. from the line

range.setStartBefore(wikEd.frameBody.firstChild);

On Firefox 31 the error is NS_ERROR_NOT_IMPLEMENTED: .

Helder 14:57, 12 August 2014 (UTC)[reply

]

Thanks, this has been fixed in 0.9.135. BTW, the Firefox error is a browser bug that has not been fixed for nine (!!!) years, please see bug 309731. Cacycle (talk) 11:40, 25 August 2014 (UTC)[reply]

If I open a page whose content is the string "* {{TEST}}" and click on (or ) I get the error Uncaught TypeError: Cannot read property 'replace' of undefined from the line

p4 = p4.replace(/^(\s*)(.*?)$/,

The problem doesn't happen on Firefox 31.

Helder 14:48, 12 August 2014 (UTC)[reply

]

Helder: Fixed in 0.9.134. Thanks, Cacycle (talk) 16:19, 25 August 2014 (UTC)[reply

]

Hello, Cacycle. Please check your email; you've got mail!
It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{

ygm}} template.

--Schnark (talk) 09:40, 19 August 2014 (UTC)[reply

Thanks, working on it. Cacycle (talk) 22:59, 24 August 2014 (UTC)[reply]

Schnark: Fixed in wikEd 0.9.134 by removing InstaView (local preview). Cacycle (talk) 15:22, 25 August 2014 (UTC)[reply]

• Date: 2014-08-22 01:46:51 UTC
• wikEd version: 0.9.132a G (August 05, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0 (Win32)
• Skin: monobook (detected: monobook)
• MediaWiki: 1.24wmf17
• Gadgets: Gadget-popups.js, Gadget-wikEd.js
• MediaWiki scripts: RefToolbarNoDialogs.js, Common.js/edit.js, Common.js/secure_new.js
• Scripts: User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
• URL: https://en.wikipedia.org/w/index.php?title=Murghab,_Tajikistan&action=edit
• User subpages: //en.wikipedia.org/wiki/Special:PrefixIndex/User:Tomaxer/
• User/skin.js: https://en.wikipedia.org/wiki/User:Tomaxer/monobook.js
• User/common.js: https://en.wikipedia.org/wiki/User:Tomaxer/common.js
• Error console:
  • Loading mixed (insecure) display content on a secure page "http://upload.wikimedia.org/wikipedia/en/d/d0/Flag_of_Tajikistan.svg" index.php:6451
  • Loading mixed (insecure) display content on a secure page "http://upload.wikimedia.org/wikipedia/commons/d/d0/Flag_of_Tajikistan.svg" index.php:1
• Problem description: Mixed passive content problem (https://developer.mozilla.org/en-US/docs/Security/MixedContent) occurs when using short preview on given page (and possibly on other pages using flags). Always reproducible for me. I have tried to find the offending line causing the http request (using Firebug Net tab) but unsuccessfully – looking through HTTP responses, all links there to Flag_of_Tajikistan seem to use URL without specifying http or https explicitly.
• Steps to reproduce:
  • open URL given in the report
  • open browser console
  • press "Show preview below" button
  • console shows mixed content and address bar icon changes from padlock to warning

--Tomaxer (talk) 02:00, 22 August 2014 (UTC)[reply]

I can't reproduce this. Here's my bug report; hopefully Cacycle can compare the two and figure out what's going on:

• Date: 2014-08-25 05:23:11 UTC
• wikEd version: 0.9.133 GM (August 24, 2014)
• Browser: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Win32)
• Skin: monobook (detected: monobook) (also unable to reproduce in Vector)
• MediaWiki: 1.24wmf17
• Gadgets:
• MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Dr_pda/prosesize.js, User:AzaToth/twinkle.js, User:Mr.Z-man/closeAFD.js, User:King_of_Hearts/closexfd.js, User:Phantomsteve/xfdrelist.js, Wikipedia:WikiProject_User_scripts/Scripts/Force_edit_summary, User:Svick/SectionInput.js, User:Haza-w/cactions.js, User:Timotheus_Canens/displaymessage.js, User:Doug/closetfd.js, User:King_of_Hearts/closeffd.js, User:King_of_Hearts/closecfd.js, User:King_of_Hearts/closerfd.js, User:Doug/closemfd.js, User:Haza-w/cactions-languages.js
• URL: https://en.wikipedia.org/w/index.php?title=Murghab,_Tajikistan&action=edit&useskin=monobook
• User subpages: //en.wikipedia.org/wiki/Special:PrefixIndex/User:Jcgoble3/
• User/skin.js: https://en.wikipedia.org/wiki/User:Jcgoble3/monobook.js and https://en.wikipedia.org/wiki/User:Jcgoble3/vecctor.js
• User/common.js: https://en.wikipedia.org/wiki/User:Jcgoble3/common.js
• Error console: nothing relevant

jcgoble3 (talk) 05:27, 25 August 2014 (UTC)[reply]

Tomaxer, jcgoble3: It looks like this has been fixed by removing InstaView in version 0.9.134. Thanks for reporting, Cacycle (talk) 16:21, 25 August 2014 (UTC)[reply]

Sorry for a later response. Now it does seem fixed and I get no warnings. Thank you for looking into it. --Tomaxer (talk) 20:52, 12 September 2014 (UTC)[reply]

wikEd bug report: ____ (Please add short title)

• Date: 2014-09-02 21:16:03 UTC
• wikEd version: 0.9.137 G (September 01, 2014)
• Browser: Chrome/36.0.1985.125
• Skin: vector (detected: vector_new)
• MediaWiki: 1.24wmf18
• Gadgets: Gadget-popups.js, Gadget-HotCat.js, Gadget-markblocked.js, Gadget-popups.js, Gadget-defaultsummaries.js, Gadget-citations.js, Gadget-wikEd.js, Gadget-dropdown-menus.js, Gadget-metadata.js, Gadget-RegexMenuFramework.js
• MediaWiki scripts: RefToolbar.js, Common.js/edit.js, Common.js/secure_new.js, LinkFixr.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js, User:Lupin/recent2.js, User:Lupin/popups.js, User:TheDJ/Gadget-HotCat.js, User:Porchcrop/rollbackSum.js, User:Smith609/toolbox.js, User:Ale_jrb/Scripts/statusCheck.js, User:Ale_jrb/Scripts/userhist.js, User:GregU/dashes.js, User:Joshua_Scott/Scripts/pendingchanges.js, User:TheJosh/Scripts/NewPagePatrol.js, User:TheJosh/Scripts/RecentChangesPatrol.js, User:Ais523/topcontrib.js, User:NuclearWarfare/Mark-blocked_script.js, User:Ale_jrb/Scripts/csdhelper.js, User:Smith609/citations.js, User:Ale_jrb/Scripts/waLib.js, Wikipedia:AutoEd/core.js, User:Magnus_Manske/LinkFixr.js, User:Cacycle/diff.js
• URL: https://en.wikipedia.org/w/index.php?title=User:Cymru.lass/drafts/WHO_ranking&action=edit&section=1
• User subpages: https://en.wikipedia.org/wiki/Special:PrefixIndex/User:Cymru.lass/
• User/skin.js: https://en.wikipedia.org/wiki/User:Cymru.lass/vector.js
• User/common.js: https://en.wikipedia.org/wiki/User:Cymru.lass/common.js
• Error console: Uncaught TypeError: Cannot read property 'length' of null index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:8299
• Problem description: Basically, RegEx search isn't working at all. Even if I don't use any special characters. I can type 1 into the search box, and wikEd will highlight the first appearance of the character, but pressing "Find next match" won't take me to the next appearance of the character. This is the case no matter what has been put into the search box. Turning off RegEx allows me to do normal searching (and the "Find next match" button does work).

Thank you!! cymru.lass (talk • contribs) 21:21, 2 September 2014 (UTC)[reply]

Fixed in 0.9.138, thanks for reporting! Shift-Reload to update. Cacycle (talk) 09:11, 3 September 2014 (UTC)[reply]

@

Helder 13:13, 3 September 2014 (UTC)[reply

]

Joeytje50: Good idea, I have put it on the to-do list. Cacycle (talk) 17:25, 6 October 2014 (UTC)[reply]

• Version: maybe later 0.9.134 (August 25, 2014) diff
• Attention line: title = title.replace(/[#<>\[\]|{}]/g, );

In the diff page, section link is not working. I am guessing that is because the # sign has been removed from the link. Thank you very much. --Frozen-mikan (talk) 01:32, 27 September 2014 (UTC)[reply]

Frozen-mikan: fixed in 0.9.143, thanks for reporting! Cacycle (talk) 11:37, 11 October 2014 (UTC)[reply]

Steps to reproduce problem

1. Edit a biography with a person infobox (e.g., Frank McLaury).
2. Manually select all text in the article (i.e., CTRL + A).
3. Click the wikEd button to "Fix caps in headers and lists".
4. Save the results.

The infobox fails to display. The problem is that the initial characters of the parameters for the infobox are converted to initial caps, as in the following example:

{{Infobox criminal | Name = Frank McLaury | Image_name = Fmclaury.jpg | Image_size = 220px...

This breaks the infobox which requires lowercase parameters. If this functionality is not implemented by wikEd, I'd appreciate a redirect to the correct script. Thanks.

Supporting info

Confirming bug still appears in 0.9.142.

Running Chrome Version 37.0.2062.124 m

Windows 8.1 64bit

Wikipedia Modern skin

Bug still present after disabling all other custom scripts

For an example, see this diff.

Chrome error console contained the following error.

console.trace()
2XMLHttpRequest cannot load https://commons.wikimedia.org/w/api.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://en.wikipedia.org' is  therefore not allowed access. 
en.wikipedia.org/w/index.php?title=Frank_McLaury&action=edit:1

Let me know if you need any more information. — btphelps ^{(talk to me) (what I've done)} 16:43, 7 October 2014 (UTC)[reply]

btphelps: Thanks for reporting this. The fix buttons use relatively simple rules and cannot detect the difference between a table and template parameters. This will not change in the near future. After using these buttons always check the changes for unexpected collateral damage and always use the smallest possible selection. Please see User:Cacycle/wikEd_help#Fix_buttons. Cacycle (talk) 08:12, 23 October 2014 (UTC)[reply]

Wikipedia:TemplateData is a brand new feature which is apparently not fully compatible with wikEd:

1. Pick a template doc subpage, e.g. Template:Croatian Census 2011/doc.
2. Click on Edit.
3. Click on the "Manage TemplateData" button.
4. Change something in the pop-up form, e.g. the description.
5. Click on the "Apply" button".

Now, changes made to template data should be propagated to the edit area (<templatedata> element), but they are not. The workaround is to switch wikEd off when working with TemplateData form, or to use the edit area directly rather than the form. GregorB (talk) 20:13, 7 October 2014 (UTC)[reply]

Previously reported in #Compatibility with TemplateData Editor. Paradoctor (talk) 22:33, 7 October 2014 (UTC)[reply]

Oops, I somehow missed that. Sorry for the duplication... GregorB (talk)

GregorB: See meta:User talk:Krinkle#wikEd/TemplateData. Cacycle (talk) 10:33, 27 October 2014 (UTC)[reply]

Hi Cacycle, I'm wondering what code wikEd is currently using for the rapid preview? I see a few mentions above, that InstaView was removed in 0.9.134, but InstaView is still listed at User:Cacycle/wikEd#Full_features and at User:Cacycle/wikEd_help#Preview_and_changes.

I ask because I'm putting together a table at mw:Requests for comment/Live preview, and I'd like to know what's missing. Please, join in there! Quiddity (talk) 00:32, 27 October 2014 (UTC)[reply]

Quiddity: Thanks for the note, I have added wikEd to your table and will update the wikEd feature lists. Cacycle (talk) 09:28, 27 October 2014 (UTC)[reply]

Extensive edits! Much thanks for all that. :) Quiddity (talk) 18:49, 27 October 2014 (UTC)[reply]