User talk:Cacycle/wikEd

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Recent improvements[edit]

  • Modernized and updated user interface. (March 07, 2014)
  • wikEd now displays redlinks in red. Also, the link tooltip popups displays the redirect's targets. You can then use the Fix redirects button to fix redirects. (December 14, 2013)

Please support wikEd[edit]

Please support wikEd by helping to fix the following browser and MediaWiki issues. You could also vote for these bugs in the respective bug trackers (login required).

  • Firefox:
    • 458524 Automatic syntax highlighting would interfere with undo/redo. The only reason why wikEd does not have automatic syntax highlighting.
    • 543204, 579760 (cursor/caret disappears)
    • 819753 (undo broken)
    • 926230 (space at end of line not styled)
  • Webkit/Chrome:
WikEd logo64x64.gif  wikEd:  Home · Discussion · Help

Installation:  Installation · Customization · Images

Project:  User box · · Navigation box · Testimonials

Development:  Version log · Documentation · Developer discussion

Helper programs:  diff · wikEdDiff 

Program code:  Current version · wikEd · Greasemonkey bundle · diff · wikEdDiff · InstaView · wikEd dev · Installation template

Gadgets:  Guide · English: Description · Code
Arabic · Chinese · Galician · German · Hungarian Japanese · Malay · New Norwegian · Polish · Portuguese · Romanian · Sicilian · Spanish · Kazakh

Translations:  Guide · Example · Arabic · 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 · Vietnamese

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.


Archived discussions from this page: 1 2 3 4 5 6 7 8 9 10 11 12 13


wikEd Bug reports[edit]

Please Ctrl-click the wikEd logo (WikEd logo.png on top of the page) or the wikEd button (WikEd logo.png) on the page where you observe your problems. This gives you a bug report form that contains important debugging information.

In order to help you with problems, the following details and information are needed:

In addition, please fill in the following fields:

  • Error console entries. See reporting JavaScript errors. (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. Please be as specific as possible about what is wrong, including when it happens, what happens, what is broken, and what still works.
  • Steps to reproduce your problems. Please include what happens at each step. Your problems cannot be fixed without reproducing them first!

Please add your bug report at the bottom of this page.


Request - Pipes and Bangs[edit]

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! 03:16, 2 October 2007 (UTC)

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)
I would personally prefer #1 - if a cell is all bold, give it header style. (talk) 21:55, 19 December 2007 (UTC)

Wikia link suggest[edit]

I know that this is supposed to be available for all MediaWiki wikis, but the requests I'm asking now is specific to Wikia. Wikia has a link suggest feature described at wikiasite:help:Help:Link Suggest. However, this feature doesn't work while widEd is on. I was wondering if there's any way that you could allow link suggest to work in Wikia; it would be very helpful. Thanks. --Michaeldsuarez (talk) 01:37, 10 February 2009 (UTC)

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

Popups with wikEd[edit]

I am a devout user of WP:POPUPS here. Normally when in the edit page, I can highlight a wikilinked word with my cursor and I get a popup like on articles. But wikEd does not allow me to do that. The ctrl-click works, but I don't want to open a new page for it, just see a preview with popups. How can I do this? Thanks! Reywas92Talk 00:31, 24 May 2009 (UTC)

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

Preview background-color[edit]

Where can i change the background-color for the Preview function mentioned in Preview and changes?
Is this only possible using a css-rule or is there also a variable i can modify?
⇐⇑©TriMoon™ Talk @ 06:51, 4 February 2010 (UTC)

  • PS: maybe you could change the default background-color to be "inherrit" instead of the white as it is now, that way it will look better on all wiki's because it will use the site's default colors.
    ⇐⇑©TriMoon™ Talk @ 09:11, 5 February 2010 (UTC)
TriMoon: please use the following setting. Cacycle (talk) 17:05, 11 April 2014 (UTC)
var wikEdConfig = {};
wikEdConfig.mainEditCSS = { '.wikEdPreviewBox': 'background: #faf8f6; padding: 5px; border-width: 1px; border-style: solid; border-color: #404040 #ffffff #ffffff #404040;' };

Disable autoscroll?[edit]

Is it possible to selectively disable the autoscroll feature that causes the page to jump down to the edit box when loaded? I saw the previous discussion that this behavior is disabled when there's an edit notice, but I really would rather it not happen at all. I use Friendly and Twinkle, and often find myself opening a non-existent talk page to welcome or warn someone. However, wikEd jumps down to the edit box, causing the tabs to go off-screen, and I have to manually scroll back up to use my other tools. Since my browser is big enough to see the whole edit box anyway, the scrolling is more annoying than useful for me. --Darkwind (talk) 05:37, 16 April 2010 (UTC)

I will work on this as soon as I find the time after the upcoming major change to version 0.9.91. Cacycle (talk) 20:28, 20 April 2010 (UTC)

UploadForm.js not working when wikEd is enabled[edit]

Is there any way to switch of wikEd for selected articles? I have a problem with running the UploadForm-Script when the wikEd Option is active. I tried disabling loading wikEd.js (which does work wrt. wikEd not showing up), but the new upload form is still not applied. When switching off wikEd (user preferences), the new upload form is correctly applied. Thanks --StefanSchulzDe (talk) 18:30, 27 April 2010 (UTC)

How do I install UploadForm-Script? I don't think it loads when I try this and I cannot find any installation instructions. Cacycle (talk) 20:33, 28 April 2010 (UTC)
The script is loaded via the MediaWiki:Common.js script. Has some pre-requisits though, as can be seen, and I am not sure whether it can be applied via User-Scripts. I assume there is a reason, why WikEd is not available in commons. --StefanSchulzDe (talk) 17:56, 2 May 2010 (UTC)

Bug using wikEd on a specific website[edit]

On this website : wikEd can be activated via gadgets preferences, but doesn't work properly.

With Firefox one can only have the right part of wikEd but not functionnal. And with Camino or Safari the edit window is to small to be visible except when set to full screen.

Thanks for your help.

--Dieudo (talk) 22:31, 6 September 2010 (UTC)

Thanks for reporting this. I could replicated this and will fix it as soon as I find some time. Cacycle (talk) 06:46, 10 September 2010 (UTC)

Text highlighter on view source page?[edit]

Would it be possible to implement the font/text highlighter on the view source page? (without the toolbars of course). — Train2104 (talkcontribscount) 19:25, 12 September 2010 (UTC)

What is the "view source" page? Cacycle (talk) 21:36, 12 September 2010 (UTC)
The one a user gets when they try to edit a page and they don't have permission to . — Train2104 (talkcontribscount) 21:46, 12 September 2010 (UTC)
Sure, I will add it as soon as I find some time. Thanks for the suggestion - Cacycle (talk) 22:06, 12 September 2010 (UTC)

wikEd is overwriting user customization (I give also an solution)[edit]

Hello, Cacycle! That's a very good and powerful Gadget! I have one problem/suggestion about accesskeys. You wrote "it overwrites the MediaWiki shortcuts", that's pretty fine. But You also overwrite user customization with that:

    // button access keys
    if (typeof(wikEd.config.buttonKey) == 'undefined') { wikEd.config.buttonKey = {}; }
    // wikEd.InitButtonKey: define accesskeys for edit buttons (wikEd button number: [key string, JS key code])
    wikEd.InitButtonKey = function() {
        wikEd.InitObject(wikEd.config.buttonKey, {
            26: ['b', 66], // wikify
            27: ['o', 79], // textify
            67: ['g', 71], // scrolltoedit2
            72: ['g', 71], // scrolltoedit3
            74: ['g', 71], // scrolltoedit4
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key

I'd like to attach 'u' to Underline button, 'i' to Italic button and 'b' to Bold button but the 'b' key seems not to work. It's attached to Wikify, I think that's because You add user customization and then set accesskeys for wikify, textify and scrolltoedit. Maybe You should reverse it?

    wikEd.InitButtonKey = function() {
            26: ['b', 66], // wikify
            32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
        }, wikEd.config.buttonKey);

P.S. Don't You think about archiving some sections here? q;) Vinne2 (talk) 18:57, 13 August 2011 (UTC)

Reversing the variables does not work. Please see User:Cacycle/wikEd_customization#Keyboard_shortcuts for how to redefine existing shortcuts. Cacycle (talk) 00:14, 4 January 2012 (UTC)

Fail on bold italic text[edit]


Some of us on frwiki have problems with wikEd when editing a page with bold italic text.

  • wikEd 0.9.97a
  • Firefox 3.6.13 on Ubuntu 10.10 (for me, but it looks it's not related)
  • Plenty of addons (not related either)
  • Plenty of other gadgets (including popups — but I don't think this is related either)
  • Not related to userscripts (same behaviour with or without)
  • monobook for me (don't know for the others) and no beta interface

How to reproduce :

Relevant information :

 Error: parseObj.tree[openNodeIndex] is undefined
 Source File:
 Line: 11679

The line 11679 is

 parseObj.tree[openNodeIndex].tag = tag; // openNodeIndex is null, the previous value of tag is “bold”

This is called by line 11147:

 wikEd.HighlightTreeRedefine(parseObj.secondlastOpenNodeFiltered, 'bold', 0, 3, parseObj); // just after case “'boldItalic':”

This is called by line 13316:


With obj.whole == true and obj.html == // the whole page

If you can't reproduce, please let me know at fr:User talk:Arkanosis, I'd be happy to help.

Best regards — Arkanosis 15:44, 8 February 2011 (UTC)

Oops. I can reproduce it and will check into it. Thanks for reporting. Cacycle (talk) 08:18, 9 February 2011 (UTC)

Req: Sort (and normalize?) list entries contained in a single line[edit]

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)

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)
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)
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)

Extra line is inserted with regular expression replacement function if text ends a line[edit]

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)

I see this too and I will check into this. Cacycle (talk) 07:44, 9 March 2011 (UTC)
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)
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)
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)

Making scripts compatible with wikEd[edit]

