User talk:Cacycle/wikEd/Archive 010

Firefox 3.0

 * wikEd Version: 0.9.62g GM (April 25, 2008)


 * Fx/OS Version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 on Microsoft XP


 * Error: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMXPathEvaluator.evaluate]

Source File: file:///C:/Documents%20and%20Settings/Gentry/Application%20Data/Mozilla/Firefox/Profiles/lfgmobjb.Stability%20Test/gm_scripts/lyricwikicleanerv2.user.js Line: 32


 * Error: [Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit :: anonymous :: line 0"  data: no]

Source File: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit Line: 0


 * Installed addons:


 * Monobook installs: None


 * Description: Currently, none of wikEd's buttons work. All I did was install the new Firefox 3.0 as my primary browser. Now wikEd works for Wikipedia, but not LyricWiki. So I reverted to 2.0.0.14 and everything was fine. I could edit and there was no problem. The next step was to test on a different computer (basically one with no addons/modifications) but that was the same thing.


 * To reproduce: just try to use wikEd (GM version, I think) on lyricwiki.org, with 3.0 installed
 * color=#333333>King_Nee1114 (talk page • contributions  • deletions) 17:34, 18 June 2008 (UTC)


 * The error message complains about lyricwikicleanerv2.user.js. Cacycle (talk) 20:11, 18 June 2008 (UTC)
 * Please update your Greasemonkey add-on under https://addons.mozilla.org/en-US/firefox/addon/748. Cacycle (talk) 02:59, 19 June 2008 (UTC)

Cacycle (talk) 02:45, 19 June 2008 (UTC)
 * Unfortunately, updating Greasemonkey and any other attempted fix failed. In Firefox 3.0, I can only use wikEd on Wikipedia, and none of the other MediaWiki sites.
 * 71.82.148.8 (talk) 06:20, 19 June 2008 (UTC)


 * Did you install the new Greasemonkey version (0.8.20080609.0) and restart the browser and disable that lyricwikicleanerv2 script in Greasemonkey? Cacycle (talk) 22:19, 19 June 2008 (UTC)


 * Yes, I have the most current version, disabled the other scripts, and tried at 4 different wikis. The only place wikEd works is at Wikipedia. All the rest, the buttons appear, but do nothing.
 * color=#333333>King_Nee1114 (talk page • contributions  • deletions) 06:12, 21 June 2008 (UTC)
 * Also: every time I click a button on wikEd, I get hit with this:

 Error: [Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)"  location: "JS frame :: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit :: anonymous :: line 0"  data: no] Source File: http://lyricwiki.org/index.php?title=User:Kingnee1114lyrics&action=edit Line: 0
 * color=#333333>King_Nee1114 (talk page • contributions  • deletions) 06:15, 21 June 2008 (UTC)


 * It seems to be a Firefox 3.0 problem, I have filed a bug report . You might want to use an older and stable Firefox version (2.0.0.12) until they fix it. Cacycle (talk) 05:21, 22 June 2008 (UTC)


 * Thanks for the help. Good thing I kept fx2 and fx3 separate installations.
 * One question though: why does wikEd work at Wikipedia, but not any MediaWiki site?
 * color=#333333>King_Nee1114 (talk page • contributions  • deletions) 07:16, 22 June 2008 (UTC)


 * I have added a workaround for this Firefox/Greasemonkey bug in 0.9.63d. Cacycle (talk) 02:03, 23 June 2008 (UTC)


 * problem still persists
 * wikiEd 0.9.63e GM (June 25, 2008)
 * Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062414 Firefox/3.0
 * no JS errors in error console
 * addons: CustomizeGoogle (0.72), Delicious Bookmarks (2.0.64), Extended Statusbar (1.2.8), FireFTP (0.98.1), Flashblock (1.5.6), Googlepreview (3.11), Greasemonkey (0.8.20080609.0), Web Developer (1.1.6)
 * description: While i'm writing this report in wikiEd, on my wiki site wikiEd doesn't work. I tried all install types, now i'm using greasemonkey.
 * 193.93.72.82 (talk) 12:44, 26 June 2008 (UTC)

Edit cursor lost on preview
WikEd version 0.9.62g

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Whenever you click Preview and then scroll back to the edit box, you find that your cursor position has been lost. When you're editing a long article and frequently want to do previews, this is rather inconvenient, as you then have to spend time finding your place again so as to be able to continue with the editing. You don't get this problem with the standard MediaWiki editor. —Preceding unsigned comment added by 195.188.254.61 (talk) 11:39, 19 June 2008 (UTC)
 * That was an annoying Firefox bug that has been fixed in the new version, please update your browser under http://en-us.www.mozilla.com/en-US/. Cacycle (talk) 12:33, 19 June 2008 (UTC)
 * I've now upgraded to Firefox 3.0, but the problem remains. Could it be something to do with the transcluded text I have on the page? —Preceding unsigned comment added by 195.188.254.61 (talk) 10:08, 20 June 2008 (UTC)
 * Oh, sorry, I misread your report. I will see if I can focus the edit box after pushing the buttons. Thanks for the suggestion, Cacycle (talk) 13:08, 20 June 2008 (UTC)
 * Implemented in 0.9.63. Cacycle (talk) 05:31, 21 June 2008 (UTC)
 * One of our technical guys upgraded wikiEd.js to 0.9.64g, but the problem is still there. As before, on a preview, the edit box insists on scrolling its text back to the beginning and losing the cursor position. —Preceding unsigned comment added by 195.188.254.61 (talk) 12:20, 18 September 2008 (UTC)
 * Is there a chance of this ever being fixed? There's not much point in having a preview if you lose your place in the edit box every time. Such a pity about this glitch - it spoils an otherwise excellent extension. —Preceding unsigned comment added by 195.188.254.61 (talk) 11:20, 11 November 2008 (UTC)
 * It works for me. Maybe I do not understand what you mean, please describe your problem as detailed as possible, please see the top of this page for relevant information. Thanks, Cacycle (talk) 03:31, 24 November 2008 (UTC)
 * I've just discovered the "Show preview below" button (the small one with the magnifying glass, next to the main Preview button). If you use this, then there is no problem - the edit cursor position is not lost. It seems that you only get the problem if you use the main Preview button. —Preceding unsigned comment added by 195.188.254.61 (talk) 12:30, 5 January 2009 (UTC)

What i hate most about my wonderful WikEd

 * 1) Hides a cue i've spent 5 years getting used to using: when the Subject/headline pane is above the edit one, anything you add after the section heading changes the heading, but when it's below, you can put lots of info that appears only in the edit history. (Or rather, that's how i'm used to it working, so i get reminded bcz i've saved a verbose & unsuitable hdg.) --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
 * Please could you explain this in more detail, I do not recognize this feature. Is it a non-native user script function? Cacycle (talk) 14:30, 13 January 2009 (UTC)
 * Surely i've just described it badly. The situation is creating a new section with the "new section" tab on a talk page, which with my prefs appears as a "+" tab. With the WikEd gadget absent from my prefs, this produces in relevant part (using a handy talk page [wink]):
 *  Editing User talk:Cacycle/wikEd (new section)  From Wikipedia, the free encyclopedia This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes ( ~ ). Subject/headline (Single-line editing pane) (Good-sized rectangular  editing  pane) Content that violates any copyright will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the terms of the GFDL*. (Check box) This is a minor edit (what's this?) (Check box) Watch this page ("Save page", "Show preview", and "Show changes" buttons ) Cancel | Editing help (opens in new window) Do not copy text from other websites without a GFDL-compatible license. It will be deleted.
 * Adding something to each pane and hitting Preview adds something like
 *  Preview 
 * Remember that this is only a preview; your changes have not yet been saved!
 *  test 
 * aksfjasfjdaklj ljkdflaksfj; lksdfjl;askdfj ljkslf;djka
 * above the one-line pane, and a line like
 * Subject/headline preview: (→test: new section)
 * between the two panes.
 * With the WikEd gadget pref'ed on (and even with its toggle set to "classic text area"), the + or "start new section" tab has the same result, except that the WikEd 5x2 set of buttons above the good-sized pane at the right, and i think a few other buttons below it appear. But when text is added to both boxes and a preview is requested,
 * the non-WikEd layout as previously described briefly appears (including the one-line pane replacing the 5x2 set of buttons), then
 * the 5x2 set replaces the one-line pane, and
 * a "Subject/headline" one-line pane appears below the good-sized pane, and
 * the "Subject/headline preview: (→test: new section)" line is now below both the good-sized pane and the "Save..., Preview,..." row of buttons.
 * I consider this a design fault bcz the wording difference ("Subject/headline" vs. "Edit summary (Briefly describe the changes you have made) ) quickly becomes invisible to a regular editor, while the difference in position remains a highly visible and effective cue of the difference between the "Subject/headline" and "Edit summary" panes. That difference is: The contents of the former become both the section heading and (i think suffixed by "new section") the edit summary. The latter begins with the existing section heading which (if not edited or removed) becomes the intro for the edit-specific summary that courteous editors add. A long contrib on a talk page with WikEd gadget-selected invites the editor to put the desired section name in the box, but later (despite the absence of the similarly invisible /* ... */ formatting) construe it as an existing section being updated and deserving an edit-specific summary. (The result of this error is creating a heading that looks like an edit summary. IMO, the normal positioning should be the default; of course i will be delighted to use any config param (whether well or under-documented) to restore normal positioning. --Jerzy•t 23:57, 16 January 2009 (UTC)
 * Fixed in upcoming release 0.0.73. Cacycle (talk) 05:09, 7 February 2009 (UTC)
 * I consider this a design fault bcz the wording difference ("Subject/headline" vs. "Edit summary (Briefly describe the changes you have made) ) quickly becomes invisible to a regular editor, while the difference in position remains a highly visible and effective cue of the difference between the "Subject/headline" and "Edit summary" panes. That difference is: The contents of the former become both the section heading and (i think suffixed by "new section") the edit summary. The latter begins with the existing section heading which (if not edited or removed) becomes the intro for the edit-specific summary that courteous editors add. A long contrib on a talk page with WikEd gadget-selected invites the editor to put the desired section name in the box, but later (despite the absence of the similarly invisible /* ... */ formatting) construe it as an existing section being updated and deserving an edit-specific summary. (The result of this error is creating a heading that looks like an edit summary. IMO, the normal positioning should be the default; of course i will be delighted to use any config param (whether well or under-documented) to restore normal positioning. --Jerzy•t 23:57, 16 January 2009 (UTC)
 * Fixed in upcoming release 0.0.73. Cacycle (talk) 05:09, 7 February 2009 (UTC)


 * If your own completion of edit summaries is more structured than mine, you may find dramatic evidence, in my preceding one on this page, of how visual a summarization style some experienced editors may develop: not being sure how far i would get in that edit, i acknowledged the pseudo-forgery i was doing (i.e., i supplemented the section title with "Remedy insertions into signed contrib"), which had the result that my eye was satisfied that i'd entered a summary, and i saved without noticing i'd made no mention of the substantial part of the edit, namely providing you the further info you requested. --Jerzy•t 19:45, 17 January 2009 (UTC)
 * 1) Navigation popups' edit-pane lk'd-article previews don't work, so i have to click preview and hover in the page preview links to preview the lk'd articles.
 * What is "lk'd-"? Cacycle (talk) 05:09, 7 February 2009 (UTC)
 * 1) If i start typing as soon as the edit pane opens, it disappears from where i put it (and then may show up in an unexpected place, maybe not to be noticed until after i've saved, even if i preview with attention to the part that i intended to change). And the delay until it's safe is frustrating. (Even when i have WikEd suppressed via the edit page control.) --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
 * 2) * Does this still happen with the newest version? Cacycle (talk) 14:30, 13 January 2009 (UTC)
 * 3) ** I de-pref'd WikEd today, did some experiments, and re-pref'd it, which i would assume suffices to ensure it's the newest. I saved a long chunk of text (bcz my first attempts didn't give enuf delay to position the cursor & type in. I clicked edit, positioned the mouse cursor where the middle of the edit box would open, clicked once only on the edit box and immediately after, hit the space bar. The result was a blank inserted at the start of the edit box, and the last half of one line and first half of the next highlighted, indicating to me either an unsolicited change of cursor position or mis-sequencing of the mouse click and keystroke. However, i think i have seen such mis-sequencing on this hardware & Win-version, when the system was otherwise responding to input slower than i could input (perhaps virtual-memory bound?) but not during an edit-window "load-up", and it may be a matter of WikEd being the thing that most reproducibly exercises a weakness that it is not responsible for. Could the old Win have such a vulnerability? --Jerzy•t 23:57, 16 January 2009 (UTC)
 * 4) Altho the case-change button works better than Navigation popups' magnifying-glass/cC-buttons case-change button, the mag-glass button stops working and the WikEd search/repl facility has never made me confident enuf that i'm using it right that i rely on it (rather than switching WikEd off to search & repl). --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
 * What's the problem with wikEd search and replace? Cacycle (talk) 14:30, 13 January 2009 (UTC)
 * I'll continue to investigate whether i'm just still in the initial overwhelm-ment phase of responding to unfamiliar icons & a large set of intimidating surrounding icons. But in using it more, in an attempt to become more articulate abt it, i do note that the default seems to be selecting the first or next occurence of the from-string -- and thus treating change-all as "change next instance" when "Replace all matches in whole text or selection" is used, unless user clicks the good-sized pane again to de-select. --Jerzy•t 23:57, 16 January 2009 (UTC)
 * 1) Switching WikEd on (or off?) clears the selection of text within the edit pane.
 * 2) Hmmm, nagging worry that the wiki-page i originally created (to get Pop-up tools before it was a gadget) is screwing things up now that i have the gadget turned on. --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
 * Try to empty your now useless User:Jerzy/monobook.js page and see if things get better. Cacycle (talk) 14:30, 13 January 2009 (UTC)
 * Done, and that may have at least speeded things up. But i'm not yet willing to treat the Zocky tool as "useless", in light of my tendency to alternate between automated replacements and viewing lk'd pages (via Pop-ups, which remain functional when WikEd is pref'd but toggled off, and thus save need for intervening preview refreshes). --Jerzy•t 23:57, 16 January 2009 (UTC)
 * And is it WikEd that makes long-summary previews fail to word-wrap? --Jerzy•t 07:20, 13 January 2009 (UTC)
 * Please explain in more detail. Thanks, Cacycle (talk) 14:30, 13 January 2009 (UTC)
 * Will do, tho not before the pending save. --Jerzy•t 23:57, 16 January 2009 (UTC)
 * It is indeed WikEd (or combining it with "A clock in the personal toolbar...", which feels too far-fetched to explicitly test!) that has this effect, which i now describe in detail:  Immediately below the single-line pane labeled "Edit summary" there appears the wording "Preview of edit summary" which is followed, usually on the same line, by a representation of how the summary will be rendered in edit histories and the like. With WikEd un-Pref'd, a long summary (i presume any that when preceded by "Preview of edit summary" renders wider than the good-sized edit pane) is "word wrapped" into a two-line form that can be read without scrolling to the right. With WikEd in my prefs (whether the WikEd toggle is set to "classic text area" or not), a sufficiently long rendering instead extends in the window further right than anything else (except for the monobook "wallpaper-like" background graphic).   It may be important to mention that while my Prefs page is exactly the width of the screen, my edit page is wider than the screen (which barely accommodates the good-sized edit pane), even tho what is off the screen to the right (with the window maximized in the default state where the left edge of the page is at the left edge of the screen) is normally only the wallpaper. With WikEd Pref'd, the wallpaper is overlaid by any excess length of the rendering of the summary. If the edit summary renders wider than the minimum edit-page width (which as stated is more than the screen width), it controls the width of the page: the close-paren in that rendering is against the right edge of the page. --Jerzy•t 19:45, 17 January 2009 (UTC)
 * The summary preview is not a standard feature on the English Wikipedia. Please could you tell me which wiki you use or which extension, user script, or gadget is responsible for it. Thanks, Cacycle (talk) 13:42, 2 February 2009 (UTC)

Globally relevant details

 * 1) Thanks for the quick response to my casual kvetching, which shifts me into a much more serious attempt to optimize all of this; sorry i'm so slow in responding.
 * 2) Plz accept my restatement: i am very pleased to be a WikEd user, whether or not the above gets fixed, bcz what i dislike is easily worth the current downsides.
 * 3) I've now blanked my monobook.js, which had the Pop-ups (redundant to Gadget installation), and Zocky SearchBox (even tho it has some small advantages).
 * 4) User:Cacycle/wikEd gadget version seems to say i'd been on 0.9.68a for several days before i left my note, and i presume on 0.9.68 for a week and a half preceding. Observations i henceforth report here are as of the timestamped UTC day unless stated otherwise. I'll be surprised if i ever use other than the gadget installation on :en: WP, and i'll mention it if i give you any observations from other wikis.
 * 5) I am currently using Firefox 3.01 on Win 2000 v. 5.0 SP4. If Win version matters, say so, bcz it is presently subject to promiscuous change. --Jerzy•t 23:57, 16 January 2009 (UTC)

