User talk:Cacycle/wikEd/Archive 013

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Problems with fix html

In "fix html" () I found two issues

  • tables don't inherit attributes (example <table class=wikitable> doesn't turn into {|class=wikitable)
  • when converting, it converts new lines into <br /> in some tags like pre and math, causing malfunctions (try for example here; after fixing html, substitution <br /> -> \n gives the correct conversion) --93.47.29.46 (talk) 13:37, 18 August 2009 (UTC)
Finally fixed in 0.9.109! Have converted Help:Displaying a formula to wiki style. Cacycle (talk) 18:25, 4 January 2013 (UTC)

Inserting/deleting newlines spuriosly 2 (bugreport)

Here you go. ~ Boro (talk) 09:42, 12 August 2010 (UTC)

Hopefully fixed in 0.9.91k, please could you verify this? Thanks everybody for reporting and insisting on this :-) Cacycle (talk) 21:55, 15 August 2010 (UTC)
Could not reproduce the steps from the section above (Chrome 5.0.375.126/Win 7), so it looks like it's finally fixed! GregorB (talk) 07:27, 18 August 2010 (UTC)
However, it appears that newlines do creep in in some situations, i'll try to construct a test case. GregorB (talk) 10:15, 18 August 2010 (UTC)
It's a variation of the earlier test case:
  1. Open e.g. this page in a new tab.
  2. Type #<Enter>#<Enter>#<Enter>
  3. Click on "Preview" (or on Textify).
  4. "#" characters from the step 2 are now separated by empty lines Not any more, this has been fixed
  5. Add the fourth "#" in the last line, directly below the third "#" in the edit window
  6. Click on "Preview"
  7. The third and fourth "#" are separated by an empty line. GregorB (talk) 11:37, 18 August 2010 (UTC)

I hope I could fix it in 0.9.91m. Cacycle (talk) 00:25, 22 August 2010 (UTC)

Cannot reproduce this in the new Google Chrome 6.0.472.53. Might be considered fixed. GregorB (talk) 22:23, 4 September 2010 (UTC)
  • I've been consistently having this problem up until even today when using wikEd 0.9.100b G (September 17, 2011) in Chrome 14.0.835.202 and Vector and OS X. Test case is Military career of Hugo Chávez. Clicked edit tab, selected all text, then clicked the "Convert pasted content to plain text ..." button. Editor then inserted one newline after each paragraph.
  • Further, wikEd mysteriously deletes a space before every [[, {{, and '' (there may be others in this list) that happen to be butted along the left-hand margin. If I use Firefox, no space-deletion or newline-addition issues, but wikEd becomes horrendously slow--dilatory cursor updates, general GUI flakiness, etc.
  • Is there a pertinent thread for the latter issue? Otherwise, thanks for the great work. Saravask 09:48, 12 October 2011 (UTC)

Links in diff link to template

Safari 5.0.2 (6533.18.5). The wiki-links in the diff link to the template of that link, so if the diff has [[Joss Whedon]] and I click it I go to [[Template:Joss Whedon]]. Templates aren't clickable at all, so this doesn't work at all, which would be extremely helpful. c Not sure when it started acting this way, maybe a week or so ago. Any thoughts?

Also, quick diff (Is that the name?) and quick preview haven't worked for a long time, I think since Safari 5. Thanks. Xeworlebi (talk) 17:07, 18 October 2010 (UTC)

Will check, but it will take a while. Safari 5 seems to have several issues. Cacycle (talk) 20:49, 19 October 2010 (UTC)
Mostly fixed in 0.9.95c, still working on wikEdDiff for Safari 5... Thanks for reporting, Cacycle (talk) 23:06, 1 November 2010 (UTC)
Thanks. Xeworlebi (talk) 12:37, 2 November 2010 (UTC)

InputBox retargets edit form


Edit this page with the above InputBox element

  1. Quick preview
  2. Click Save/Show Changes/Show Preview (keep the preview open)

Now you'll land on the inputbox specified page. This is because of the "title" field in the inputbox. Tested in Firefox 3.6.15 Windows XP. — Dispenser 17:42, 21 March 2011 (UTC)

This happens to me often and is very annoying. Usually I can click the back button and resubmit and it works fine, but this should be fixed. —danhash (talk) 18:21, 30 January 2012 (UTC)

Google Chrome

Google Chrome does not work. Version may be due. I'm using version 12.0.712.0 Beta.--Ğaaw (talk) 10:12, 23 April 2011 (UTC)

The latest version, 0.9.99, failed on Google Chrome 12.0.742.100 with MediaWiki 1.15.5-3 on Ubuntu Natty 11.04 64 bit and on Google Chrome (version unknown) with MediaWiki version 1.16 (I think) on Windows XP 32 bit. However, version 0.9.91o dated Aug 23, 2010 works on the Ubuntu setup. I won't know until tomorrow if it works on the XP setup. See the previous versions for the download link. --216.210.84.195 (talk) 04:00, 30 June 2011 (UTC)
I confirm this, latest working version is the one from Aug 23, 2010 on Chromium (15.0.861.0 (Developer Build 97968) Built on Ubuntu 10.10). -- Trinevahepttinette (talk) 09:23, 27 August 2011 (UTC)

Font sizes and memory usage

There are two big disadvantages I find to using wikEd: memory usage in Firefox and font sizes.

  • Memory usage: one load of wikEd after some WP browsing, especially long pages, can take up 100+ MB of RAM. Several more edits can easily push the memory usage of Firefox over 550 MB, and by the time it reaches 820 MB, the browser is sluggish to the point of inusability. Restarts of the browser fix the situation, but it's very inconvenient.
    • User Note: doesn’t seem to be a problem under OS X Lion/Firefox 6 beta. Opening multiple edit windows on the entire Barack Obama article did push up RAM allocation to FF6 past 800MB (and slow things down), but memory was released once the edit windows were closed (back down to ≈525MB [still a hefty chunk]). The buglet described below, and the solution below it, still do apply on this platform, however. —Schweiwikist (talk) 10:37, 8 August 2011 (UTC)
  • Font sizes: This is probably a very common complaint, but when you try and paste texts from a page title or level 1 heading, it appears as a large font size and with breaks before and after. The easy way of getting rid of the breaks involves placing the cursor after the last character of normal text and pressing "delete". But it does not work in every case and one must sometimes undo and press backspace from before the first large character. Is this one of those Firefox bugs or what? Pasting of most other text results in unhighlighted but properly sized text, which I think is perfectly acceptable.

Can you please investigate these bugs? — Train2104 (talk • contribs • count) 02:25, 25 July 2011 (UTC)

For the font size, issue, I click the "[T]" button ("Convert pasted content to plain text, update highlighting"). It works every time. Chris the speller yack 13:16, 25 July 2011 (UTC)

New Wiki Look Compatibility

Is there any way to use WikEd as a userscript with the new Wiki look (Oasis I belive)? --Pichu659 (talk) 10:59, 26 September 2011 (UTC)

Sig Button

This is probably the only feature to be added with WikEd. On user talk pages its annoying to have to toggle between the standard toolbar and wiked only. --Kangaroopowah 22:21, 23 October 2011 (UTC)

Cannot get wikEd to display at all. Followed instructions, but still no dice.

I've installed the extension completely on my site. I'm trying to set it site wide. I've added the lines to the localsettings file, added all of the .js pages to my install. Tried it both as a gadget, and as a full local install. No dice either way.

Anyone care to take a look, I'd be happy to provide you access. I'm just not sure what I'm missing. --Fadmwheeler (talk) 03:46, 22 November 2011 (UTC)

Please could fill out the bug form (see top of the page)? Please feel free to send me your site's details using the E-mail this user page. Cacycle (talk) 13:35, 26 November 2011 (UTC)
WikEd version is the latest version. I've tried this is IE 9, Firefox, Chrome, and Safari to no avail. (I am a coder myself, so I generally verify which platforms will function for my users). No errors, the addin just doesn't load at all, it's like it's ignoring the commands all together. No browser add-ons except Java. No affect if i disable the add-ons. Using Pixeled skin, although i've tried it in MonoBook and Vector as well to no avail. (We have moved some items in CSS in pixeled, so i understand it wont look EXACTLY the same, but we have tried it in the out of the box monobook and vector styles as well. Using Windows XP and Windows 7, no change in either. The problem is simple, the script just doesn't load. There is no evidence that it is ever taking affect. I have e-mailed you my site information. I appreciate your help! Fadmwheeler (talk) 15:24, 27 November 2011 (UTC)
Your problems are caused by 1) the semicolon at the end of line 21 in your MediaWiki:Common.js (see your error console) and 2) by the Pixelated skin (I have added support for it to the next release going online soon). Cacycle (talk) 23:32, 13 December 2011 (UTC)
It should work now, please update your copy of wikEd to version 0.9.102 (January 03, 2012) (or, even better, load wikEd from its official page so that you get updates automatically). Cacycle (talk) 11:45, 4 January 2012 (UTC)
Cacycle - thank you so much it does in fact work now! (talk) — Preceding unsigned comment added by 99.118.198.202 (talk) 05:22, 7 January 2012 (UTC)

window.wikEdUseWikEd is undefined

window.wikEdUseWikEd is undefined even when WikEd is on, so old scripts can't detect WikEd and some of the examples in WikEd's documentation don't work. (Firefox 6 & Chrome 15, Windows OS, wikEd 0.9.101, Vector skin.) --V111P (talk) 04:00, 2 December 2011 (UTC)

Please could you provide more details? Why exactly do you think that window.wikEdUseWikEd is undefined? Please also provide details about your system and configurations (see the top of the page for the bug report form). Which examples do not work? Cacycle (talk) 19:10, 3 January 2012 (UTC)
I can confirm that this is a bug in the current version of wikEd. My script is no longer working correctly with wikEd because it tests this variable per the guidance, and it is undefined. My script worked with previous versions of wikEd. —GregU (talk) 21:03, 16 February 2012 (UTC)

Insertion of special characters fails

I'm using wikiEd as a gadget in ro.wp and en.wp on Firefox 7. I've noticed that if I try to insert a character from the new Vector toolbar, it only works on the first click. On subsequent clicks, the cursor jumps around, but nothing else happens. Debugging with Firebug, it would seem that everything goes ok until the execCommand('insertHtml'), which for some reason fails. If I disable wikiEd, everything goes back to normal. Has anyone else seen this behavior?--Strainu (talk) 08:23, 17 December 2011 (UTC)

Fixed in wikEd 0.9.102 (January 03, 2012), thanks for reporting. Cacycle (talk) 19:06, 3 January 2012 (UTC)

How can I disable thumbs within syntax highlighting?

When syntax highlighting is enabled, thumbs of used images are shown within the text editor window. This is confusing and buggy (tiny images are repeated to fill a certain width). How can I dsiable those thumbs while keeping normal syntax highlighting? --Subfader (talk) 15:22, 30 December 2011 (UTC)

Images are only repeated when the image size parameter is not set (e.g. instead of ). It is not exactly a bug as there is no other way to implement this without knowing the image size. In order to turn image preview off, you might try

wikEdConfig = { 'filePreview': false };. See User:Cacycle/wikEd customization for details. Cacycle (talk) 19:18, 3 January 2012 (UTC)

Thanks a lot that worked :) --Subfader (talk) 19:04, 4 January 2012 (UTC)

wikEdDiff and Special:ComparePages

Just letting you know that wikEdDiff explodes when using it on Special:ComparePages. →Στc. 04:50, 16 January 2012 (UTC)

Please could you give me enough infos to replicate this (please see the top of the page for a bug report form)? Thanks, Cacycle (talk) 23:06, 23 January 2012 (UTC)

Convert MS Word to Wiki?

I've read several times that wikEd can convert text from MS Word, but I can't see how? — Preceding unsigned comment added by Subfader (talk • contribs) 12:40, 17 January 2012 (UTC)

Copy from Word, paste into the editing area, and push the wikify button Wikify. Please see the User:Cacycle/wikEd help for more background. Cacycle (talk) 07:38, 23 January 2012 (UTC)

Whitespace "fixing"

Is there a way to move all whitespace "fixes" and changes of any kind to a separate function which does not run unless explicitly invoked? The AWB RegEx function in particular is pretty much useless if it screws around with whitespace in addition to the useful RegEx fixes. In instances where the RegExTypoFixer rules may manipulate whitespace, perhaps all edits that would have been made could be ignored if they only affect whitespace. Other functions such as "fix html to wikicode" are very annoying to use with all the unnecessary whitespace editing. I end up selecting small areas and running the tool on them individually, which is tedious and annoying. AutoEd and other automated tools work with whitespace too and often end up undoing each other's edits (for example, spaces in between headings and equal signs). —danhash (talk) 16:15, 26 January 2012 (UTC)

These whitespaces make articles much easier to read, so I do not really see a reason not to add them (unless the implementation should be buggy and adds spaces where they are not supposed to be). Cacycle (talk) 16:59, 28 January 2012 (UTC)
See here and here for examples of how script-based whitespace edits can cause problems and scripts can step on top of each other with needless edits. This isn't the only problem though—very often when I use one of wikEd's "fixes", numerous newlines are inserted. I believe there are at least 2 or 3 separate sources of the unwanted whitespace addition/removal issue:
  • Extra newlines are often inserted when editing a page. One example where this happens to me almost every time is on this user page. Typically I click edit, place the cursor at the beginning of the bulletted list, hit enter, and create a new line. When I hit [W], most of the time a newline is added after the line I just created (even if I don't click [W], the line shows up when I save the page or preview). This sounds similar to the "Inserting/deleting newlines spuriosly 2 (bugreport)" section also on this page. I actually just experienced this issue again, when previewing this edit.
  • Often, regular copy/paste edits remove newlines, leaving two words mashed together. This bug is not always apparent until re-reading a section and noticing grammar errors where there were none before. This is particularly annoying when copying content from one page to another (for example for archiving a talk page) where a regular diff will not show the error.
  • The word wrap feature seems to have a bug that causes the removal of spaces when editing lines of text.
  • When using the "fixes" I often just apply the fix to a small section of a page that I manually highlight, because using fixes (especially on a large page) often making unintended (and very annoying) unnecessary whitespace (and newline) changes. Even if some of this extra whitespace "should" be there, if I want to add it, I should be able to choose to do so via a separate function, separate from other fixing functions. For example, if I was going to apply these whitespace "fixes", I would do so as the last step of editing a page. Often it takes a succession of fixes and various edits to clean up a page, and screwing with whitespace every step of the way introduces more problems and annoyances than it fixes. Also, if I am editing a talk page, I have no intention to "fix" the whole page by changing the posts of numerous other editors. The presence or absence of whitespace in the source in and around headings is a style/MOS issue and is not something that should be forced on users by a user script.
To conclude: 1. whitespace should not be changed by a script unless that script is asked to do so, and 2. there are some bugs in wikEd's handling of whitespace. —danhash (talk) 15:31, 30 January 2012 (UTC)
The "newlines added by [W]" issue may be a result of a misinterpretation on my part of what the button is supposed to do. I believe that most circumstances where I have been clicking [W], I should have been clicking [T], since my intention is to end up with plain text, disregarding any formatting that has been pasted. —danhash (talk) 14:29, 2 February 2012 (UTC)

Show source button

No matter what I do I can't get the show source button () to show up. I've tried my current common.js in Firefox and Chrome; am I doing something wrong? —danhash (talk) 18:50, 26 January 2012 (UTC)

Got it. The variable name is "showSourceButton", not "wikEdShowSourceButton". —danhash (talk) 18:58, 26 January 2012 (UTC)
Seems like a number of settings in the documentation are listed as "wikEd*" instead of "wikEdConfig.*". —danhash (talk) 19:12, 26 January 2012 (UTC)

Wiked + Firefox = "_moz_dirty" + "empty font"

Follow up to User talk:Cacycle/wikEd/Archive 011#Some bugs in WikEd 0.9.99 and Firefox 5

  • Does it still do this in Firefox 6? Please could you give me an example of pasted text where this happens?

A lot of such issues active even in FF10.

Demo:

  • Results:
<font>'''''77777'''''</font>
3333333

name="cutid1" _moz_dirty=""[1:27:18] 44444444

[1:57:48] 2222

Annoying issues:

  • " _moz_dirty" crap
  • empty tags "font"

Please, give some ideas how to fix it (submit bugs to FF? may be regexp heuristics after wikifying? …) --StasFomin (talk) 16:57, 2 February 2012 (UTC)

I will fix this in wikEd as soon as I find the time. Cacycle (talk) 00:07, 4 February 2012 (UTC)
It was a stupid bug and has been fixed in the upcoming version. Cacycle (talk) 15:28, 4 February 2012 (UTC)


wikiEd replaces the non breaking space (U+00A0) character with space (U+0020)

  • wikiEd version: latest (the one from this page)
  • browser: Some version of Firefox, the user would not say. I was able to reproduce it using FF9.0.1 on Windows.
  • skin: Monobook (is reproducible also using Vector)
  • problem description: when editing a page containing non-breaking space characters (for instance ro:Lista_monumentelor_istorice_din_România/Alba), wikiEd replaces character U+00A0 with character U+0020, creating incorrect line separations.
  • workarounds: disable wikiEd :)--Strainu (talk) 21:30, 6 February 2012 (UTC)
This is a complicated and difficult issue. The general consensus was that the only reliable, transparent, and safe way to use non-breaking spaces in articles is the character entity &nbsp; instead of the actual character. Cacycle (talk) 08:12, 10 February 2012 (UTC)
That is in en.wp and does not apply to other projects. :) I second the suggestion made above to prevent any automatic whitespace change.--Strainu (talk) 22:02, 10 February 2012 (UTC)
The en:wp guideline exists because it is technically as well as from the editing side not possible to reliably preserve non-breaking spaces. It is definitely not possible in wikEd without some major design changes. This has been discussed in depth and repeatedly, e.g on Wikipedia:Village_pump_(technical) (check the archives). Sorry, Cacycle (talk) 13:18, 11 February 2012 (UTC)