I have installed WikEd on my wiki with the "intgrated to wikifarm" installation. I have some problem with the WikiEditor extension, when activated wiked's editing frame isn't visible. It work when you activate the fullscreen mode but the modification aren't applied. I have a mediawiki 1.16 and the WikiEditor (Version 0.2.0) extension installed with UsabilityInitiative (Version 0.1.1)

I want to do "Making scripts compatible with wikEd" installation but I don't get how it has to be done and where to paste the code --Tsouchon (talk) 13:41, 18 March 2011 (UTC)

This sounds like an incompatibility, perhaps with WikiEditor. What happens if you disable that extension? Please could you also fill out a bug report form (from the top of this page)? Do you see the wikEd logo on top of the page and does it give an error message on hovering? The "Making scripts compatible with wikEd" section is for authors of simple scripts, not for users. Cacycle (talk) 16:02, 18 March 2011 (UTC)
I have this problem too. MW version is 1.16.2. When WikiEd is on I cannot edit pages and sometimes I also get a "WikiEd Error" (WikiEd icon has a red X on it). For some reason here everything is OK... --Tharbad (talk) 19:03, 19 March 2011 (UTC)

I got the same problem too, my MW version is 1.16.2. These two editor just work fine in but not in my wiki. here is a Screenshot of the broken editor

PS: the small icon in right-top show as normal(There are no red X on it.)--晒太阳的冰 (talk) 04:44, 29 March 2011 (UTC)

"Convert to plain text" button jumps to the end[edit]

Here is a problem in Firefox 4:

  1. Edit e.g. this page
  2. Scroll down to the middle of the text in the edit window
  3. Click on [T]
  4. This causes wikEd to jump to the end of the text, instead of staying in the same position, as it does in 3.6.16 and Chrome 10

Somewhat annoying when using [T] in big articles, otherwise not a big deal. GregorB (talk) 11:18, 26 March 2011 (UTC)

This is relatively annoying, though I wouldn't imagine it's as important to fix as other things. Still, it would be convenient if the cursor was in the same position after the function completes. —danhash (talk) 18:09, 30 January 2012 (UTC)
The problem seems to be gone in Firefox 21... GregorB (talk) 11:27, 25 May 2013 (UTC)

Bug in diff.js[edit]

Hi. I found a bug in your diff.js: Look at this diff (don't care about the text, this was the example I found the bug in, and I didn't look for an English example). There is a move shown, which looks like only the comma and the space was moved. If you look at the HTML source, you can see that the deleted "also" and the inserted "wenn man" are in the moved block too, which is kind of strange. But even if you accept this to be a move, it is wrong still, since the following "einfach" should belong to the moved block too. I hope you are able to find the bug in your diff.js. --Schnark (talk) 07:29, 11 April 2011 (UTC)

In certain cases, the results are counterintuitive, especially for many close minor changes of common words and when block moves are involved. I would not call this a bug. Cacycle (talk) 17:07, 8 May 2011 (UTC)
The diff suggests that the word "einfach" wasn't changed. But it was changed: It was moved from the point where the yellow arrow shows a move to the place where it is shown in the diff. But it is not highlighted yellow as it should. The span with the class wDiffHtmlBlock should end after the word, not before it.
It should be possible to restore both the old and the new text from the diff, by omitting either the inserted or deleted blocks and by putting moved blocks either where they were or where they are now. But in this case you can only get the new text correctly in this way, the old text can't be restored from this diff. --Schnark (talk) 09:34, 10 May 2011 (UTC)
It is even possible to hide vandalism: [1] If you only look at the text marked as changed you won't notice the vandalism that occured. --Schnark (talk) 07:44, 12 May 2011 (UTC)
Screenshots to show the bug: "Vandalism is" should be yellow. --Schnark (talk) 08:31, 17 June 2011 (UTC)

Edit window size[edit]

I'd like to customize the size of the edit window in my browser and I'm a wiked user. Is there a customization bit for that, or will I need to do something special?
— V = IR (Talk • Contribs) 14:08, 19 April 2011 (UTC)

  • To do that, you can drag the grip handle at bottom right of the edit window. -Pgan002 (talk) 03:39, 26 April 2011 (UTC)
    • You can chose the textarea size in your wiki preferences, wikEd keeps the default size. You can also use the Fullscreen fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
      • Is it possible to calculate the text area height depending on the window height? it seems this should be already happening in

wikEd.SetEditArea(), but for me it always comes up a standard height. -Pgan002 (talk) 01:25, 24 December 2011 (UTC)

      • Full-screen mode is great! But it should resize area dynamically if the window gets resized, or if the Find bar is shown or hidden (for example in Firefox) or a notification bar appears (in Firefox). Is that achievable? I noticed that the width does change dynamically.

Weird cursor behaviour[edit]

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)

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)

JS errors in IE 8[edit]

After enabling the wikEd gadget on Portuguese Wikipedia and going to a page like pt:Idempotência using Internet Explorer 8.0.6001.18702 I get the following errors in the console:

Error: Type mismatch
javascript&smaxage=21600&maxage=86400, line 15568 character 3
                domElement.detachEvent('on' + eventType, domElement[eventType + eventHandler]);


Error: Object doesn't support this property or method
javascript&smaxage=21600&maxage=86400, line 15547 character 4
                        domElement['wikEd' + eventType + eventHandler](eventRootElement.event);

Could this be fixed? Helder 20:46, 9 May 2011 (UTC)

minor bug considering new lines and highlighting[edit]

New lines created at the beginning of the document will already possess the highlighting of the following lines, no matter what you write there. It's distracting me slightly.

It's reproducible. For instance, open the page [2], go to the start of the document, press enter two times and start writing. The text will adopt the highlighting of the following lines, no matter the content. --Aetas volat. (talk) 13:30, 30 May 2011 (UTC)

Supplement: It's not just highlighting, but formatting in general. --Aetas volat. (talk) 16:03, 30 May 2011 (UTC)

Removes empty comments[edit]

  • 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)

Fixed in version 0.9.100 Thanks for reporting, Cacycle (talk) 11:42, 4 September 2011 (UTC)
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)

Preview doesn't work properly in Safari[edit]

In Safari 5.1 under Mac OS 10.7, clicking on the same-page preview button (the magnifying glass) results in a generated preview where templates are not expanded, but instead appear in their source code form. Firefox works properly. Hgrosser (talk) 03:41, 1 September 2011 (UTC)


Did something change with the tabbing? For some mysterious reason, tabbing out of the edit textarea to the edit summary now fails to select the content of the edit summary (instead inserting the cursor at the beginning of the input), which is the behavior behavior anywhere that I know in computing. Circéus (talk) 16:48, 14 October 2011 (UTC)

Ref hiding bug[edit]

In this edit I used the "[REF] and [TEMPL] hiding" feature to make the text easier to edit, but it removed the </ref> tag at the end. —danhash (talk) 18:35, 31 October 2011 (UTC)

Could not reproduce this under wikEd 0.9.119c. Cacycle (talk) 16:36, 7 October 2013 (UTC)

Plain pasted text?[edit]

Sorry if this isn't the right page to ask this on, but is there a way to force any text that's pasted into wikED to be plain text? It's really annoying when I copy things in from other sites and it keeps the font style, sometimes even the page's formatting gets through and screws up the whole page. I hate having to copy text through Notepad in order to change it to plaintext. Thanks very much for the assistance and keep up the work! I love this extension! (talk) 17:52, 30 January 2012 (UTC)

Check out this thread which addresses the issue. The short answer is to use Ctrl-Shift-V to paste instead of Ctrl-V, or to right-click and select "Paste as plain text" in supported browsers. —danhash (talk) 18:05, 30 January 2012 (UTC)
I am actually working on this. Unfortuntely, Ctrl-Shift-V does not work in most cases. Cacycle (talk) 00:09, 4 February 2012 (UTC)

Chrome: Hotkey «Alt-S» not working for saving article[edit]

  • 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)

Problem with Word[edit]

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. Rabah201130 (talk) 10:37, 20 March 2012 (UTC)

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

Little search & replace bugs in regual expression mode[edit]

  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)

instant preview not working[edit]

0.9.102 Firefox 11 all addons disabled apart from wikEd/greasemonkey default skin no other scripts Windows XP sp3

I pasted the contents of the firefox error console at

Whenever I try to use the "preview" function of wikEd to show a live preview of an article without reloading the page, the preview doesn't appear. All that appeasr is a text box containing "..."

Clicking the preview button again adds an additional blank line to the text box

Lemonbalmtea (talk) 14:25, 10 April 2012 (UTC)

I see this too, I will check into it. Cacycle (talk) 16:48, 8 July 2012 (UTC)


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)

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)
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 "&nbsp;" 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))

Black and bolded highlighting of text selection[edit]

Hi: Highlighted text in the edit area is now bolded and black, rather than the (Mac OS X) system highlight color.

See the following screenshot "side-by-side" demo available here:

The bug appears in Safari and Chrome as well.

---Schweiwikist (talk) 17:38, 17 July 2012 (UTC)

It is a browser bug, please see Firefox bug 721750 and feel free to help/comment. Cacycle (talk) 20:50, 17 July 2012 (UTC)
Thanks, however, as I previously mentioned, the bug appears in Safari & Chrome as well. Toggle wikEd text area off in any of the 3 browsers,
and my edit-area text highlighting is my preferred color. Fresh link below shows (Chrome) that the highlighting is “boxed in” after a select-all or drag-select:
---Schweiwikist (talk) 07:25, 28 July 2012 (UTC)

Idea (See and edit tables as tables)[edit]

I had an idea recently, and I was wondering how hard it would be to have a button in wikiEd that would display tables as actual tables, so that people could edit the entries easily without having to sort through the jumble of code. Is such a thing even possible? ~Adjwilley (talk) 19:16, 17 July 2012 (UTC)