fr translation
Hi, there's a problem with the translation of theses lines : 'wikEdFixUnicode alt':         'Fix Unicode', 'wikEdFixUnicode title':      'Fix Unicode character  representations', 'wikEdFixRedirect alt':       'Fix redirects', 'wikEdFixRedirect title':      'Fix redirects', All the others translation lines work here, but not theses four. Any idea ?

Can you update your example ? Thanks Leag (talk) 12:33, 5 February 2009 (UTC)


 * Hi Leag, sorry, I will update the translations and the example as soon as  possible. BTW, please always use the French translation on en.wikipedia  as I cannot edit the fr.wikipedia version. Cacycle  (talk) 13:32, 5 February 2009 (UTC)
 * I'm sorry too, I had forgotten this file.  I've translate your updates in french but Redirect, Unicode and Sort  don't work anymore. I don't know why. Leag  (talk) 08:58, 6 February 2009 (UTC)
 * The casing of the names has changed (wikEd f ixUnicode  to wikEd F ixUnicode). I will fix  that in all translations as soon as I find some time. Cacycle (talk) 13:23, 6 February 2009 (UTC)

"Sort" and "Unicode" translation work correctly now, but not "Redirect". Thanks Leag (talk) 14:20, 6 February 2009 (UTC)
 * wikEdFixRedirect works now, thanks. Leag (talk) 09:28, 21 February 2009 (UTC)


 * I will add the missing translations of the most recent version this weekend for  translation. There is also a new option to check for missing  translations   Cacycle (talk) 17:56, 21 February 2009 (UTC)

Why is it the various translations (not just the French) are not on translatewiki.net? Urhixidur (talk) 17:36, 16 July 2009 (UTC)