Dup: Non breakable spaces (Alt+0160) are automatically changed to normal spaces

wikEd 0.9.102 G (Jan 03 2012), Chrome 18.0.1025.39 beta-m, I believe there are no console errors, addons do not interrupt, skin vector... anything else? :)

When typing the Alt+0160 shortcut it inserts non-breakable space (NBSP). But when editing in wikEd it saves it as normal space everytime when:

  • you hit Save,
  • you hit Preview (and you do not have the dynamic one turned on),
  • you hit Changes,
  • you switch from wikEd to normal text area during editing.

That causes every NBSP between a number and unit (e.g. "40 mph") be changed to normal space allowing word wrap there. Yes, we can write &nbsp; there but that's ugly and hard to understand for newbies that'll try to edit an article or correct one value. Vinne2 (talk) 23:48, 26 February 2012 (UTC)

Please see the section "wikiEd replaces the non breaking space (U+00A0) character with space (U+0020)" above, a recent discussion of the same thing. Chris the speller yack 01:05, 27 February 2012 (UTC)
Merged the threads. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contribs. 12:25, 27 February 2012 (UTC)

Reusing User:Cacycle/diff.js

Hi, thanks for your work. I am going to use it in commons:MediaWiki:VisualFileChange.js for the regexp-replace-examination. That's all. -- Rillke (talk) 16:44, 13 February 2012 (UTC)

Great! Let me know if you have any questions or suggestions! Cacycle (talk) 07:53, 14 February 2012 (UTC)ps://bugzilla.mozilla.org/show_bug.cgi?id=724241 bug 724241] and it is currently being resolved. Cacycle (talk) 07:48, 14 February 2012 (UTC)
After nearly 8 months, it doesn't look like it's being fixed; looks like it's been passed around and forgotten. I just reinstalled Firefox 10 15, and it's unacceptable. Now I have to go back to Firefox 9 again, and other websites are barking about the old release. I'm afraid I will soon be forced to use Firefox 10 15, and that will be the end of my ability to use wikEd. Are other wikEd users not seeing this problem, or are they just showing more patience than I am? Chris the speller yack 19:07, 7 October 2012 (UTC)
Mozilla have marked this as fixed in August 2012, so it may not be released yet. You can try downloading and Firefox 16(Beta is quite stable) but I suspect it's not working until Firefox 17. Regards, Sun Creator(talk) 19:58, 7 October 2012 (UTC)
I just installed Firefox 18.0.2, and the situation is slightly better. If a wikEd find is done, the selected text shows up blurry, but repeat finds work OK. So I can just move the cursor back to the beginning of the page and repeat the find, a slight annoyance. If I use the Firefox Find bar, though, any selected text inside the edit box still shows up blurry. I think a large part of this bug was missed by Mozilla, but maybe there is something that can be done on the wikEd side. I would appreciate your looking into it again. I do use the Firefox Find bar heavily, because I can use it to zoom around the page without flushing valuable entries from the wikEd Find and Replace drop-down lists. I doubt that I will retreat to Firefox 9 again, instead limping along with this slightly better version. Wow, what Mozilla can accomplish in just short of a year! Chris the speller yack 21:51, 11 February 2013 (UTC)

An utterly fatal flaw - loses state and flushes all changes if you navigate away and back in same window

Well, wikEd is superlatively badass, but I can't use it. It's already cost me hours and hours of work because of the way I edit. For years, I've always recycled the same editing window to move back and forth between things while editing. E.g., I might be editing an article and inserting a template and forget what a parameter is called, and edit the URL bar to go the template documentation, then hit "Back" to finish editing the article, and remember something I saw earlier and hit "Back" 5 times to go copy it, then "Forward" 5 times to get back to editing and paste that in and save all these changes. This is impossible for me (Firefox 10.0.2, Mac OS X 10.7 Lion), because all changes made in the editing window are flushed if you navigate away and back, when wikEd is running. Practically makes me cry (not just for the lost work, but because I've been waiting for years for something like wikEd and was very excited about it). — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contribs. 12:23, 27 February 2012 (UTC)

This bug is caused by another script, please see bug 22680. Cacycle (talk) 22:07, 24 March 2012 (UTC)
I have this same problem on Wikia in the Monobook skin. My JS page is here. jcgoble3 (talk) 23:59, 24 March 2012 (UTC)

Very slow to load

With WikiEd 0.9.102G, the edit page takes about 10 seconds to load on my fast computer. The edit page loads the text, then adds syntax highlighting, and finally the WikiEd toolbar loads. Is there any way to speed this up? Here's my info:

Windows 7 x64 Home Premium

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0

WikiEd 0.9.102G My Monobook skin