Great suggestion. This is actually possible and most of the code has already been written (you can see it in the source). It is just that I am really busy IRL at the moment. Cacycle (talk) 20:53, 17 July 2012 (UTC)
Wow! That's exciting to hear. If I had any experience programming I would offer to dive in and help, but unfortunately I'm no programmer. Good luck with whatever you've got going on :-) ~Adjwilley (talk) 21:18, 17 July 2012 (UTC)

My talk page[edit]

wikEd version: 0.9.104a G (August 6, 2012) browser id: Firefox 14.0.1 for Ubuntu (however the problem is also there in Chrome) Errors: Timestamp: 12-08-16 09:03:40 AM Error: TypeError: mw.loader.implement is not a function Source File:* Line: 12

Timestamp: 12-08-16 09:03:41 AM Error: TypeError: c1 is null Source File:* Line: 15

Timestamp: 12-08-16 09:03:43 AM Error: TypeError: parseObj.tree[openNodeIndex] is undefined Source File: Line: 11802

Timestamp: 12-08-16 09:03:43 AM Error: TypeError: mw.user.sessionId is not a function Source File: Line: 1162

Timestamp: 12-08-16 09:03:43 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Timestamp: 12-08-16 09:04:39 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Timestamp: 12-08-16 09:05:30 AM Error: TelemetryStopwatch: key "FX_SESSION_RESTORE_COLLECT_DATA_MS" was already initialized Source File: resource://gre/modules/TelemetryStopwatch.jsm Line: 53

Skin: Vector

OS: Ubuntu 12.04 LTS

Problem: When I try and edit my own talk page, User talk:CambridgeBayWeather, all I get is blank page. This does not appear to happen with any other page. However at one time it did the same thing with {{Infobox airport}} but it currently works fine there. See also Wikipedia:Help desk#My talk page. Thanks. CambridgeBayWeather (talk) 15:18, 16 August 2012 (UTC)

A few additional details (not sure if they'll help, but can't hurt): If I load you talk page with the wikEd text area turned off (as I normally do), it comes up fine. When I try to turn on the wikEd text area, the mouse cursor changes to the "busy" symbol and won't change back, and this error is produced:

If I click on the wikEd text area button again, the mouse cursor goes back to normal and the edit box is now blank. Loading your talk page with the wikEd text area turned on produces a blank edit box and the same error. I get no other errors in my error console. I'm on Firefox 14.0.1, Windows Vista, Vector skin, wikEd 0.9.104a G (August 6, 2012). jcgoble3 (talk) 16:01, 16 August 2012 (UTC)

wikEd is unable to close the old edit toolbar on Wikia[edit]

I tried wikEd 0.9.105 Deutsch in 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)

Installation problem[edit]

Can't seem to install with a User script. Have tried both Complete_version and Ultra-simple_version with refreshing and even reloading the browser. Using Firefox 16.0.1 and Firefox 17. Does common.js prevent use in monoboook.js perhaps? However it works fine with the gadget, but the gadget doesn't appear to support Fix typos which was my mean purpose of installing the gadget. Regards, Sun Creator(talk) 23:54, 13 October 2012 (UTC)

Does it work now? Please see User:Cacycle/wikEd customization#RegExTypoFix for the correct (new) syntax of customization. Cacycle (talk) 22:32, 2 December 2012 (UTC)
Your message is to cryptic to understand or perhaps the documentation is outdated. After having followed the installation instructions my monobook.js page has no '/ start of user configurable variables' section. What am I doing wrong? Regards, Sun Creator(talk) 00:27, 6 January 2013 (UTC)

Issues remaining[edit]

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)

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)

wikEd & Narayam compatibility[edit]

Hi Cacycle, I am an admin on where I recently installed this gadget. I am localising it there as well. I am facing an issue with its compatibility with Narayam. When WikEd is enabled, narayam doesn't work, saying that input language is only English. Once WikEd is disabled Narayam starts working. Before I file a bug, thought to check with you whether you are aware of this issue? Or is it because I missed something while installing?-- DhavalTalk 08:46, 5 January 2013 (UTC)

I am not aware of this, please post a detailed bug report (see top of page) so that I can replicate your problems. Thanks, Cacycle (talk) 19:14, 6 January 2013 (UTC)

How to get and set the cursor/selection positions?[edit]

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)

Wikidata Template German[edit]

Hey I use the gedaget on Wikidata. if there is a Template highlited I can click it and it opens a new tab but instead of "Template:..." it opens "Vorlage:..." this would be correct on the German wikipedia but as I am using Wikidata (yes in German language) it should still be "Template:..." there. --Sk!d (talk) 00:23, 16 January 2013 (UTC)

Fixed in version 0.9.118a (May 19, 2013), now the customization settings in wikEdConfig.text take precedence over loaded translations. Simply add the following code to common.js to the wikidata:MediaWiki:Gadget-wikEd.js page. Cacycle (talk) 13:27, 19 May 2013 (UTC)
if (typeof(wikEd) == 'undefined') { window.wikEd = {}; }
wikEd.config.text = { 'wikicode Template': 'Template' };

Special char gallery inserts into article editor, not edit summary or subject line, despite focus[edit]

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)

Automatic replacement[edit]

Hi, someone asked me a question about automatic replacement of this html code : obj.plain = obj.plain.replace(/ | |\xa0/g, ' '); Is it possible to disable this replacement in personnel common.js ? Thanks Leag (talk) 08:03, 5 February 2013 (UTC)

Up Leag (talk) 07:14, 7 March 2013 (UTC)
No, that is not possible as non-breaking space as a character (but not as a character entity) is not supported by wikEd. Cacycle (talk) 10:48, 20 May 2013 (UTC)

wikEd fails on a specific diff[edit]

Hello. On the following diff, wikEd fails :

In the console, it says there is an issue in wikEdDiff.js at line 652 (title = decodeURI(title);) : URIError: malformed URI sequence @

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)

Forwards to editing Main Page without asking[edit]

  • Date: 2013-03-25 05:00:37 UTC
  • wikEd version: 0.9.111b (February 12, 2013)
  • Browser: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2 (Linux i686)
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.21wmf12
  • Gadgets: Gadget-easyPeerReview.js, Gadget-Feedbackhack.js, Gadget-edittop.js, Gadget-wikied.js
  • MediaWiki scripts: common.js/Main_Page, Edittools.js
  • Scripts:, User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
  • URL:
  • User/skin.js:
  • User/common.js:
  • Error console: Nothing.
  • Problem description: I am editing a user talk page with WikEd enabled. After clicking preview and editing it a few times, I click save. Then I realize that it added my edits to Main Page rather than the user's page.
  • Steps to reproduce:
  1. Enable WikEd on Wikinews.
  2. Create a new user talk page.
  3. Add "{{subst:Welcome}}" to it, click WikEd's preview, click save.
  4. You will get a message that you have tried to edit the Main page.

--Gryllida 05:05, 25 March 2013 (UTC)

It depends on the previewed <input name="title"> that hijacks the save command to a new page title.
Given that in your project it's matter of a frequently saved template, while waiting a fix in wikEd, you can apply this temporary patch in n:MediaWiki:Gadget-wikied.js :
// patch for the title-trapdoor
// on saving after a live-preview of an <input name="title">
$( '#wpSave' ).click( function() {
    $( '#wikEdLocalPrevWrapper' ).remove();
} );
-- Codicorumus  « msg 19:48, 27 March 2013 (UTC)
I cannot replicate this problem, neither using wikEd as a gadget nor under Greasemonkey. Has this already been fixed somewhere else? Maybe this has been caused by Gadget-Feedbackhack.js? Do you still see this with all other gadgets disabled? BTW, it is wikEd, not wikiEd... Cacycle (talk) 14:55, 7 April 2013 (UTC)
OK, I can see it now and are working on it... Cacycle (talk) 21:26, 7 April 2013 (UTC)

Has been fixed a while ago in 0.9.114c (April 21, 2013). Cacycle (talk) 19:41, 11 May 2013 (UTC)

Inline links to Wikidata items[edit]

Some of the Wikipedias (and all of them soon) allow you to pull information from Wikidata. A common example is for the population of a country or city so that updating the value in Wikidata will update it for all of the articles and languages that use that information. There is concern about how easy it is to get from a Wikipedia article to the item in Wikidata. It would be great if wikEd could link to Wikidata items like it does for Commons media items. The basic idea would be to turn any into a link to the Wikidata item with the title of the article. More details are here. My JavaScript is a bit dusty, but I could help out. Wakebrdkid (talk) 19:28, 29 March 2013 (UTC)

Added to version 0.9.113. Thanks for suggesting this. Cacycle (talk) 21:36, 6 April 2013 (UTC)

Signature button / custom buttons / Common.js[edit]

Hi. After installing wikEd recentlly I noticed the standard "sig" button on the wiki I use stopped working. So, I decided to disable the standard toolbar and make a custom wikEd button. I copied the custom buttons example as per User:Cacycle/wikEd_customization#Custom_buttons however no buttons appear and I get the following in the error console:

Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'.  Expected ';' or '}' to terminate declaration but found 'ie'.  Declaration dropped.
Source File:
Line: 13
Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'.  Expected ';' or '}' to terminate declaration but found 'ie'.  Declaration dropped.
Source File:
Line: 13
Timestamp: 30/03/2013 2:12:38 PM
Warning: Expected 'important' but found 'ie'.  Expected ';' or '}' to terminate declaration but found 'ie'.  Declaration dropped.
Source File:
Line: 13
* Date: 2013-03-30 03:18:03 UTC
* wikEd version: 0.9.111b GM (February 12, 2013)
* Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 (Win32)
* Skin: vector (detected: vector_new)
* MediaWiki: 1.19.4
* Gadgets:
* MediaWiki scripts: JQuery-makeCollapsible.js, Wikiminiatlas.js
* Scripts: /skins/common/anchorad.js
* URL:
* User/skin.js:
* User/common.js:

I guess this is two or three bug-reports in one. Sorry about that! -- Niightblade (talk) 03:20, 30 March 2013 (UTC)