Insertion of "unknown" character
Hi Cacycle, For a while, i have been mystified by the appearance in some of my edits of these characters. I have finally figured out where they came from. They are inserted when wikEd is on and I try to use the javascript accesskeys for; save, preview, content page, main page etc...  It is fully reproducible, though i have no idea why wikEd feels the  need to interfere with these keys. My specific env. is Safari 3.2.1 (5525.27.1) for Mac OS X (this is a nightly build, but earlier versions  have it as well) wikEd 0.9.73 G. The key combo in that case would be  ctrl-alt-s for saving  for instance. --Th e DJ (talk • contribs) 13:57, 18 February 2009 (UTC)


 * Unfortunately, I do not have a Mac to test this. Please could you check if this also happens in other rich text editors such as http://www.kevinroth.com/rte/demo.htm.  Thanks, Cacycle (talk) 14:32, 18 February 2009 (UTC)
 * It does not. On Safari Windows, the key combo's should be alt-? if i remember  correctly. --Th e DJ (talk • contribs) 14:44, 18 February 2009 (UTC)
 * The characters appear to be EF BF BD, and to quote: "If we assume UTF-8 and convert  UTF-8 "ef  bf bd" to its Unicode code point, we get U+FFFD [3].  If we look up  U+FFFD we see that it is the "REPLACEMENT CHARACTER"" --Th e DJ (talk • contribs) 14:49, 18 February 2009 (UTC)
 * I also note that these characters are not visible in WikEd mode. Only when i  disable WikEd after the edit, or when viewing the page after saving, the  problem becomes visible. --Th e DJ (talk • contribs) 15:12, 18 February 2009 (UTC)


 * The "replacement character" is used when conversion of the character fails,  either because there is no such character in Unicode, or more likely  because of a syntax error in the encoding.  Reading a page with the  wrong encoding (e.g. viewing Windows-1252 as UTF-8) shows those.  So, I assume a bad  byte sequence got inserted into the text stream there. —Długosz  (talk) 19:33, 18 February 2009 (UTC)
 * This sounds like a browser bug. I can try to filter that character before  submitting the text. What happens if you do the same procedure with  wikEd toggled off (wiked logo button above the text area)? Cacycle (talk) 22:48, 18 February 2009 (UTC)
 * It correctly processes the action. The problem only occurs when wikEd is  activated, and only when converting from WikEd -> submitted  text. --Th e DJ (talk • contribs) 22:58, 18 February 2009 (UTC)
 * I think it is the browser that erroneously inserts the ctrl-alt-s acceskey as a  character into rich text editors as a strange combination of bytes.  These then get converted to the � character (U+FFFD) at a later stage in  the browser or on the server side. It would be interesteing to figure  out the invisible bytes inserted by these actions: Could you try if this  also happens with ctrl-alt-i  (minor edit) and then use a hex-capable editor an copy and paste the  unsubmitted text. If you see something, try the same on http://www.kevinroth.com/rte/demo.htm  to see if it is Wikipedia only. Then we should probably file a  (WebKit?) bug report. Cacycle  (talk) 14:29, 19 February 2009 (UTC)
 * I think you are right.... It seems as though these keys are linked to some  "standard" editor functions that are also available/show the same  behaviour in TextEdit (our wordpad :D ). I will file a bugreport on  this. (and I hope they don't decide to change the accesskey combo  AGAIN). --Th e DJ (talk • contribs) 15:35, 19 February 2009 (UTC)
 * bug filed. The current talk in IRC seems to be that each document has it's  own accesskey domain. An iframe is a separate document, and thus does  not respond to acceskeys defined in it's parent's view. The specific  keycombination however is linked in the standard US keyboard layout on  Macintosh to a range of characters that are hardly used. Apparently some  of these characters are either no longer valid in utf-8, or possibly  there is an error in on of the conversion routines that the wikEd  javascript uses. --Th e DJ (talk • contribs) 21:20, 19 February 2009 (UTC)

Font too big!!
My edit box, both the main edit area and the subject line, have become "large print". It's about twice the size of normal text on the page, and almost as big as header text.

This is the May 25 edition, and I suppose the problem may have occurred when I picked up that edition.

If I reset the page zoom, it's still larger than the body text.

Długosz (talk) 15:38, 28 May 2009 (UTC)
 * Which browser and operating system are you using (including versions). Cacycle (talk) 01:59, 29 May 2009 (UTC)

I'm using Windows, Firefox 3.0.10.

If there's a way to read out the settings it took and tell you, let me know. Regular content I can examine the DOM and the "generated CSS" for it. But that doesn't show up for the workings of the edit control.

Długosz (talk) 22:25, 1 June 2009 (UTC)
 * Długosz: You can use the "DOM inspector" which comes with the "Web developer" Firefox addon (under Tools:Web developer:Tools:DOM inspector)  on an edit page to check CSS rules and to see the calculated CSS  properties. It would be of enormous help if you could check the font-size properties  and see where their large size originates. The strange thing is that I  have not made any changes to the CSS of the summary or anything outside  the edit window :-S  Thanks in advance, Cacycle (talk) 00:43, 3 June 2009 (UTC)

I didn't know that the DOM inspector would show inside the rich edit control  But it looks like it is a separate document. With the normal text box, there are 26 lines displayed. With yours, in the same size it displays 20. The normal TEXTAREA is the built-in font-size of "medium" and a computed size of  17.2833. With WikEd, the various SPANs that show up for the rich edit has a computed size of 22.98. The only CSS in an enclosing element is that mentions text-size  is the BODY, which has 17.28 as a style attribute of the element.

There does not seem to be any CSS that makes it jump 33%. It is not in the DOM Node. It seems that the size is set directly in the style of the BODY node. It has a Computed Style of 22.98, when the style="font-size:17.2833px" would seem to indicate otherwise.

Thanks, Długosz (talk) 17:03, 8 June 2009 (UTC)

June 10 edition of WikEd, and it's still bothering me greatly.


 * I am really sorry, but I do not have a Mac and I cannot figure out myself  what leads to the large font size. Please could anybody with a Mac try  to figure out where the style for the large font size originates?  Thanks, Cacycle (talk) 23:10, 19 June 2009 (UTC)


 * "I'm using Windows, Firefox 3.0.10."  Not Mac.


 * Use the following in your  monobook.js page to  fix the problem:  Gary King  (talk )  00:40, 20 June 2009 (UTC)
 * Gary King: Thanks for your help! The really really strange thing is that this  style is only applied to the editing frame, not to anything else on the  page. It is beyond my understanding how this could "bleed" into the  rest of the page such as the subject field! BTW, the font size is  currently set to medium, which probably uses your browser preferences - have you set  your default browser font to something very large? Cacycle (talk) 01:31, 20 June 2009 (UTC)


 * It is strange in that the applied CSS shown does not agree with the "computed  values".  Are you sure the script isn't changing them somehow?  E.g.  applying the "text zoom" command for Huge?   Anyway, still doing it with  0.9.81G.  Długosz (talk) 17:07, 22 June 2009 (UTC)
 * In 0.9.81 the script now sets the font size to the same pixel size as that  of the standard textarea. There is no longer a CSS definition for the  font size. Does it work for you? Cacycle  (talk) 17:26, 22 June 2009 (UTC)


 * (Hopefully) fixed in 0.9.81. Cacycle (talk) 04:49, 22 June 2009 (UTC)

Looking at the main document, the DIV wikEdTextareaWrapper has a computed style font-size  16.8833px. This matches the Copyright paragraph later on the page. The wpTextbox1 TEXTAREA I suppose is the original input control and you are hiding it. The CSS is applying the built-in browser style font-size:medium  to that, and computed is 17.2833px. Your IFRAME wikEdFrame has a computed font-size  of 16.8833px.

Diving in, the contained document HTML wikEdFrameHtml has a computed size of 21.2667px, and BODY wikEdFrameBody has a computed size of  22.9833px. There is nothing in the CSS (according to DOM browser) that would make the HTML larger, and the BODY has an explicit font-size:17.2833px,  so the computed style directly contradicts that.

Adding the JS as suggested by Gary King does not have any visible effect. Długosz (talk) 17:31, 22 June 2009 (UTC)


 * Does it work with 0.9.82? Do the classical textarea and the wikEd editing frame  the exactly same text size when you toggle wikEd on and off? If not,  then you might have another script (Greasemonkey?) or plugin changing  the textsize after wikEd set them to exactly the same size in pixels. Or  is a read pixel size not the same as a set pixel size on Macs? Cacycle (talk) 13:44, 26 June 2009 (UTC)


 * Toggling off, this window shows 26 lines. Toggling wikEd 0.9.83a G back  on, 19 whole lines show.  See the paragraph above after the red  highlighting for more details.  Again, nothing to do with Macs  (confusing me with someone else?)  I don't have Greasemonkey installed,  and Stylish is not applying anything.  Is there a way to enable logging,  so I could see what pixel size it is reading and writing, on my  machine?  Have you tried it on Firefox with "Zoom Text Only" turned  (back) on and some zoom value other than 100%?  As I reported earlier, I  don't know the exact value without any plug-ins.


 * Have you turned the [1] button off? Cacycle  (talk) 22:50, 2 July 2009 (UTC)

Font too small
I just realized that my problem is different from the one that the thread starter is having. The font is too small for me on a Mac in Firefox; setting a custom font size of 0.75em makes it just the right  size for me. This still occurs in the latest version of wikEd FYI. <font face="Verdana"><font color="#02b">Gary King (<font color="#02e">talk )  18:21, 22 June 2009 (UTC)
 * Which version is "the latest"? Cacycle  (talk) 13:44, 26 June 2009 (UTC)
 * It happens only if you zoom the page by default with "Zoom Text Only"  selected. Cacycle (talk) 05:09, 3 July 2009 (UTC)

Bug: copy/paste in Safari introduces extraneous line breaks when text is from Word Pad

 * My wikEd version : 0.9.79c (May 25, 2009)
 * My browser id : Safari Version 3.1.2
 * Error console errors : Couldn't find an error console on  Safari's Menu list
 * Which browser add-ons have you installed : Lots of plugins  (too many to list). None seemed relevant to this problem
 * Which user scripts have I installed on my monobook.js page: gWatch
 * Which operating system do you use: Windows Vista SP1 (and Mac OS X 10.4.11 (8S165))


 * Problem: Copy and paste from WordPad (TextEdit on Mac) into edit window when  WikEd enabled causes extraneous line breaks.


 * Steps to reproduce: Enable WikEd. Copy the following  text (except for the  and    tags) to a WordPad file:

Then open a Sandbox, edit it and clear all text. In WordPad, highlight and copy the text given above. Then paste it into the Sandbox edit window. Save the edit and reedit. Extraneous line breaks are added between each line. I first noticed this problem with Safari and TextEdit running on Mac OS X. I then verified the problem also exists on Windows  Vista. This bug is important to me, since eliminating extraneous line breaks is necessary for a workaround of Mozilla bug 18994, which I need  to use for a template I have devleoped. Dnessett (talk) 18:42, 5 June 2009 (UTC)

Bold text
This problem started showing up after I had enabled the new enhanced toolbar in the preferences. If I have wikEd enabled (but editor mode disabled), and press enter/return in the "edit summary"-field (in order  to submit the form), the Bold text is added after the  cursor position in the textarea and this is then submitted. This happens on at least Safari 4 and Chrome (Jarry). If i disable wikEd with it's "p-personal" icon, the problem does not occur. —Th e DJ (talk • contribs) 23:09, 16 July 2009 (UTC)
 * Happens only in Chrome >= 2.0, will check into it. Thanks, Cacycle (talk) 13:57, 20 July 2009 (UTC)

Lingering ctrl-click bug
Last week I was making a difficult edit on a user talk page involving a lot of brackets and assorted wikicode, and for some reason at one point it  added "ctrl-click"  into one of the nowiki tags. I don't know why this is. I have seen no sign of the much more prevalent ctrl-click bug that inserts it into external  links, and my guess is that I'll never be in whatever odd combination of  circumstances it would take to trigger this bug again, but I wanted to  let you know that it had happened. I'm on Windows Vista with Firefox 3.0. -- <B>Soap</B> Talk/Contributions  17:08, 24 July 2009 (UTC)
 * Thanks for reporting this, it happens reliably with "User:". Probably not very common but I  will fix it anyway :-). Cacycle (talk) 17:27, 24 July 2009 (UTC)

Custom button help
About as far as I could get with the custom button code, was changing the actual 2 images used and the wikEd names (see wikEdTB and wikEdSig)  but can't figure out how to make them do what I want. How would I change... // define  custom buttons (id, class, popup title, image src, width,  height, alt text, onClick and parameters) var wikEdButton = {}; wikEdButton[100] = ['wikEdTB', 'wikEdButton', 'Supposed to be signature', 'http://upload.wikimedia.org/wikipedia/commons/6/67/Button_BY.png',  '16', '16', 'DIV', 'javascript:WikEdEditButton(this, this.id, null,  TestHandler);' ]; wikEdButton[101] = ['wikEdSig', 'wikEdButton', 'Supposed to be talk back', 'http://upload.wikimedia.org/wikipedia/commons/5/5f/Button_rediriger.png',  '16', '16', 'Test', 'javascript:WikEdEditButton(this, this.id, null,  TestHandler);' ];

