User talk:Cacycle/wikEd/Archive 010

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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: [1]

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

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.

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

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 [2]. 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?

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

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)

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)

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)
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
- Does this still happen with the newest version? Cacycle (talk) 14:30, 13 January 2009 (UTC)
  - 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)
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)
Switching WikEd on (or off?) clears the selection of text within the edit pane.
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

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.
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.
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).
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.
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 (wikEdfixUnicode to wikEdFixUnicode). 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 (var wikEdShowMissingTranslations = true;) 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. --TheDJ (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. --TheDJ (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"" --TheDJ (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. --TheDJ (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. --TheDJ (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). --TheDJ (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. --TheDJ (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: wikEdFrameCSS['.wikEdFrameBodyNewbee'] = 'font: .75em;'; 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. Gary King (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 <br> and <nowiki> tags) to a WordPad file:

<includeonly>{{#switch: {{{OP}}}
| nop
| note = <ref group=fn name=first></ref>
}}</includeonly>

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. —TheDJ (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. -- Soap ^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 (  /<div>(.*?)<\/div>/i.test(obj.changed.plain)  ) {
obj.changed.plain =  obj.changed.plain.replace(/<div>(.*?)<\/div>/gi,  '$1');
}

// add the text formatting
else {
obj.changed.plain  = '<div>' + obj.changed.plain + '</div>';
obj.changed.plain  = obj.changed.plain.replace(/(<div>)( *)(.*?)(  *)(<\/div>)/, '$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 {{subst:User:Allstarecho/sig}} and when I click the second one, at the cursor, it adds {{subst:User:Allstarecho/tkbk}}? 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#Automatic_syntax_highlighting 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.[3] 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 [4] 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

text text text^[1] text wrongly highlighted as part of reference.^[2] text correctly not highlighted

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 [5] 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 Wikipedia:Village pump (proposals)/Archive 52#Link_color_proposals. 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 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. — SkyLined (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:

<nowiki  /> vs <nowiki></nowiki>

Is there any chance you could correct this? ⇐⇑©TriMoon™ Talk @ 12:11, 17 September 2009 (UTC)

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 <br /> and <references/>. Thanks, Cacycle (talk) 12:58, 17 September 2009 (UTC)

Spurious semicolons

When wikEd is enabled, a spurious semicolon is shown after every closing </ref> tag in diffs, such as in this one: [6]. I'm using wikEd 0.9.88b G in Firefox 3.0.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071316 Remi/fc6). — Emil J. 13:04, 17 September 2009 (UTC)

Fixed in wikEdDiff.js version 0.9.6b. Thanks for reporting this, Cacycle (talk) 17:27, 19 September 2009 (UTC)

Great, thanks. — Emil J. 15:50, 21 September 2009 (UTC)

visible nbsp in diffs

If the number of lines between two revisions in a diff is not equal, mediawiki inserts an nbsp into the empty column where only one revision contains that line. wikEd converts that nbsp into a visible   see for example this diff. I suspect the line html = html.replace(/&/g, '&'); in this diff is responsible.

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. 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   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:

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
If an extension is causing it, it's not Greasemonkey, and it's not Adblock Plus

Is anyone having the same problem? Does anyone know how to fix it? GregorB (talk) 07:50, 28 September 2009 (UTC)

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

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:

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.

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

def  simplifyLinks(page, text):
	def  dot2percent(m):
		return m.group().replace('.', '%')
	# Prettify links, remove  underscore and decode characters
	for  m in re.finditer(ur'\[\[([^[\]{|}\n]+)\|([^\n|]*?)\]\]', text):
	
	link = m.group(1).replace('_', ' ').encode('utf-8')
	
	if '#' in link:
		
	title, anchor = link.split('#', 1)
			anchor = anchor.replace('%', '.25')
	
		anchor = re.sub(r'''(?x)

			# Single byte character (Printable  ASCII)
		
	# we make that [0-9A-Za-z\-.:_] and  [[\]{|}] are not included
		
	 \.2[1-9A-CF]
	
		|\.3[BD-F]
	
		# We need to avoid  encoding <tag> and </tag>
			|\.3C(?!\w|/\w|\.2F\w)
	
		|\.40
	
		|\.5[CE]
	
		|\.60
	
		|\.7E
	
		# skip .8-B\h
	
		#  Two  byte UTF-8 character  U+0080-U+07FF
	
		|\.[CD][0-9A-F]\.[89AB][0-9A-F]
	
		# Three byte UTF-8 character  U+0800-U+FFFF
	
		|\.E[0-9A-F]\.[89AB][0-9A-F]\.[89AB][0-9A-F]
	
		# Four  byte UTF-8 character  U+10000-U+10FFFF
	
		|\.F[0-7]\.[89AB][0-9A-F]\.[89AB][0-9A-F]\.[89AB][0-9A-F]
	
		''', dot2percent, anchor)
	
		link = ''.join((title, '#', anchor))
	
	link = urllib.unquote(link) 	#  unescape %xx
		link = link.replace('# ', '#') #  get ride of copy/paste space
		link = unicode(link, 'utf-8')
	
	text = text.replace(m.group(), '[[%s|%s]]'%(link, m.group(2)))
	return text

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 [[Fiat%20600#The_Multipla_.281956.E2.80.931965.29]] into <nowikxi>Fiat 600</noxwiki>. — 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 (&…;), 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#NOTBROKEN, 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 <foo>" 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"></script>');

~~--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#Site-wide_installation. Preceed the installation code with if (wgPageName == 'WikEd Box'). 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 {{DISPLAYTITLE:{{lcfirst:{{PAGENAME}}}}}} 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? Antarctic-adventurer (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

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.[7] 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 var wikEdScrollToEdit = false; var wikEdFocusEdit = false; 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 Wikipedia:Bot_requests#Bot_from_changing_multi_line_refs_to_one_line_refs 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

{{Cite journal
| last =
| first =
| authorlink =
| coauthors =
| title =
| journal =
| volume =
| issue =
| pages =
| publisher =
| location =
| date =
| url =
| issn =
| doi =
| id =
| accessdate =  }}

well other wish it all on one line.

{{cite journal|  author = | title =  |  journal =  | volume = | issue = | pages = | year = | pmid = | doi = | month =| issn =}}

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

[8] 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 [9] which I guess was caused by wikEd. Experimenting with that gave this simpler example: [10]. 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.<ref>{{cite web
| url=http://en.wikipedia.org/  }}</ref> Second  reference<ref />

wikEd considers

<ref>{{cite web
| url=http://en.wikipedia.org/  }}</ref> Second  reference<ref />

as one single reference. 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. _Xeworlebi ^(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: "ââ <entry>". When selecting one, the line gets filled with "â <entry>", I normally type the find and replace stuff out anyway. _Xeworlebi ^(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,

-- Soap ^Talk/_{Contributions} 22:40, 19 January 2010 (UTC)

Maybe I fixed this by changing the line 2258

from	`wikEdInputWrapper.insertBefore(wikEdSummaryWrapper, wikEdEditWrapper);`
to	`wikEdEditorWrapper.insertBefore(wikEdSummaryWrapper, wikEdEditWrapper);`

-- Codicorumus « 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. -- Codicorumus « msg 15:39, 28 January 2010 (UTC)

^ Irifune T, Kurio A, Sakamoto S, Inoue T, Sumiya H. (2003). "Ultrahard polycrystalline diamond from graphite". Nature. 421: 599.{{cite journal}}: CS1 maint: multiple names: authors list (link)
^ V. Blank; et al. (1998). "Ultrahard and superhard phases of fullerite C60: comparison with diamond on hardness and wear" (PDF). Diamond and Related Materials. 7: 427. doi:10.1016/S0925-9635(97)00232-X. {{cite journal}}: Explicit use of et al. in: |author= (help)

[iri-1] Irifune T, Kurio A, Sakamoto S, Inoue T, Sumiya H. (2003). "Ultrahard polycrystalline diamond from graphite". Nature. 421: 599.{{cite journal}}: CS1 maint: multiple names: authors list (link)

[2] V. Blank; et al. (1998). "Ultrahard and superhard phases of fullerite C60: comparison with diamond on hardness and wear" (PDF). Diamond and Related Materials. 7: 427. doi:10.1016/S0925-9635(97)00232-X. {{cite journal}}: Explicit use of et al. in: |author= (help)

[1]

[2]