Please use the updated example under User:Cacycle/wikEd_customization#Custom_buttons instead. Also, in order to use custom functions (such as the button handlers) under Greasemonkey, you have to add the function code to the wikEd Greasemonkey code bundle. Cacycle (talk) 20:59, 5 April 2013 (UTC)
Everything is working perfectly now thanks! I moved to the non-GS version too. One last thing: Why no signature button on the wikEd bars? -- Niightblade (talk) 02:43, 6 April 2013 (UTC)

wikEd bug report (improper whitespace added)[edit]

  • Date: 2013-04-15 13:31:39 UTC
  • wikEd version: 0.9.113 G (April 06, 2013)
  • Browser: Mozilla/5.0 (Windows NT 6.0; rv:20.0) Gecko/20100101 Firefox/20.0 (Win32)
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.22wmf1
  • Gadgets: Gadget-DotsSyntaxHighlighter.js, Gadget-HotCat.js, Gadget-searchFocus.js, Gadget-imagelinks.js, Gadget-HideFundraisingNotice.js, Gadget-ReferenceTooltips.js, Gadget-defaultsummaries.js, Gadget-wikEd.js, Gadget-externalsearch.js, Gadget-addsection-plus.js, Gadget-CommentsInLocalTime.js, Gadget-PrettyLog.js, Gadget-RegexMenuFramework.js, Gadget-contribsrange.js
  • MediaWiki scripts: Common.js/edit.js, RefToolbarBase.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
  • Scripts:, User:Cacycle/wikEd.js, User:Gary_King/comments_in_local_time.js, User:Pathoschild/Scripts/Regex_menu_framework.js, User:Mabdul/afc_beta.js, User:Technical_13/Scripts/Gadget-BugCreateNew.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Technical_13/Scripts/Teahouse.js, User:Ocaasi/WikiLoveinstallscript.js, User:Lupin/recent2.js, User:Technical_13/Gadget-LiveClock.js, User:Technical_13/Scripts/Edit_counter.js, User:Timotheus_Canens/displaymessage.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
  • URL:
  • User/skin.js: 13/vector.js
  • User/common.js: 13/common.js
  • Error console:
    • N/A
  • Problem description:
    • Clicking "Fix spaces before punctuation" breaks <ref>...</ref> contents by adding spaces to URLs and other punctuation delimited content.
  • Steps to reproduce:
    • Go to GLYX-13 for example
    • Click to edit the page
    • Select all by pressing ^ Ctrl+a
    • Click WikEd fix punct.png
    • Click the button next to Changes that looks like: WikEd diff.png
    • Note the change to:
      • <ref>{{cite journal |doi=10.1016/j.neurobiolaging.2009.04.012 |title=The N-methyl-d-aspartate receptor modulator GLYX-13 enhances learning and memory, in young adult and learning impaired aging rats |year=2011 |last1=Burgdorf |first1=Jeffrey |last2=Zhang |first2=Xiao-lei |last3=Weiss |first3=Craig |last4=Matthews |first4=Elizabeth |last5=Disterhoft |first5=John F. |last6=Stanton |first6=Patric K. |last7=Moskal |first7=Joseph R. |journal=Neurobiology of Aging |volume=32 |issue=4 |pages=698–706 |pmid=19446371 |pmc=3035742}}</ref>

Hi Technical 13, this is not a real bug, please see User:Cacycle/wikEd_help#Fix_buttons. After using the fix buttons, always check the changes with the WikEd diff.png button for unexpected collateral damage. Always use the smallest possible selection. Keep in mind that the applied rules are very simple. Only the Unicode character fixing is completely safe. Cacycle (talk) 21:25, 21 April 2013 (UTC)

Improper space inserted in front of references[edit]

  • Date: 2013-04-16 07:17:17 UTC
  • wikEd version: 0.9.113 G (April 06, 2013) 0.9.116 G (April 26, 2013)
  • Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1 (Win32)
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.22wmf1
  • 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/secure_new.js
  • Scripts:, 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, https:/api.php, User:Cacycle/diff.js
  • URL:
  • User/skin.js:
  • User/common.js:
  • Error console: (nothing relevant)
  • Problem description: When inserting a reference with a Cite form, it inserts an extra space in front of the reference, which is incorrect according to the MOS.
  • Steps to reproduce:
    • Position cursor at desired insertion point (e.g. after the period at the end of a sentence).
    • Click the "Cite" option at the top of the edit form, revealing a new row with a Templates dropdown listbox, "Named references" link, and "Error check" link.
    • Choose "cite web" from the listbox, fill out the resulting form, and click its Insert button.
    • The reference is inserted, but with a leading space, violating WP:MOS.
    • New (still broken) behavior now described here

I could swear I have seen this bug reported in the past, but am unable to find it, and so am reporting it again, since it still occurs (and is polluting WP some). —[AlanM1(talk)]— 07:36, 16 April 2013 (UTC) (edited) —[AlanM1(talk)]— 19:46, 6 May 2013 (UTC)