// define custom button bars (id outer, class outer, id inner, class inner, height, grip title, button numbers) var wikEdButtonBar = {}; wikEdButtonBar['custom1'] = ['wikEdButtonBarCustom1',  'wikEdButtonBarCustom1',   'wikEdButtonsCustom1',  'wikEdButtonsCustom1',  44, 'My custom buttons',  [100, 'br', 101] ]; wikEdButtonBar['custom2'] = ['wikEdButtonBarCustom2',  'wikEdButtonBarCustom2',   'wikEdButtonsCustom2',  'wikEdButtonsCustom2',  44, 'My custom buttons',  [100, 'br', 101] ];

// define the function which is called upon clicking the custom button // this example code adds or removes div tags around the selected text

function TestHandler(obj) {

// select the appropriate text change target (whole, selection, cursor,  focusWord, focusLine, selectionWord, or selectionLine) //  focus... is the text under the cursor; ...Word and ...Line extend the target to the start/end of the word or line WikEdGetText(obj, 'selection, cursor'); if (obj.selection.plain != '') { obj.changed = obj.selection; } else { obj.changed = obj.cursor; }

// make the changes to the plain target text

// remove the previously added formatting if ( /&lt;div&gt;(.*?)&lt;\/div&gt;/i.test(obj.changed.plain)  ) { obj.changed.plain = obj.changed.plain.replace(/&lt;div&gt;(.*?)&lt;\/div&gt;/gi,  '$1'); }

// add the text formatting else { obj.changed.plain = '&lt;div&gt;' + obj.changed.plain + '&lt;/div&gt;'; obj.changed.plain = obj.changed.plain.replace(/(&lt;div&gt;)( *)(.*?)(  *)(&lt;\/div&gt;)/, '$2$1$3$5$4'); }

// keep the changed text selected, needed to remove the formatting with a second  custom button click obj.changed.keepSel = true;

return; }

...so that when I click the first one, at the cursor, it adds and when I click  the second one, at the cursor, it adds  ? This adds a 1 click Talkback button and a 1 click Signature button. I tired using User:MarkS/extraeditbuttons.js but for some reason, it will only work on User: and User talk: pages, which means I can't use it for a 1-click signature  option at many places such as ANI, Afd, etc. That's really all I need  is these 2 extra edit buttons and not all of the full features wikEd  offers but it's the only way I see now that I can get these 2 edit  buttons. So any help in making them work would be much appreciated. -      allstar ▼ echo     05:54, 11 August  2009 (UTC)

Beta Açai
I'm using Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) and wikEd 0.987 G, and  the new user interface bêta Açai. I noted that when I enable wikEd, I can no longer use the buttons from the Wikipedia toolbar. I can develop the advanced menus but any click on a button results in nothing  happening. I suppose that the form where wikEd edits the text is not recognized by the Wikipedia toolbar. --Gandalfcobaye (talk) 17:29, 21 August 2009 (UTC)


 * The WikiEd documentation specifically mentions not being compatible with the  Wikipedia toolbar. I'll go find the section.  --King Öomie 17:39, 21 August 2009 (UTC)
 * I'm not sure we're talking about the same thing, because in the normal interface  (the one before Açai), I could click on any of the Wikipedia buttons  and it worked good, like the signature button or any other. Now it  doesn't anymore. --Gandalfcobaye (talk) 17:59, 21 August 2009 (UTC)
 * Oh. Well, then I'd post this report to the maker of the Firefox skin you're  using. I seem to be unable to find the one you're talking about, but if  it includes code to alter the appearance of buttons, it may be causing  your issue.  --King Öomie 18:06, 21 August 2009 (UTC)
 * Again we're misunderstanding ourselves. The Wikipedia toolbar which I talk  about is the one proposed by Wikipedia and that is included each time  you edit an article. Nothing to do with Firefox or Safari or any skin at  all. Here  you can see it, with a and a,  etc, the advanced buttons like format, edit etc. --Gandalfcobaye (talk) 07:57, 22 August 2009 (UTC)
 * This has already been fixed and we are just waiting for the fixed version to  become active, see bug 20134.  Cacycle (talk) 04:47, 28 August 2009 (UTC)

Suggestion: auto-preview without sending to server
Congratulations on WikEd - it's a great tool! It seems to me that the preview is still done by sending the wiki code to the server to convert to an HTML  preview. Would it be possible to instead put the formatter inside the browser and distribute it with WikEd? [slightly edited since my first posting]  That would reduce latency for previews and reduce the load on the  server if the code is cached in the browser. When WM updates its formatter, WikEd would push a new version to the browser. This would also allow to implement as-you-type  preview as an option for the wiki code close to the cursor. -Pgan002 (talk) 22:55, 24 August 2009 (UTC)


 * That'd work great for testing formatting, but you wouldn't be able to use the  preview to check for redlinks (as an embedded library wouldn't know  which articles do/don't exist). I'm constantly using it for that.  --King Öomie 02:27, 25 August 2009 (UTC)


 * Yes, the main problem are redlinks and, especially, templates and images.  wikEd can actually do a completely local preview (add "var  wikEdUseLocalPreview = true;" to your monobook.js/vector.js), but there  is no way it could render templates, images, and links correctly and  since it only simulates the server rendering, there is no guarantee that  the results are identical, especially for incorrect wikicode. Cacycle (talk) 00:25, 28 August 2009 (UTC)


 * Hmm, I can see it's more complicated than I thought. But in time it can be  done well. For example, links should be checked with a special-purpose service  that transmits only whether the page exists (or a summary suitable for Navigation pop-ups). This can then be used even  during editing in WikEd.  As for images, can WikEd look for suitably  named images in the browser cache? Templates can be requested separately  and formatted by the server. -Pgan002  (talk) 08:19, 8 September 2009 (UTC)

Bolding of links inside references and citations
Why does WikEd bold links inside references and citations? Being bold blue-on-gray, they  stand out more than other text -- too much, I think. I'm using WikEd 0.9.87 G (August 12, 2009) and Firefox/3.0.11 Gecko/2009060215 on Linux. -Pgan002 (talk) 06:41, 25 August 2009 (UTC)
 * It is just that links are always bold blue in order to stand out. Why should  that be different in references? Cacycle  (talk) 17:34, 29 August 2009 (UTC)

Text size cycling in Subject field on talk pages
Text size (zoom) cycling does not affect the size of text in the Subject field on talk pages. I think it would be preferable if that text size too was changed, not just the size of text in the main text box. -Pgan002 (talk) 06:46, 25 August 2009 (UTC)


 * If you want to increase the text size in general, why don't you use your  browser zoom setting? Cacycle  (talk) 17:36, 29 August 2009 (UTC)