--Yutsi Talk/ Contributions 15:49, 28 February 2012 (UTC)

Inserting characters from the Vector toolbar

Suddenly all the vector toolbar buttons appear to have stopped working. If I click on any of them then rather than appear here in the edit box they appear in the section subject/heading box, if I opened the page using new section, or don't appear at all if I opened the page any other way. I can only use the buttons with wikEd toggled off which is a bit of a bind. And now the edit window is pointing out spelling errors which I don't recall before. Great for plain text, a bugger for code and markup. I'm running wikEd 0.9.102 GM (I get the same problem using 0.9.102 G with Greasemonkey switched off), Firefox 9.0.1, Windows 7 (64bit), Vector skin NtheP (talk) 16:56, 1 March 2012 (UTC)

All seems to be resolved today. Perhaps my laptop had a 24 hour bug? NtheP (talk) 12:46, 2 March 2012 (UTC)

Problem editing refs since MediaWiki upgrade.

Since the latest MediaWiki upgrade, it appears that WikiEd is preventing me from editing any refs. If I try to edit a page, instead of the detailed citation, I just see a grey button labelled "ref". There is no way to display or edit the ref itself. I blanked and reinstalled my vector.js page, and found that deleting WikiEd resolves the problem. I don't know what version I was using, but I tried reinstalling through the Gadgets menu, and the problem recurred. I edit using Firefox 10.0.0.2. I've posted a screenshot here of the problem. RolandR (talk) 22:16, 1 March 2012 (UTC)

See User:Cacycle/wikEd_help#wikEd_control_buttons, first row of the table. jcgoble3 (talk) 22:37, 1 March 2012 (UTC)
OK thanks. So something in the upgrade altered the default setting for this, since I certainly changed nothing since it was working last night. RolandR (talk) 22:55, 1 March 2012 (UTC)y for gadget authors]] to use. Please check it out and post any questions or comments there. -- ☠MarkAHershberger☢(talk)☣ 01:02, 9 March 2012 (UTC)

insertTags fails on empty textareas

WikEd's insertTags() fails on empty textareas. It happens mostly on Special:Upload, as the textarea in edit page mode always contains "\n".

The following patch fixes it: 

