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.
Please Ctrl-click the wikEd logo ( on top of the page) or the wikEd button () 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:
wikEd version. Does the bug persist if you update to the latest version 0.9.155 (November 5, 2017) with Shift-Reload or Ctrl-Shift-R.
Gadgets that you have checked in your preferences. Optional: What happens if you disable these gadgets.
Web address (URL) of the page or wiki installation where you experience your problems
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!
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:
If a cell is all bold, give it header style.
If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
If the variable wikEdWikifyTableHeaderCol = true then header-ize first column
I like #1 the best, but of course this is your wikEd invention!
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)[reply]
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! Reywas92Talk00:31, 24 May 2009 (UTC)[reply]
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)[reply]
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)[reply]
On this website : http://fr.nvcwiki.com 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.
wikEd is overwriting user customization (I give also an solution)
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:
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(){wikEd.InitObject({26:['b',66],// wikify(...)32:['g',71]// scrolltoedit, overwrites previous wikEd buttons for same key},wikEd.config.buttonKey);};
Req: Sort (and normalize?) list entries contained in a single line
Hi! I've got a feature request for you. Hope it hasn't been up for discussion before (boy was that ToC long – didn't dare to cast an eye on the archives too..!) Sometimes, in navboxes for instances, there are lists contained in a single table cell (e.g., Template:Beta blockers, delimited by various methods involving a bullet. Could you make the sort function sort these single-line lists somehow?
Also, if possible, normalization would be neat to ensure that the method used for separating the entries (I guess " • " is the most common version) is consistent for a given line. Sometimes there is a bullet first on the line, where it's not supposed to be, sometimes people forget the or add double spaces after the item, etc. Sometimes this can make editing the list a minor nightmare.
For now, I sorted the Template:Beta blockers by replacing the bullet stuff with newlines, opening up another WikEd tab and sorted the newly-created lines, then re-replaced the newlines with the bullet goo and pasted back in the first tab. Not so practical. :) W n C? 11:35, 23 February 2011 (UTC)[reply]
A workaround is to replace "• " with "•\n" (regex mode) then sort it afterward undo the replacement. Now I've been asked to add extra sort method (sort by last name, date, link title) to Dab solver, it would be nice to have a more powerful sorting interface. — Dispenser04:25, 2 March 2011 (UTC)[reply]
Oddly, single-line sorting doesn't seem to work for me now anymore (Safari 5.0.5, OS X 10.6.7). It just seems to mess around with the whitespace. Tried it on Template:Peripheral vasodilators. Doesn't help if I replace the • with e.g. {{•}}, either (though I do think WikEd could clean the ampersand mess up though, but maybe that's just wishful thinking. ;) ). W n C? 12:55, 16 June 2011 (UTC)[reply]
Extra line is inserted with regular expression replacement function if text ends a line
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. Christhe spelleryack19:00, 8 March 2011 (UTC)[reply]
Just to let you know that this is still a problem, and it effectively stopped me from cleaning up an article with a very long list. I can let the article wait, or do a whole lot of deleting lines by hand. Christhe spelleryack00:34, 25 June 2011 (UTC)[reply]
I omit this bug by adding "\n" at the end of the RegExp "Find" field and at the end of the "Replace" field. But it works only if You know and want to find expressions at the end of line. If that expressions are not only at the end You can add (\n?) to "Find" field and $1 (in the simpliest case) to "Replace" field. BUT: that doesn't changes the fact that I'd love that bug to be removed... q;) Vinne2 (talk) 19:10, 13 August 2011 (UTC)[reply]
The problem still persists and is rather annoying... However, while this doesn't work right in Firefox 23.0.1, there is no problem in Chrome 29.0.1547.57. GregorB (talk) 14:22, 21 August 2013 (UTC)[reply]
Making scripts compatible with wikEd
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)[reply]
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)[reply]
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)[reply]
I got the same problem too, my MW version is 1.16.2. These two editor just work fine in zh.wikipedia.org(1.17) but not in my wiki. here is a Screenshot of the broken editor http://easycaptures.com/fs/uploaded/387/0939602272.png
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
You can chose the textarea size in your wiki preferences, wikEd keeps the default size. You can also use the fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)[reply]
Is it possible to calculate the text area height depending on the window height? it seems this should be already happening in
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
Hello! I'm using the WikEd, which is integrated into the German Wikipedia on Firefox 4.0 and Windows XP. I know the following two problems:
When I remove a term which is framed by ''', the cursor will skip the last '''.
The cursor also sometimes skips an entire line, after removing a term, which is framed by square brackets for instance.
I experience the same bug in the English Wikipedia. It is easily reproducible. Access the article Ermine_Street and try removing words out of any tag letter by letter. See what happens. --Aetas volat. (talk) 09:16, 29 April 2011 (UTC)[reply]
I will try if I can fix the first problen (it's a really tricky one). The second one seems to be a strange Firefox bug. Cacycle (talk) 21:19, 8 May 2011 (UTC)[reply]
JS errors in IE 8
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]);
and
Error: Object doesn't support this property or method
javascript&smaxage=21600&maxage=86400, line 15547 character 4
domElement['wikEd' + eventType + eventHandler](eventRootElement.event);
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)[reply]
wikEd version: 0.9.99 G; browser: Firefox 6.0; no JS errors in the console; skin: Vector; addons and other scripts: several, but problem persists when they are all disabled.
When I edit the page Template:Navbox with columns (unprotected copy at User:Ucucha/sandbox), a few empty comments get removed before I make any change to the wikitext. See the revert here. This can be reproduced by editing the page and clicking "Show changes"; it will show that these two comments are removed. This no longer happens when I disable wikEd and it does happen when I disable all other scripts and browser add-ons I have. Ucucha (talk) 23:17, 22 August 2011 (UTC)[reply]
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)[reply]
Tabbing
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)[reply]
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! 76.172.107.173 (talk) 17:52, 30 January 2012 (UTC)[reply]
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)[reply]
Hello, when I copy text from MS Word 2010 or 2007, and then when i publish it, this sentence : Normal 0 21 false false false FR X-NONE AR-SA apperas on the top of my text. You can see that here
Little search & replace bugs in regual expression mode
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.
When replacing text at the end of the line in Regular Expression mode, an extra new line is inserted after the replacement.
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
What exactly does the "fix dashes" function do? It doesn't seem to do much of anything related to dashes (for example it doesn't change spaced hyphens to spaced en dashes). It does, however, make totally unnecessary and annoying whitespace changes. Is its function supposed to be at all similar to dashes.js? —danhash (talk) 15:01, 10 April 2012 (UTC)[reply]
Currently, it does the following:
convert html character entities into actual dash characters
remove spaces around em dashes
convert -- to em dashes
convert hyphen next to lone number into a minus sign character
convert hyphen next to lone number into a minus sign character
This means "-([0-9]+)" → "−$1" (in regex, ignoring the quotes), right?
convert minus or en dashes to dashes with spaces
Does this mean "([^ ])[−–]" → "$1 –" and "[−–]([^ ])" → "– $1" (i.e. "dashes" means "en-dashes")? If so, the first replacement should have a " " instead of a space (0x20) per the MOS. Also, unspaced en-dashes are appropriate for some ranges of dates and other numbers.
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:
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)[reply]
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)[reply]
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)[reply]
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:
Timestamp: 8/16/2012 11:56:04 AM
Error: TypeError: parseObj.tree[openNodeIndex] is undefined
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)[reply]
wikEd is unable to close the old edit toolbar on Wikia
I tried wikEd 0.9.105 Deutsch in http://de.memory-alpha.org which does not use Wikias GUI editor. The skin is called "Wikias new look" = Wikia.js/css. Pushing the close editing toolbar button has no effect. I am using Firefox 15.0.1 on Linux. It works on Wikias monobook. Matthias M. (talk) 12:41, 6 October 2012 (UTC)[reply]
Installation problem
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)[reply]
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)[reply]
Issues remaining
I've been doing some editing, and the two remaining issues below are, I'm guessing, really just a variation of one problem - that pasting into the Edit Window inserts either an extra space, or a line break. All the other issues above seem to have been resolved. — Maile (talk) 21:25, 17 December 2012 (UTC)[reply]
1) Inserting into a table or into an Infobox - either Paste insertion, Toolbar link insertion, Toolbar Template citation insert - inserts a line break to the left of it, placing the insertion between the left-hand margin and the pipe character that begins the next entry space on the line below where it was supposed to insert
2) Inserting a citation into the body text from the drop-down "Templates" selection on the toolbar inserts an extra blank space to the left of the insertion. It doesn't matter which cite template is inserted.
3) Inserting a citation from the drop-down Template on the toolbar Instead of inserting where my pointer is, clicking the "Insert" button causes it to jump to the top of the section, in the margin to the left of section header, and inserts the citation there
Adding #3 today. Mentioned in above sections as one of the original issues, but I've only again used the feature with regularity in the last few days. — Maile (talk) 13:31, 6 January 2013 (UTC)[reply]
wikEd & Narayam compatibility
Hi Cacycle, I am an admin on gu.wiki 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?-- DhavalTalk08:46, 5 January 2013 (UTC)[reply]
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)[reply]
How to get and set the cursor/selection positions?
Hi, Cacycle. I was wondering, is it not possible to make UpdateTextarea() and UpdateFrame() to also update the cursor/selection position? Then everyone would be able to create user scripts compatible with WikEd. Is there any way at all to get the cursor/selection position (in number of characters from the start of the text - like with selectionStart/End in the normal textarea) in WikEd? --V111P (talk) 00:01, 15 January 2013 (UTC)[reply]
Wikidata Template German
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)[reply]
Special char gallery inserts into article editor, not edit summary or subject line, despite focus
Below the article editing area (selected with Alt-Shift-G) is the standard gallery of special characters and wiki markup codes that can normally (without WikEd enabled) be clicked on to insert those characters at the current cursor position. However, with WikEd enabled, the insertion always occurs in the last position of the cursor in the article editing area, even if the cursor is currently in the Subject/headline or Edit summary textboxes. This occurs on Win7Home, FireFox 15.0.1. —[AlanM1(talk)]— 08:24, 29 January 2013 (UTC)[reply]
Automatic replacement
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)[reply]
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)[reply]
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:
Enable WikEd on Wikinews.
Create a new user talk page.
Add "{{subst:Welcome}}" to it, click WikEd's preview, click save.
You will get a message that you have tried to edit the Main page.
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();});
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)[reply]
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. http://blog.wikimedia.de/2013/03/27/you-can-have-all-the-data/ My JavaScript is a bit dusty, but I could help out. Wakebrdkid (talk) 19:28, 29 March 2013 (UTC)[reply]
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: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
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: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
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: http://en.pathofexilewiki.com/wiki/User:Nightblade/common.js
Line: 13
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)[reply]
wikEd bug report (improper whitespace added)
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)
<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 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)[reply]
Improper space inserted in front of references
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)
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.
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)[reply]
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:
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.
Begin editing an article or section.
Add some LaTeX markup to this article or section if none already exists.
Refresh the edit preview without saving your edits by clicking 'Preview.'
Any embedded LaTeX will not render correctly.
Possible Leads:
BugzillaBug 35478: Remove support for WikEd and ajaxPreview from ext.math.mathjax.enabler.js
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)[reply]
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.
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)[reply]
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 ()?
Do you see it with wikEd disabled ( button above edit area inactive)?
Do you see it with highlighting disabled ( button inactive)?
Do you see it with [REF] and [TEMPL] hiding on as well as off ( 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):
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)[reply]
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. -- tariqabjotu07:57, 28 April 2013 (UTC)[reply]
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)[reply]
wikEd bug report: Extra newline on replace
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)
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.
Click the "Find ahead as you type" button (with the binoculars on it) if necessary to the "unchecked" state.
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.
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).
Click the "Find next match" button, which should highlight "1992-93 NBA..."
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "31-10" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "19-7" should be highlighted.
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.
Click the "Find next match" button. "28-13" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "16-10" should be highlighted.
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".
Click the "Find next match" button. "31-10" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "17-9" should be highlighted.
Click the "Replace next match" button. In addition to replacing the hyphen, it incorrectly inserts a newline before the 17.
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:
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.'
Create a new article or section.
Add some LaTeX markup to this article or section.
Refresh the edit preview without saving your edits by clicking 'Preview.'
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)[reply]
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 Accesspreference 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.
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?
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 Safari5.0.6, simply be 'image,' but this is most likely a consequence of the fact that my browser doesn't renderpages 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?
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 (talk • contribs) 08:26, 2 May 2013 (UTC)[reply]
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.
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)[reply]
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.
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)[reply]
Feature request: display redlinks in red
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.
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.
Problem description: links to expand collapsed sections in #wikEdClonedWarnings duplicated editnotices reloads the page (sends to #top at least) and sections refuse to expand. The section at the top of the page will expand, but is useless due to its distance from the editbox. Perhaps the script that creates the #wikEdClonedWarnings duplicated editnotice could also .remove() the section on the top of the page eliminating this problem? Technical 13 (talk) 18:41, 21 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
WikEd for Commons?
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)[reply]
I've added it to User:Kevjonesin/common.js but I haven't seen any icon or sidebar link show up (even after refreshing my page cache). How do I activate/access it? --Kevjonesin (talk)
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)[reply]
Where is the discussion archives search?
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)[reply]
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)[reply]
Bug report: Double pasting
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:
"twicetwice"
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:
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)[reply]
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. Christhe spelleryack01:19, 15 July 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Hi there!
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)[reply]
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)[reply]
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)[reply]
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)[reply]
The first method in this section does not work : I always have wikEdUseWikEd set (really, by window.wikEdUseWikEd = wikEd.useWikEd) to undefined. I used
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. — LtrlG☎, 23:06, 30 July 2013 (UTC)[reply]
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)[reply]
Bracket matching
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)[reply]
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)[reply]
Wikidata links to items and properties
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)[reply]
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)[reply]
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.
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)[reply]
As far as I an tell, wikEd's Image button 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 )? Thanks, Cacycle (talk) 14:09, 20 November 2013 (UTC)[reply]
Wiked personalization
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)[reply]
Press Ctrl-A, Ctrl-C, Ctrl-V (select all, copy, paste)
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)[reply]
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)[reply]
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)[reply]
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.
Hi Hunsu, I cannot replicate your problems deleting "{{fi}} ". Please could you give me step-by-step instructions? Also, I am not sure what you mean by highlighting vs. undo/redo. wikEd does not implement any undo/redo, it just highlights in a way that is compatible with the browser's built-in undo/redo functionality. If you want an alternative highlighter, you could use the still experimental VisualEditor (Wikipedia references) or User:Remember the dot/Syntax highlighter (both are not compatible with wikEd). Cacycle (talk) 15:24, 16 December 2013 (UTC)[reply]
Put the cursor just before {{lien web
Use the delete button to delete {{fi}} (space included)
When you click on delete button you delete the space (normal) but the second time you click on delete button you don't delete } but instead you delete the \n between {{Lien web and | url. Why the cursor jumped there?
How do you tested it?
For the request I have thought that WikEd implements its own undo/redo so I suggested to choose between automatic highlighting and undo/redo. Hunsu (talk) 19:09, 17 December 2013 (UTC)[reply]
"Replace all" is case-insensitive and ignores the case-sensitive button
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)[reply]
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)[reply]
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)[reply]
Thanks Cacycle. It's changed.
Hello Cacycle, Gtaf has smiled at you! Smiles promote WikiLove and hopefully this one has made your day better. Spread the WikiLove by smiling at someone else, whether it be someone you have had disagreements with in the past or a good friend. Go on, smile! Cheers, and happy editing! Smile at others by adding {{subst:Smile}} to their talk page with a friendly message.
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
How does WikEd detect redlinks?
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.
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: ____ (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: ____ (Please include what happens at each step. Your problems cannot be fixed without reproducing them first!)
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 (talk • contribs) 14:51, 22 February 2014 (UTC)[reply]
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 (talk • contribs) 14:38, 25 February 2014 (UTC)[reply]
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).
I consider this a feature, not a bug. The spaces at the beginning of the line are not required and not part of any style recommendation. The button is specifically made to clean out unnecessary spaces. If you want to keep those spaces, you have to use the button only on selections around that section. Cacycle (talk) 09:11, 5 March 2014 (UTC)[reply]
I noted a problem (insertion of the signature at the wrong location here at VPT. User:Technical 13 asked a good question; when I removed wikEd the problem disappeared, when I reinstalled it the problem reappeared. Needless to say (no not needless, so I will say it) I love having the capabilities of WikEd, so I don't want to remove it, but I would like to have the ability to paste text, and add a signature using the icon. It only happens with Firefox. --S Philbrick(Talk)00:31, 28 February 2014 (UTC)[reply]
Syntax highlight doesn't work on protected pages
Debug info
Date: 2014-02-22 14:26:12 UTC
wikEd version: 0.9.122c G (December 16, 2013)
Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 (Win32)
Works fine for me - maybe it is related to one of your other scripts? Please could you complete the bug report (especially relevant error console messages)? Thanks, Cacycle (talk) 09:29, 9 March 2014 (UTC)[reply]
Cacycle, try looking at it from a non-admin account. Syntax highlighting only works for me when I have edit rights for the page; e.g. it doesn't work on protected pages here on Wikipedia, but it does work on protected pages on Wookieepedia, where I have admin rights. However, before I was promoted to admin at Wookieepedia, it didn't work there either. Here's my debug info from the example page cited by Rezonansowy:
jcgoble3's debug info
Date: 2014-03-13 21:23:17 UTC
wikEd version: 0.9.124a GM (March 08, 2014)
Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Win32)
(P.S. The error report form is out of date, because Firefox no longer has an "Error console" option under "Web Developer"; it is now called "Browser Console".) jcgoble3 (talk) 21:30, 13 March 2014 (UTC)[reply]
"Save (minor edit)" button would be nice
Minor edits are a bit of a hassle to save. You have to select "minor edit", then either click save or click focus back to the edit summary and hit return (since selecting the checkbox takes focus away, at least for me.)
A button to "Save page (minor edit)" or similar would simplify things, rather than requiring multiple steps.
Can this be done with a custom button instead? I guess I could figure out how to make JavaScript set the minor-edit flag and then save, but that doesn't seem like a great way to do it. E4FZq (talk) 02:09, 12 March 2014 (UTC)[reply]
Actually, hitting Enter/Return with focus on the minor edit checkbox also submits the form (the same applies to the watch page checkbox). I use that shortcut all the time by typing in my edit summary and hitting Tab-Tab-Space-Enter (I need two tabs to get to the minor edit box, since I use User:Svick/SectionInput.js, which, when combined with wikEd, inserts its section box between the wikEd summary box and the minor edit checkbox in the tab order; you would probably only need one tab.) jcgoble3 (talk) 02:30, 13 March 2014 (UTC)[reply]
Also, Alt-Shift-i focuses and toggles that box. Maybe I could add a persistent lock feature to that checkbox (e.g. triggered by Shift-click)... Cacycle (talk) 10:36, 13 March 2014 (UTC)[reply]
Tab-space-enter does work for me. Thanks! (In fact, now I remember using that in the past. I think it stopped working at some point from a browser or OS bug, and I forgot I could do that.) Ctrl-alt-i works too. Safari doesn't focus the checkbox if I do click on it, so I still need to go back to the keyboard if I click, but it focuses it doing either of the above so I can hit return. More of a browser problem than a wikEd problem, obviously... You also need "All controls" selected in the Shortcuts tab of the Keyboard prefpane on OS X to focus things like checkboxes at all, which I already had but isn't the default.
A persistent lock would definitely be useful for doing lots of minor edits in a row or for people who mostly do minor edits. (Especially since it seems like the pref for doing that disappeared at some point, but maybe I'm wrong on that.) E4FZq (talk) 15:55, 13 March 2014 (UTC)[reply]
When previewing, screen now jumps down to edit window
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, Miniapolis21:34, 13 March 2014 (UTC)[reply]
It seems that strike is being deprecated in some circles in favor of delete. Cacycle, how do you feel about the change (which I don't like, FYI) and changing WikEd to go along with it? The tag s is 9.1 times as popular as del. (911% more popular in marketingspeak; 5,840,886 for <s> vs 641,205 for <del> using Special:Search) --Elvey (talk) 01:12, 20 March 2014 (UTC) (edited)[reply]
Non-breaking space chars – ways of preserving?
Hi Cacycle. We've encountered a problem with wikEd's NBSP→SP replacement on skwiki recently. We don't have that "use HTML entity" policy like here on enwiki and literal character form is preferred, so it's quite serious issue – editors using wikEd (as a gadget opt-in available in user prefs) are just silently crippling articles, containing non-breaking spaces (between numbers and units, around range dashes, inside dates, between prepositions and words, and so on...).
I understand, that there are design issues with full NBSP char support, as you've stated several times here. But anyway, I can imagine a better workaround alternatives, than current "silent" replacement by plain spaces:
to replace them by entities (inside the pre-filter code before passing markup to the editor)
and optionally replace all back into literal chars in post-filter (an opt-in for environments where literal form is preferred)
to replace them by some macro markup, that will be displayed and preserved by wikEd and substed back into NBSP chars on saving
on top of the page) or the wikEd button (
What it looks like
What it should look like
fullscreen mode which is a persisting setting. Cacycle (talk) 07:03, 6 May 2011 (UTC)
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)
)?
button above edit area inactive)?
button inactive)?![[REF, TEMPL]](/media/wikipedia/commons/0/0b/WikEd_ref_hide.png)
active as well as inactive)?
![[REF, TEMPL]](/wiki/File:WikEd_ref_hide.png?lang=en){kind=small}
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)
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 
Resolved