WikiEd, I love it except...
When I copy and paste stuff, it shows up in the same font size as where it came from. This "Editing User talk:Cacycle (new section)" looks huge to me, for instance, and is underlined. I just figured out the [W and [T buttons, but can't it just default to that? Or maybe there's something good about how it copies and pastes, and I just don't realize  it. Thanks. - Peregrine Fisher  (talk) (contribs) 18:17, 27 August 2009 (UTC)


 * Thanks for your comment. No, there is not much good about it (beside that it  allows you to convert/import the pasted text into wiki code).  Unfortunately, there is no simple way to realize automatic syntax  highlighting, please see User:Cacycle/wikEd_help for more details and feel also  free to vote for this Firefox feature request 458524.  Cacycle (talk) 20:46, 27 August 2009 (UTC)


 * I voted, or at least I think I did. I  left a comment, if that's the same as voting.  There, I chose a  question mark from one of those drop down boxes too.  Now that I think  about it, I use Google Chrome.  It has the same problem, or uses  Bugzilla, or...? -  Peregrine Fisher  (talk) (contribs) 22:15, 27 August 2009 (UTC)


 * Commenting is not the same as voting. The developers much prefer you use the  voting mechanism for this kind of feedback rather than leaving a  comment. See the ( vote ) link in the top  section of the bug report. —GregU (talk) 15:27, 4 September 2009 (UTC)

Sort
Hi, a french user report me a bug with sort functions. In this page the sort button don't sort lines alphabetically. Can you explain this problem ? Thanks Leag (talk) 08:01, 28 August 2009 (UTC)
 * Strange indeed, I will check into this. Cacycle  (talk) 12:54, 28 August 2009 (UTC)
 * Fixed in the current version 0.9.88
 * Thanks a lot. Leag (talk) 08:51, 4 September 2009 (UTC)

wikiEd on wikia
I've installed wikiEd on a wikia project but it doesn't seem to work. Wikia runs MediaWiki. http://docs.wikia.com/wiki/MediaWiki:Common.js I've also tried it in my personal .js page   but that didn't work either. Clearing cache and purging didn't help. -- penubag  (talk) 17:04, 31 August 2009 (UTC)
 * Fixed in the current version 0.9.88a. You have to turn off rich text editing in  your Wikia preferences. Cacycle  (talk) 04:20, 4 September 2009 (UTC)

Inter-wiki wikEd link

 * Hi it might be usefull for users if you changed the comment in wikEd_installation#Complete_version: // install User:Cacycle/wikEd in-browser text editor into: //  install wikipedia:User:Cacycle/wikEd in-browser text editor This way they can  copy&use the wiki code,  wikipedia:User:Cacycle/wikEd , to your wikEd page without  modifications. This probably works for all MediaWiki wiki's.
 * --TriMoon (talk) 13:52, 11 September 2009 (UTC)
 * Done, thanks. Cacycle (talk) 00:09, 12 September 2009 (UTC)

Pipelinks
Could the button that removes wikilinks be altered so that it also removes pipelinks? Epbr123 (talk) 10:24, 1 September 2009 (UTC)
 * This. This. THIS. Circeus (talk) 16:30, 1 September 2009 (UTC)
 * This has been added to the current version 0.9.88. Cacycle (talk) 03:17, 4 September 2009 (UTC)

Problem in highlighting/hiding references
There's a problem in highlighting/hiding references when citation templates are present. See below

<tt>text text text text wrongly highlighted as part of reference. text correctly not highlighted</tt>

93.47.28.160 (talk) 19:32, 3 September 2009 (UTC)


 * Since the current highlighting is regular expression based it cannot  distinguish between table cells and template parameters, it just assumes  a table cell for every line starting with a |. The new highlighter that  will come soon is a real parser with support for nested code. Cacycle (talk) 22:12, 3 September 2009 (UTC)

.wikEdSummaryText
Hi, it's me again. On french wikipedia the width of the summary text is to small. We can only see 21 caracters. I looked at your script and I find this line who seem to control the width : '.wikEdSummaryText':           'vertical-align:  0%; padding: 0; margin: 0; position: absolute; z-index: 2; -moz-box-sizing: content-box; left: 0;  top: 0px; height: 18px; width: auto;', Have you an idea ? Thanks Leag (talk) 08:56, 4 September 2009 (UTC)
 * It works fine for me under Firefox and Seamonkey. Please file a complete bug  report (see page top). Thanks, Cacycle  (talk) 16:43, 4 September 2009 (UTC)

wikiEd on wikia
I've installed wikiEd on a wikia project but it doesn't seem to work. Wikia runs MediaWiki. http://docs.wikia.com/wiki/MediaWiki:Common.js I've also tried it in my personal .js page   but that didn't work either. Clearing cache and purging didn't help. -- penubag  (talk) 17:04, 31 August 2009 (UTC)
 * Fixed in the current version 0.9.88a. You have to turn off rich text editing in  your Wikia preferences. Cacycle  (talk) 04:20, 4 September 2009 (UTC)
 * Thanks, it works under my login but I'm having trouble with all other users  because richtext editing is enabled by default. So I have to deactivate  WikiED as the 2 are incompatible. This is probably out of your league,  but any ideas?-- penubag  (talk) 08:00, 5 September 2009 (UTC)
 * There is no simple solution, if your users want to use wikEd they have to  disable rich text editing in their preferences. You might want to make  wikEd a gadget which can then also be selected in the preferences,  please see User:Cacycle/wikEd installation and http://help.wikia.com/wiki/Help:Gadgets.  Cacycle (talk) 16:30, 5 September 2009 (UTC)

Losing focus when loading WikEd
When WikEd first re-formats the wiki code, is there any way to preserve the caret (or remember its  location and re-instate  it)? This would avoid a usability problem where a user starts editing the document while WikEd is loading, then when WikEd has loaded, she  discovers she's typing at the top of the document or nowhere at all. -Pgan002 (talk) 08:46, 8 September 2009 (UTC)
 * That sounds like a bug of the new enhanced editing toolbar which steals the  focus, see bug 20498.  Cacycle (talk) 03:24, 9 September 2009 (UTC)


 * Thanks, Cacycle! WikEd also selects the text after pressing the [W] and [T]  buttons, thereby losing the cursor position. Is that part of the same  bug? -Pgan002 (talk) 08:35, 15 September 2009 (UTC)

Request to highlight links to dab pages
The project WP:DPL seems to be forever fighting links to disambiguation pages. There are frequently over 100K. Would it be possible for wikEd to somehow highlight these wikilinks, perhaps with  a different color like purple? This would help editors avoid introducing them and make it easier for others to fix them when they are  editing related text. Thanks! UncleDouggie (talk) 09:34, 10 September 2009 (UTC)
 * That sounds like an interesting gadget or user script, but it is problematic  because it mangles English Wikipedia specific content (a certain  category link on a page) with a universal software that is widely used  outside Wikipedia. Beside that, the software would have to fetch the  article text from all links from one page which sounds like a big  performance and resource issue. It is probably easier to use the popups  gadget on suspicious links. Cacycle  (talk) 13:47, 10 September 2009 (UTC)
 * I see the problem. A full list of dab pages is unworkable as well because  there are 115K on the English WP. I'm going to instead propose an option  to have the WM SW format dabs as purple in the main display, just like  broken links can be shown in red. UncleDouggie (talk) 20:12, 10 September 2009 (UTC)
 * There has been a lengthly discussion under Village  pump (proposals)/Archive 52. Essentially, such a proposal  would not have any chance to be implemented, partly because of the  reasons I gave above, partly because of usability issues. A gadget could  actually do what you want in a more resource-economic way by  reading a page with all existing dab pages (which would have to be  maintained by hand (or  semi-automatic).  I suggest to create a stand-alone gadget  for this, but if it exists I would adapt wikEd so that it also works in  edit windows.  Cacycle (talk) 22:01, 10 September 2009 (UTC)
 * Thanks for the link! Buried in the discussion I found that the problem has already been solved with the script User:Anomie/linkclassifier.js. It's working great for me, I  don't notice any performance impact at all. I didn't like the default  colors, so I'm using a toned down set. Dab links <font style="background-color:#ffff88">look just like this  for me now. It would be great to incorporate this into wikEd. I'm using  the beta interface, so my settings are at User:UncleDouggie/vector.js and User:UncleDouggie/vector.css. The same code can be run in the  monobook skin files. The .js file also has my enhanced version of  converting talk page comments to local time. UncleDouggie (talk) 02:59, 11 September 2009 (UTC)

reg. exp. search does not seem to work correctly.
(moved here from User_talk:Cacycle/wikEd_help Cacycle (talk) 13:33, 14 September 2009 (UTC))

I was searching a page for occurance of numbers using the reg.exp. \d+ and switching on /R/. This does not seem to work; if I click "find next match", nothing happens, if I click "find previous  match", I find some matches but skips others and sometimes the match is  incorrect (eg. it found "20" in "2009", where it should have found the  entire number). I also tested with this page: it seems to work at first but eventually it cycles between finding "2" and "008" in "2008" and  doesn't find anything else anymore. I'm using Chrome 2.0.172.43 on Windows XP sp3. I checked if there were any JavaScript errors, but there didn't seem to be any. — <TT style="color:#008000;font-size:120%;">SkyLined</TT> (talk) 07:55, 14 September 2009 (UTC)


 * The search works fine in Firefox, the problem happens only in Chrome. I will  try to figure out why but it may take a while. Thanks for reporting, Cacycle (talk) 13:49, 14 September 2009 (UTC)

References pop-up is intrusive
When references are hidden (the "R" button in the 5th panel), hovering over a reference makes it pop up (almost?) immediately. That makes it very annoying to accidentally hover over a reference, which happens  often, especially for articles with many references. The references should pop up with a delay of about 1 second. That would make editing and viewing references a but slower, but navigating and editing the rest  of the text much easier. I'm sure there is a parameter for the delay, but I could not find it in the source code. You could require the user to press the "ref" button to see the reference, but that is less  desirable than a small delay.

Another way to make the references pop-up less intrusive is to make it an editable tool tip. I think it is better to obscure some text than displace text.

-Pgan002 (talk) 08:55, 15 September 2009 (UTC)


 * I guess if it looks like a button, we could actually make it act like a button  (it actually is css-inserted  text that does not really exist in the realm of the rest of the text) - i.e. clicks  will opens and close the folded code. I will experiment with it for the  next big release (which is coming soon and will have a real wiki syntax  parser instead of regular expressions, so the code folding will never  hide regular parts of the article if there are wikicode errors on the  page). Cacycle (talk) 12:53, 15 September 2009 (UTC)

Replace and search for next match
I think it would be useful if, after a replace, WikEd automatically finds the next match. When would a user want to not see the next match? Maybe if she wants to find the previous match instead, or stop replacing, without seeing the next match. In any case, it seems very rare. And in those rare cases, the user can return to the previous replace using Undo. -Pgan002 (talk) 06:48, 16 September 2009 (UTC)
 * A user (talking about myself) might want to see the applied change, especially  if the result is somewhat unpredictable as for many regexp  substitutions. And I hate to use undo/redo just to review what just  happened. :-)  Cacycle (talk) 03:01, 17 September 2009 (UTC)

Syntax highlighting: Self-closed single tags, that have no explicit  closing tags.
Hi, it seems you syntax-highlighting code can't handle self-closed single tags, that have no explicit closing tags. eg: vs    Is there any chance you could correct this? &lArr;&uArr; ©TriMoon™ Talk  @ 12:11, 17 September 2009 (UTC) and    in this diff  is responsible.
 * This will be fixed with the new real wiki code parser for highlighting in the  next release. The current version does actually support self closing  tags that make sense, such as

I've tested under firefox 3.5 (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.3) Gecko/20090915 Ubuntu/9.10 (karmic)  Firefox/3.5.3),  chromium (4.0.212.0  (Ubuntu build 26652))  and opera 10 (Opera/9.80  (X11; Linux x86_64; U; en) Presto/2.2.15 Version/10.00) and only firefox and  chromium had this problem, however something else is wrong with opera  because wikEd doesn't work at all there. I've disabled all other gadgets and userscripts.

-- Nx  / talk   21:14, 20 September 2009 (UTC)


 * Confirmed with the visible nbps. I think that wikEd is only officially supported in Firefox, and not in other browsers like IE and Opera. <font face="Verdana"> Gary King  ( talk )  00:19, 22 September 2009 (UTC)


 * wikEdDiff and the underlying diff work in all browsers, I will fix this as soon as I find the time. Cacycle  (talk) 03:44, 23 September 2009 (UTC)
 * The &amp;nbsp; bug has been fixed (Shift-Reload this page  to upgrade if needed). Cacycle  (talk) 13:37, 23 September 2009 (UTC)
 * Thanks. -- Nx  / talk   14:45, 23 September 2009 (UTC)

Auto-fix button (two ticks) capitalises first letter of infobox fields
As per title, the auto-fix (two ticks) button ("Fix basic html, capitalization and Unicode") automatically capitalises the first letter of every  argument/field in an infobox. This renders most infoboxes blank save for the title upon submission. It should leave the arguments/field names lowercase.

WikiEd 0.9.88b (September 16, 2009) in Mozilla/5.0 (Windows; U; Windows NT  5.1; en-US;  rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) — Hugh  08:56, 24 September 2009 (UTC)
 * Please use that button only on selected text, never on whole articles. wikEd  cannot easily detect if a line starting with | is a table cell or a  template argument. This might be  possible at a later point after the  wikicode parser has been implemented though. Cacycle (talk) 13:41, 24 September 2009 (UTC)

Button images are constantly reloaded
It seems that I too have a problem that is described here. It occurs in an unpredictable fashion and is very irritating. It is difficult to tell what's wrong, but I'm pretty sure about the following: Is anyone having the same problem? Does anyone know how to fix it? GregorB (talk) 07:50, 28 September 2009 (UTC)
 * 1) On a  clean browser (run in safe mode, i.e. without extensions) everything  seems to work fine; therefore, wikEd is not really to blame here
 * 2) If an  extension is causing it, it's not Greasemonkey, and it's not Adblock  Plus


 * I have checked the network traffic with Firebug a while ago, the images are not  actually reloaded if you reload the page through the "Reload" button  (i.e. they do not go from empty placeholder to image). The browser  instead checks after loading the page with cached image versions if  there are newer version on the server and receives "304 Not modified"  messages. When the browser freezes (e.g. due to Firefox 3.5 bugs that  slow wikEd down), the status bar might also freeze on one such requests  with a "Transfering data from..." message. Is that consistent with what  you see? Cacycle (talk) 00:43, 29 September 2009 (UTC)


 * Well, the browser behaves as if it saw these images for the first time and has  to fetch each and every one. I'm not up to scratch with the HTTP  expiration mechanism so, frankly, I'm not sure what is supposed to happen. Whenever I inspect the  browser disk cache, I find these images with a 2010 expiry date. Whether  the images are actually fetched, or the alternative  mechanism (conditional GET and 304 response) becomes too slow for some  reason, I can't tell. Pressing "Reload" always works as expected. GregorB (talk) 11:49, 30 September 2009 (UTC)


 * The only other possibility that comes to my mind is an autoupdate mechanism  gone haywire... Would you mind disabling it and see if it still happens?  Just add "var wikEdAutoUpdate = false; to your monobook.js/vector.js.  How often does this reload actually happen (more often than new updates  appear? Every two days (= autoupdate?)). The Ajax autoupdate checks  every two days for the newest version  number on non-edit pages and  clears the browser cache if it finds one (equivalent to Shift-Reload). Thanks,  Cacycle (talk) 13:08, 30 September 2009 (UTC)


 * Unfortunately, toolbar images are reloaded much more often; sometimes as often as 3 or 4 times in 10 minutes. I'm not sure if autoupdate has  something to do with it, but I'll try it nevertheless and post a follow-up here. GregorB (talk) 17:30, 30 September 2009 (UTC)


 * Thanks in advance :-) It might help if you could report you system / browser / connection  details (see top of page). Are you using anything that prevents cookies  to actually be changed (Privacy mode browsing...) or WOT? Cacycle (talk) 18:25, 30 September 2009 (UTC)