Index: WikEd.js
===================================================================
--- WikEd.js	(revision 1623)
+++ WikEd.js	(working copy)
@@ -9651,6 +9651,8 @@
 //
 
 wikEd.FindBoundaries = function(word, line, para, whole, selection) {
+	if (!whole.plainArray.length)
+		return;
 
 	// get the start node and offset
 	var startNode = selection.range.startContainer;
Has been fixed meanwhile. Cacycle (talk) 10:48, 20 May 2013 (UTC)

Quotation characters

Across the quick insert bar, or whatever it's called, I'm concerned about the inclusion of these ‘single’ and these “double” accents, and being able to surround words with one-click whilst the 'single' or "double" straight quotation marks do not, they only appear one at a time. Per MOS:PUNCT:

Quotation characters
Do not use grave and acute accents or backticks (`text´) as quotation marks (or as apostrophes).
There are two possible methods for rendering quotation marks at Wikipedia (that is, the glyphs, displayed with emphasis here, for clarity):
  • Typewriter or straight style: "text", 'text'. Recommended at Wikipedia.
  • Typographic or curly style: “text”, ‘text’. Not recommended at Wikipedia.
The exclusive use of straight quotation marks and apostrophes (see preceding section) is recommended.

I come across a lot of articles using the non-recommended style, grave and curly quotations and am quick to copy-edit. Perhaps this part of wikEd should be designed to default to, and encourage, the use of straight style characters also, to help editors out in this matter?

Ma®©usBritish [talk] 09:12, 1 September 2011 (UTC)

Now that you brought it to my attention, it gives me the willies, too. And those glyphs following the degree sign are not double and single straight quotation marks, but double and single primes, I think. I agree that it would be helpful to have the surround ability for the straight form of single quotation marks and, especially, double quotation marks. It would be very, very helpful for articles with lots of song titles. I once wrote my own custom button for this, but it soon caused problems. Chris the speller yack 14:55, 1 September 2011 (UTC)
Oh, yes now I look closely, yes they are primes.. for feet and inches, mins and secs etc 5′11″ vs 5"11' doesn't look much different in the edit box unless you squint. Still, would still help to have the inset bar with "' before ‘’“”°″′, as you say, they're a pest on pages with albums, or edited by people where English characters are not their first language and the insert bar looks convenient to use. Ma®©usBritish [talk] 22:18, 1 September 2011 (UTC)

wikEd has nothing to do with that - wiked is only the grey button bars. Cacycle (talk) 19:55, 3 September 2011 (UTC)

Sorry, just re-read the request. Yes, this sounds like a good idea for a fixing butten and should be relatively easy to implement. I will try to add this as soon as I find some time. Cacycle (talk) 07:15, 7 September 2011 (UTC)


Disable Pasting of Rich-text

I sort of asked this once before, but it bears repeating: Is there a way to disable rich-text pastes from being pasted as rich text? Currently, whenever I want to paste into the edit box I first paste into my search bar, then copy that text and paste it into the wikiEd editor. This method removes any formatting. Or I paste into Notepad, then copy, then paste into wikiEd. This is a huge pain. Is there anyway to make all pastes act as plain text? I only use wikiEd for its syntax highlighting as it is, and having this paste method I've devised is a bit of a hassle. --Odie5533 (talk) 11:23, 17 September 2011 (UTC)

Unfortunately not because this is done by the browser, not by wikEd. There is no reliable way for JavaScripts to intercept these events. I know it is a major annoyance. Cacycle (talk) 16:30, 17 September 2011 (UTC)
Perhaps an option to automatically remove the highlighting by pressing [T] after a user performs a paste, and then return to the right cursor position? Currently pressing [T] selects all. --Odie5533 (talk) 22:59, 17 September 2011 (UTC)
Please see also User:Cacycle/wikEd help#Automatic syntax highlighting for more details. Cacycle (talk) 19:29, 18 September 2011 (UTC)
You could add a "Plain-text pasting" text input field to the WikEd toolbar. Pasting text into it would automatically insert that text at the cursor position (or replace the selected text) in the text area. It could be done as a text input field above WikEd through a user script, but it would be nicer if it is a built-in function. --V111P (talk) 03:49, 24 December 2011 (UTC)
Ok, apparently you can use Shift+Ctrl+V to paste as plain text in Firefox and Chrome. Chrome even has an option "Paste as plain text" in its right-click context menu. --V111P (talk) 02:41, 25 December 2011 (UTC)

Firefox 10.0.x/Windows issue - Blurry text when normal text is selected

A few days ago the highlighting of selected normal text suddenly changed, from normal white characters on a blue background to extra bold, fuzzy white on a blue background, making the text nearly impossible to read. Text that is already highlighted (e.g. lists, templates, images) is still the normal white characters on a blue background when selected. The selection can be manually done or as the result of a search. I'm willing to swear on a stack of dictionaries that I haven't changed anything on my end. I don't think I have upgraded Firefox (10.0.1) recently. I am running Windows Vista Home Premium, Service Pack 2. Is anyone else having this problem? Chris the speller yack 22:50, 13 February 2012 (UTC)

I'm not seeing this. I'm running the same OS with Firefox 9.0.1. It might be a Firefox 10.0.1 issue; 10.0.1 was just released this past Friday (and 10.0 is barely two weeks old). jcgoble3 (talk) 23:18, 13 February 2012 (UTC)
Thanks for the info. I guess I wasn't paying much attention to Mozilla; maybe I have trusted them too much. I went back to 10.0.0 and that didn't help. I am trying to find 9.0.1 from a site that doesn't jam a lot of malware onto my browsers. Will report back. Chris the speller yack 01:19, 14 February 2012 (UTC)
Here's the grim news: I don't see the problem with Firefox 9.0.1, so it appears to be a Firefox 10.0.0 issue, and 10.0.1 does not fix it. I am going to adjust the name of this section to put the blame square on the new version. — Preceding unsigned comment added by Chris the speller (talk • contribs)
I am not seeing this in Firefox 10.0.0 or 10.0.1 (just updated) on Mac OS X 10.5.8. Ucucha (talk) 01:49, 14 February 2012 (UTC)
Alright, then it sounds like the problem is limited to Windows as well. Added to the header. jcgoble3 (talk) 02:17, 14 February 2012 (UTC)

This is a change/bug introduced with Firefox 10. I have already filed a bug report a few days ago, see bug 721750 and bug 724241 and it is currently being resolved. Cacycle (talk) 07:48, 14 February 2012 (UTC)

After nearly 8 months, it doesn't look like it's being fixed; looks like it's been passed around and forgotten. I just reinstalled Firefox 10 15, and it's unacceptable. Now I have to go back to Firefox 9 again, and other websites are barking about the old release. I'm afraid I will soon be forced to use Firefox 10 15, and that will be the end of my ability to use wikEd. Are other wikEd users not seeing this problem, or are they just showing more patience than I am? Chris the speller yack 19:07, 7 October 2012 (UTC)
Mozilla have marked this as fixed in August 2012, so it may not be released yet. You can try downloading and Firefox 16(Beta is quite stable) but I suspect it's not working until Firefox 17. Regards, Sun Creator(talk) 19:58, 7 October 2012 (UTC)
I just installed Firefox 18.0.2, and the situation is slightly better. If a wikEd find is done, the selected text shows up blurry, but repeat finds work OK. So I can just move the cursor back to the beginning of the page and repeat the find, a slight annoyance. If I use the Firefox Find bar, though, any selected text inside the edit box still shows up blurry. I think a large part of this bug was missed by Mozilla, but maybe there is something that can be done on the wikEd side. I would appreciate your looking into it again. I do use the Firefox Find bar heavily, because I can use it to zoom around the page without flushing valuable entries from the wikEd Find and Replace drop-down lists. I doubt that I will retreat to Firefox 9 again, instead limping along with this slightly better version. Wow, what Mozilla can accomplish in just short of a year! Chris the speller yack 21:51, 11 February 2013 (UTC)

Documentation for gadget authors

We're trying to start a library for gadget authors to use. Please check it out and post any questions or comments there. -- ☠MarkAHershberger☢(talk)☣ 01:02, 9 March 2012 (UTC)

Template unhiding doesn't work

With 0.9.102 (FF 10.0.2 Ubuntu, Monobook), if you have template (and char entity) hiding turned on with the "R" icon, it doesn't unhide when you click or mouseover the template box. I have fixed this by going back to 0.9.101 by installing the development version (by adding importScript('User:Cacycle/wikEd_dev.js'); to my common.js). Also, you might want to update all your documentation to refer to common.js, rather than monobook.js, etc.
On an unrelated note, sortable tables don't appear as sortable in WikEd's previews; but it's not your fault, as they don't appear in Wikipedia's built-in preview. Hgrosser (talk) 17:06, 11 March 2012 (UTC)

Problem with processing OSed diffs

Hi, you might want to take a look at the discussion at mediazilla:35153. Thanks. It Is Me Here t / c 17:56, 18 March 2012 (UTC)

User script listings cleanup project

I'm leaving this message for known script authors and recent contributors to Wikipedia:WikiProject User scripts/Scripts.

This scripts listing page is in dire need of cleanup. To facilitate this, I've created a new draft listing at Wikipedia:WikiProject User scripts/Scripts cleanup. You're invited to list scripts you know to be currently working and relevant. Eventually this draft page can replace the current scripts listing.

If you'd like to comment or collaborate on this proposal, see the discussion I started here: Wikipedia talk:WikiProject User scripts#Scripts listing cleanup project. Thanks! Equazcion (talk) 00:19, 25 Mar 2012 (UTC)

Template unhiding doesn't work (with a clue)

Please check at lines 656-7-8.

User:Cacycle/wikEd.js
wikEd.programVersion = '0.9.102'
// wikEdFrameBodyNewbie ref and template hiding

I think problem comes from left: -10000em; and position: fixed;
Without these properties (I tested by deleting them in the CSS through Firebug), unhiding seems to work again. However, I have not tested if this could harm some other feature. -- Codicorumus  « msg 14:58, 25 March 2012 (UTC)

Same at lines 672-73.
'.wikEdFrameBodyNewbie .wikEdCharEntity, .wikEdFrameBodyNewbie .wikEdCharEntityShow':
This time I've tested patching the js file. After deleted said properties and changed display: block; to display: none; in both instances, hiding/unhiding seems to work well.
Was it a patch for an unresolved bug ?  If that's the case, could you give me any hint for replicating that bug ?  -- Codicorumus  « msg 04:55, 26 March 2012 (UTC)
Fixed in 0.9.103b. Sorry for this. Cacycle (talk) 21:25, 8 July 2012 (UTC)
Thanks a lot.
Just another small thing that I forgot to report: a missing dot at line 664 (programVersion = '0.9.103b'):
'.wikEdFrameBodyNewbie wikEdRefContainer + .wikEdRefShow, ...
                       ^
-- Codicorumus  « msg 15:11, 9 July 2012 (UTC)
Fixed in 0.9.103c, thanks a lot, Cacycle (talk) 21:45, 9 July 2012 (UTC)

Recent change?

Has there been a change to wikEd or MediaWiki lately? In the last several days wikEd has often not been loading (on two different computers using both Chrome and Firefox). —danhash (talk) 14:27, 23 April 2012 (UTC)

Copy-paste-ing

When I copy-paste something from somewhere, there will be an extra space in the beginning and the end. Did you make it on purpose?--Kc kennylau (talk) 12:44, 24 April 2012 (UTC)

See the section Disable Pasting of Rich-text above for a solution. --V111P (talk) 17:57, 24 April 2012 (UTC)
Maybe he could make an option called "always paste as plain text". --Kc kennylau (talk) 12:51, 26 April 2012 (UTC)
I have already worked on this, but it is not yet ready for a roll out. Cacycle (talk) 16:44, 8 July 2012 (UTC)

Getting RETF to work

I've just installed WikEd. First I did it by setting my Preferences, and that brought WikEd up when I went into edit an article but the RETF button wasn't displayed. Then I discovered that I was supposed to add some code to my monobook before the WikEd installation code, so I switched off the gadget preference and instead added the installation code to my monobook, with the RegExTypoFix code line immediately before it. However, I've tried reloading monobook, logging and off Wikipedia, closing and reopening the browser (Chrome), but the RETF button still doesn't appear (the box on the toolbar beside the 'fix units' button is blank. This is what I've got now in my monobook:

wikEdRegExTypoFix = true;
// install User:Cacycle/wikEd in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></script>') ;

How do I get RETF to work? Colonies Chris (talk) 13:49, 22 May 2012 (UTC)

Please see below for the answer... Cacycle (talk) 16:33, 8 July 2012 (UTC)

Double editnotices

Whenever I use wikiEd all editnotices are displayed double. Am I the only user having this problem? If it's any help, I use Google Chrome on a Mac.  Liam987(talk) 08:17, 25 May 2012 (UTC)

It's a feature, not a bug. See User:Cacycle/wikEd help#Double edit notice. jcgoble3 (talk) 13:39, 25 May 2012 (UTC)
OK  Liam987(talk) 14:21, 26 May 2012 (UTC)

Question about the editor

I have just installed the wikED today and I'm loving the available options this has added to editting a page. But I have a question: While copy and pasting information from our forums site to transfer to mediawiki it kept the same format as on the forums. Awesome, I thought, But when I clicked preview, the format was dropped and replaced with plain txt. Screenshot of both formats (image hosted on photobucket) My LocalSettings.php is set to allow external images. Is there any way I can keep that format that's in the above edit window? I'm just confused that it would show it exactly how I want it then when I save the page it becomes plain text. Thank you for any help with this ^^ Benitora Masaki (talk) 22:10, 1 June 2012 (UTC)

You need to click on the wikify ([W]) button after pasting. --V111P (talk) 14:36, 3 June 2012 (UTC)
I've done that and it still loses the original format. Oh well, thank you for the reply. Benitora Masaki (talk) 18:34, 3 June 2012 (UTC)

Bracket matching

Any plans to add bracket matching? ··gracefool☺ 19:45, 20 June 2012 (UTC)

Interesting idea, maybe in the future. Cacycle (talk) 16:31, 8 July 2012 (UTC)

Getting RETF to work

Raising this question again because I still can't get RETF to work.

I've just installed WikEd. First I did it by setting my Preferences, and that brought WikEd up when I went into edit an article but the RETF button wasn't displayed. Then I discovered that I was supposed to add some code to my monobook before the WikEd installation code, so I switched off the gadget preference and instead added the installation code to my monobook, with the RegExTypoFix code line immediately before it. However, I've tried reloading monobook, logging and off Wikipedia, closing and reopening the browser (Chrome), but the RETF button still doesn't appear (the box on the toolbar beside the 'fix units' button is blank. This is what I've got now in my monobook:

wikEdRegExTypoFix = true;
// install User:Cacycle/wikEd in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></script>') ;

Colonies Chris (talk) 15:07, 26 June 2012 (UTC)

You have to use var wikEdConfig = {}; var wikEdConfig.regExTypoFix = true; instead, as described on User:Cacycle/wikEd_customization. This also works for wikEd as a gadget. Hope this helped, Cacycle (talk) 16:27, 8 July 2012 (UTC)
OK, I've removed the monobook WikEd installation code, added var wikEdConfig = {}; var wikEdConfig.regExTypoFix = true; at the bottom of my monobook, and switched on WikEd as a gadget on my user preferences page. But I still don't get RETF - the button on the toolbar beside the 'fix units' button is blank. Colonies Chris (talk) 11:25, 19 July 2012 (UTC)
I am in the same boat. Chris the speller yack 13:54, 19 July 2012 (UTC)

Hit Preview, work disappears

Has a change been made recently? A couple times recently, I've written something, then hit the Preview button and saw no changes and my edit box reset to how it was before the edit. As you can imagine, this is incredibly frustrating. As useful as this tool is, I obviously can't deal with work being arbitrarily erased. -- tariqabjotu 04:44, 10 July 2012 (UTC)

Sorry to hear this. Please could you give some more details? Please see the top of the page for the bug report form. Did you use the standard preview button or wikEd's 'show preview below' button? Cacycle (talk) 06:29, 10 July 2012 (UTC)
I used the standard preview button (as I've always done). I can't really give details of how it happens. It just happens sometimes. I write something. I press "Preview" and I don't get a Preview, and I get the edit box how it was before I even began editing the section. It's not just on specific pages. It's not at specific times. However, it seems like it only happens when I've been editing a page for a long time and have had it open for awhile (at least thirty minutes). In other words, the issue occurs at the time of maximal inconvenience. And it seems to know when I didn't copy and paste it into a second document before attempting the preview. The fact that no one has apparently complained about it suggests it's just me, though. But I'm not sure why. I've used wikEd for years without issue, and it's happened at least a half dozen times now since the beginning of July. -- tariqabjotu 19:28, 14 July 2012 (UTC)
Some basic details about m computer: I'm on a Mac OS X v. 10.6.8 and I edit using Chrome v. 20.0.1132.57. My wikEd version is 0.9.103d G (July 11, 2012). -- tariqabjotu 19:39, 14 July 2012 (UTC)
I've just experienced the same thing a couple of times; my setup is Chrome, Windows 7 on a PC. Colonies Chris (talk) 09:53, 20 July 2012 (UTC)
I'm in the same boat here (Chrome @ Windows XP right now). There's a particular edit I'm repeating since an hour or so to pinpoint the problem (I disabled all extensions in Chrome) and it turns out to be wikEd. I'm not applying the edit for now, to see if we can solve this issue.
I also note that since some time now, wikEd insists on adding extra spacing around my edits, which I have to correct after a preview. I'm wondering now if this is normal behavior. --Langus (t) 22:33, 21 July 2012 (UTC)
Please could you describe in detail what you mean by "insists on adding extra spacing around my edits", which preview you use, and which browser and OS you use (see bug report form on top of the page)? Thanks, Cacycle (talk) 20:26, 1 August 2012 (UTC)
I've experienced this spacing bug in recent versions of Chrome on Windows XP, Windows 7, and OS X 10.6.8. It seems to happen when I use the wikEd ajax preview button. Tuvok[T@lk/Improve] 02:45, 3 August 2012 (UTC)

I would love to help, but without a detailed bug report I cannot reproduce your problems and therefore cannot try to fix it. On top of the page you find the infos I need from you. Thanks, Cacycle (talk) 20:17, 12 August 2012 (UTC)

I think I have found and fixed this bug in version 0.9.105 (see below). Please could you verify? Thanks to everybody for the help! Cacycle (talk) 21:25, 5 September 2012 (UTC)
I will re-enable wikEd and I'll let you know if it keeps happening (and I'll fill a bug report in that case)
Thank you! :) --Langus (t) 10:01, 6 September 2012 (UTC)

URLs with whitespaces don't open correctly

When a user added a link in an article containing a whitespace (%20) those links can't be open properly from the diff-window, because WikEd replaces them with underscores "_".

Steps to reproduce: login on Wikipedia, enable WikEd and try to open the link in the following change: http://de.wikipedia.org/w/index.php?title=Iran&diff=105408401&oldid=105314771 It will say: File not found. Entering the link manually will work. --Incarus (talk) 21:51, 10 July 2012 (UTC)

Can I get feedback on that? Would be very important for me. --Incarus (talk) 21:48, 19 July 2012 (UTC)
Next on the list... Cacycle (talk) 20:30, 5 August 2012 (UTC)
Fixed in 0.9.104a. Cacycle (talk) 20:44, 6 August 2012 (UTC)
Thanks. --Incarus (talk) 16:50, 13 August 2012 (UTC)

Regular Javascript functions not working

For some reason, the regular editing menu and the "Insert" menu below the edit box don't work when I have wikEd enabled. I have tried this with several different browsers. --Eastlaw talk ⁄ contribs 01:12, 11 July 2012 (UTC)

The last couple of days I have seen the same thing with "Insert", or maybe it is just coincidentally similar. Firefox 9.0.1 under Windows Vista Home Premium. If I click to move the insertion point, characters from the "Insert" menu do not appear, and the toggle between upper case and lower case has no effect. If I select one or more characters, then the "Insert" works, and the upper-lower case toggle works. Oh, wow, just noticed the same thing with italics and bolding. Chris the speller yack 03:21, 11 July 2012 (UTC)
Fixed in 0.9.103d. Cacycle (talk) 21:42, 11 July 2012 (UTC)
Yes, indeed. Thanks. Chris the speller yack 02:06, 12 July 2012 (UTC)
Thanks dude! --Eastlaw talk ⁄ contribs 06:02, 13 July 2012 (UTC)

Cross-site scripting

In April I sent you two emails about a security issue with wikEd. Did you get these emails or should I send them again? --Schnark (talk) 10:11, 13 July 2012 (UTC)

Hi Schnark, I will fix these issues in the next release. Chris Steipp has provided a possible solution. Cacycle (talk) 17:14, 14 July 2012 (UTC)
Fixed in 0.9.104. Thanks for your patience... Cacycle (talk) 20:29, 5 August 2012 (UTC)

Custom configuration not working

I added the following to my common.js: 

   var wikEdConfig = {};
   wikEdConfig.regExTypoFix = true;
   wikEdConfig.comboPresetOptions = {};
   wikEdConfig.comboPresetOptions.summary = [
       'Redirect to already-existing article', 'Copyedit', 'Reply', 'Linkfix', 'Fixing typos', 'Removing linkspam', 'Reverting test',
       'Reverting vandalism', 'Add relevant tags', 'Keep', 'Del', '+1'
   ];

Result: No RETF or summary changes
Errors: None
Version: 0.9.104a G
Browser: Safari Version 5.1.1 (7534.51.22)
OS: OS X 10.7.2

Note: I tried using var wikEdConfig.regExTypoFix = true; (as mentioned on the config page), but then I got an error about an extra . in the code.

TIA, Dori ☾Talk ☯ Contribs☽ 21:24, 10 August 2012 (UTC)

Hi Dori, there is nothing like a common.js user page, you have to use User:DoriSmith/vector.js instead. Cacycle (talk) 10:14, 12 August 2012 (UTC)
Huh? Special:Preferences#mw-prefsection-rendering says there is such a page... jcgoble3 (talk) 17:28, 12 August 2012 (UTC)
Oh, something new... The code from above actually works fine for me from vector.js as well as from common.js. Did you Shift-Reload after your change? Cacycle (talk) 20:13, 12 August 2012 (UTC)
Whew, that threw me off for a bit, as common.js has been working just fine for me with everything else.

Yes, I did every kind of reload I could think of, including quitting and restarting my browser—but no joy. Dori ☾Talk ☯ Contribs☽ 00:22, 13 August 2012 (UTC)

It is an issue with the order of execution. Please move the wikEd configuration out of your addOnloadHook handler. BTW, wikEd has its own loader. Cacycle (talk) 06:34, 13 August 2012 (UTC)
Okay, I moved it up, and now the summary changes work but RETF doesn't. Sounds like I have the same issue some other people have above, but I can live with this (or if you want me to debug stuff for you, just say the word). Dori ☾Talk ☯ Contribs☽ 08:14, 13 August 2012 (UTC)
RETF works fine for me (with the exception of the first rule as I just noticed). Please file a bug report if you have any other problems with it. Cacycle (talk) 19:54, 13 August 2012 (UTC)

wikEd adds too much whitespace

I would like to put a word in for removing the wikEd feature that automatically adds whitespace. I tend to put exactly how much whitespace I want and need in articles and talk page comments, but wikEd insists I need more. A common example of this is where I respond to a bulleted comment as below:

  • Comment 1.
    • Comment 2.

In order for this to appear correctly, there must be no line break or whitespace between the two comments. Otherwise, you get the following:

  • Comment 1.
    • Comment 2.

WikEd does not seem to recognize that, and so when I intentionally omit line breaks after bulleted items, it'll add them and mess up the formatting.

On other occasions, it will inexplicably just add another line break (or sometimes two!) to a line break I already have. An example of this, compounded by a mistaken notice of an edit conflict mind you, is here. Long story short, I have never -- seriously never -- benefited from this feature. Instead, there have been a number of highly annoying occasions where I then have to go line by line removing line breaks I never inserted in the first place. Can this feature be removed, or at least include an option for it to be disabled? It seems as if some people have complained about this before, but the fact that this still has not been rectified suggests that not enough people have voiced their opinion about this.

P.S. In the course of writing this comment, the previous bug I mentioned -- whereby upon previewing or saving, all the content I wrote is gone -- just occurred. Copying the old text and pasting it in the box repeatedly did not work (saving kept producing an empty edit box), and the only way I could get this comment to post is by disabling wikEd. Sigh... I really love this gadget, but it's increasingly becoming a hinderance to my editing abilities. -- tariqabjotu 01:42, 24 August 2012 (UTC)

  • It's a bug, not a feature. Please could you provide a full error description (see top of the page) so that I can try to replicate and fix this? Thanks in advance, Cacycle (talk) 15:18, 25 August 2012 (UTC)
Alright, here's the info you need:
  • WikEd version: 0.9.104g
  • Browser ID: Chrome v. 21.0.1180.89
  • Error console errors: I don't know what you're talking about here
  • Add ons: EXIF Viewer, RoxioNow Player Extension, Unfriend Finder, Zotero Connector
  • Skin: Vector
  • Beta Interface?: No
  • Operating System: Mac OS 10.6.8
This is also relevant to the issue noted a couple sections above (and corroborated by other people) with the content I've written not showing up in previews. With both issues, there's really no rhyme or reason to it. However, with this issue (where extra whitespace comes about), it seems to consistently happen when you copy and paste content (even if it's from another open edit window and even when using CMND+Shift+V, rather than the standard paste). It'll often add whitespaces were none were desired or needed (e.g. between bullet points) or take existing whitespace and double or triple (or quadruple) it. For example, there would originally be an empty line between two paragraphs, and then after previewing or saving there are three four line breaks. This occurs in the example I noted.
P.S. Note that the preview bug occurred again while writing this comment. Luckily, I copied what I wrote to my clipboard before hitting "Preview"; this has become standard practice for me. Then, when I pasted what I copied in the window and then hit preview, I got this. And again... -- tariqabjotu 02:33, 1 September 2012 (UTC)
Thanks for that report! Is anybody experiencing these problems with Chrome under Windows? Or is it only Chrome under MacOs? Cacycle (talk) 07:28, 1 September 2012 (UTC)
I am. But I'm using Chrome 23 (dev channel).--Netheril96 (talk) 10:03, 1 September 2012 (UTC)
Thanks. Unfortunately, I could not yet replicate these problems with the current Chrome (21.0.1180.89 m) under Windows XP. Please could you (or one of you) give me step-by-step instructions to repeat the problems? Thanks, Cacycle (talk) 18:58, 1 September 2012 (UTC)
As I said, I have not been able to predict when the Preview blanking will occur. It just happens sometimes. As for the whitespace issue, while it happens on other cases, one method that seems to always cause the problem (and I was just able to recreate it) is to do the following:
  1. Click [Edit] to open the edit window for this particular section.
  2. Select everything and copy the entire text in the edit window to the clipboard.
  3. Immediately paste it, using CMND+Shift+V (or CTRL+Shift+V). Note that the issue doesn't come up with the regular paste, but the former is usually necessary to avoid pasting bizarre text formats.
  4. Click the native Preview button.
Viola! Whitespace galore. Pasting almost anything seems to cause the whitespace bug to occur, although it sometimes happens even when no copying and pasting has happened. For example (as I just did):
  1. Reply to this message (or I replied to yours) with the following:
::::::Test
::::::#Numbered item 1
::::::#Numbered item 2
::::::~~~~
And now there's whitespace between all of your lines (breaking the numbering), although not as much as in the previous example. -- tariqabjotu 19:44, 1 September 2012 (UTC)
Thanks! Is it possible to provoke the whitespace problems without CMND+Shift+V? BTW, you can use the Textify button to get rid of formatting. Cacycle (talk) 06:09, 4 September 2012 (UTC)
With copying and pasting, repeating the same procedure with the regular paste doesn't seem to cause the problem. However, as I said, typing (without even copying and pasting) the four lines above causes additional breaks to be added between lines (and above the text), breaking the numbering in the process. -- tariqabjotu 15:38, 4 September 2012 (UTC)

I think I have found and fixed this bug in version 0.9.105. Please could you verify? Thanks to everybody for the help! Cacycle (talk) 21:25, 5 September 2012 (UTC)

I've been traveling and didn't seem to recall if I had to do something to get the version to update. But I know for sure that I am on 0.9.105 (I guess it updates automatically), and the issue still persists. See, for example, here and here. -- tariqabjotu 14:00, 23 September 2012 (UTC)
Same here: I've test the text above and it inserts spaces between the bulleted items. I arrived to this thread when I saw the title ("wikEd adds too much whitespace"): I thought too that this was a feature, and I was looking for a way to disable it.
The "hit-preview-work-disappears" bug hasn't reoccurred so far.
My configuration:
  • WikEd version: 0.9.105 G
  • Browser ID: Chrome v. 21.0.1180.89 (User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1)
  • Error console errors: none (I went to Tools > Developer tools > Console)
  • Add ons: lots of them; I'm sending them with comments via email
  • Skin: MonoBook
  • Beta Interface?: No
  • Scripts: User:GregU/dashes.js
  • Operating System: Windows XP SP3 Spanish
If you need more info or if you need me to do some tests, I'd be glad to.
Thanks, cheers! --Langus (t) 16:17, 23 September 2012 (UTC)
This is really annoying. Has any progress been made on fixing this problem? (Note that that came about with the regular copy and paste.) -- tariqabjotu 09:07, 13 October 2012 (UTC)

Experiencing this whitespace problem consistently, both when typing text and when copy/pasting. It's getting to be a real problem for me, so I did the above test in many configurations:

Monobook skin, with user scripts at User:Maralia/monobook.js:
OS X 10.6.8 and Safari 5.1.7
OS X 10.6.8 and Chrome 23.0.1271.64
OS X 10.8.2 and Safari 6.0.2
Vector skin, with no user scripts whatsoever:
OS X 10.8.2 and Chrome 23.0.1271.64

In all those configurations, I got at least two extra blank lines; sometimes I got up to four of them.
All tests on wikEd 0.9.105 G. Error console never reported any errors. There were various browser add-ons in use across these tests—as they involved two browsers, three versions, and two different OS on two computers—but none was present in all cases, and in fact one browser was free of add-ons.
Pressing [T] produces the same extra lines as Preview, as does pasting with Command+Shift+V.
The problem did not occur when testing in Firefox 11.0.

Willing to help test or provide more info if necessary. Maralia (talk) 04:54, 25 November 2012 (UTC)

WikEd does not save changes when clicking save page (~20% of time).

Instead, there is a long loading time, you are returned to the page you tried to edit, and there is no sign of your edits. Sometimes when you press the browsers back button the edit can be recovered and the save reattempted, but other times the edit is gone and you have to start again. Looks like a very nice gadget, I just can't use it due to the frustration it causes me =(

Other details: browser: chrome. I messed with my wikipedia preferences and gadgets before enabling WikEd, so maybe this combination of settings is interfering with the editor?

Not sure if anyone else reported this bug, can't be bothered to go thru archives, sorry) tepi (talk) 10:46, 27 August 2012 (UTC)

Just realized "Disable browser page caching" was enabled (don't know why) I will try again with caching disabled. doesn't explain extended loading time though... tepi (talk) 11:12, 27 August 2012 (UTC)
I don't know, but based on the reports, the common link seems to be Chrome. But surely, especially with this being Wikipedia, Chrome is widely used. Perhaps most experiencing this issue aren't reporting it (likely). -- tariqabjotu 02:37, 1 September 2012 (UTC)
I think I have found and fixed this bug in version 0.9.105 (see above). Please could you verify? Thanks to everybody for the help! Cacycle (talk) 21:25, 5 September 2012 (UTC)

wikEd requires DOM storage

Due to privacy concerns, I normally disable DOM storage in every Firefox installation I take care of. Unfortunately, wikEd crashes silently in this environment - I have to enable dom.storage.enabled in about:config. 193.26.252.225 (talk) 16:20, 11 October 2012 (UTC)

Fixed in 0.9.106. Thanks for reporting, Cacycle (talk) 17:53, 2 December 2012 (UTC)

Error: SecurityError: The operation is insecure

On Firefox, due to the annoying bug 748620, the following line (line 14536 on programVersion 0.9.105) throws the exception "Error: SecurityError: The operation is insecure": if (typeof(window.localStorage) == 'object') {.

Please put that inside a try-catch to avoid the bug. Thanks! --Ciencia Al Poder (talk) 20:47, 1 November 2012 (UTC)

Fixed in 0.9.106. Thanks for reporting, Cacycle (talk) 17:53, 2 December 2012 (UTC)

File links

On this edit wikEd (or the editor using it?) added a space in a file name thereby breaking the link. Is there a way of stopping this from happening? -- Alan Liefting (talk - contribs) 00:32, 11 November 2012 (UTC)

Just had a look ... definitely not my own work, but that change to U.S. was done by wikEd. Sincerely, -- Gareth Griffith-Jones/The Welsh Buzzard 10:05, 11 November 2012 (UTC)
Sorry, but you have to check your changes made with those buttons (as clearly stated). wikEd is language independent and does not have lists of legit abbreviations. It simply adds spaces after punctuation. Please use these buttons on selected text only and verify all changes with the preview button. Cacycle (talk) 11:56, 2 December 2012 (UTC)
I have added an abbreviation protector anyway. Unfortunately, this introduces language specificity as in some languages spaces in abbreviations are required. Cacycle (talk) 17:56, 2 December 2012 (UTC)
Thank you for the explanation ... duly noted. I consider wikEd an excellent tool. Sincerely,  – Gareth Griffith-Jones/The Welsh Buzzard 18:04, 2 December 2012 (UTC)

insertTags bug

  • Most of these bugs appear to have been fixed in the beta version of FireFox (17.0b5a). I believe they were caused by this bug. One bug, however, still remains: When you load my example and click on the first line, then try to insert somethings using Wikipedia insertion or pressing the bold button on wikEd, the text will insert at the beginning of the second line instead of on the first line. At some point in my debugging, I noticed that if I had text on the second line and tried bolding the first line (which is empty) then wikEd seems to try to bold the text on the second line, or at least up to the first tag. I am not sure if this is a symptom or part of the problem because inserting single characters from the Wikipedia insertion tools end up on the second line as well. I also want to let you know that I commented on your bug #587461 and added a test case. --Odie5533 (talk) 08:59, 15 November 2012 (UTC)

Hi again! I am encountering a number of bugs when using insertTags with wikEd from the Wikipedia toolbar and from another script (my SnipManager). I am using FireFox 16.0.2 and wikEd 0.9.105 (the bug is not present in Chrome). The bug manifests in two forms: inserting in the wrong place, and insertions failing and throwing an error. The bugs also occur when attempting to use the insert characters below the usual edit form. For this bug I have produced a sample: [1]. Go there, then click on the first line which is empty and attempt to use any of the insert buttons. FireFox throws an error, and refers to line 13585 which I have posted below. 

Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHTMLDocument.execCommand]
Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
Line: 13585
Line 13585: wikEd.frameDocument.execCommand(command, false, option);

Also, what is the best way for an external script to insert text into the edit form when wikEd is enabled? I am currently using a very strange piece of code that doesn't work well. Here is my code: 

        // wikiEd's insertTags has bugs when inserting at the end of a line
        // it will often insert at the beginning of the next line
        // this does not fix it entirely, but it helps
       
        insert_text = insert_text.replace(/&/g, '&amp;');
        insert_text = insert_text.replace(/</g, '&lt;');
        insert_text = insert_text.replace(/>/g, '&gt;');
        var obj = {}
        obj.html = insert_text;
        if (wikEd.highlightSyntax == true)
            wikEd.HighlightSyntax(obj, false);
        wikEd.FrameExecCommand('inserthtml', obj.html);

Using this code my SnipManager is able to insert on that first empty line even when the Wikipedia insert buttons won't work. However, if I click at the very beginning of the second line, neither my code nor the Wikipedia insert buttons work. If I click at the end of the edit box so that the cursor is at the far right of the 3rd (last) line and insert a few characters from the Wikipedia bar, then the first character inserts correctly but subsequent characters are placed on the first line. In my code, if I comment out the syntax highlighting part so we are just inserting the html with no highlighting then the bug is reduced significantly and I am able to insert anywhere except at the beginning of lines which have text already. (edit) I just noticed that wikEd's own insertion buttons, such as the bold button, have the same behavior as the Wikipedia insertion tags. This is probably because they use the same code, but it does provide an easy way to test for the bug.

These are the strangest bugs, and I feel they are all related. Any input on them would be appreciated. --Odie5533 (talk) 06:04, 15 November 2012 (UTC)

Please see User:Cacycle/wikEd#Making_scripts_compatible_with_wikEd, User:Cacycle/wikEd_customization, and User:Cacycle/wikEd_development#wikEd_API for how to manipulate the text when wikEd is enabled. As for the insertions in your example: this is a really, really difficult and complicated problem that has to do with a mechanism to set the cursor correctly inside or outside the markup. I will definitely try to fix this, but that will probably take some while. Sorry, Cacycle (talk) 18:09, 2 December 2012 (UTC)

Pre tag incompatibility and possibly other issues

Pasting this entire conversation from Village pump (technical)#Reflinks_in_the_user_Toolbox. PrimeHunter and I both find that wikEd has an issue with pre tags. That takes up about half of the below dialog. My end posting on this, is that I think there might be other issues. I'm not a programmer. Perhaps if the pre tag issue were resolved, so would everything else.

  • wikEd version 0.9.105G (September 5, 2012)
  • Estimated onset of this issue - Spring 2012.
  • Windows XP
  • Firefox 16.0.2
  • I mostly use monobook, but this issue is on all skins.
  • Reflinks installed on common.js yesterday
  • The only other user script I have is on my modern.js, which is for the DYK Check. It's been there since March 2011, at least a year before this issue started happening.
  • I am not using Wikipedia Beta.

Please contact me with any questions. — Maile (talk) 17:08, 18 November 2012 (UTC)

I would guess that most or all of the problems you are seeing are caused by FireFox. FireFox 16.x has some serious bugs when dealing with edit areas in designmode (like wikEd). You can try disabling syntax highlighting and see if the problem persists. Alternatively, try using Google Chrome, or if you are feeling adventurous, try using the FireFox 17.x beta (it's actually quite stable [2]). If there is still a problem, please try to be a bit more specific on what you are doing, what is happening, and what you expect to happen. The comments below are hard to sift through. --Odie5533 (talk) 18:44, 18 November 2012 (UTC)
I was very specific in my second sentence above that another editor and I have discovered a pre tag issue. And I was specific in my end-of- thread posting. Bullet points, in fact. I'm sorry that was hard for you. My currently having a certain version of Firefox is no indication of what PrimeHunter has, who experienced the same issue with pre tag. Even better than changing browsers, since wikEd has been odd through several version of Firefox since Spring 2012 - I'll just not use wikEd. Thanks for creating it and maintaining it. But it just isn't worth it to me. — Maile (talk) 23:24, 18 November 2012 (UTC)
Maile, Odie5533 is just a talk page stalker here. Cacycle (talk · contribs) is the creator and maintainer of wikEd. jcgoble3 (talk) 23:57, 18 November 2012 (UTC)
Thank you for pointing this out! I'll go over to Cacycle's page. — Maile (talk) 00:10, 19 November 2012 (UTC)
I didn't mean to offend you; I was only trying to help since Cacycle has not been very active lately and I was experiencing a similar problem myself, detailed in the section above this one. --Odie5533 (talk) 00:53, 19 November 2012 (UTC)
Got it. — Maile (talk) 01:01, 19 November 2012 (UTC)

Reflinks in the user Toolbox

This is not new, nor related to any recent changes or other issues. For at least the last year, I've been trying to get Reflinks to show up in my Toolbox. The User Script looks like it should. My preferred skin is Modern, but, one at a time, I've tried it in Monobook, Vector and Modern. I've also tried loading it on the common.js But I never see it in the Toolbox. Right now, I've got the User Script in all four of those .js I'm on Windows XP, Firefox 16.0.2 - what am I missing? Is Reflinks not supposed to be in the Toolbox? — Maile (talk) 23:44, 17 November 2012 (UTC)

You have spaces instead of newlines in all your .js files. Copy-paste the code from User:Dispenser/Reflinks#User script to User:Maile66/common.js if you want it to work in all skins. There should be 8 lines and not one long line. PrimeHunter (talk) 00:36, 18 November 2012 (UTC)
More specifically, any instance of // causes the rest of that line to be treated as a comment (indicated by the syntax highlighter as green italic text) and thus ignored. Since the line begins with //, the whole thing is treated as a comment; you must insert a newline to end the comment and return to code. jcgoble3 (talk) 00:45, 18 November 2012 (UTC)
Ta! Da! What you all were looking at WAS a copy and paste of the code from the above Reflinks page. For some reason, when I clicked on Save Page, it made it all one line. (Same thing happens if I insert an infobox into a page) I inserted manual carriage returns to break it into separate lines, and it works now. Thanks for the help. — Maile (talk) 00:52, 18 November 2012 (UTC)
It sounds like your browser has a problem. Does it happen when you are logged out? Does it happen when you preview a copy-paste, or only when you save? Do you insert infoboxes by copy-pasting code from the documentation page? PrimeHunter (talk) 01:10, 18 November 2012 (UTC)
I'm never logged out of Wikipedia. My browser has multiple issues with Wikipedia, since the changes that happened sometime last Spring. 2012 This is but one of the issues. And my Firefox has undergone multiple upgrades since the first occurrence, so it doesn't matter which version of Firefox I've used. This happens on the Preview. If I save without a Preview, it still happens. Have a look at User:Maile66/Person in the Edit screen. I did that as a copy and paste from Template:Infobox person - the version under the "Blank template with basic parameters". Copied. Pasted. Saved. Conversely, if I copy an infobox from an existing article, replacing the info therein to suit my article, this collapsing never happens. It's when I copy from a Wikipedia Template page.
PrimeHunter, I think you hit on something. I logged off and did this copy and paste on a different blank page. It pasted exactly like it was supposed to and did not collapse the infobox. — Maile (talk) 02:00, 18 November 2012 (UTC)
And since I know the next question is "What gadgets do you have checked?", I unchecked wikEd. The infobox pastes and saves perfectly without that checked. So, that gadget is the culprit. — Maile (talk) 02:04, 18 November 2012 (UTC)
I have tried to enable WikEd and now it also happens for me when I copy-paste something from a rendered page with pre tags, for example the below two-line example. In my tests it only happens for pre tags. PrimeHunter (talk) 02:18, 18 November 2012 (UTC)
This is line 1.
This is line 2.
Yep. It's probably the pre tags. I've only experienced this with infoboxes and with the Reflinks user script. When I looked at that User Script in the Reflinks Edit window, it has pre tags. If I copy the script without the pre tags, and paste it, then it looks exactly like it should. — Maile (talk) 02:35, 18 November 2012 (UTC)
Then this should be reported at User talk:Cacycle/wikEd. Note that Cacycle can sometimes take a while to respond to bug reports, so don't expect a quick fix. jcgoble3 (talk) 04:46, 18 November 2012 (UTC)
Bit belated, but I sleep by the British clock. Anyway, it's not crucial that there be eight lines - only three of the newlines are critical, and as noted above, they are the ones at the ends of the lines containing the end-of-line comment marker //. If a line does not contain the // marker, the following line may be joined to it, so you could lay it out as follows:
// Add [[WP:Reflinks]] launcher in the toolbox on left
addOnloadHook(function () {addPortletLink( "p-tb",     // toolbox portlet
 "http://toolserver.org/~dispenser/cgi-bin/webreflinks.py/" + wgPageName + "?client=script&citeweb=on&overwrite=&limit=30&lang=" + wgContentLanguage, "Reflinks"  // link label
 )});
which is four lines. The presence or absence of the leading spaces is also stylistic. --Redrose64 (talk) 10:08, 18 November 2012 (UTC)
Yeah, but as noted by Jcgoble3, this probably should be reported as a wikEd bug. I've unchecked wikEd as a gadget for the time being, to do some other testing of my own. I've been having some funky issues the last six months or so, and I'm thinking they might also be wikEd. I've posted about them before here on the Pump, and got no response. I need to do some citation editing and multiple other things before I can prove or disprove the connection to wikEd. Off the top of my head, the most annoying issues are:
  • Spacing (inconsistent) - either one too many, or one not enough - seems to trigger malfunctions on insertions. To correct that, I either have to delete an extra space and put it up against the word to the left of it, or add an extra space. If one of those methods works, the other doesn't. And there's no consistency on the why of it.
  • Inserting a link from the icon on the Toolbar - sometimes it works, sometimes it's the Spacing issue
  • Inserting a citation from the drop-down Template menu in the Toolbar (Provelt is not affected by this).
  • Sometimes it works - sometimes it's the the Spacing issue
  • Sometimes it jumps and inserts the citation to the left of the "==" at the section heading
  • Paste - sporadic issues with Spacing, one too many or one not enough
  • Template:DYKproblem - This template has pre-tags. Spacing issue and consistent. This is put on a user's page to refer back to a nomination that has questions. Ideally, it automatically adds the section header and puts a message below that. In reality, it erroneously adds a space or two to the left of the section header. The work-around is to insert the template. Then insert my cursor in front of the template, even though I see no space there, and hit the Backspace twice.
  • Deleting characters/text (consistent issue) by tapping the keyboard "Delete" key . The first one or two deletions happen where they should - then it jumps to elsewhere on the page and deletes in another place.
There are possibly more, but these are the ones that have been irritating and happening on everything I've been editing for months.— Maile (talk) 16:55, 18 November 2012 (UTC)

Answer and response

Fixed in 0.9.106. Please could you check and report back? I hope this did not break some other functionality... Sorry for the delay, but I am really busy IRL at the moment. Cacycle (talk) 22:22, 2 December 2012 (UTC)

Let me do some checking for a few days and get back to you. My Firefox has updated itself to 17.0.1- and probably will continue to update and change. I've been editing without WikiEd for days, so I'll have to try it out. In regards to the more precise list that I put on your user talk page, I was just going down it and checking it. Two things are for sure not fixed.:
1) Copy and Paste from within the edit window - The Paste inserts a line break before pasting text. But not consistently.
2) Copy and paste of Template:Infobox person (or any other infobox template) - the issue is Edit Window view and how it responds to "Preview". That is to say, this set of actions: Copy, Paste, Preview - Preview can be right after the Copy, or first input text and then Preview
- Without WikiEd - Copy, Paste, Preview - Edit window looks exactly as it looks on that template page - vertically breaking at every line as it should
- With WikiEd - Copy, Paste, Preview - Edit Window is a big blob of text, one long wrapping "justified" paragraph rather than having line breaks. "Justified" in the fact that it visually has long gaps to stretch a line from left to right. Very ugly. Filling in the blanks, I visually see the text in front moving and continually wrapping the paragraph as I type. The resulting output is the same. It will produce an infobox on the page. But difficult to work with. Time consuming to go in and manuallly insert line breaks just for the Edit Window view. — Maile (talk) 14:55, 4 December 2012 (UTC)
OK, finally fixed I hope... As for "The Paste inserts a line break before pasting text" this happens if you paste block level elements like divs or heading. This is not really a bug, but I am working on a new feature to deal with this. Cacycle (talk) 21:45, 9 December 2012 (UTC)
Afraid not. I did a "reboot" of sorts, by unchecking WikiEd, running a test, and then checking WikiEd and running the same test. Exact same results above as I was getting on Dec 4. BTW, when I say I'm pasting, it's usually just one word or two, not block level elements or heading. When I did it just now, I copied and pasted one word into an infobox. Can't remember if before it was happening elsewhere on the Edit Window. However, I think WikiEd might be having conflict with something in infoboxes.
And there's another oddball thing in the Copy and Paste with an infobox. It's been there since I've noticed the other issues. If you go to the above link for Infobox person, the "Blank template with basic parameters" has a scroll bar (the one below it doesn't). If I copy and paste from that scroll bar one, it pastes normally without WikiEd. With WikiEd, it also pastes the scroll bar. And after I do a "Preview", in addition to the big block of Justified text, it shows a scroll bar at the bottom.
In regards to the other issues I mentioned on your talk page:
1) Delete key issue - the jury is still out. I haven't had occasion to do it lately.
2) Template DYK problem - no longer an issue, resolved
3) Inserting a link from the toolbar icon - see the next item where I inserted the internal link. When I clicked "Insert Link", it automatically inserted a line break and inserted it on a new line.
4) Inserting a citation from the drop-down Template on the toolbar. I created David J. and May Bock Woodward House on Dec 7. I used the drop-down Template on all of the inline citations. On one of them, it jumped to the top of the page and did the insertion. The other citations inserted where they should have. — Maile (talk) 22:43, 9 December 2012 (UTC)
To update to a new version (0.9.107), please push Shift-Reload. Cacycle (talk) 07:52, 10 December 2012 (UTC)

I updated to the new version, and some of the issues have been resolved.

1)  Fixed Template:Infobox person test. Copied, pasted, previewed. It worked correctly, so that is resolved.
2) Red X Not fixed Doing a copy and paste of one word into the infobox still inserts the line break
3)  Fixed Inserting link from the toolbar icon. Seems to be resolved, in the aspect of inserting into a block of text.
4) Red X Not fixed Inserting the same link into the infobox also inserts the line break
5) Red X Not fixed Inserting a citation from the drop-down Template on the toolbar - I won't know about that until I'm working on another article. TBA
6)  Fixed Delete key issue - ran a test, and it seems to be fixed.
7)  Fixed The original issue with Copy and Paste of Reflinks code to .js - resolved.
— Maile (talk) 15:06, 10 December 2012 (UTC)

german interwiki

Could you please change the interwiki-link of 'de' to de:Wikipedia:WikEd and add on your wikEd help the interwiki-link to de:Wikipedia:WikEd/Hilfe? thanks --CennoxX (talk) 23:33, 23 November 2012 (UTC)

I have done it. PrimeHunter (talk) 00:38, 24 November 2012 (UTC)
Thanks. Cacycle (talk) 22:23, 2 December 2012 (UTC)

Please repair this bug

Please repaire this bug. Here you can find a picture of the bug: http://de.wikipedia.org/wiki/Datei:Bearbeitungsfenster_mit_wikED.png --Harry Canyon (talk) 13:07, 4 December 2012 (UTC)

What is wrong in that screen shot? Push the Use wikEd button to enable the other buttons. Otherwise, please provide a detailed bug report (please see the top of this page). Cacycle (talk) 18:46, 4 December 2012 (UTC)


B icon makes five instead of six apostrophes

The B icon makes five ''''' instead of six '''''' when it doesn't mark existing text, for example when the cursor is surrounded by whitespace or punctuation, or the edit box is empty. It was reported at Wikipedia:Village pump (miscellaneous)/Archive 40#Bold mark-up and Wikipedia:Village pump (technical)#Dead horse. PrimeHunter (talk) 17:11, 28 December 2012 (UTC)

Bug in bold

This is copied from the village pump: Sorry to keep beating the proverbial deceased equid, but my complaint about the bug in the B function has not been addressed, except for one other editor confirming that it is a bug. To see what I mean, just click on the B and see what you get: five single quotes. Kdammers (talk) 06:59, 28 December 2012 (UTC)

You didn't say which B you click but a reply at Wikipedia:Village pump (miscellaneous)/Archive 40#Bold mark-up found that it happens for the B in the box added by wikEd. wikEd : is disabled by default and can only be enabled by registered users. The B in the default toolbar works fine. wikEd bugs belong at User talk:Cacycle/wikEd. PrimeHunter (talk) 15:49, 28 December 2012 (UTC)
Sorry for not specifying, but I only see on B' when I'm editing, as no. As I stated and another editor confirmed, does not work fine. It prints out five squotes when it is clicked on unless a text has already been selected.Kdammers (talk) 07:47, 29 December 2012 (UTC)
Fixed in 0.9.108, thanks for reporting. Cacycle (talk) 13:54, 2 January 2013 (UTC)

Comment - actually a question

Why does this structurally important page have such an obscure name?Kdammers (talk) 07:49, 29 December 2012 (UTC)

wikEd is a user script maintained by User:Cacycle. wikEd can only be used by registered users who have chosen to enable it, usually at Special:Preferences#mw-prefsection-gadgets where you must have set a checkmark. Wikipedia has lots of scripts with different authors. See for example Wikipedia:WikiProject User scripts/Scripts where some of them are listed. PrimeHunter (talk) 12:09, 2 January 2013 (UTC)
It seems the OP means to suggest that this page should be at something like Wikipedia Talk:WikEd (which is currently a redirect here ) —[AlanM1(talk)]— 08:08, 29 January 2013 (UTC)

Feature Request

Fix redirected images.,
At Wikipedia:Database_reports/Unused_file_redirects is a report which lists 'unused' file redirects.
It would be nice to have a feature in WikiEd which was able to automatically update filename in Image and File transclusions to the current names, bypassing redirects. Sfan00 IMG (talk) 12:10, 5 January 2013 (UTC)

This is already implemented, just push the Fix redirects button (). Please see also the wikEd help page.Cacycle (talk) 19:21, 6 January 2013 (UTC)
Note that you should not do this indiscriminately. It is sometimes correct to leave a redirect in place because it is likely that there will be an article for the currently redirected title in the future. For example, Bob Smith is CEO of XYZ, and is individually notable, but nobody has written a page for him yet, so he has a page that is just a redirect to XYZ. Links to Bob Smith should remain, and not be changed to point to XYZ, since it is likely that the redirect page will be changed to a regular article in the future. —[AlanM1(talk)]— 08:05, 29 January 2013 (UTC)

Speaking of requests for new features, has anybody that about merging the wikEd toolbar with the standard one? The former's interface really clashes with that of the latter, and there are some duplicated buttons which are much easier to find on the main toolbar. Maybe somebody could move the contents of the standard toolbar's current 'Advanced' tab to some new tabs, replacing them with the wikEd functionality currently not available to people who don't use it. I just think that all of these tools should be a lot more accessible to the general public than they are right now as part of a separate gadget. Aren't gadgets supposed to be experimental testbeds or betas? I mean, for how long has wikEd existed, and is this length of time large enough to have begun prompting its creators to bring its features out of the wikEd beta and into the current MediaWiki release's default editing toolset?
RandomDSdevel (talk) 23:42, 13 February 2013 (UTC)

Extra spaces

This editor consistently adds extra spaces in most edits; articles, talk pages, etc. Is there anyway to fix it so the number of spaces is exactly what has been entered in the edit box?

  • Example 1: How it ended up
File:WikiEd error example 1.png
how it ended up
  • Example 2: How I had it spaced in the edit window and wanted it to look
File:Example of WikiEd error 2.png
How I had it spaced in the edit window and wanted it to look:

The text is slightly different because I went back to correct my content after I fixed the spacing left by WikEd. Mkdwtalk 07:31, 20 January 2013 (UTC)

I am also still experiencing this problem, which I added to a thread above in November. I very much appreciate that this is a volunteer-produced tool and that you are certainly not obligated to maintain it—which is why I haven't posted here further, except for a reminder in early December—but I hope that seeing it is affecting other users will add a little motivation. I went to great lengths to bug test as extensively as possible; here's a diff to make it easier to find. Thanks for considering this again. Maralia (talk) 08:24, 20 January 2013 (UTC)

Sorry for the brevity of my first post. I would also like to mirror Maralia's comments in that this tool is excellent and I use it all the time. This is the only hiccup I experience so I wanted to mention it. Mkdwtalk 08:40, 20 January 2013 (UTC)

Toolbar is hidden

Helllo Cacycle! I have a problem with wikEd. Now I am using it at Thai Wikipedia by putting following code in my common.js file. 

document.write('<script type="text/javascript" src="'
+ 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></' + 'script>');

Recently, I just knew that wikEd can be customized the keyboard shortcut. Since I sometimes want to disable wikEd and lazy to click the top right icon, I put following code. 

var wikEdConfig = {};
wikEdConfig.buttonKey = {
  33: ['a', 65], // shift-alt-a ['wikEdUseWikEd', 'wikEdButtonChecked'...
}

After I pressed shift-alt-a, wikEd toolbar (undo, redo, bold, search & replace, ...) is hidden. I expected that pressing shift-alt-a will make the toolbar come back again. Sadly, it never does.

However, it seems that wikEd is not really disable; other functions of wikEd still work properly (preview below, changes button, ...). In addition, the top right icon still can be used for truly enabling/disabling wikEd.

I have tried many methods to bring that toolbar back such as clear my cookies, remove keyboard shortcut customization. It doesn't work.

So ... how can I bring that toolbar back? Thank you very much :) --Nullzero (talk) 05:13, 22 January 2013 (UTC)

Fixed in version 0.9.110. Thanks for reporting this. Cacycle (talk) 13:00, 28 January 2013 (UTC)

Progress on whitespace issue?

Has there been any progress on the whitespace bug described at #wikEd adds too much whitespace. Months later, I still experience the same problem (now on Safari, my new browser of choice) with wikEd adding additional line breaks between paragraphs and within lists. -- tariqabjotu 19:16, 9 February 2013 (UTC)

Sorry, the section above has become really confusing and I am not sure what has been fixed for whom and what not. Please could somebody paste a detailed bug report (again)? The most important infos being a very detailed 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) and the exact and detailed steps to reproduce (please include what happens at each step. Your problems cannot be fixed without reproducing them first!). Please keep in mind that I do not have access to a Mac, so all I have are your details. Thanks, Cacycle (talk) 19:53, 12 February 2013 (UTC)
Cacycle, I just love your editor for MediaWiki and it did not used to have this problem back about 2 years ago, then about a year ago I resumed using wikis and your editor then this problem showed up and has been there ever since. I'm currently using it on my own private MediaWiki installation, version 1.20.2 and wikEd is installed/activated as a MediaWiki Gadget. I've just reproduced this issue of extra whitespace inserted by the wikEd editor with a very simple test. (1) Create a new wiki page and add one line of text, no carriage returns, save the page. (2) Edit the now created page and hit ENTER twice at the end of the line you added, then type a second line of text, don't hit ENTER at the end of that, then save the page. (3) Edit the page a second time and you'll see that there are now TWO empty lines in between the two lines of text. I just did a second test with a bullet/numbered list using the pound and asterisk characters of 14 lines with no whitespace in between, just carriage returns at the end of each line as is normal for Windows Notepad. (1) Type a list using pound and asterisk characters with different levels of indentation in Windows Notepad, hitting ENTER once after each line. (2) Copy the whole list from Notepad to the clipboard (3) Either create a new page or edit an existing page and paste the list somewhere in the page, then save the page. (4) Edit the page again and view where you posted the list, you will see extra white space lines in between all of the list lines where there were clearly none when you typed them in Notepad. Could this be something to do with incorrectly interpreting CR and LF characters from copy/pasted text, say from documents, notepad text files, etc on Windows then going into the MediaWiki or wikEd data structures? I hope that helps you figure out what's going on as I would love to get back to using this editor exclusively. There is NO other wiki editor that has the syntax highlighting and visual aids for editing wiki pages ;) Thanks! Aknorjaden (talk) 22:41, 12 February 2013 (UTC)
Cacycle, I'm sorry I didn't follow the bug reporting convention you laid out, so here is the full list of stuff I've got on my system setup that should help you along with my length two-example description of this bug. I read the #wikEd adds too much whitespace posting above by another individual and he/she exactly describes the symptoms that I've seen in my own editing experience as well. Hope this all helps!
  • WikEd version: 0.9.111b G
  • Browser ID: Chrome v. 24.0.1312.57 m
  • Error console errors: I'm assuming you mean the JavaConsole - Errors, if so, there were none when I saved the page
  • Add ons: Adblock Plus 1.3.4, dealnews toolbar 1.0, DoNotTrackMe 2.2.8.109, Session Manager 0.4
  • Skin: Vector
  • Beta Interface?: No
  • Operating System: Windows 7 Ultimate 64-bit
Aknorjaden (talk) 22:51, 12 February 2013 (UTC)
My information again:
  • WikEd version: 0.9.111b G
  • Browser ID: Safari Version 6.0.2 (8536.26.17) [this is my preferred browser now, but I believe it still happens on Chrome and Firefox]
  • Add ons: None
  • Skin: Vector
  • Beta Interface?: No
  • Operating System: Mac OS X 10.8.2


As for replicating the issue... even without copying and pasting, this occurs nearly every time I make a comment or write anything with paragraph breaks. So, for example, I pressed edit for this section, went to the end, pressed enter twice to start my own comment, and started typing. Nothing out of the ordinary, but when I press Preview or Save, it then contains extra line breaks. An example of that comes in this very comment. What I wrote was:


::* Operating System: Windows 7 Ultimate 64-bit

::My information again:
::*WikEd version: 0.9.111b G
::*Browser ID: Safari Version 6.0.2 (8536.26.17) [this is my preferred browser...
::*Add ons: None
::*Skin: Vector
::*Beta Interface?: No
::*Operating System: Mac OS X 10.8.2

::As for replicating the issue...



But, instead what I get is...


::* Operating System: Windows 7 Ultimate 64-bit



::My information again:

::*WikEd version: 0.9.111b G

::*Browser ID: Safari Version 6.0.2 (8536.26.17) [this is my preferred browser...

::*Add ons: None

::*Skin: Vector

::*Beta Interface?: No

::*Operating System: Mac OS X 10.8.2



::As for replicating the issue...



I'm preserving my comment in this messed-up format for your observation (and note that as I continue writing, I'm getting more whitespace issues). -- tariqabjotu 23:06, 9 March 2013 (UTC)
I didn't understand the relevance of the first set of version information. Is this only happening on Mac? I'll note there are different conventions for line termination characters (0x0d and/or 0x0a) between Mac, Win, and *nix. Could this be related? —[AlanM1(talk)]— 07:08, 16 April 2013 (UTC)
Aknorjaden signed his name in the wrong place. The first set of version info is his. And seeing as he has a Windows computer, it doesn't just appear to be a Mac problem. -- tariqabjotu 07:15, 16 April 2013 (UTC)

The wrong tag order causes wikEd failure

The wrong tag order <sub><font size="1">...</sub></font> in the signature '''''<sub><font size="1">[[User:My76Strat|<span style="color:black;">My</span><font color="#ff4500;">76</font><span style="color:black;">Strat</span>]]{{*}}[[User talk:My76Strat|talk]]{{*}}[[Special:EmailUser/My76Strat|email]] </sub></font>''''' causes a wikEd failure discussed at Wikipedia:Village pump (technical)#Inability to edit. Tested with wikEd 0.9.111b G (February 12, 2013) enabled in preferences. PrimeHunter (talk) 15:32, 24 February 2013 (UTC)

Here is the bug report for an old page revision with the faulty signature:

  • Date: 2013-02-25 03:30:08 UTC
  • wikEd version: 0.9.111b G (February 12, 2013)
  • Browser: Mozilla/5.0 (Windows NT 6.0; rv:19.0) Gecko/20100101 Firefox/19.0 (Win32)
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.21wmf9
  • Gadgets: Gadget-HotCat.js, Gadget-popups.js, Gadget-ReferenceTooltips.js, Gadget-wikEdDiff.js, Gadget-wikEd.js, Gadget-afchelper.js, Gadget-edittop.js, Gadget-externalsearch.js, Gadget-addsection-plus.js, Gadget-PrettyLog.js, Gadget-contribsrange.js
  • MediaWiki scripts: Common.js/edit.js, Common.js/secure_new.js
  • Scripts: https://bits.wikimedia.org/geoiplookup, User:Cacycle/wikEdDiff.js, User:Cacycle/wikEd.js, User:Timotheus_Canens/displaymessage.js, User:PrimeHunter/My_subpages.js, User:Ais523/bracketmatch.js, User:Kylu/diff.js, User:X%21/userrights.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Jsimlo/shortcuts.js, User:Cacycle/diff.js, User:Pilaf/include/instaview.js
  • URL: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Did_you_know&action=edit&oldid=540161114
  • User/skin.js: https://en.wikipedia.org/wiki/UserPrimeHunter/vector.js
  • User/common.js: https://en.wikipedia.org/wiki/UserPrimeHunter/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: The edit box is automatically blanked about a second after loading.
  • Steps to reproduce: Click the above URL with wikEd enabled.

PrimeHunter (talk) 03:36, 25 February 2013 (UTC)

Fixed in version 0.9.112, thanks for reporting. Cacycle (talk) 21:02, 5 April 2013 (UTC)

Features disappeared

When I run WikEd, the alphabetize command and the undo/redo command are missing!

Were they taken out of WikEd? The Transhumanist 02:37, 7 March 2013 (UTC)

Found it - the toolbar was collapsed. (Sheepish grin). The Transhumanist 02:44, 7 March 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd/Archive_013&oldid=1180748148"