Just added a bug report, please see Cacycle (talk) 17:58, 20 May 2013 (UTC)
Bug is obsolete as the unmaintained template editor was removed from WikiEditor recently (see bug 48652. Cacycle (talk) 10:40, 9 April 2014 (UTC)

MathJax-Related wikEd Bug Report[edit]

wikEd version:  0.9.113 (released on April 6th, 2013)
Browser ID:  

Human-Readable Summary:  Safari 5.0.6 for Mac OS X 10.5.8 Leopard
Browser User Agent String:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/534.50.2 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.3

Enabled Browser Extensions:  

  • Cuss Off 1.1
  • Duplicate Tab Button 2.0
  • Lazarus Form Recovery 3.2
  • Middle-Click AutoScroll 1.04
  • Print Plus
  • Search Preview 1.2.3
  • Sessions
  • Tab Reloader 1.5.2
  • TabLock 1.1

Operating System:  Mac OS X 10.5.8 Leopard
Computer Model:  24-inch, Mid 2007 iMac (iMac7,1)
Wikipedia Skin:  Vector
User Scripts:  None Installed
Installed Gadgets:  

Site of Problem Occurrence:  

Wikipedia's Mathematics Reference Desk, specifically̌

Disabled Functionality:  

LaTeX code parser activation upon refresh of post preview

Reason for Addition for Bug Queue:  

Users requesting help on the mathematics reference desk need to be able to properly preview their posts before they finish submitting them.

Problem Description:  

wikEd's article-previewing functionality does not call MathJax upon its activation even though the normal Wikipedia editor, which appears during an edit page's initial loading sequence, does, thereby allowing MathJax to parse any LaTeX code embedded in the page which one is currently editing only when the article's editing form first loads but not when the edit preview is refreshed from wikEd.

Error Console Entries:  

None applicable to website code (all apply to installed extensions and disappear when I disable extensions through Safari's master switch in 'Preferences → Extensions')

Steps Necessary to Reproduce this Problem:

  1. Check your preferences to make sure that the following options are enabled:  
    • Preferences → Appearance → Math → ⊙ MathJax (experimental; best for most browsers)
    • Preferences → Gadgets → Editing → ☑ wikEd, a full-featured integrated text editor for Firefox, Safari, and Google Chrome. Please read the help page for usage instructions.
  2. Begin editing an article or section.
  3. Add some LaTeX markup to this article or section if none already exists.
  4. Refresh the edit preview without saving your edits by clicking 'Preview.'
  5. Any embedded LaTeX will not render correctly.

Possible Leads:  

RandomDSdevel (talk) 22:28, 22 April 2013 (UTC)

I will work on this for the next release in a few days. In the meanwhile, simply push the standard preview button with math in the text one in order to load MathJax. Cacycle (talk) 21:25, 22 April 2013 (UTC)
Thank you so very much!!! I look forward to being able to use MathJax with wikEd once again and will check back every once in a while to make sure I catch your update to wikEd when you notify wikEd's userbase of it via the script's history page.
— RandomDSdevel (talk) 22:34, 22 April 2013 (UTC)
Fixed in 0.9.115. Cacycle (talk) 21:19, 23 April 2013 (UTC)
Once again, I'm very grateful that you found it very easy fix this bug so quickly. Thanks to you, I'm back in business!
— RandomDSdevel (talk) 00:15, 24 April 2013 (UTC)
Okay, I take it back: you haven't completely fixed the problem; it still occurs when I try to refresh a preview for a section I'm just starting on the mathematics reference desk. I'll submit a new bug report…ugh, why doesn't everything just work like it's supposed to? — RandomDSdevel (talk) 16:33, 26 April 2013 (UTC)

Fixed in 0.9.117. Cacycle (talk) 19:31, 11 May 2013 (UTC)

Need help with whitespace issue[edit]

I need your help in order to fix the whitespace issue extensively discussed above (wikEd adds too much whitespace, Extra spaces, Improper space inserted in front of references). The bug consists of the addition of empty lines into submitted text after pushing the Save page or Preview buttons. Examples from above include text containing wikicode lists. The bug seems to happen only under OS X, but unfortunately, I do not have access to an OS X system to figure this out on my own.

  • Do you see the issue in the preview area after pushing the Show preview below button (WikEd preview.png)?
  • Do you see it with wikEd disabled (Use wikEd button above edit area inactive)?
  • Do you see it with highlighting disabled (Syntax button inactive)?
  • Do you see it with [REF] and [TEMPL] hiding on as well as off ([REF, TEMPL] active as well as inactive)?
  • Do you see the issue when not pasting text
  • Please could you create a minimal test case that contains the minimum amount of text and unnecessary wikicode?
  • Has anybody experienced this issue under Windows first-hand?
  • Please email me the following debugging information (only working with wikEd version 0.9.114c):
    • Add the following code to your User:Username/common.js page:
      var wikEdConfig = { 'debugging': true };
    • Update wikEd as well as your common.js userscript by Shift-Reload
    • Edit a page so that the blanks will be inserted into the text when submitting it
    • When you now push Shift while clicking the Preview button, the debugging information will be displayed above the edit box
    • Please go to Special:EmailUser/Cacycle, copy and paste that debug info, and send it to me

Thanks in advance, Cacycle (talk) 15:07, 21 April 2013 (UTC)

Cacycle, #wikEd bug report (improper whitespace added) is about the same issue as you linked above and I'm running Win Vista with the latest version of Firefox. Technical 13 (talk) 15:31, 21 April 2013 (UTC)
Hi Technical 13, your bug is not related to this, please check my upcoming comments above. Cacycle (talk) 21:20, 21 April 2013 (UTC)

Because of a bug I had to revert to last stable version (0.9.113). Therefore, the debug info function is temporarily disabled. I will fix this asap. Cacycle (talk) 19:52, 21 April 2013 (UTC)

Debugging mode works again in 0.9.114c. Please update with Shift-Reload and submit your bug reports. Cacycle (talk) 18:37, 23 April 2013 (UTC)
I'll note, too, that #Improper space inserted in front of references is on Win7/FFox. —[AlanM1(talk)]— 01:29, 24 April 2013 (UTC)

OK, I think I have found the bug! It is a bit difficult to fix, please give me some time. Cacycle (talk) 21:32, 24 April 2013 (UTC)

I think I have fixed it, please update to version 0.9.116 and report back. Thanks, Cacycle (talk) 23:05, 26 April 2013 (UTC)
I'm going to cautiously say it looks like it's fixed. Thanks a lot! As I'm sure you noticed, this has been bothering me for several months, almost a year. -- tariqabjotu 07:57, 28 April 2013 (UTC)
I typed this line and then attempted to insert a ref with the cursor position just after this period -->. Not only did it add a space after the period, but it inserted the reference at the top of the buffer (instead of after the period and new space), in front of the section header (i.e. "<ref>blah...</ref>== Need help with whitespace issue =="). Version=0.9.116 G (April 26, 2013). —[AlanM1(talk)]— 19:43, 6 May 2013 (UTC)

wikEd bug report: Extra newline on replace[edit]

  • 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:, 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:
  • User/skin.js:
  • User/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)

Extra newline test section[edit]

Midwest Division W L PCT GB Home Road Div
y-Houston Rockets 55 27 .671 31-10 24–17 19-7
x-Utah Jazz 47 35 .573 8 28-13 19–22 16-10
x-San Antonio Spurs 49 33 .598 6 31-10 18–23 17-9

Undead MathJax-Related wikEd Bug[edit]

wikEd version:  0.9.115 (released on April 23rd, 2013)
Browser ID:  

Human-Readable Summary:  Safari 5.0.6 for Mac OS X 10.5.8 Leopard
Browser User Agent String:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/534.50.2 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.3

Enabled Browser Extensions:  

  • Cuss Off 1.1
  • Duplicate Tab Button 2.0
  • Middle-Click AutoScroll 1.04
  • Print Plus
  • Search Preview 1.2.3
  • Sessions
  • Tab Reloader 1.5.2
  • TabLock 1.1

Operating System:  Mac OS X 10.5.8 Leopard
Computer Model:  24-inch, Mid 2007 iMac (iMac7,1)
Wikipedia Skin:  Vector
User Scripts:  None Installed
Installed Gadgets:  

Site of Problem Occurrence:  

Wikipedia's Mathematics Reference Desk, specifically̌

Disabled Functionality:  

LaTeX code parser activation upon refresh of post preview

Reason for Addition for Bug Queue:  

Users requesting help on the mathematics reference desk need to be able to properly preview their posts before they finish submitting them.

Problem Description:  

wikEd's article-previewing functionality does not call MathJax upon its activation. The normal Wikipedia editor, which appears during a normal edit page's initial loading sequence, does; this would normally allow MathJax to parse any LaTeX code embedded in the article which one is currently editing upon first loading this article's edit page, but the normal Wikipedia source code editor doesn't have anything to preview when a user creates a new section.

Error Console Entries:  

None applicable to website code (all apply to installed extensions and disappear when I disable extensions through Safari's master switch in 'Preferences → Extensions')

Steps Necessary to Reproduce this Problem:

  1. Check your preferences to make sure that the following options are enabled:  
    • Preferences → Appearance → Math → '⊙ MathJax (experimental; best for most browsers)'
    • Preferences → Gadgets → Editing → '☑ wikEd, a full-featured integrated text editor for Firefox, Safari, and Google Chrome. Please read the help page for usage instructions.'
  2. Create a new article or section.
  3. Add some LaTeX markup to this article or section.
  4. Refresh the edit preview without saving your edits by clicking 'Preview.'
  5. Any embedded LaTeX will not render correctly.

Possible Leads:  None
— RandomDSdevel (talk) 17:36, 26 April 2013 (UTC)

It works for me under wikEd 0.9.116 (Firefox under Windows). BTW, for an automatic and concise bug report summary, please see the top of this page Cacycle (talk) 23:12, 26 April 2013 (UTC)
Sorry for not getting back to you right away, but I haven't been able to get to my computer over the past few days. Anyway, I can confidently state in response to your second sentence that I've tried to figure out the keyboard shortcut that you mentioned a couple of times in the past without success. Although I should really submit a second bug report for this, I thinks that I can safely summarize what might go into such a report by saying that that this might be a problem for me because I use a Mac. On such computers, Control - clicking (along with its Mouse Keys equivalents of either Function - ^ Ctrl - 5 on the row of number keys above the main section of the keyboard, or ^ Ctrl - 5 on the numeric keypad, or Function - ^ Ctrl - i, which are respectively available via the keyboard after you activate these said Mouse Keys – either via System Preferences's Universal Access preference pane or by rapidly pressing down the Option key five times – –depending on whether the type in use is a large desktop keyboard, a small desktop keyboard, or a laptop keyboard) is associated in OS X with the trigger that opens contextual menus. Similarly, holding down the Shift key or the Command key while clicking the primary (left) mouse button after selecting a single item allows users to select continuous and non-contiguous multiple selections, respectively. As you can now see, Mac users such as myself are in a bit of a pickle when it comes to the use of keyboard shortcuts here on Wikipedia. Sometimes Shift - {key press|Option}} works, though, and Wikipedia's instructions for using keyboard shortcuts tell those of us using Safari 4 or higher to use ^ Control - Option to activate them, so I'll try that next. I think that my previous filibuster, though, is enough of the tangent which it pursued, and I should really be discussing your first point with you. I'll purge both my local and server caches to see what happens, and then I'll report the results back to you.
See you later, 
RandomDSdevel (talk) 23:52, 30 April 2013 (UTC)
Okay, let me make a long story short by saying that none of your or Wikipedia's keyboard-mouse shortcut doo-hickeys work in my browwer when applied to the bug report button, but, again, that's for another bug report (oh, the irony!) Anyhow, I should probably also elaborate on your reply's first point by stating that the 'Preview' button should call MathJax whenever it's pressed…except that it doesn't! Oh, what am I going to do?
— RandomDSdevel (talk) 01:29, 2 May 2013 (UTC)

MathJax fixed in 0.9.117. Cacycle (talk) 19:25, 11 May 2013 (UTC)

Actually, that doesn't seem to be the case for me, Cacycle. I emptied the cache in my copy of Safari 5.0.6 and also purged the mathematics reference desk's server cache and didn't get any results from MathJax when I plopped the text that I wanted to see rendered into the wikEd text box. Going over to Safari's error console only provided me with a warning about how the generic picture of a person to the left of my username does not express the correct MIME type (it is 'image/svg+xml' but should, according to Safari 5.0.6, simply be 'image,' but this is most likely a consequence of the fact that my browser doesn't render pages with the latest version of WebKit –I really need to help my Dad finish migrating all six of the accounts on our family's computer to Mountain Lion, don't I? Moving along, I then decided to have Mac OS X 10.5.8 Leopard's version of Activity Monitor sample the pieces of Safari that were in my machine's memory because of how few were the results that Safari gave me. Doing so when I clicked the 'New section' tab at the top of the mathematics reference desk resulted in this text file, which I have made available for your inspection through my Google Drive. Similarly, the application produced this other text file, which I have also made available to you through that service, when I had it profile Safari while wikEd attempted to preview the results that my input text would generate. I will therefore probably have to switch over to using texvc until you can notify me that this bug has been fixed, but at this point I'm starting to wonder if there's a problem with either the extension or Live Preview, which doesn't really work anyway. I guess it's time to disable that and find out, eh?
Yours sincerely, 
RandomDSdevel (talk) 00:35, 15 May 2013 (UTC)
UPDATE: Yup, it was the live-previewing functionality (ugh…) — RandomDSdevel (talk) 17:16, 15 May 2013 (UTC)

New MathJax hook[edit]

He Cacycle, just would like to let you know that I added a $jquery method to the MediaWiki version of MathJax (so not Nageh's version), that can be used to postprocess DOM fragments with MathJax. It can be used like: $('#wikiPreview').renderTex(); Therefore this version now also no longer has the hack to trigger it from the preview mode of wikEd. It is not yet live, and will probably take a few weeks before it does go live. Also under development right now is a new hooks system to trigger these type of events automatically after a page has loaded bugzilla:30713. That means that in the future, you can trigger a new 'wikipage ready' event from wikEd and it will execute all the registered postprocessing hooks. So do expect some breakages on this front in the coming months and let us mediawiki devs know if something goes terribly wrong somewhere :D —TheDJ (talkcontribs) 08:26, 2 May 2013 (UTC)

It's about time that you guys figured this out! I reported this bug for Cacycle to fix only to have it break again! No wonder things got so messed up…oh, well; I guess you guys can just ping me when every thing's hunky-dory.
RandomDSdevel (talk) 16:37, 2 May 2013 (UTC)

Hi DJ, thanks for the note. I had already added that to the next version of wikEd. Please wait a few days until it gets online. Cacycle (talk) 20:58, 5 May 2013 (UTC)

Nuvola apps edu languages.svg
Hello, Cacycle. You have new messages at Wikipedia:Help desk.
Message added 22:08, 5 May 2013 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.
Um, sorry to intrude again, but…Cacycle, I have a problem with waiting for this to be fixed, just as I have mentioned at the bottom of the linked/talkbacked section.
Please take this into consideration, 
RandomDSdevel (talk) 22:08, 5 May 2013 (UTC)
P.S.:  Regardless of what's going on, I'm glad that you're back on Wikipedia to help everybody. I was starting to get worried about you; are you okay?

Fixed in 0.9.117. Cacycle (talk) 19:16, 11 May 2013 (UTC)


Nuvola apps edu languages.svg
Hello, Cacycle. You have new messages at Wikipedia:Village pump (technical).
Message added 22:19, 4 May 2013 (UTC). You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Not directly a talkback, but please add a comment. ;-) mabdul 22:21, 4 May 2013 (UTC)

Sorry for being too late... I do not think that such a library makes much sense as the existing tools are too specialized and different in their intended purposes. Developers can always check the workings and functionality of the existing code and have to adopt that to their own project. Cacycle (talk) 19:22, 11 May 2013 (UTC)

Feature request: display redlinks in red[edit]

Long time, no see. (Though I see/use "Ed" every time I log on to Wikipedia).

I spend a lot of time stripping redlinks from lists.

To do this, I have a viewing copy of the page I'm editing with WikEd open in another window, so I can see which items are red.

It would sure help if WikEd identified these by showing them in red directly in its editor window.

I look forward to your reply. The Transhumanist 02:47, 19 May 2013 (UTC)

I have added redlinking to wikEd 0.9.122a, thanks for the suggestion. 00:15, 15 December 2013 (UTC)
It is simply awesome. Works great. Thank you! The Transhumanist 03:24, 9 February 2014 (UTC)

Feature request: structured list sorting[edit]

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)

wikEd bug report (May 21)[edit]

Please give me links to such articles. Cacycle (talk) 20:07, 21 May 2013 (UTC)
I have a collapsed section on my talk page editnotice. It also occurs with the reviewer tools section on WT:AfC pages. I can try to get a screen capture too if you need. Technical 13 (talk) 20:28, 21 May 2013 (UTC)
I do neither see a simple fix for that nor any problems caused by the current behavior. Sorry, Cacycle (talk) 19:21, 23 May 2013 (UTC)
If you don't mind me asking, what is the code that you use to duplicate the notices in the first place? I'm trying to recreate "just" that piece in my vector skin so that I can create a patch/workaround that should work and test it. Technical 13 (talk) 18:29, 24 May 2013 (UTC)

WikEd for Commons?[edit]

What follows is copied from a thread I started on the Commons:Help desk.
Anyone have any further suggestions?

Is it possible (if so, how to?) use WikEd on Commons? I've started using it on en:Wikipedia and rather like it. The full screen mode is particularly nice with my old 1024x768 CRT monitors and I like the way it displays syntax highlighting. --Kevjonesin (talk) 13:38, 5 June 2013 (UTC)

You should add the following to your common.js :
Ruslik (talk) 19:18, 5 June 2013 (UTC)
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? --Kevjonesin (talk)
What do you mean by "icon or sidebar link"? Ruslik (talk) 18:45, 6 June 2013 (UTC)
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. --Kevjonesin (talk) 18:54, 7 June 2013 (UTC)

Where is the discussion archives search?[edit]

Is there an "archive search" field on this page that I'm not seeing for some reason? Or am I on the wrong page? I was going to search for the latest info about running this with an Opera browser on Ubuntu Linux. Thanks!  Grollτech (talk) 20:56, 18 June 2013 (UTC)

All discussions have been archived, please see the top of this page for the archived pages. Opera before version 15 is not compatible with wikEd. Since version 15, wikEd works just fine under Opera, unfortunately, they have not yet released a linux version above 15. Cacycle (talk) 16:14, 7 October 2013 (UTC)

Bug report: Double pasting[edit]

I noticed just today (so I imagine this is new) when I paste something within the edit box on a new line, the item gets pasted twice. An example of this is here and here. I copy the first line (using CMND+C), and paste it to the last line (using CMND+V), and I get the same text repeated twice. This seems to only occur in certain conditions as noted below:

  • This occurs regardless whether the item is copied from a source in the edit box or outside the edit box.
  • When the source text is unitalicized, this bug seems to occur if and only if it's pasted to a new line on its own.
  • When the source text is italicized, this bug seems to occur regardless of whether it's pasted to a new line or on a line with something else already. That behavior also exists regardless of whether you actually copy the single quotes that cause the italicization or not.

In other words, when I copy the word twice right here, I get "twicetwice". If I copy the word twice right here, I just get "twice". However, if I copy and paste the second, unitalicized instance of twice onto a new line, I get:


There are also a few other situations where the issue occurs, but I can't isolate the common factor. For example, if you look at Template:In the news and copy "Brétigny-sur-Orge derailment aftermath" (from the template embedded within the source of the page) and paste it either someplace there or someplace here, even if its on the same line as something else, you get "Brétigny-sur-Orge derailment aftermathBrétigny-sur-Orge derailment aftermath".

Anyway, that should give you an idea of what the problem is. As you request, here's some details about my computer and browsing:

  • WikEd version: 0.9.119g
  • Browser ID: Chrome v. 28.0.1500.71
  • User scripts: Prose size
  • Gadgets: Reference tooltips, Popups, GoogleTrans
  • Skin: Vector
  • Operating System: Mac OS 10.8.3

Let me know if you need more information. Thanks. -- tariqabjotu 15:59, 14 July 2013 (UTC)

This started happening to me today, shortly after I noticed that WikEd was coming and going on the page (appears and disappears with "Preview"). Firefox 22.0, Windows WP, Skin Modern. Scripts - Reflinks and DYK Check in toolbox. — Maile (talk) 21:50, 14 July 2013 (UTC)
The issue of wikEd coming and going was due to system problems with gadgets in general; there was lots of talk about this on Village Pump, with some editors blaming VisualEditor. Actually, this was one thing VE did not mess up. Chris the speller yack 01:19, 15 July 2013 (UTC)
I clicked the Gadgets box that removes VisualEditor from the interface. I still get the coming and going, so I guess that confirms what you are saying about it not being VisualEditor. — Maile (talk) 11:17, 15 July 2013 (UTC)

Oops, sorry for that. I have reverted to the last good version for now until I have figured this out. I do not see the problem under Firefox, so it might be Chrome related. Cacycle (talk) 06:26, 15 July 2013 (UTC)

As of this morning, I'm still getting the double pasting. — Maile (talk) 11:37, 15 July 2013 (UTC)

OK, I have fixed this Chrome-only bug in version 0.9.119a. Pasted text is now automatically [T]extified. For the formatted text, please push the undo button once. Cacycle (talk) 20:51, 17 July 2013 (UTC)

Then you only did a Chrome-only fix. Because I still get the double pasting in Firefox 22.0. I'll just unclick WikEd in the Gadgets and do without it. I'm still having issues I posted months ago that never got resolved. Too much trouble for me. — Maile (talk) 21:01, 17 July 2013 (UTC)
I am sorry to hear that. Have you updated (Shift-Reload) and use version 0.9.119b? Would you mind pasting a bug report here (See top of this page)? Thanks, Cacycle (talk) 07:04, 18 July 2013 (UTC)

Haven't done a bug report, yet, but please refer to Issues_remaining from January, and also what is posted below by Schweiwikist. I think the issues are related. Also, in regards to "issues remaining", how I've gotten around it in a rather clunky and time-consuming manner is to do a tap-tap-tap on the space bar, manually inserting spaces, then backspace into the (on my computer) gray area where the extra spaces are, and then doing in insert into that space. Quite time consuming. So, add that to what is happening now, and I'm not sure WikEd is much of a tool for my use. — Maile (talk) 16:25, 18 July 2013 (UTC)

Hi there![edit]

I’m getting the same behavior, by doing the following (it’s okay in Chrome) under Firefox 22 (Snow Leopard/Monobook—can’t figure out how to bring up the bug report form for you). Ready?

1. Open up a new user sandbox for editing.
2. Select only the template code {{User sandbox}}. It’s blue-black highlighted. But note that it was already wikEd highlighted.
3. copy or cut the selected text in the usual way (menu item or keystroke)
4. now move the insertion point to the end of the page code, i.e., at the end of: <!-- EDIT BELOW THIS LINE -->|
5. type a return to start a new line of code.
6. now Paste the copied or cut text snippet. the code {{User sandbox}} appears ONCE. So far so good.
7. Now Select All and DELETE all the code.
8. Now Paste again. This is when the double-paste occurs, with the extra paste wikEd-highlightEd.

At least this is a reproducable recipe where one way the bug doesn’t appear and the other way it does.
I first noticed this buglet when I was prepping my CE Cal pages for speedy-deletion, deleting all the page code and then pasting in {{Db-g7}}. Hope this helps.
----Schweiwikist (talk) 16:07, 18 July 2013 (UTC)

Oh, replacing the whole text or pasting into an empty area makes problems. I have reverted to the last good version for now. Please update by Shift-Reload. Cacycle (talk) 21:25, 21 July 2013 (UTC)
I thought maybe I had a keyboard bounce problem of some kind. I had the problem occasionally with Win7/Ffox20 in the last week or so – maybe 3 days ago the last time. It seemed to happen most often when insert-pasting a single-line template row at the top of the buffer. —[AlanM1(talk)]— 02:15, 25 July 2013 (UTC)

This has been fixed in the current wikEd 0.9.119c. Cacycle (talk) 12:53, 7 October 2013 (UTC)

WikEd gone for two days[edit]

As I posted on Village Pump yesterday, I had re-checked WikEd in my Preferences, intending to run some tests so I could input a Bug report above. And, yes, I've bypassed my cache several times. Firefox 22.0, Windows XP. My Error Console shows nothing. WikEd does not appear in my edit window. Not today, not yesterday. Anybody know what is going on with this? — Maile (talk) 11:55, 20 July 2013 (UTC)

Based on what you said above, I just did a Shift+Reload. I still don't have WikEd on my browser. Three days now. — Maile (talk) 21:29, 21 July 2013 (UTC)
if you see a tiny icon that looks like so: WikEd disabled.png to the right of "Log out" at the top of the page, try to click it. peace - קיפודנחש (aka kipod) (talk) 23:22, 24 July 2013 (UTC)
Well, for goodness sakes! That took care of it. I never knew about that. Thanks for posting. — Maile (talk) 23:37, 24 July 2013 (UTC)

Making scripts compatible with wikEd[edit]

The first method in this section does not work : I always have wikEdUseWikEd set (really, by window.wikEdUseWikEd = wikEd.useWikEd) to undefined. I used

if( window.wikEd && window.wikEd.useWikEd == true ) { WikEdUpdateTextarea(); }

This is working. I think it is simpler (it can be shorted into window.wikEd && window.wikEd.useWikEd), but there is a problem for the 'compatibility for older customizations' because you never update this value when it changes. — Ltrl G, 23:06, 30 July 2013 (UTC)

Thanks for bringing this up, I have updated that page and have added updating of wikEdUseWikEd to the code in version 0.9.119d. Cacycle (talk) 16:27, 7 October 2013 (UTC)

Bracket matching[edit]

It would be very nice to have bracket matching (especially for parser functions brackets).
I found this thread and tried the linked script but it didn't work.
Would it be much work to add bracket matching to wikEd?
Thanks. Britpoper (talk) 17:42, 9 August 2013 (UTC)

wikEd's syntax highlighting already marks wrong brackets for wikicode. It is actually not possible to have a general bracket matching because excluded passages (e.g. comments, strings, regular expressions...) will differ between target languages. Cacycle (talk) 12:49, 7 October 2013 (UTC)

Wikidata links to items and properties[edit]

Would it be possible to add two buttons to the toolbar. The first symbol adds brackets to an internal link. On Wikidata most people use a template to link to items and properties, which displays the number and the label for the link. The two links look like this {{q|123}} for an item and {{p|123}} for a property The two buttons should convert "Q123" into "{{Q|123}}" and "P123" into "{{P|123}}". Thanks a lot and keep up the excellent work. --Tobias1984 (talk) 07:23, 30 August 2013 (UTC)

Thanks for your suggestion. You would probably have to add these as custom buttons, please see User:Cacycle/wikEd customization#Custom buttons. Cacycle (talk) 12:43, 7 October 2013 (UTC)

wikEd bug report[edit]

[14:55:09.773] ReferenceError: reference to undefined property obj.from @
[14:56:23.181] ReferenceError: reference to undefined property wikEd.UseWikEd @
[14:56:23.252] ReferenceError: reference to undefined property openNode.firstChild @
[14:56:23.255] ReferenceError: reference to undefined property node.tag @
[14:56:23.376] ReferenceError: reference to undefined property a.start @
[14:56:28.093] Use of attributes' nodeValue attribute is deprecated. Use value instead. @
[14:56:29.172] SyntaxError: JSON.parse: unexpected character @
[14:57:06.364] ReferenceError: reference to undefined property this.originalResizeStyle @*:68
[14:57:16.272] SyntaxError: JSON.parse: unexpected character @
  • Problem description: Bugzilla:53914
  • Steps to reproduce: Having wikEd loaded on pages that are taken over by mw:Extension:CodeEditor has undesired results. The error console messages above are caused by toggling wikEd off and on and syntax highlighting off and on and CodeEditor off and on. The consensus on IRC and Bugzilla seems to be that wikEd shouldn't load on any page that CodeEditor loads on (.js .css and Module:) Technical 13 (talk) 19:05, 8 September 2013 (UTC)
Thanks, I have made wikEd compatible with CodeEditor in wikEd 0.9.119c. As long as the CodeEditor is turned off during page load, both can actually co-exist - just disable one before enabling the other. To turn off the CodeEditor during page load, un-click its [/*] button and reload or, alternatively, turn the CodeEditor off and click the wikEd logo (with an error message) on top of the page to activate wikEd. Also, I have fixed the JSON error.

German Translation[edit]

I suggest you transfer User:Matthias M./wikEd international de.js to someplace else so other people can edit it. I don't use wikEd anymore and won't update the translation, sorry. Matthias M. (talk) 14:41, 8 October 2013 (UTC)

Esperanto translation[edit]

Hallo. I suggest, that we use User:Tlustulimu/wikEd-eo.js for the Esperanto translation, because I can't edit User:ArnoLagrange/wikEd-eo.js and Arno is no more active here. Greetings --Tlustulimu (talk) 15:21, 8 October 2013 (UTC)

Thanks for translating this. I will rename that page to User:Tlustulimu/wikEd international eo.js and update the maintainer info and the code accordingly. Cacycle (talk) 17:28, 8 October 2013 (UTC)
I just put the translation from User:Tlustulimu/wikEd-eo.js into User:Tlustulimu/wikEd international eo.js and changed the list on User:Cacycle/wikEd international. Greetings --Tlustulimu (talk) 08:45, 9 October 2013 (UTC)

de * shifting maintenance of wikEd translation[edit]


today I have established

and fixed the first spelling error.

Greetings --PerfektesChaos (talk) 18:24, 15 October 2013 (UTC)

Thanks! I have updated all links to the German translation to your translation. Cacycle (talk) 20:38, 15 October 2013 (UTC)

use locally wikicode Image tag[edit]

Is it possible that "Add Image" button use "language specific wiki code" instead of "Image"? and use locally "thumb" keyword? שמוליק (talk) 22:18, 31 October 2013 (UTC)

As far as I an tell, wikEd's Image button Image adds translated code. I have also tested this with the wikEd gadget on the Hebrew Wikipedia and it works for me. Please could you give some more details (e.g. by filling out a bug report - simply Ctrl-push the Use wikEd)? Thanks, Cacycle (talk) 14:09, 20 November 2013 (UTC)

Wiked personalization[edit]

Hello, I want to personalize WikEd to do just syntaxhighlight. My script is here. I deleted WikEd toolbar but the problem is that when I click to save button my changes are not saved. Can you please help to detect the cause?. Thanks. Rabah201130 (talk) 14:24, 1 November 2013 (UTC)

I have foud the problem. Rabah201130 (talk) 13:21, 2 November 2013 (UTC)
You may want to try Dot's syntax highlighter instead. It only colors the background, but it does it in real time, while you are typing. --V111P (talk) 00:10, 3 November 2013 (UTC)

Whitespace stripped when copy-pasting in Firefox[edit]

Happens in Firefox 25, here's how to reproduce it:

  1. Edit an article (say Luka Modrić)
  2. Press Ctrl-A, Ctrl-C, Ctrl-V (select all, copy, paste)
  3. The contents of the article should be the same as before, but a click on the Changes button shows that repeated whitespace (e.g. in the infobox) has been stripped

This works fine in Chrome 30.0.1599.101, i.e. the text remains unchanged. My guess is that this is a bug in Firefox 25, I don't remember encountering the same problem in the earlier versions. GregorB (talk) 21:15, 9 November 2013 (UTC)

Sadly, unchanged in Firefox 25.0.1. GregorB (talk) 00:32, 16 November 2013 (UTC)
I have fixed this in wikEd 0.9.121. Thanks for reporting. Cacycle (talk) 13:49, 20 November 2013 (UTC)
Works fine in 0.9.121 G, thanks! GregorB (talk) 17:17, 20 November 2013 (UTC)

Resolved bug[edit]


It seems that the bug 587461 is resolved. So maybe we could retire it from the list. NB: it seems that we can't vote for the Webkit's bug (nor for the Chromium's bug?). Automatik (talk) 20:10, 5 December 2013 (UTC)

It seems to have landed in Firefox 26, when I checked with Firefox 24 or 25, I think it was still buggy. Thanks for bringing this up, I will remove it from the header box. On the Chromium bug tracker you have to be logged in and it is called "starring" instead of "voting". Cacycle (talk) 16:38, 16 December 2013 (UTC)

Updated Traditional Chinese translation[edit]

Hi, I noticed the Traditional Chinese translation hasn't seen an update in a while, so I've put up an updated one at User:Liflon/wikEd_international_zh-hant.js. Thanks. Liflon 14:20, 14 December 2013 (UTC)

Cool, thanks a lot! I have updated the documentation and the program (wikEd 0.9.122a). Cacycle (talk) 00:12, 15 December 2013 (UTC)

wikEd bug report: Error when deleting template[edit]

  • 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)

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)
  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)

"Replace all" is case-insensitive and ignores the case-sensitive button[edit]

Fixed in 0.9.122c, please update with Shift-Reload. Thanks, for reporting, Cacycle (talk) 16:26, 16 December 2013 (UTC)

internal “redlinks”[edit]

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)

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)
Meanwhile I have collected one more case: subpage ups and downs.
To keep the overview: No target check in the following special cases
  • # fragment
  • (page title itself, might be superfluous when accessing # fragment)
  • /subpage (ignore or needs to be resolved for full title)
  • ../traversing (ignore or needs to be resolved for full title)
  • /^(file|image|datei|bild):/i namespace 6
  • :interwiki (already implemented, as far as I took it from the colours)
Successful 2014 --PerfektesChaos (talk) 19:21, 9 January 2014 (UTC)

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)

wikEd for Ukrainian (and Russian language)[edit]

I installed "wikEd" to the browser Mozilla Firefox v.27 (by dint of "Greasespot"), editing articles in Ukrainian (and Russian) Wikipedia. But I work so hard - English interface. Help me please. I am from city Kiev (Ukraine). Regards --Krupski Oleg (talk) 22:46, 22 December 2013 (UTC)

Unfortunately, we do not yet have an Ukrainian translation. Please see User:Cacycle/wikEd_international for how to create one - maybe you know somebody who could do that? Cacycle (talk) 18:20, 1 January 2014 (UTC)

WikEd in French[edit]

I use wikED on wikipedia and wikibooks in french. All the words are underlined in red and when I right click, English words are available for correction. How to configure Wiked for spelling on French. Thank you in advance. Gtaf (talk) 02:10, 5 January 2014 (UTC)

Hi Gtaf, spell checking is done by the browser itself, not by wikEd or a web page. You might have to install a French-specific dictionary add-on. Good luck, Cacycle (talk) 19:14, 6 January 2014 (UTC)
Thanks Cacycle. It's changed. Gtaf (talk) 18:45, 8 January 2014 (UTC)


I am offering a prize for a fix to WikEd. Have posted the issue here [4]. The problem occur with google chrome latest version. Unable to copy and paste colors across with Firefox. Let me know if you are interested. Else will offer to a wider community. Great program by the way. Doc James(talk · contribs ·email) (if I write on your page reply on mine) 11:58, 30 January 2014 (UTC)

Another issue is that WikEd does not work well with the cite tool in the top of the edit box. An extra space occurs after you insert a citation. Doc James (talk · contribs · email) (if I write on your page reply on mine) 12:09, 30 January 2014 (UTC)

Any word on this yet? Doc James (talk · contribs · email) (if I write on your page reply on mine) 18:02, 24 February 2014 (UTC)

This is actually an already known bug in Chrome, please see Chrome bug 318925. It is not specific to wikEd, it also affects CodeEditor and VisualEditor. Please feel free to comment on their bug tracker or "star" that bug. Cacycle (talk) 14:59, 3 March 2014 (UTC)
So how to fix it? I am offering a $200 award. Doc James (talk · contribs · email) (if I write on your page reply on mine) 23:19, 5 March 2014 (UTC)

WikEd conflicts with code editor[edit]

Note: Ctrl-click on the wikEd logo does not seem to do anything in this case.

  • wikEd version - enabled via Preferences, so assumed to be latest
  • Browser: Pentadactyl hg6978 (created 2013/12/20 00:00:04) running on: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0
  • OS: Linux Mint 13 Maya, Linux 3.2.0-23-generic i686 GNU/Linux
  • Skin: Vector default, custom CSS disabled
  • No custom JS
  • I have a lot of gadgets enabled. If there are any specific ones that might cause this interference, I can try disabling them.

This bug is best illustrated by a screenshot:

As you can see, the editing text area is completely missing. When wikEd is disabled, it returns:

Disabling the code editor doesn't seem to do anything:

Attys (talk) 01:25, 4 February 2014 (UTC)

This is actually a problem with the signaling mechanism of CodeEditor, please see bug 62250. Please see the bug report below for more details. Cacycle (talk) 10:16, 5 March 2014 (UTC)

wikEd bug report: Edit box doesn't appear on CSS pages[edit]

  • Date: 2014-02-04 20:22:16 UTC
  • wikEd version: 0.9.122c G (December 16, 2013)
  • Browser: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 (Win32)
  • Browser: Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0 (Win32)
  • Browser: Mozilla/5.0 (Windows NT 6.2; rv:26.0) Gecko/20100101 Firefox/26.0 (Win32)
  • Skin: monobook (detected: monobook)
  • MediaWiki: 1.23wmf11
  • Gadgets: Gadget-removeAccessKeys.js, Gadget-searchFocus.js, Gadget-popups.js, Gadget-HideFundraisingNotice.js, Gadget-wikEd.js, Gadget-addsection-plus.js
  • MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbarBase.js, RefToolbarNoDialogs.js
  • Scripts:, User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js, User:Pilaf/include/instaview.js
  • URL:
  • User/skin.js:
  • User/common.js:
  • Error console: Nothing of note. (event.returnValue is deprecated. Please use the standard event.preventDefault() instead.)
  • Problem description: I have no edit text box on my custom CSS pages. It appears briefly as the page loads, but then disappears. This is not just a Chrome problem, as I also tried in Firefox 26. I also was sure to disable adblock.
    • Oddly enough, the problem goes away after I activate the JS preview and then Ctrl-F5 on the page. (Ctrl-F5 alone does not fix the problem.)
  • Steps to reproduce: Open a custom CSS page while WikEd is enabled.

— trlkly 20:44, 4 February 2014 (UTC)

I confirm the problem. Also when we modify .js pages and pages in module name space. Hunsu (talk) 11:20, 8 February 2014 (UTC)
Cacycle might know but did not yet make use of: There is a rather new wgPageContentModel which tells that a page is css or javascript. Iff it is wikitext wikEd should start working, otherwise quit. See (in German) de:Wikipedia:Technik/MediaWiki #Content Model. Greetings --PerfektesChaos (talk) 20:37, 11 February 2014 (UTC)
This is actually a problem with the signaling mechanism of CodeEditor, please see bug 62250. wikEd already uses wgPageContentModel, but in the absence of a conflicting editor, wikEd can handle css and js pages just fine. Cacycle (talk) 10:14, 5 March 2014 (UTC)

How does WikEd detect redlinks?[edit]

Thank you for adding the redlink display feature. It is very helpful. Damn nice addition to WikEd functionality.

By the way, I'm working on a script in which I need to detect redlinks.

How do you do it in WikEd?

I look forward to your reply. The Transhumanist 03:50, 9 February 2014 (UTC)

You may take a look at the functions wikEd.LinkInfoCall and wikEd.LinkInfoHandler. Hunsu (talk) 10:44, 9 February 2014 (UTC)
Yep. These functions collect all links and make an AJAX API call. Cacycle (talk) 09:15, 5 March 2014 (UTC)

wikiEd conflicts with new WikiEditor interface[edit]

Current WikiEditor interface without wikiEd

Please see the actual wikiEd footer. You see that it conflicts with already existing layout, I mean breaking the copywarn text and chopping the background gray panel. This layout conflict is uncomfortable to me (and some others). Here's a mockup how it should look. What do you think about it? --Rezonansowy (talkcontribs) 14:51, 22 February 2014 (UTC)

@Cacycle: You're the main dev, could take a look a this please? --Rezonansowy (talkcontribs) 11:21, 24 February 2014 (UTC)

Bump! @Cacycle: or anyone? --Rezonansowy (talkcontribs) 10:42, 5 March 2014 (UTC)

Already working on this cosmetic problem... Cacycle (talk) 10:50, 5 March 2014 (UTC)
@Cacycle: Thank you, please see my mockup. --Rezonansowy (talkcontribs) 12:15, 7 March 2014 (UTC)
Fixed in 0.9.124. Cacycle (talk) 18:58, 7 March 2014 (UTC)
How nice, thank you! --Rezonansowy (talkcontribs) 09:36, 8 March 2014 (UTC)

wikEd bug report: Error while loading, no content visible[edit]

  • Date: 2014-02-25 14:26:08 UTC
  • wikEd version: 0.9.122c GM (December 16, 2013)
  • Browser: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Linux i686 on x86_64). This is Aurora
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.23wmf14
  • Gadgets: None
  • MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js, RefToolbarBase.js, RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
  • Scripts:
  • URL:
  • User/skin.js: (==> as reported with Ctrl + Click, this page actually doesn't exist)
  • User/common.js: (==> as reported with Ctrl + Click, this page actually doesn't exist)
  • Error console: [Exception... "The operation is insecure." code: "18" nsresult: "0x80530012 (SecurityError)" location: "<unknown>"]
  • Problem description: When switching to Edit mode, the textarea is empty, the editor toolbar doesn't appear and the WikEd icon (upper right corner) is covered with a red cross. The Title icon's attribute contains Loading error - wikEd 0.9.122c GM (December 16, 2013) Click to disable
  • Steps to reproduce: With Firefox Aurora 29.0a2 (2014-02-22), any MediaWiki edition page. This problem doesn't appear with Chromium (ver. 32.0.1700.107) on the same machine. — Preceding unsigned comment added by Benoitb (talkcontribs) 14:38, 25 February 2014 (UTC)
This has been fixed in wikEd version 0.9.123. Thanks for reporting. Cacycle (talk) 19:56, 4 March 2014 (UTC)

wikEd bug report: Spaces deleted after making replace all[edit]

  • 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:, 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:
  • User/skin.js:
  • User/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).
Screen capture showing WikiEd bug

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

Moved from [5]. MER-C 10:35, 26 February 2014 (UTC)
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)
How can I replace all the occurrences of a word without using that button? Hunsu (talk) 21:58, 5 March 2014 (UTC)
Sorry, I misread your report. I will check into it. Cacycle (talk) 13:13, 7 March 2014 (UTC)

Possible bug[edit]

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)

Syntax highlight doesn't work on protected pages[edit]

See for example this. --Rezonansowy (talkcontribs) 13:41, 8 March 2014 (UTC)

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)
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)

"Save (minor edit)" button would be nice[edit]

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)

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)
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)
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)

When previewing, screen now jumps down to edit window[edit]

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)

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)

Could this page have an archive?[edit]

It's becoming very long. --Rezonansowy (talkcontribs) 22:50, 13 March 2014 (UTC)

There are links to 13 archives near the top of this page. But another archive would be good, I agree. this shows that Cacycle has been manually archiving the page and adding an index. Anyone could set up automatic archiving by one of the common bots and add a search field, as has been requested in a thread above, provided they're familiar with the auto-archivers. I could give it a shot, but it would take me a while to figure out how to get right (so that the old and new archives were compatible...). Any volunteers? Any objection, Cacycle? --Elvey (talk) 23:37, 27 March 2014 (UTC)
Since this page doubles as a bug tracking system, I prefer to archive the fixed issues manually from time to time and to keep the open issues here. Cacycle (talk) 21:36, 28 March 2014 (UTC)
Ok. I'm going to add a search field; feel free to improve/revert...--Elvey (talk) 06:14, 1 April 2014 (UTC)

s vs del[edit]

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)

Non-breaking space chars – ways of preserving?[edit]

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 &nbsp; entities (inside the pre-filter code before passing markup to the editor)
    • and optionally replace all &nbsp; 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)

Curly apostrophes vs. typewriter apostrophes[edit]

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)