UPDATE: Fixed under Firefox 3.6b4? Download this beta and see if the JS responsiveness improves. see this bug report. I myself am seeing an improvement. ---Schweiwikist (talk) 12:58, 28 November 2009 (UTC)
 * Just installed 3.6, and it looks good! From what I can tell after 30 minutes  of editing, the problem is now gone. GregorB  (talk) 22:11, 21 January 2010 (UTC)

Signature button
I think a button for adding a signature would be helpful.--Marcus Brute (talk)  00:48, 29 September 2009 (UTC)

Redirect fixer does not work
I edited Template:Oryzomyini nav to fix the links  to redirects on that page. When I click the redirect fix button, nothing changes, even though there are lots of links to redirects on that page  that could be fixed.
 * WikED version: 0.9.88b G
 * Browser id: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3)  Gecko/20090824 Firefox/3.5.3
 * Errors: None.
 * Add-ons: ChatZilla.
 * User scripts: User:Dr_pda/prosesize.js
 * OS: Mac OS X 10.5.8
 * Problem:

Thanks for making this tool, Ucucha 00:36, 13 October 2009 (UTC)
 * Thanks for reporting this, I will check this as soon as I can find some time.  You can try it on smaller sections. I also noticed that fixing Cerradomys  andersoni gives a  wrong character encoding. Cacycle  (talk) 03:28, 13 October 2009 (UTC)


 * Thanks. Yes, there are some other problems with one of the fix buttons. I  remember that it capitalized the possessive "s" in names like "Nelson's  Rice Rat". I'll do a more detailed report on that when I have time. Ucucha 13:43, 13 October 2009 (UTC)
 * You have pushed the [H2O] button to fix chemical formulas. Cacycle (talk) 04:20, 17 October 2009 (UTC)
 * That makes sense. Thanks. Ucucha 10:46, 17 October 2009 (UTC)

You had simply too many links for that button, the server returns an error message if the request gets bigger than 8 KB. Please use smaller  chunks until I have added a workaround. Cacycle (talk) 04:37, 17 October 2009 (UTC)


 * Fixed in upcoming release. Cacycle (talk) 06:05, 17 October 2009 (UTC)
 * Good, thanks. Ucucha

There is another problem with the redirect fixer: when I did this edit (in chunks, to avoid hitting the 8 kb limit), it did not fix the  redirects of any links with an apostrophe in the link text. Ucucha 12:53, 17 October 2009 (UTC)
 * That has already been fixed, too. Cacycle  (talk) 16:55, 17 October 2009 (UTC)

Speed of loading and caching in Firefox 3.5.3 (OS X Tiger [PPC])
Hi again after a long while. I saw that in your description of the Ref button &mdash;  &mdash; since  you use the ref tag without content, and had no Notes section, you  wound up with an unsightly "Cite Error" at the end of the Help page. All fixed, in a useful manner.
 * UPDATE: Did similar work with internal wikilink and external weblink buttons.  Saving these edits produced unexpected code to appear, and it had to be  carefully debugged from archived versions, so take a look via the recent  history, will you? - -  - - Schweiwikist (talk) 15:27, 16 October 2009 (UTC)


 * Thanks, looks good. Cacycle (talk) 06:12, 17 October 2009 (UTC)

As a return favor, here’s a question and/or challenge:

Even on a fast 1-year-old MacBook with plenty of wireless broadband available, it takes an extra fraction  for wikEd to first load (Firefox 3.5). Once it’s cached it reloads "instantly", but apparently Firefox may flush it back out of its cache  after some amount of inactivity, and the lag reappears. On my much older PowerBook (running Tiger), which has its bandwidth limited, this lag is  much more noticeable (and annoying), especially the loading of the  toolbar icons. I thought this might be due to the fact that I had implemented wikEd before it became an official WP gadget, so it was part  of my monobook.js page already, and I’d also enabled wikEd as a gadget  in prefs. So I turned it off in prefs instead. It still initializes slower than I'd like. I wonder if there’s a way to tell Firefox to lock it into the cache, or pre/reload  it whenever loading a WP page, rather than when starting an edit  session. Would it help if I left a "dummy" edit page open, and refreshed it regularly? In any case, eventually this will be less of a hassle once the population of Intel processors in our household doubles. Thanks again for a product I value every day. Schweiwikist (talk) 14:14, 16 October 2009 (UTC)


 * UPDATE: Sorry (sheepish shrug), didn't notice the above discussion. If this is a  Firefox issue, then never mind. At least I brainstormed a workaround or  two. Thanx again. Schweiwikist (talk) 14:22, 16 October 2009 (UTC)


 * Which above discussion are you talking about? Would you mind posting a  complete system report (see top of this page)? Does it happen on very  short pages as well? Does it happen for Reload clicks only or also for  normal link clicks? It would be great if you could install the Firefox  extension Firebug  and check  the Net tab  for the loaded images and the server response.   Thanks, Cacycle (talk) 06:12, 17 October 2009 (UTC)


 * Hi, it’s the section here.  I'll work on the research you are requesting right away, and thanks for  the pointers. Schweiwikist (talk) 04:16, 21 October 2009 (UTC)
 * FIRST FOLLOWUP: Here’s my system info: Mozilla/5.0 (Macintosh; U; Intel Mac OS X  10.5; en-US;  rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Schweiwikist (talk) 04:20, 21 October 2009 (UTC)
 * SECOND FOLLOWUP: Got Firebug working (forced it to run under Firefox 3.5.3).  I'm not sure how you'd like me to convey the response times, but to load  this edit session, the total was as follows: 77 requests, 42KB, 3.49s.  This on the intel MacBook with the hi-speed wireless (max 12Mb/sec). I do see  long "waiting for response" (the purple bars) times from  upload.wikimedia.org for several of the toolbar icon pngs, most notably  several of the "fix" icons. BTW, they load last. All that occurs to me  about this is that throughput might improve if the clickable tools were  implemented via imagemaps, if such a thing is possible. Firebug is quite  a tool! Schweiwikist (talk) 05:09, 21 October 2009 (UTC)
 * THIRD FOLLOWUP: Looks like it's an add-on issue. Disabled all add-ons and problem goes away. More on this very shortly. Schweiwikist (talk) 14:43, 21 October 2009 (UTC)
 * FOURTH FOLLOWUP: Not an issue with add-ons. Problem didn't disappear by turning  them off (on my intel mac). This seems to be a Firefox/js bug. Users  with slow-reloading  button icons, try this test. 1. Clear the FF cache and leave only one  browser window open (to optimize throughput). 2. Invoke a WP edit  session from a WP page. 3. As wikEd loads, and icons slowly begin to  appear, click the "back" button, interrupting the process. Check to see  whether button icons all become visible just before previous page  displays. 4. Now click the "forward" button. wikEd loads faster, and  button icons seem to load all at once. This behavior doesn't make a lot  of sense, but at least it's reproducible. After completing step 4, quit  and relaunch firefox (configured to "remember" previous state) and see  how wikEd reloads, with the back and forward buttons. We could also try  this with FireFox's disk cache set to zero, and then various multiples  of 16KB. See how that makes a difference. Maybe wikEd ought to be an add-on itself.Schweiwikist (talk) 08:53, 22 October 2009 (UTC)

Duplicate editnotice in portuguese wikipedia
It seems wikEd is duplicating editnotices in portuguese wikipedia. See this example in sandbox and this example in Água article (you must activate wikEd in preferences->Gadgets->Edição->wikEd). This only happens on first edit and not in preview. Since this doesn't happens on english wikipedia editnotices, may be we have some problems  with editotices code. I can't find anything wrong in pt:MediaWiki:Editnotice-0 and pt:MediaWiki:Editnotice-4-Página de testes. At first the browser loads the editnotice, then when it loads the wikipedia toll bar and wiked tool  bar, shows another editnotice. It happens in the following configurations:
 * wikEd version 0.9.88b G, Firefox 3.5.3, Win x64
 * wikEd version 0.9.88b G, Firefox 3.0.14 for Ubuntu 1.0, Ubuntu 9.04 x86

I have a lot of add ons and some scripts. If you can't see editnotice duplicated I can give more details and test other configurations. I don't know if this happens only to me. Mosca (talk) 18:25, 16 October 2009 (UTC)
 * It is a feature, not a bug. It allows you to see the notices despite being  scrolled down automatically. Cacycle  (talk) 04:14, 17 October 2009 (UTC)

simplifyLinks code
The above code will convert valid UTF-8 anchor encoded string (.28) into compatible character. — Dispenser 20:34, 20 October 2009 (UTC)


 * Why are you posting that Python code here? Cacycle  (talk) 22:37, 20 October 2009 (UTC)


 * Because if you reject the idea ask you did with the other code I don't have to  waist time converting it.  —  Dispenser 23:04, 20 October 2009 (UTC)
 * I still have not the slightest idea what you suggest and how it relates to  wikEd. Please provide the necessary context and background. Thanks, Cacycle (talk) 01:17, 21 October 2009 (UTC)
 * The code above will simplify link such as   into  .  — Dispenser 02:19, 21 October 2009 (UTC)
 * Dispenser: if you imply that WikEd should start simlifying links I think you had to say it outright. P.S. My script user:js/urldecoder can simplify http and internal  links (although of course it's not compatible with WikEd).  — AlexSm  16:15, 21 October 2009 (UTC)
 * Sorry I though it was clear enough.  Interesting script, it seems that we  both have taken two different ways of dealing with the problem, your  converting character by character while I'm converting the valid values  into a percent encoded string then converting it.  It also seems that  we've encountered different edge cases.  Here's the combined list of  what we should avoid, HTML tags, character entities (&amp;…;),  wikicode which is parsed into HTML, %XX (or .25XX) since the software  screws that up.  — Dispenser 03:08, 22 October 2009 (UTC)


 * When and where are dot-encoded links used in MediaWiki. I see that they work, but where do they originate and have to be dealt with? Cacycle (talk) 13:53, 22 October 2009 (UTC)

Redirect fixing
The "fix redirects" function seems to clash with WP:REDIRECT, see also About fixing redirects. Are there uncontroversial uses for this tool? At any rate, a reminder for users might be helpful to avoid needless reverts. Regards, Paradoctor (talk) 13:47, 31 October 2009 (UTC)


 * The function should indeed be used with care. However, the text you cite  also lists legitimate uses of redirect fixing, and wikEd is very  convenient for that. I used it to fix the tons of redirects in Oryzomyini nav,  for example, which is a legitimate use of the function. Ucucha 14:07, 31 October 2009 (UTC)


 * "with care": So I noticed. ;) From the looks of it, it shouldn't generally be  used on normal articles, so a warning for powern00bs like me would be  appreciated. Paradoctor (talk) 14:46, 31 October 2009 (UTC)

Config issue- font
I'm sure this is a gigantic noob mistake, but am I missing something, or should var wikEdFrameCSS = {}; wikEdFrameCSS['.wikEdFrameBody'] = 'background: #FFFFFF; margin: 0px; padding: 0.2em;  overflow: -moz-scrollbars-vertical;  overflow-x:  auto; font-face:  arial;'; ...change the editbox font to Arial? It's correctly placed before the install script, but it doesn't actually change anything, regardless of  what I throw in the place of font-face (or font-family). -- King Öomie 15:48, 4 November 2009 (UTC)


 * You have to define '.wikEdFrameBodyPlain', .wikEdFrameBodySyntax, and  .wikEdFrameBodyNewbee instead. Cacycle  (talk) 14:24, 5 November 2009 (UTC)

Gadget works; code doesn't. Solution ideas.
Gadget works; code doesn't.

My edit pages started displaying all screwed up about when the new UI beta came out. I solved the problem and figure others are having the same problem, and  that reporting it could help others. If it's widespread, maybe communicate directly to users likely to be having it?)

I use wikEd here on en.wikipedia.org, so I'm using the current version and I  assume you can see my monobook history here. I'm using Firefox 3.5.3 (.4 as soon as I quit) on MacOS 10.5.8. By screwed up, I mean that the edit field, plus the editing toolbar, expanded to fill the whole window (the tabs,  "Editing " text, sidebar,  Edit summary, save page and adjacent buttons were all gone.  Edit pages  started displaying normally as the page loaded, and then the toolbar and  edit field resize, filling the window. Reproducible: yes, at least  by me.  Anyone else?

Troubleshooting results: Summary: Gadget works; code doesn't.

I edited my monobook.js to see if I could fix the problem, and found that leaving everything but  the wikEd code fixed the problem. I found that I could enable wikEd using the Gadget preference.

Here's the code that I commented out to fix the problem. It's the standard code.: //SUCCESS! Replacing the following with enablement in Preferences... Gadgets... Editing Gadgets! // 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"> ');

--Elvey (talk) 20:53, 4 November 2009 (UTC)
 * Err...  This was just a combination of some unidentified glitchines and   fullscreen mode... I think. --Elvey  (talk) 21:04, 4 November 2009 (UTC)

Simple occasional access to wikEd
''I asked a question here, then had an idea of how to answer it. I'll update very soon. --'' In Appropedia (the sustainable development wiki), we convert a lot of web pages and other formatted content to  MediaWiki, and wikEd is an awesome tool.

To make it easier for people who just do this occasionally, I want to set up an open account on a MediaWiki wiki somewhere, with a password  that I'll share with others doing this work, to be used only for the  wikify function in wikEd. This would be for people who only want this particular function, and only occasionally, therefore they're not  motivated to install it for themselves.

The problem is that I can't share the login details openly, if I do it on a wiki such as - I thought about  having the account blocked, but a blocked account can't even view the  edit box.

So...:
 * I'm thinking about using our development site (no important content there),  and only giving the account details on request.
 * If you have a better idea please tell me: e.g. if there's an open-edit wiki  somewhere with wikEd, or...
 * Got it! I'll just use a spammed MediaWiki site with no content... they've got  nothing to lose anyway. Will update.

Thanks again for a great tool. --Chriswaterguy talk 03:48, 17 November 2009 (UTC)


 * If you can edit Common.js on that site just make wikEd load for everybody on  one specific page on that site, like "WikEd Box" or something. — AlexSm  04:41, 17 November 2009 (UTC)
 * Yes, check User:Cacycle/wikEd_installation. Preceed the installation code  with  . Cacycle (talk) 17:25, 21 November 2009 (UTC)


 * Thanks guys. Thanks for the help. It's not working though :-(.


 * First I made this change  to MediaWiki:Common.js. It didn't work even after hard refresh, so I  tried adding curly brackets, (grasping at straws).


 * So then I tried adding the code to MediaWiki:Monobook.js But that didn't work either. Any  clues? Thanks!


 * And happy new year, and any other applicable festival? I won't be here again  till the new year, so I'll catch you then. Thanks again. --Chriswaterguy talk  17:47, 23 December 2009 (UTC)


 * Ping... any idea what's wrong at the MediaWiki:Monobook.js that I modified? --Chriswaterguy talk  08:58, 15 January 2010 (UTC)
 * Yes, the monobook.js has to be in lowercase characters...  Cacycle (talk) 20:24, 30 January 2010 (UTC)
 * I guess you mean in the title, since I couldn't find this text in the  body. I tried w MediaWiki:monobook.js but it automatically became a  capital initial. The initial of a namespace is different to a user  subpage, that way. Same with MediaWiki:monobook.js on Wikipedia. Or have I  misunderstood?


 * I tried adding  on the page, but  it didn't work. --Chriswaterguy talk  04:23, 2 February 2010 (UTC)


 * Oops, you are right about the capital letters. But you have to substitute the  blank in "WikEd box" with an underscore. Just check the page html source  for the correct spelling (var wgPageName = "WikEd_box";). Hope that helped, 08:34, 2 February  2010 (UTC)


 * Okay, I changed that, but the edit box  is still not showing the WikEd tools... --Chriswaterguy talk  23:47, 2 February 2010 (UTC)


 * You have to change it on MediaWiki:Common.js, MediaWiki:Monobook.js does not  get loaded. Cacycle (talk) 12:38, 3 February 2010 (UTC)
 * Please see my reply on the wikEd discussion page and please keep thr discussion in one place :-) Cacycle (talk) 19:20, 3 February 2010 (UTC)


 * Got it, thanks! I got sidetracked with trying the code on monobook.js. Sorry  for the multiple messages - I got the impression you didn't see changes this far  up in this page.


 * Here's the wikieditbox  which anyone is free to use. --Chriswaterguy talk  05:23, 11 February 2010 (UTC)

Opera support
I would like to request the developers to support this editor for opera. Thank you. Rvian00 (talk) 14:08, 17 November 2009 (UTC)


 * I second this request. Opera is a great browser used by many wikipedians. The  abilityi it enables to navigate around the page using only the keyboard  is a big plus. Are there any plans to extend this software for Opera? <font color="#009966">Antarctic-adventurer <font color="#009966">  (talk)  00:18, 24 February 2010 (UTC)

Error when looking at a diff
I was using "wikEd 0.9.88b G (September 16, 2009)" with "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.9.0.5) Gecko/2008120122  Firefox/3.0.5" and got the following error when viewing this diff  at pt.wikibooks: An invalid or illegal string was specified"  code: "12 http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript Line 659 and the Line 659 has this: this.styleElement.sheet.insertRule(selector + ' { ' + declaration + ' } ', 0); It seems to be a compatibility problem with meta:User:Pathoschild/Scripts/Ajax sysop (because when I  disable this gadget at pt.wikibooks the wikEdDiff works again) Helder (talk) 20:09, 18 November 2009 (UTC)


 * Fixed in 0.9.88d, thanks for reporting. Cacycle  (talk) 00:21, 26 November 2009 (UTC)

Turkish translation
Hello,

The localization file for Turkish is now ready and located at User:Vito Genovese/wikEd international tr.js. My local user page is tr:User:Vito Genovese.

Thank you for this fantastic tool. I will also translate the help pages in a couple of days.

Cheers

<font color="#008000">Vito Genovese 20:14, 20 November 2009 (UTC)


 * Thank you very much! Cacycle (talk) 00:08, 26 November 2009 (UTC)

wikEd and Liquid Threads
On my Wiki I use wikEd and the LiquidThreads-Extension. The thing is that when having wikEd enabled and creating a new thread it is created two times.  Thx --DaSch (talk) 17:00, 24 November 2009 (UTC)
 * I do not see that duplication with wikEd as a Greasemonkey script or loaded from  cavendish.js. Please could you provide more details (see the top of  this page) so that I can reproduce your problem. Thanks, Cacycle (talk) 10:11, 26 November 2009 (UTC)

Focus edit summary instead of textarea when doing an undo
When doing an undo, the most common place to go is the edit summary to explain the undo, not the edit area. WikEd is currently giving focus to the textarea always, and maybe when an undo is done it's preferrable to  focus the edit summary instead. Just an opinion. And good job! --Ciencia Al Poder (talk) 16:57, 27 November 2009 (UTC)


 * Also, when editing a new section (the first time only) the focus could be put  in the title. And maybe have the option to disable the automatic focus,  because sometimes I start typing before wikEd starts and resets the  caret position at the beginning of the textarea. --Ciencia Al Poder  (talk) 13:04, 28 November 2009 (UTC)


 * You're right about that option. It should be possible to disable the automatic  focus. --Eleassar my talk  15:44, 28 November 2009 (UTC)


 * While trying to implement these I got the feeling that the focus should be  consistent between differrenttypes of editing pages, otherwise it gets  too confusing. But I have changed the code in 0.9.89a so that the  focusing happens earlier, as soon as possible. And if you really have  to, you can disable focusing and scrolling with    Cacycle (talk) 21:08, 2 January 2010 (UTC)

Incompatible with Babaco usability release
Hi, the wikiEd tool does not seem to be compatible with the Babaco release. Having the wikiEd enabled in the preferences, the link insertion dialogue and the navigable table of contents next to the edit  window do not work. --Eleassar my talk 11:35, 28 November 2009 (UTC)
 * I will look into it, thanks for reporting. Cacycle  (talk) 07:50, 21 December 2009 (UTC)
 * Link insertion works in wikEd 0.9.90d. The navigatable TOC is now compatible  with wikEd but is not visible or functional when using the wikEd edit  field. wikEd has a similar feature (it is in the dropdown list of the  Find field). Cacycle (talk) 20:22, 30 January 2010 (UTC)

Viewing references
A discussion taking place here Bot_requests is wondering if it would be possible to allow different users to view references in different ways  thru WikiEd.

Some wish to see them spaced out

well other wish it all on one line. Doc James (talk · contribs · email) 06:48, 9 December 2009 (UTC)
 * I will think about it. Have you tried the  template hiding mechanism of wikEd  ([[Image:WikEd_ref_hide.png|16px]])? Cacycle  (talk) 07:54, 21 December 2009 (UTC)


 * I prefer to see it inline just over fewer lines.  Some wish it over many lines.   Had a long discussion about how the refs should be presented and the  group seemed polarized.  Each group hating what the other preferred.   Anyway let me know if you do this.  Thanks. Doc James  (talk · contribs · email) 22:37, 21 December 2009 (UTC)

hi, do you know what caused this?
 Stopped hapening when I disabled the gadget.

Thanks! Brilliantine (talk) 20:37, 16 December 2009 (UTC)


 * Thanks for reporting. I have fixed the problem and will update the program as  soon as I find the time. Cacycle  (talk) 07:49, 21 December 2009 (UTC)
 * Fixed in 0.9.89. rCacycle (talk) 14:07, 2 January 2010 (UTC)

Finnish translation of wikEd
Hi! I have made a Finnish (fi) translation of the wikEd user interface: User:Ejs-80/wikEd international fi.js. My user page is at fi:Käyttäjä:Ejs-80. Thank you for this tool! –Ejs-80 (talk) 15:33, 21 December 2009 (UTC)
 * Thanks a lot! I have updated wikEd and the info pages. Cacycle (talk) 22:15, 21 December 2009 (UTC)

Local (LAN) installation still reaches for upload.wikipedia.org website to get images
Hi,

I followed the instructions for a complete standalone install, but I see the images are still downloaded from the internet. I may be a bit lost : I first followed the instructions to install wikEd as a gadget and it worked nicely. Then I followed the howto for LAN setup, and though it is still working, and though I setup (and validated) a dedicated website to serve the  pictures, they are still coming from the wikipedia website. (I also do use cache-flushing the way it has to be.)

My setup :
 * server : ubuntu karmic desktop
 * apache 2.2.12
 * mediawiki 1.15.1
 * Gadgets r48268
 * wikEd 0.9.88e (December 5, 2009)

I notice my Gadget-wikEd.js looks like : // install Wikipedia: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>');

Questions :
 * Is it correct for my Gadget-wikEd.js to look like this? I tried to change the URL  accordingly to my local setup, but in that case, wikEd disapears...
 * Is it correct to have a Gadget-wikEd.js for a LAN local setup? (I guess yes, because  the LAN-local  way to set it up has to be switchable. Local users may want to keep  their simple editor)
 * What am I missing for this to work?  —Preceding unsigned comment added by Nbozo (talk • contribs) 23:09, 21 December 2009 (UTC)


 * If you want to serve wikEd locally you have to change all URLs accordingly,  including images, autoupdate, Gadget-wikEd.js... If that does not work, then  you have to check the browser's error console to see what went wrong.  Hope that helped, Cacycle (talk) 14:51, 29 December 2009 (UTC)

(ctrl-click) bug with italics in link
wikEd can add text containing "(ctrl-click)" to edited or previewed pages with italics (ctrl-click)">italics  (ctrl-click)">italics  or bold (ctrl-click)">bold  (ctrl-click)">bold  code inside double brackets (this is not rendered as a link by  MediaWiki). If preview is hit more than once then the text is added more than once. It happens with wikEd 0.9.88e G (December 5, 2009) in both Firefox 3.5.5 and Google Chrome 3.0.195.38. The problem is not there when wikEd is disabled. I first saw it in  which I guess was caused by wikEd. Experimenting with that gave this simpler example:. This bug report was written with wikEd disabled. If the section is later saved by an editor with wikEd enabled then "(ctrl-click)" may be  added to the italics and bold  inside brackets above. PrimeHunter (talk) 22:14, 1 January 2010 (UTC)
 * Fixed in 0.9.89. Unfortunately, I have to wait for the Firefox 3.6 release  sometimes later this month (hopefully) until I can roll out the new and  better highlighting code based on real wikicode parsing. Cacycle (talk) 13:29, 2 January 2010 (UTC)
 * Thanks for the quick fix. I have fixed around 20 affected articles and will  look at other namespaces later. The articles used invalid link  formatting so "ctrl-click"  became a way to search for that. PrimeHunter (talk) 17:03, 2 January 2010 (UTC)
 * Thanks for cleaning up behind this :-) Cacycle  (talk) 19:29, 2 January 2010 (UTC)

WikEd as gadget on intranet
Hello Everybody,

I am quite new to Wikipedia and Mediawiki. I have been trying install WikiEd in my mediawiki for last few weeks. Its seems amazingly complicated to install it as the instructions are very discrete and  confusing. I wanted to install wikiEd for my company intranet. After following the instructions given under the topic 'wikis without internet  connection', I have succesfully installed Gadget option in my user  preference but cannot see the wikiEd logo next to the logout link. If there is anyone out there who can give me  clear instructions, I would  really appreciate him/her. By the way, I am using firefox 5.0 as browser.

Thank you, Sathish


 * Hi Sathish, Please check your browser's error console for wikEd-related errors  and report them here. The documentation might be a bit outdated, but you  have to overwrite all preferences containing an internet URL with your  intranet URLs if you do not have an outside connection. Feel free to  keep us updated and to ask if you need more help. Cacycle (talk) 21:00, 10 January 2010 (UTC)

HI, thanks for your response. I checked my error console and have listed the error below. I managed to edit few except one below. Could you please give me an insight how to handle these;

Error: invalid assignment left-hand side Source File: http://kb/index.php?title=MediaWiki:Gadget-wikEd.js&action=raw&ctype=text/javascript Line: 8, Column: 46 Source Code:

window.WikEdInitGlobalConfigs = function {

Thank you, Sathish —Preceding unsigned comment added by Entopia (talk • contribs) 09:37, 12 January 2010 (UTC)


 * Please give me a full error report (see top of this page). Did you use an UTF-8 enabled  editor / system to copy the code (check the comments on top of the code  for the heart)? Did you copy the code out of the editing window and not  from the article page? Cacycle  (talk) 20:11, 15 January 2010 (UTC)

Hiding references does not properly hide multi-line references
This might already be a known problem, but when hiding references, wikEd does not properly hide multi-line references, such as:

First reference. Second reference

wikEd considers

Second reference

as one single reference. <font face="Verdana"> Gary King  ( talk )  02:10, 12 January 2010 (UTC)


 * There is a new and fully functional real wiki code parser for highlighting that  will replace the regelar expression based current highlighter. I only  have to wait for a Firefox bug fix in their next release until I can  implement that (see the box on top of this page). Thanks for reporting, Cacycle (talk) 07:58, 12 January 2010 (UTC)

preview/changes = save page
Since yesterday whenever I press the WikEd preview or changes button (the ones with the icons) the page gets submitted instead of the desired  effect that it had before yesterday. I use Safari 4.0.4 (6531.21.10) on Mac OS X 10.6.2. I haven't changed anything since then so I guess it's the update to 0.9.90 that happened yesterday.  X  eworlebi (t•c)  18:21, 15 January 2010 (UTC)
 * I am working on it, sorry, Cacycle  (talk) 19:30, 15 January 2010 (UTC)
 * Fixed, please update with Shift-Reload to 0.9.90a. Did the Find and Replace dropdown  history boxes work before the last update? Thanks, Cacycle (talk) 20:05, 15 January 2010 (UTC)


 * Thanks, don't remember if they worked before, I type it out manually. But now every entry is like: "ââ ". When selecting one, the line gets  filled with "â  ",  I normally type the find and replace stuff out anyway.   X  eworlebi (t•c)  20:19, 15 January 2010 (UTC)

Problem with R and I in page titles
Hello, Cacycle. I found some days ago and today a strange error, that appeares in FF 3.5.7, if I use it in FF-mode. If I change into IE-mode (I use IE-Tab) the problem isn't. I edited a template, that uses the template hsb:Předłoha:KodeRěce in FF, but I saw a wrong page tile  Předłoha:Koderěče with a letter "r" instead "R" in the middle of the  title. If I changed into IE-mode, I saw the correct title. The same problem was today in the saterfrisian wikipedia, there I use WikEd too. But there the image commons:File:BrockenSnowedTreesInSun.jpg appeares with a wrong title ("Trees In" [without space] changed into "Treese", with "e" instead  "In". I don't know why.). I had to change into IE-mode with IE-tab browser extension for correct the error in a template.

Don't like WikEd some capitals in the middle of some page titles, and automatically changes them into small letters? Greetings --Tlustulimu (talk) 21:26, 19 January 2010 (UTC)
 * I just found a browser extension, that caused the problem. And I just  uninstalled it. Greetings --Tlustulimu (talk) 21:30, 19 January 2010 (UTC)


 * Please could you tell us the name of that extension just in case others  experience similar problems? Thanks, Cacycle  (talk) 22:28, 19 January 2010 (UTC)
 * Oh, yes, I can. The name of the extension is "Binnen-I be gone". You  can find it on the page https://addons.mozilla.org/de/firefox/addon/6822.  But I think, that this extension is useful for German users only.  Greetings --Tlustulimu (talk) 17:32, 28 January 2010 (UTC)
 * As far as I can see, the problem is not at all related to wikEd. Cacycle (talk) 14:00, 30 January 2010 (UTC)

As of today, WikEd no longer works when clicking "(new section)" on a user talk page
Is it just me? It seems that you have done some recent code updates. Browser is Firefox 3.0.7, Im using a slightly customized monobook, and it has the plus sign instead of the word "new section".

From a long time fan,
 * -- <B>Soap</B> Talk/Contributions  22:40, 19 January 2010 (UTC)


 * Maybe I fixed this by changing the line 2258


 * from ||
 * to   ||
 * }-- <tt>Codicorumus</tt> &laquo; msg  04:20, 20 January 2010 (UTC)
 * }-- <tt>Codicorumus</tt> &laquo; msg  04:20, 20 January 2010 (UTC)


 * I've been having the same problem, and this change hasn't fixed it for me.  Browsers are Firefox 3.5.7 and 3.6 RC2. — Malik Shabazz Talk/Stalk  17:38, 20 January 2010 (UTC)
 * I will fix this next week, shouldn't be too difficult... Thanks for reporting,  Cacycle (talk) 18:50, 20 January 2010 (UTC)


 * Thanks. — Malik Shabazz Talk/Stalk  18:52, 20 January 2010 (UTC)
 * Fixed with 0.9.90b, please push Shift-Reload to update. Cacycle (talk) 23:28, 27 January 2010 (UTC)


 * Looks good. Thank you. — Malik Shabazz Talk/Stalk  23:45, 27 January 2010 (UTC)


 * Thanks. -- <tt>Codicorumus</tt>  &laquo; msg  15:39, 28 January 2010 (UTC)