User talk:Cacycle/wikEd

Please support wikEd

Please support wikEd by helping to fix the following browser and MediaWiki issues.

• Firefox:
  • 579763, 579760 Cursor/caret disappears (07-2010)
  • 1016372 Space lost when deleting text (05-2014)
  • 926230 Space at end of line not styled (10-2013)
  • 543204 Focus after search (01-2010)
  • 926164 Editor deletes blank before inserted block element when converting to text (10-2013)
  • 458524 Automatic syntax highlighting would interfere with undo/redo. The only reason why wikEd does not have automatic syntax highlighting. (10-2008)

• Webkit/Chrome:
  • None.

This is the discussion page for wikEd, a full-featured in-browser text editor that adds enhanced text processing functions to Wikipedia and other MediaWiki edit pages. Feel free to leave your comments, suggestions, and bug reports at the end of this page.

Archives

Archived discussions from this page: 1 2 3 4 5 6 7 8

wikEd Bug reports

In order to help you with problems, I need as many details and informations as possible:

• Your wikEd version (hover over the wikEd logo on top of every page close to the logout link). Does the bug persist if you update to the latest version (Shift-Reload or Ctrl-Shift-R)
• Your browser id (in your browsers's main menu under Help → About) (something like "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2")
• Error console errors (in your browsers's main menu under Tools → Error console; push clear, reload the page, and copy and paste the error messages)
• Which browser add-ons have you installed (in your browsers's main menu under Tools → Add-ons)
  • Optional: What happens if you disable your add-ons and restart the browser (close the quick start and the error console too)
• Which user scripts have you installed on your monobook.js page
• Which operating system do you use
• Describe the problem, please be as specific as possible about what is wrong (including when it happens, what happens, what is broken, and what still works)
• Steps to reproduce
• What exactly happens if you follow these steps
• Please add your bug report at the bottom of this page

Bug - Bullets embedded in table

My config -

• wikEd: 0.9.43
• Browser: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Steps -

• Create a table in Word 2007 that contains bullets nested inside a table cell.
• Paste into wikEd.
• Select all.
• Click "Convert pasted content to wiki code..."

Actual wiki code:

| * Bullet 1
* Bullet 2

Required wiki code:

|
* Bullet 1
* Bullet 2

Tom.ngo 15:49, 22 September 2007 (UTC)

I will fix this as soon as I find the time. Thanks, Cacycle 04:34, 25 September 2007 (UTC)

Works in 0.9.69a. Cacycle (talk) 03:02, 30 January 2009 (UTC)

Request - Pipes and Bangs

Frequently we prefer that the first row (and, less frequently, the first column) of a table to be wiki-ized as headers, i.e., with '!' delimiters instead of '|'. Do you have a way to make this happen by editing the rich text appropriately? If not, here are some suggestions:

1. If a cell is all bold, give it header style.
2. If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
3. If the variable wikEdWikifyTableHeaderCol = true then header-ize first column

I like #1 the best, but of course this is your wikEd invention!

Tom.ngo 03:16, 2 October 2007 (UTC)

Thanks for the suggestion. I am thinking about a "if the first row or the first cell is bold" rule. Cacycle 12:19, 2 October 2007 (UTC)

I would personally prefer #1 - if a cell is all bold, give it header style. Tom.ngo (talk) 21:55, 19 December 2007 (UTC)

WikEd Preview vs Standard Preview

Hitting the WikEd preview (the one with the icon and that loads below the edit section) and later the Standard Preview button will force a Return on the previewed page.
That's bad when you edit a page with a Submit form or an inputbox. When you preview by hitting the preview icon and later hit the standard preview button, it will submit the form and you will be taken to the submit destination page. God bless it only works in Firefox so browsing back won't lose the data ;) Either fix it or remove the standard preview when WikEd is used, cos the WikEd preview feels much better. --Subfader (talk) 20:21, 16 March 2008 (UTC)

Sorry, but I cannot understand your problem, please could you reword your text. Thanks, Сасусlе 03:34, 6 April 2008 (UTC)

Edit a page that includes a submit form like the inputbox. Preview with WikEd preview, then hit the MW preview button. This will cause the form to be submitted and you're taken to the form's destination page. --77.135.30.91 (talk) 16:18, 25 May 2008 (UTC)

Has been fixed. Cacycle (talk) 03:04, 30 January 2009 (UTC)

Change-highlighting bug?

As my browser (Firefox 2.0.0.14) is loading this diff, it highlights (in red) the newly added text. But as the page finishes loading, the highlighting disappears. Does this happen with anyone else? --zenohockey (talk) 21:35, 31 May 2008 (UTC)

Seems to work now. Cacycle (talk) 03:36, 24 November 2008 (UTC)

Freezes on image tag

Version is 0.9.62g. See this diff. Apparently it's related to this. GregorB (talk) 19:44, 13 June 2008 (UTC)

Shit, this looks like difficult one. Thanks, Cacycle (talk) 20:08, 18 June 2008 (UTC)

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)

Bug - <blockquote> does not work as expected

My config:

• wikEd: 0.9.64b

When copying rich text with many paragraphs left-indent, wikEd adds a <blockquote> section.

But <blockquote> needs the <p> mark to break paragraphs. And itallic or bold applies only to the first paragraph instead of the whole section.

The solution would be not to replace <p> marks with <br> marks within <blockquote>.

Another solution would be to use the Poem extension (it adds <br> after each end of line).

To get the left-indent, add this code to poem.php:

    // Add a margin-left "style" attribute.
    if( isset( $attribs['style'] ) ) {
        $attribs['style'] = 'margin-left: 40px; ' . $attribs['style'];
    } else {
        $attribs['style'] = 'margin-left: 40px;';
    }

If you put a '' before the <poem> mark (as wikEd acutally does with blockquote), then the whole quote is itallic. For instance:

''<poem>
Au clair de la lune,
Mon ami Pierrot:

Prête-moi ta plume,
pour écrire un mot.
</poem>

would give:

Au clair de la lune,
Mon ami Pierrot:

Prête-moi ta plume,
pour écrire un mot.

Gabuzo (talk) 11:16, 22 July 2008 (UTC)

Fixed in 0.9.96. Thanks, Cacycle (talk) 04:56, 26 January 2009 (UTC)

Request-JavaScript&CSS syntax highlighting

Could you add syntax highlighting for .js & .css pages in edit mode? The code can be found on one of wikipedias common js pages. Thanks, ManishEarth^Talk 15:13, 14 August 2008 (UTC)

Regular expressions, please

When will WikEd's find/replace feature support regular expressions? I really need to be able to add new lines in replaces). (And I don't have access to a computer upon which I can load AWB.  :( The Transhumanist    19:05, 18 November 2008 (UTC)

Maybe tonight? Cacycle (talk) 19:57, 18 November 2008 (UTC)

I have fixed it, you can use \n for newlines. Cacycle (talk) 04:43, 19 November 2008 (UTC)

Custom settings do not work after latest gadget update

My custom settings used for wikEd do not work anymore after the latest wikEd update, even after a hard refresh. Gary King (talk) 15:08, 17 November 2008 (UTC)

I see you have renamed most of the variables. Do realize that this will break a lot of existing scripts. Gary King (talk) 15:20, 17 November 2008 (UTC)

Sorry for that, I will add a temporary compatibility fix later today so that you have time to change your settings. All you have to do is to consistently change the 'e' in 'wiked' from lowercase to uppercase 'wikEd'. Cacycle (talk) 16:04, 17 November 2008 (UTC)

Yeah I already did it, but I'm just noting that it will probably affect some scripts out there run by people who aren't as familiar with JS. Gary King (talk) 16:16, 17 November 2008 (UTC)

The wikEdWiki class is not working correctly anymore. Some text is wrapped in the class when they shouldn't be. It happens after a reference that closes itself, such as <ref name=test />. Gary King (talk) 17:58, 17 November 2008 (UTC)

I'm using this as a temporary fix, but hopefully it doesn't have to be permanent: wikEdFrameCSS['.wikEdWiki'] = 'color: #000;';. Gary King (talk) 04:04, 19 November 2008 (UTC)

Please could you explain this in more detail with an example text or page so that I can reproduce it. Thanks, Cacycle (talk) 04:54, 19 November 2008 (UTC)

Here Gary King (talk) 15:29, 19 November 2008 (UTC)

I have tested the latest SeaMonkey, Firefox, Safari, and Chrome and in none of them does the text show up in any markuped way, it is just normal unformatted text (the only very minor problem I see is the second ref formatting which should not be wikEdWiki and I will fix that). Which browser are you using? Cacycle (talk) 01:19, 20 November 2008 (UTC)

I am using Firefox 3.0.4 on Mac OS X. The entire text in that link uses the wikEdWiki class, which as set by your script is colored with #0000E0. Gary King (talk) 03:28, 20 November 2008 (UTC)

I think I have fixed it and I am in the process of uploading the new version 0.9.67d. It happened only with the ref hide button pushed. Cacycle (talk) 03:31, 20 November 2008 (UTC)

Alright thanks. My apologies, I forgot to mention that I had the ref hide button enabled because I almost always have it turned on. Gary King (talk) 03:42, 20 November 2008 (UTC)

Spontaneous spaces removal

Hi. I use wikiEd 0.9.67d G with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3. When I click on the edit this page (while editing Kīlauea article) button and then click on Changes button, there are mutliple removed spaces from the beginning of the line between paragraphs and in infobox. In error console are a few tens of errors

Warning: Error in parsing value for property 'color'. Declaration dropped.

Source File: http://en.wikipedia.org/enwiki/w/index.php?title=K%C4%ABlauea&action=submit

Line: 0

and one

Warning: Expected ':' but found '='. Declaration dropped.

Source File: http://en.wikipedia.org/enwiki/w/index.php?title=K%C4%ABlauea&action=edit

Line: 0

--Tomaxer (talk) 22:00, 22 November 2008 (UTC)

This is somewhat strange because the version you edited did not contain those empty lines in the first place. Maybe you actually introduced these lines by pushing the button? The css error messages are not caused by wikEd. Cacycle (talk) 01:57, 24 November 2008 (UTC)

Beyond wikiEd

Today I had time to evaluate the gadget version of wikiEd.

The good news is that it implements highlighting of the embedded citations that make extensively referenced articles very difficult to read in edit mode. I made this suggestion unnoticed last year on an unrelated talk page, so thank you.

The bad news is that wikiEd doesn't solve my fundamental time-wasting problem of constantly reloading a rendered preview so that I can see what I get.

I read the wikiEd help page and the link to What you see is Wiki - Questioning WYSIWYG in the Internet Age (PDF) by Christoph Sauer. He has many good points, but the central notion of deprecating WYSIWYG is not one of them. While formatting may not be durable, it matters locally. It's also an unnecessary dichotomy. WYSIWYG Corel WordPerfect still has the Reveal Codes feature. Why accept less (unless one is a monopoly victim of MS Word)?

The inverse of Reveal Codes is code folding requested above at #Feature request: code folding – but too difficult to implement for wikiEd.

So let's plan beyond wikiEd to the next editing tool – to what I (and many others it appears) really need for "concentrating on the content" in Sauer's words. I need to:

• Usually see the wikified preview when I open the editor.
• Click anywhere and start typing changes, with dynamic format update just like any other WYSIWYG editor.
• Type inline wikicode without a mode shift. When it's complete the code should dynamically fold. (There are several preferences for how exactly how and when it should autofold, but clicking or scrolling away should make it fold immediately. The key issue is how to display a longer unfolded line so that it doesn't jump while typing on it.)
• See and edit wikicoded markups by clicking them to unfold. They should fold after clicking or scrolling away. An option to unfold on mouseover could be useful if the unfolding is by horizontal scroll.
• See and edit wikicoded markups on several lines by Ctrl-clicking them, which makes them stick unfolded for viewing or editing, until they are toggled to fold by again Ctrl-clicking them.
• Have buttons for fold and unfold of all wikicodes, with a preference default for either at opening. The Unfold All button should also reveal hidden text for editing.

Milo 08:12, 23 November 2008 (UTC)

Hi Milo. thanks for your comments, they were a nice opportunity to think about this in more detail... These are the thoughts I came up with:

WYSIWYG does not work smoothly for wiki editing because of the powerful and complex syntactic constructs such as images, tables, templates, parser directives, references, and, actually, any element with an opening tag/closing tag structure. These have long-range non-local effects on the final document that might result in the disappearance of large portions of the text inside such a construct. Therefore, WYSIWYG would only be feasible when you absolutely hide and encapsulate any existing wikicode from editing, e.g. by using separate editing frames or popup forms for non-trivial constructs that require parameters such as images, tables, template, and even simple span or div tags, and guarantee a correct and complete syntax for rendering.

Your proposal to mix WYSIWYG and WYSIWYM (i.e. wiki code with syntax highlighting) does intentionally not encapsulate the code and can therefore not work and will probably result in a confusing visual and conceptual mishmash between two fundamentally different and incompatible approaches. I am almost certain that you will end up with something less user friendly and efficient than using either pure approach alone.

Then we have the technical limitations: Your suggestions are well beyond the current capabilities of JavaScript (e.g. see Mozilla bug 458524 in the orange box on top of this page). It would instead require a locally installed browser-independent external program or a cross-browser capable applet. In either case you would have to program and maintain a huge and powerful editor application from scratch which sounds like a major project, nothing one person alone could possibly do in his spare time.

BTW, you can already see the wikified content by checking "Show preview on first edit" in your editing preferences.

Cacycle (talk) 01:49, 24 November 2008 (UTC)

Possible to use wikEd only when explicitly invoked?

Hi! I love wikEd, the syntax markup makes it so much easier to edit text, especially with a lot of in-line refs. Unfortunately, I guess my computer is a bit too slow – when editing a big page with wikEd, the whole computer freezes for a long while. Therefore, I normally keep wikEd disabled, and enable it when I need it. However, every now and then, I forget to disable it, open up some big edit and there we go... sometimes I have to kill the browser. It would be so cool if you'd be able to make it scale better for big pages, but until then – would it be possible to have an option to always have wikEd disabled, unless explicitly enabled for a specific edit? Is this already possible? Thank you for this very useful tool. /skagedal^... 19:58, 26 November 2008 (UTC)

There are no configuration settings to do that yet, but I will add this to the next release. The slow down is caused by syntax highlighting (?), so disabling this would probably help you without sacrificing the rest of wikEd. I could also try to tweak the code. Please could you provide more background information and details about your speed problem (see top of this page), especially you browser, your type of computer (speed, CPU, age...), and Wikipedia articles where you experience the problem. Thanks in advance, Cacycle (talk) 23:05, 26 November 2008 (UTC)

Of course.

• wikEd version: I use the gadget on English Wikipedia.
• Browser ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
• Error messages: (my translations)
  • Varning: Okänd egenskap (unknown property) ”column-count”. Ignorerad deklaration. (Ignored declaration). Källkodsfil (Source code file): http://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 ; Rad (line): 33
  • Varning: Okänd egenskap ”word-wrap”. Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 ; Rad: 50
  • Varning: Väntade sig ”:”, men fann ”=”. (expected ":", found "=") Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
  • Varning: Okänd egenskap ”column-width”. Ignorerad deklaration. Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
  • Varning: Väntade sig en deklaration, men fann ” ”. (Expected declaration, found " ".) Hoppar till nästa deklaration. (Jumping to next declaration). Källkodsfil: http://en.wikipedia.org/enwiki/w/index.php?title=Major_depressive_disorder&action=edit ; Rad: 0
• Addons: ChatZilla 0.9.84, Greasemonkey 0.8.20080609.0, Zotero 1.0.7
• Nothing in monobook.js. Gadgets: Navigation popus, wikEd, Twinkle, "Display an assessment..."
• Operating system: Windows XP SP3
• An example of a big enough page to cause the problem is usually Major depressive disorder. It always takes a long time to load the edit, but I do not always experience the "whole computer freezes" thing. I suppose it depends on how much other stuff I have going on.
• Computer is a HP Pavilion (laptop), IIRC 2.5 years old. CPU is "AMD Turion 64 Mobile", 1.79 GHz, 384 MB of RAM.

Thank you for listening, looking forward to the next version then! Disabling syntax highlighting is not really an option for me, since that's pretty much the "killer feature" I use wikEd for. /skagedal^... 09:33, 27 November 2008 (UTC)

The maximal time wikEd uses for syntax highlighting is now 2 s with wikEd 0.9.68 and highlighting will be canceled if it takes longer. It is possible to manually highlight text in smaller chunks. Cacycle (talk) 21:13, 28 December 2008 (UTC)

Wonderful! /skagedal^talk 15:31, 30 December 2008 (UTC)

Installation on another wiki

Greetings,

I want to use WikEd on a mediawiki installation that I have. I have installaed Gadgets on my wiki, however I am unclear on how to make the code for WikEd availabel on my site that users may select it as a Gadeget in their preferences. Can anyone offer me a little help here with the installation?? --Shannara Fan (talk) 02:35, 1 December 2008 (UTC)

The page Wikipedia:Gadget has good instruction on how to install gadgets. Feel free to contact mew if you have more questions. You can copy the code from the the Wikipedia wikEd gadget page. Good luck - Cacycle (talk) 02:53, 1 December 2008 (UTC)

Newbie question: Shortcut keys

I just installed WikEd today, and it seems to work great. I'm only wondering why there are no shortcut keys for the most common functions, such as wikilinks or bold. (At least they're not displayed in the tool tips.) I feel these are so useful for everyone that they should be there by default, especially since it is more ergonomic while your typing than having to navigate (with the touch pad) to the button, and then back to the place you were working at. For that reason, I would also like to have shortcuts for the increase headline and related buttons and for #R, or, come to think of it, for almost all of the in-text buttons. if you feel that not everybody would appreciate it, maybe there is a way I can add shortcuts for myself?

PS: This is strange: Just now I tried alt-shift-o, and it inserted a wikilink. Then I clicked the [T] button, and it selected the whole text (which is not what I would expect from the tooltip), and after that, alt-shift-o does the same. (I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4.) — Sebastian 20:50, 3 December 2008 (UTC)

I have just fixed the bug that interfered with these access keys. The fix will become available with the next update. Thanks for reporting this. You can define your own access keys but you will lose the Wikipedia predefined ones. Add the following to your monobook.js page:

// define accesskeys for edit buttons (wikEd button number: [key string, JS key code])
var wikEdButtonKey = {
  26: ['b', 66], // wikify
  32: ['g', 71]  // scrolltoedit
};

Check the wiked source code for the required codes and check the wikEd_customization page for more details. Cacycle (talk) 00:10, 4 December 2008 (UTC)

Thank you - that's great! I'll have to look into that. What do you mean by "lose the Wikipedia predefined ones"? Will I not be able anymore to preview with shift-alt-p, or does "Preview" double as WikEd button, and I can repredefine it? Would you, by any chance, have a template that contains all the existing predefined shortcuts? That would save me quite a bit of typing and research work, it seems. — Sebastian 05:41, 4 December 2008 (UTC)

Just check the source code of a Wikipedia edit page for acceskey=" to see the current accesskeys. wikEd uses b, g, and o (the only free ones when I implemented this). Cacycle (talk) 17:21, 4 December 2008 (UTC)

Cool, thanks! — Sebastian 04:00, 5 December 2008 (UTC)

Coding assistence sought: plugin for date delinking and adding metric units

I have a date delinking script: User:Lightmouse/monobook.js/script.js. It has the following options:

• Change linked dates to 'dmy' format. Unlink dates.
• Change linked dates to 'mdy' format. Unlink dates.
• Change all dates to 'dmy' format. Unlink dates.
• Change all dates to 'mdy' format. Unlink dates.
• Add metric conversions.

I would like to turn it into a WikEdit plugin, but it is outside my current skills. Would anyone be willing to help me with the coding? Lightmouse (talk) 10:12, 4 December 2008 (UTC)

Another newbie question: Syntax coloring

I just ran into an unclosed ref tag, and because the syntax seemed correct, I asked at HD. The edit diff is here. I had thought such an important difference would be obvious thanks to the syntax coloring, but it seems to me that this looks normal. Maybe it's that you're using different shades of bluish-gray to express different things? — Sebastian 04:07, 5 December 2008 (UTC)

As far as I can see the syntax coloring works just fine - the unclosed ref tag is treated as normal text. Cacycle (talk) 05:30, 7 December 2008 (UTC)

BUG? - WikiEd not working (version 0.9.67d G (November 19th, 2008)

Hello, my WikiEd does not seem to be working. I was about to send a warning message user:72.148.61.160 for vandalizing this page, however, the WikEd just seems to stop at "data loaded..." with no message added. What should I do? Prowikipedians (talk) 03:15, 7 December 2008 (UTC)

Adding: Time 03:15, 7 December 2008 (UTC)

Browser: Mozilla Firefox, Safari, Internet Explorer

Please describe your problem in more detail, I am not sure what exactly your problem is (see the top of this page for the required infos). Thanks, Cacycle (talk) 05:23, 7 December 2008 (UTC)

Updated Bug Report by Prowikipedians (talk) 05:47, 7 December 2008 (UTC)

Version: WikiEd 0.9.67d G (November 19th, 2008) Safari Version 3.2.1 (525.27.1) Cleared all cache as a user suggested, but nothing worked. All browsers (Mozilla Firefox, Internet Explorers, Safari) all have shockwave/flash installed. No user scripts installed on my monobook.js page Windows XP (and Ubuntu 8.10) Cannot use the warn/arv/etc buttons. 1) Clicked "warn" on user talk page. 2) Only shows "data loaded..." and freezes there. Nothing. Just freezes there.

This sound like a problem with a gadget, please check your Wikipedia preferences -> Gadgets and find out which gadget is responsible for these buttons. Thanks, Cacycle (talk) 18:11, 7 December 2008 (UTC)

Currently working. Hey. It's working now under Linux. Was able to warn this user. Prowikipedians (talk) 12:02, 8 December 2008 (UTC)

WikED produces an unwanted space in the comments field on uploading images, forcing a 'blank' comment

Config:
WikED version: 0.9.67d
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js, the only script installed is the install for wikED

Problem encountered:
On uploading an image with WikED enabled, if no comment is inserted in the Summary field, WikED automatically sends a single space as the comment. This results in the parentheses appearing in the recent changes, enclosing a single space.

I tested this with 3 image uploads, and produced the following:

Uploaded image and added a comment in the Summary produced: Username uploaded "Image:filename.png" (comment)
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png" ( )
Disabled WikED
Uploaded image with no comment in the Summary produced: Username uploaded "Image:filename.png"

To make things interesting, with WikED enabled, I went into the upload image window, then clicked on "toggle to standard edit window". This produced the expected standard edit window and put a space followed by a carriage return in the window!

I realize that this is a minor thing, but one of the sysops brought it to my attention, so I thought I'd pass it along. The community involved is wiki.ffxiclopedia.org

Thanks! Ffxiclopedia Catrinm (talk) 04:52, 10 December 2008 (UTC)

Fixed in upcoming release. Thanks, Cacycle (talk) 01:05, 26 December 2008 (UTC)

Fixed in 0.9.68. Cacycle (talk) 19:30, 28 December 2008 (UTC)

Killing leading whitespace

Using the gadget version (0.9.67d G). Reproduce open page (like James Bond (character)) with the HTMLarea and syntax highlighting enabled, then disabled syntax highlighting (leave HTMLarea enabled). Click the diff and notice the leading whitespace is gone now. — Dispenser 19:11, 22 December 2008 (UTC)

Fixed in upcoming release. Thanks, Cacycle (talk) 01:05, 26 December 2008 (UTC)

Fixed in 0.9.68. Cacycle (talk) 19:30, 28 December 2008 (UTC)

When following the steps listed above it continues to remove the leading whitespace using 0.9.68 in Firefox 3.1 Beta 2. — Dispenser 06:38, 7 January 2009 (UTC)

Finally fixed in 0.9.68a. Thanks, Cacycle (talk) 13:49, 9 January 2009 (UTC)

Things from User:Dispenser

• WP:AWB/FR#External to Interwiki for converting those pasted in URLs

  This is problematic because it is Wikipedia-specific. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  Should you be able to use wgServer + wgArticlePath ? Also the regexes at the end are shorter and might be a good inclusion for the fixes button. — Dispenser 06:11, 29 December 2008 (UTC)

• Using [#R] should no longer blank the edit summary since we now have WP:AES

  This is also Wikipedia-specific and there is no reason to use that fallback instead of the wikEd-generated summary. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  No, just MediaWiki specific. Since wikEd fills it automatically in and fails to trigger the blank summary warning when a user hasn't touched it. — Dispenser 06:11, 29 December 2008 (UTC)

  It is a new addition and most MediaWiki installations do not have it yet. Beside that I do not see a reason to use that empty summary fallback mechanism when we can automatically fill in the summary. Cacycle (talk) 08:40, 29 December 2008 (UTC)

• WP:AWB/FR#Regex checker, so I don't constantly do /| cell/

  I will think about an error flag, but this will not help you with syntactically correct regexps.

  I was think just coloring the back of the text box #F6DFE0 for errors and #FFF8DC for warning. Sample idea code:

function checkRegexp(text) {
    window.status = "No error detected"
    try {
        if(text == '')
            return 0
        re = new RegExp(text)
        if(''.match(re)){
            window.status = "Empty string matches";
            return 1
        }
        if(' \r\n\t'.match(re)){
            window.status = "Matches white space";
            return 1
        }
        return 0;
    }catch(e){
        window.status = "Compiling error"+e;
        return 2;
    }
}

• http://www.pml.ac.uk/biomare/sites/Darß-Zingst.htm is incorrectly highlighted (listed at WP:linkrot) as I tried to point out before character \u007f-\uffff are valid in URLs. I use three regexes in my Checklinks tool: brackted link, free link, free link contain '('.

  Fixed in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

  Isn't it a little excessive to define every character, for reference here's the MediaWiki regex

// Line 133-134, Parser.php
        $this->mExtLinkBracketedRegex = '/\[(\b(' . wfUrlProtocols() . ')'.
            '[^][<>"\\x00-\\x20\\x7F]+) *([^\]\\x0a\\x0d]*?)\]/S';

• The table button should be producing class="wikitable" border="1" per Wikitable borders without CSS

  Added in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

Mostly fixed in upcoming release. Thanks, Cacycle (talk) 01:06, 26 December 2008 (UTC)

Fixes and suggestions added to in 0.9.68. Cacycle (talk) 19:29, 28 December 2008 (UTC)

does not work with other wikipeida preferences page serif pref

If you choose serif (or is it sans?) in your preferences page wikied is still monospace. how can i change the font from monospace?

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 latest version from wikipedia pref page

Add the following code to your monobook.js and change to your preferences: Cacycle (talk) 01:04, 26 December 2008 (UTC)

var wikEdFrameCSS = {};
wikEdFrameCSS['.wikEdFrameBody'] = 'background: #FFFFFF; margin: 0px; padding: 0.2em; overflow: -moz-scrollbars-vertical; overflow-x: auto; font-family: monospace;';

Documentation bug

On User:Cacycle/wikEd.js, it says: "5. Optional: customize the program by adding user settings to your ''''' page". This should be monobook.js, no? /skagedal^talk 15:31, 30 December 2008 (UTC)

Yes, it should be monobook.js, I will change that for the next release. Thanks, Cacycle (talk) 16:12, 30 December 2008 (UTC)

Fixed in 0.9.68a. Thanks, Cacycle (talk) 13:48, 9 January 2009 (UTC)

xcen > de

Insertion of "xcen > de" on each "save page", "preview"

I'm using wikEd via Greasemonkey on my local mediawiki. Each time I press the Save Page or Preview button when editing a page somebody inserts automatically a line containing xcen > de on the top of the edited page (the more I press the buttons the more lines will be inserted) Disabling wikEd by disabling greasemonkey, the standard Save or Preview buttons of Mediawiki work as expected: no unwanted lines are inserted ...

What's going on? Who inserts those unwanted lines and why? Probably you will see those lines on top of this page due this behaviour ... ;-)

I cannot reproduce this. Please could you fill out a full bug report (see top of this page). Thanks, Cacycle (talk) 15:02, 7 January 2009 (UTC)

a bug about followLink ? and a suggestion

i am in korean translation. while editing, for example, when i put a mouse on the

[[Image:filename|thumb|150px|explain]]

then popup shows "Imagefilename (ctrl-click)" i think "Image:filename" is right than "Imagefilename" check it please. and it would be nice that HighlightSyntax could be always being updated. --Ilovesabbath (talk) 19:48, 8 January 2009 (UTC)

I have fixed this in the current release (0.9.68a). Unfortunately, automatic syntax highlighting is not possible at the moment, please see User:Cacycle/wikEd_help#Automatic_syntax_highlighting. Thanks, Cacycle (talk) 13:47, 9 January 2009 (UTC)

What i hate most about my wonderful WikEd

1. Hides a cue i've spent 5 years getting used to using: when the Subject/headline pane is above the edit one, anything you add after the section heading changes the heading, but when it's below, you can put lots of info that appears only in the edit history. (Or rather, that's how i'm used to it working, so i get reminded bcz i've saved a verbose & unsuitable hdg.)
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   

   Please could you explain this in more detail, I do not recognize this feature. Is it a non-native user script function? Cacycle (talk) 14:30, 13 January 2009 (UTC)

   • Surely i've just described it badly. The situation is creating a new section with the "new section" tab on a talk page, which with my prefs appears as a "+" tab. With the WikEd gadget absent from my prefs, this produces in relevant part (using a handy talk page [wink]):

   Editing User talk:Cacycle/wikEd (new section)
   From Wikipedia, the free encyclopedia
   This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).
   Subject/headline (Single-line editing pane)
   (Good-sized
   
   rectangular
   
   editing
   
   pane)
   Content that violates any copyright will be deleted. Encyclopedic content must be verifiable. You irrevocably agree to release your contributions under the terms of the GFDL*.
   (Check box) This is a minor edit (what's this?) (Check box) Watch this page
   ("Save page", "Show preview", and "Show changes" buttons ) Cancel | Editing help (opens in new window)
   Do not copy text from other websites without a GFDL-compatible license. It will be deleted.

   Adding something to each pane and hitting Preview adds something like

   Preview
   

   Remember that this is only a preview; your changes have not yet been saved!
   

   test
   

   aksfjasfjdaklj ljkdflaksfj; lksdfjl;askdfj ljkslf;djka

   above the one-line pane, and a line like

   Subject/headline preview: (→test: new section)

   between the two panes.

   With the WikEd gadget pref'ed on (and even with its toggle set to "classic text area"), the + or "start new section" tab has the same result, except that the WikEd 5x2 set of buttons above the good-sized pane at the right, and i think a few other buttons below it appear. But when text is added to both boxes and a preview is requested,

   1. the non-WikEd layout as previously described briefly appears (including the one-line pane replacing the 5x2 set of buttons), then
   2. the 5x2 set replaces the one-line pane, and
   3. a "Subject/headline" one-line pane appears below the good-sized pane, and
   4. 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)
  

1. Navigation popups' edit-pane lk'd-article previews don't work, so i have to click preview and hover in the page preview links to preview the lk'd articles.
   

   What is "lk'd-"? Cacycle (talk) 05:09, 7 February 2009 (UTC)
   

2. 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)
       
3. 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)
     

4. Switching WikEd on (or off?) clears the selection of text within the edit pane.
5. Hmmm, nagging worry that the wiki-page i originally created (to get Pop-up tools before it was a gadget) is screwing things up now that i have the gadget turned on.
   --Jerzy•t 07:06, 13 January 2009 (UTC) Late sig
   

   Try to empty your now useless User:Jerzy/monobook.js page and see if things get better. Cacycle (talk) 14:30, 13 January 2009 (UTC)

   • Done, and that may have at least speeded things up. But i'm not yet willing to treat the Zocky tool as "useless", in light of my tendency to alternate between automated replacements and viewing lk'd pages (via Pop-ups, which remain functional when WikEd is pref'd but toggled off, and thus save need for intervening preview refreshes).
     --Jerzy•t 23:57, 16 January 2009 (UTC)
     

• And is it WikEd that makes long-summary previews fail to word-wrap?
  --Jerzy•t 07:20, 13 January 2009 (UTC)
  
  • Please explain in more detail. Thanks, Cacycle (talk) 14:30, 13 January 2009 (UTC)
    • Will do, tho not before the pending save.
      --Jerzy•t 23:57, 16 January 2009 (UTC)
      
    • It is indeed WikEd (or combining it with "A clock in the personal toolbar...", which feels too far-fetched to explicitly test!) that has this effect, which i now describe in detail:
      Immediately below the single-line pane labeled "Edit summary" there appears the wording "Preview of edit summary" which is followed, usually on the same line, by a representation of how the summary will be rendered in edit histories and the like. With WikEd un-Pref'd, a long summary (i presume any that when preceded by "Preview of edit summary" renders wider than the good-sized edit pane) is "word wrapped" into a two-line form that can be read without scrolling to the right. With WikEd in my prefs (whether the WikEd toggle is set to "classic text area" or not), a sufficiently long rendering instead extends in the window further right than anything else (except for the monobook "wallpaper-like" background graphic).
      It may be important to mention that while my Prefs page is exactly the width of the screen, my edit page is wider than the screen (which barely accommodates the good-sized edit pane), even tho what is off the screen to the right (with the window maximized in the default state where the left edge of the page is at the left edge of the screen) is normally only the wallpaper. With WikEd Pref'd, the wallpaper is overlaid by any excess length of the rendering of the summary. If the edit summary renders wider than the minimum edit-page width (which as stated is more than the screen width), it controls the width of the page: the close-paren in that rendering is against the right edge of the page.
      --Jerzy•t 19:45, 17 January 2009 (UTC)
      

The summary preview is not a standard feature on the English Wikipedia. Please could you tell me which wiki you use or which extension, user script, or gadget is responsible for it. Thanks, Cacycle (talk) 13:42, 2 February 2009 (UTC)

Globally relevant details

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

Color highlighting

How would I go about changing the colors used to highlight the text? That's a really nice program that you made!

WriterHound (talk) 03:13, 14 January 2009 (UTC)

Please check User:Cacycle/wikEd_customization and the top of the source code. Cacycle (talk) 04:21, 14 January 2009 (UTC)

Bug - probably fix space before punctuation

There is a bug, probably in the fixing of spaces before puncuation. I'm using the latest version of the program and the latest version of Firefox. When there is an image, it puts a space before ".jpg" or ".gif". It also puts a space before ".html" in external references. Example, see my recent edit to My 60 Memorable Games. Bubba73 (talk), 04:25, 14 January 2009 (UTC)

I might improve this sooner or later. Until then, make sure to check your changes :-) Thanks, Cacycle (talk) 02:56, 26 January 2009 (UTC)

I have now improved this fixing function in version 0.9.71 so that punctuation characters in article titles, file names, web links, and character entities are not changed. Cacycle (talk) 03:18, 2 February 2009 (UTC)

Request for script audit as a potential Gadget

Hi, I've proposed a script I wrote as a potential Gadget at Wikipedia:Gadget/proposals#Add_the_.22Localize_Comments.22_script. As a Gadget writer, could you check it out when you have time and audit the script, and post your thoughts on whether it should be a Gadget or not? Thanks in advance! Gary King (talk) 16:54, 16 January 2009 (UTC)

Inserting/deleting newlines spuriously

It appears that wikEd sometimes inserts or deletes a newline in the edit window. Typical scenario is as follows:

1. you copy and paste something in the edit window
2. you see that there is e.g. one empty line in the edit window
3. after you save the changes and edit the article again, you find out that there are two empty lines (or no empty lines) where there used to be one

This happens in Google Chrome, never in Firefox. Do you know what might be the reason? I'm suspecting a Webkit bug... GregorB (talk) 22:38, 18 January 2009 (UTC)

Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)

When pasting rich text it is not always easy to see the number of line breaks. Push the or button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)

Here's what "works" for me:

1. Open e.g. this page in a new tab.
2. Type #<Enter>#<Enter>#<Enter>
3. Click on "Preview" (or on ).
4. "#" characters from the step 2 are now separated by empty lines

The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)

Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)

I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)

Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)

Here it is:

• WikEd version: 0.9.68a
• Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19
• Console errors: none (hope I'm getting it right: ctrl-shift-J window)
• Add-ons: none
• User scripts: none
• OS: Windows XP SP3

• Problem and steps to reproduce: as described above

Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)

Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)

Safari and Chrome use <div>...</div> tags for linebreaks instead of <br>. I have no idea why they do this. It seriously messes things up and there is no easy workaround for it other than using browser detection as far as I can see :-S Cacycle (talk) 04:29, 27 January 2009 (UTC)

Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)

I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)

Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[3], then inserts too many.[4] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)

It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)

Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)

I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)

2 vars not working?

I'm using 0.9.68a on FF3 - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

I don't have any other JS tools in my monobook.js nor using Gadgets.

I've been using wikEd ever since I registered for wikipedia and it's a great tool. Only today did I learn that I could customize it so I read the manual and made a few changes.

Most of the tweaks in my monobook.js worked, but 2 of them didn't:

var wikEdButtonsOnTop = false; var wikEdButtonBarFindHidden = true;

The toolbars are still above the edit box and the find bar isn't hidden.

Is this a bug or am I doing something wrong?

Thanks. This is a really useful tool! --Armchair info guy (talk) 02:39, 19 January 2009 (UTC)

The two variables no longer exist. I am curently preparing a complete and updated list. Thanks, Cacycle (talk) 02:50, 26 January 2009 (UTC)

Thanks for replying. I should've searched the code first. I see that cookies are used for the Hidden and that the Top feature no longer exists. Just curious - why is the top feature gone? --Armchair info guy (talk) 09:04, 11 February 2009 (UTC)

can wikEd automatically scroll to the preview/change box and move focus out of edit box?

Me again. I'm wondering if wikEd can automatically scroll to the preview/changes box when I press either button. I know I can do it with the separate buttons on the tooblar at the right side of the screen, but it'd be more convenient to do so automatically.

Also, it'd be great if the browser focus switches out of the edit box and onto the page when I press preview/changes, so that when I hit spacebar it's a browser page down scroll instead of adding an undesired text space. Probably been dozens of times I've had this happen and then I have to click outside the edit box to change focus.

Thanks again. --Armchair info guy (talk) 02:52, 19 January 2009 (UTC)

I have fixed the intelligent scrolling function in 0.9.71, depending on your window scrolling position it will scroll to the buttons, the edit field, or the preview field. Unfortunately, changing the focus would come surprising for most users and would probably cause more problems than leaving it as it is. Thanks - Cacycle (talk) 03:04, 2 February 2009 (UTC)

The new rev doesn't properly scroll down to the preview/changes box. It only scrolls down a fraction of an inch. So it appears to be doing some sort of scroll down but effectively it's nothing. What I'd like it to do is basically a standard "page down" scroll, since wikEd & toolbars fit nicely within the screen.

And if this "page down" scroll is implemented, I need to reiterate that window focus should transfer out of the edit box. Most sections/pages I edit are longer than an entire screen, so I need to scroll down even further to verify my edits. And to take it one step further, using the existing scroll buttons on the right-side toolbar should also transfer window focus: pressing "down" should transfer focus to the main page but "up" should put the focus in the edit box. It would make wikEd cleaner and more efficient. I suppose existing users would be "surprised" by this new feature but I'm confident most/all would prefer it.

Thanks again for your active maintainance of wikEd and responses here. --Armchair info guy (talk) 04:23, 10 February 2009 (UTC)

The final scrolling position depends on were your current scrolling position is. If you are lower than the middle of the edit box it will scroll down to the preview/diff box. Focusing into the preview/diff box is not a good idea as you will lose the caret (cursor) position. Most people would not want that for the small benefit of being able to use the space bar shortcut that most people are not even aware of. But thanks for the suggestions! :-) Cacycle (talk) 20:05, 10 February 2009 (UTC)

Thanks for explaining the design decision. I definitely take spacebar scrolling for granted. But, could you add this feature with a var default to false? Those of us who use spacebar scrolling would surely appreciate it ;)

Also, I'd like to know more about how wikEd looks at "current scrolling position". If it's variable (which I hope) I'd like to set it to the top of the screen to always snap to the preview/changes box. Otherwise, if hardcoded, where/how can I tweak it? (I know very little about DOM,javascript,etc. so the newbie version is appreciated) Thanks! --Armchair info guy (talk) 09:02, 11 February 2009 (UTC)

bug with AWB's RegExp - capitalizing every word beginning with "th"

My 3rd topic in a row. I also added AWB's RegExp button (one of the monobook.js var additions that worked properly, in reference to my first topic). I tried it out and it capitalized every word beginning with "th" - the, them, they, etc. Obviously a bug since most shouldn't be. I assumed it was a bug with RegExp and filed a bug over there but one of them replied that the problem was likely in wikEd.

I have no idea one way or the other. Just reporting it here so you guys can get to the bottom of it. Thanks! --Armchair info guy (talk) 04:08, 19 January 2009 (UTC)

ThaddeusB was right about the case sensitive thing. I will correct this in the next release. Thanks, Cacycle (talk) 13:02, 19 January 2009 (UTC)

Fixed in 0.9.69a. Cacycle (talk) 04:55, 26 January 2009 (UTC)

Paste from Word?

Perhaps this isn't a bug and I'm doing something wrong or my system isn't fully supported, but I can't discern that from the documentation.

• WikiEd v0.9.68a (appears to be latest)
• Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5
• FF Error Console is has no errors or warnings
• AddOns: FlashBlock, AllInOne Gestures, GMail notifier, Web Developer
• User scripts: none
• OS: Mac OS X 10.4.11
• Word X for Mac Service Release 1

I'm trying to get copy from Word to MediaWiki with formatting intact. I'm trying an extremely minimal test case: in the Word document are three words, each on their own line. One is normal, one is bold, and one is italic. When I copy/paste into WikiEd, I get the three words with no formatting. When I click the [W] button, the text I just pasted is selected but otherwise nothing happens.

Am I missing a step, is my software combination unsupported, or did I actually find a bug? —Preceding unsigned comment added by 209.240.239.188 (talk) 17:20, 19 January 2009 (UTC)

Strange, after pasting the formatting should remain as in Word. Maybe something is still strange on Mac. Unfortunately, I do not have an Apple and cannot test this. Do you see the normal syntax highlighting? Cacycle (talk) 23:36, 19 January 2009 (UTC)

I get syntax highlighting on wiki-formatted text (like if I edit the main page). I do not get syntax highlighting on what I paste from Word. I can verify two possibly useful bits of information: when I copy text in Word for Mac, it does go to the OS level clipboard rather than an internal, app-specific one, and formatting is preserved.

I also found formatting - at least the basics that I've tested - are preserved in Safari. I suspect the problem has more to do with FF's handling of the OS X clipboard than anything WikiEd is doing. If you can point me in the right general direction where clipboard handling is in the code (and how to run a local copy instead of sourcing it off wikipedia), I'd be willing to look for a Firefox workaround. —Preceding unsigned comment added by 209.240.239.188 (talk) 15:29, 20 January 2009 (UTC)

wikEd completely relies on the browser's internal editor and I have no idea about that Firefox code. Here is a rich text editor on the web (good for testing such issues): http://www.kevinroth.com/rte/demo.htm. On User:Cacycle/wikEd_development there is a description for setting up a local test environment for wikEd (somewhat complicated). Thanks, Cacycle (talk) 05:29, 21 January 2009 (UTC)

Could you please file a bug report at http://bugzilla.mozilla.org/ stating that under Os X only plain text, not rich text is pasted from Word into the Firefox editor Midas. Thanks, Cacycle (talk) 13:26, 21 January 2009 (UTC)

There is already a Firefox bug report: bug 428096. Cacycle (talk) 14:25, 27 January 2009 (UTC)

Spacing and punctuation at references

I have a suggestion for a new feature. Could you program wikEd to repair spacing and punctuation placement at references? Some examples below:

• Wikipedia is an encyclopedia<ref>reference</ref>. (punct. at end)
  
• Wikipedia is an encyclopedia. <ref>reference</ref> (extra space)
  
• Wikipedia is an encyclopedia <ref>reference</ref>. (extra space and punct. at end)
  
• Wikipedia is an encyclopedia.<ref>reference</ref>. (duplicate punct.)

It should read:

• Wikipedia is an encyclopedia.<ref>reference</ref> It is really thorough.
• Wikipedia is an encyclopedia;<ref>reference</ref> it is a wiki.

See: Manual of Style.

This feature could detect certain end of sentence punctuation . ? ! and place it before the reference(s), then remove any extra space(s). It would also remove extra spaces before references in the middle of a sentence; none before and only one space after the reference. One space would be preserved or added as necessary at the end of each reference. Duplicate punctuation at the end of a reference would be removed.

Thank you for your consideration and nice work here. ~ All is One ~ (talk) 00:52, 20 January 2009 (UTC)

Thanks for the suggestion, I will probably add this when I find the time. Cacycle (talk) 02:46, 26 January 2009 (UTC)

But then, this is probably an English Wikipedia specific convention, it might be different in other languages and other wikis. Cacycle (talk) 13:30, 29 January 2009 (UTC)

Creating tables

Will this WYSIWYG editor allow for an easy method of creating tables? I'm trying to find an editor for my wiki that will help users create tables easier than the standard wiki markup. Thanks! --Brandon (talk) 16:04, 21 January 2009 (UTC)

Let me take the liberty of answering the question... A single click on the wikEd's "Table" toolbar button produces this:

caption

heading	heading
cell	cell
cell	cell

It beats typing. :-) GregorB (talk) 16:49, 21 January 2009 (UTC)

wikEd is also almost set up to switch between WYSIWYG-like table editing and wikicode... Cacycle (talk) 00:02, 22 January 2009 (UTC)

Try var wikEdShowTableModeButton = true; on your monobook.js page... Cacycle (talk) 14:43, 22 January 2009 (UTC)

(Works currently only with pasted html tables). Cacycle (talk) 03:00, 2 February 2009 (UTC)

EditEnhancements conflicts with WikEd

Config:
WikED version: 0.9.68a
Browser: Firefox 3.0.4
Addons installed: Adblock, Flashgot, Greasemonkey, Noscript, Stylish
Using Monaco.js

Recently, wiki.ffxiclopedia.org installed a new extension "EditEnhancements" from MediaWiki. The expected result is that the "Save", "Preview" etc. buttons now appear on a bar which sits at the bottom of the view area, and scrolls up and down as the view area changes so as to always sit at the bottom of the view area. The Special:Version lists this as: EditEnhancements (Version 1.0) Christian Williams and Maciej Brencz

With WikEd enabled, it doesn't work as expected. The result is that directly below the edit window I only have the "save" button. I have to drop out of full page edit mode to find the preview button which, along with several other bits and pieces, are now in a fixed position further down the page. There is all sorts of unexpected behaviour from this. As one example, on the FFXI site, the space below the "save, preview, changes" buttons is used for a table containing some commonly used wiki markup shortcuts. Closing the preview pane from the WikEd button simply toggles this on and off and doesn't affect the prefiew pane at all! With WikEd enabled, "save" button remains in place while the "preview" and "Changes" buttons are moved to below that table, so I have to hit ctrl-end (end of page) to get to them!

A preview of this can be achieved on this page by editing the text, then scrolling below the edit box. Imagine the "preview" and "Changes" buttons now appear below the line that starts "Once you click the Save button..." and the "Do not copy text from other websites without ...." line has moved down there with them, leaving the "Copy and Paste" table in place. I can provide screenshots if required, just let me know!

Thanks for your attention to this :) Ffxiclopedia Catrinm (talk) 08:14, 22 January 2009 (UTC)

As a workaround add var wikEdNoRearrange = true; to your monobook.js page. Cacycle (talk) 02:45, 26 January 2009 (UTC)

can't insert non-breaking-space correctly in German Wikipedia

steps to reproduce:

1. switch to German Wikipedia, this bug does not occur on en.wikipedia
2. enter text, example: 22 km
3. place cursor (|): 22|km
4. click &nbsp; and you get &22kmnbsp; instead of 22&nbsp;km

using

• wikEd 0.9.68a Deutsch
• Firefox 3.0.5

Matthias M. (talk) 18:26, 28 January 2009 (UTC)

There is neither a &nbsp; button in wikEd nor is there such an extension on your monobook.js page. Please could you specify what button one has to push. Thanks, Cacycle (talk) 18:50, 28 January 2009 (UTC)

Hello, I hope you understand my bad english: The Button &nbsp; is part of the normal edit window for Articles und discussions in the german wikipedia. If wikEd is switched on, then the malfunction, discribed by Matthias M., happens. I myself reported this malfunction to Matthias M., he is the translator of the german GUI. Nice day --Astrobeamer (talk) 19:17, 28 January 2009 (UTC)

Ah, I see, it is one of the links  under the edit  area. Cacycle (talk) 22:08, 28 January 2009 (UTC)

It has to do with this workaround at the German Wikipedia: de:MediaWiki_Diskussion:Edittools/Archiv#nbsp-Probleme. Please tell them to switch to the MediaWiki:Edittools.js system that is used on the English Wikipedia. Cacycle (talk) 23:07, 28 January 2009 (UTC)

As far as I can tell, somebody was working on it but did not make the final edit: de:MediaWiki_Diskussion:Edittools/Archiv#Edittools_durch_dynamisch_ladbares_Skript_ersetzen. Cacycle (talk) 13:26, 29 January 2009 (UTC)

I put a message to de:MediaWiki_Diskussion:Edittools#zu_en:MediaWiki:Edittools.js_wechseln to inform the German Wikipedians about this issue. Matthias M. (talk) 16:18, 29 January 2009 (UTC)

wikEd in Wikisource

Hi, I work on Wikisource fr and I would realy appreciate wikEd to work properly in proofreading mode (for example). The edit window goes to the bottom of the page instead of next to the image, where the textarea normally stands. With wikEd 0.9.69a, on Firefox 3.0.5. —Preceding unsigned comment added by Aroche (talk • contribs) 12:52, 31 January 2009 (UTC)

I have added Proofread Page extension compatibility to the newest release 0.9.70. Thanks for the suggestion - Cacycle (talk) 21:45, 31 January 2009 (UTC)

Fix Unicode

When I use button for fix Unicode in it.wiki, it doesn't works anymore and now appears a window: Uknown function wikEdFixUnicode. Moreover, in some pages some wikEd buttons don't appear. What can be the problem? I don't understand. Script is called here, and these problems started I think not more than few weeks ago. Thank you Lenore (talk) 14:58, 1 February 2009 (UTC)

This has been fixed in the latest release, Shift-Reload to update. Cacycle (talk) 15:25, 1 February 2009 (UTC)

Ok thank you Lenore (talk) 17:07, 1 February 2009 (UTC)

Problem with the Firefox extension "WOT" and your script

Hello, Cacycle. Since some months I have a problem, if i upload an image using your script on the upload page with my firefox.

• Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
• WOT (from http://www.mywot.com/de)

Always the following lines apear on the upload page, but not until storing of the image.

Vertrauensw.:
Händlerzuverl.:
Datenschutz:
Jugendschutz:

The lines not apear in the editing box, but during the preview (of your script) in the lower part of the page and after the storing. I would be glad, if you could find a solution. Greetings --Tlustulimu (talk) 17:04, 2 February 2009 (UTC)

I will fix this for the next release. Cacycle (talk) 04:50, 3 February 2009 (UTC)

Fixed in wikEd 0.9.72. Cacycle (talk) 04:20, 16 February 2009 (UTC)

Thank you very much. --Tlustulimu (talk) 16:43, 16 February 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)

Wikia link suggest

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

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

Feature request - dashes

I'm always replacing casual use of the ASCII '-' (hyphen-minus) with the correct typesetting mark, typically em-dash but sometimes em-dash and occasionally the minus character. These show up as different in a proportional font like the normal web page, but all look the same in the edit window!

I think that simply coloring them differently would do the trick. For example, if regular text is black, make the em-dash blue, the en-dash green, and the minus red. To serve as a key of sorts, color-code the "insert" hyperlinks to match.

—Długosz (talk) 17:42, 12 February 2009 (UTC)

P.S. Some time ago I tried the "fix dashes" button, but it didn't do anything useful. That was years ago, so I'll try it again.

On this page (permanent link to version), the "fix dashes" button does not handle the first paragraph:

The technological singularity is a theoretical future point of unprecedented technological progress -- typically associated with advancements in computer hardware or the ability of machines to improve themselves using artificial intelligence.

It changes this to an EN-dash and leaves the spaces around it. The correct fix is an EM-dash and delete the spaces.

On this page (permanent link to version), select the paragraph:

There has also been speculation that a large tsunami in the Mediterranean Sea caused by the Thera eruption dated ca. 1630-1600 BC geologically…

The fix-dashes button did nothing. I expected it to change the hyphen-minus in the range "1630-1600 BC" to an EN-dash.

On editing this section (permanent link to version), the first paragraph contains a range and the second contains a parentetical thought. I expected the "fix dashes" button to change the first to an EN-dash and the second to EM-dashes without surrounding whitespace. It did nothing.

Unconventional dashes and spaces are now highlighted with a small blue indicator and hover-over popup in version 0.9.73. I have changed the -- fix to em space. Unortunately, there is no automatic way to differentiate between range and minus between numbers. Cacycle (talk) 04:15, 16 February 2009 (UTC)

I saw the minus signs. The Testing→(− – — -)Cool! The difference in bullet, n, and m is visible, and not intrusive. Where can I see the rules/logic for dash fixing? At the very least I'll know what to expect. But perhaps I can offer further improvement. —Długosz (talk) 19:29, 18 February 2009 (UTC)

Search the code for "WikEdFixDashes", currently line 6501. Please feel free to suggest more or better rules. Cacycle (talk) 14:38, 19 February 2009 (UTC)

wikEdRegExTypoFix

I tried to load typos in it.wiki from this page, but doesn't work, button doesn't appear. The function in it.wiki is enabled from this page (at the bottom). Thank you for support Lenore (talk) 19:31, 13 February 2009 (UTC)

It works for me. Please could you post a full bug report (see top of this page). Thanks, Cacycle (talk) 02:12, 14 February 2009 (UTC)

Now it works for me too, but only after a total cleaning of FF3 data (cookies, recent, password etc.), cache purge wasn't sufficient. I don't know if this is a bug, but this is the first time that happens something like that for me. I'm sorry to have wasted your time anyway Lenore (talk) 14:34, 14 February 2009 (UTC)

Broken in Google Chrome?

When attempting to edit any article, wikEd displays a red "X" icon in the top right corner ("Loading error"). Edit window is empty.

WikEd version is 0.9.73, user agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19, JavaScript console message is Uncaught TypeError: Cannot call method 'charCodeAt' of undefined http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript (line 8591), OS is Windows XP SP3. On the same machine Firefox 3.0.6 appears to works fine with wikEd 0.9.73. GregorB (talk) 13:03, 17 February 2009 (UTC)

I will fix this as soon as I find the time (tonight?). Cacycle (talk) 17:37, 17 February 2009 (UTC)

Fixed in 0.9.37a, please SHIFT-Reload to update. Cacycle (talk) 04:09, 18 February 2009 (UTC)

Looks good, thanks! GregorB (talk) 08:01, 18 February 2009 (UTC)

Ndash/mdash display bug

Here's a way to reproduce it (Firefox 3.0.6):

1. Click e.g. here
2. Click on the ndash on the area under the edit window
3. An ndash is inserted in the edit box (minus with the small "n" above)
4. Position cursor to the left of the just inserted character
5. Type something
6. The small "n" gets misaligned, i.e. it is rendered above the text typed in the step 5

BTW I really like this new feature. I wish there was a way to custom-render the nbsp character entity in a user-friendlier way. Would this be possible? GregorB (talk) 21:29, 17 February 2009 (UTC)

Now mostly fixed in 0.9.73a... Cacycle (talk) 04:09, 18 February 2009 (UTC)

It still does that for me. 0.9.73a

And I second the suggestion for displaying non-breaking spaces, and extra space in general. &nbsp; is not replaced with U+00A0 by the purple Unicode button. But it certainly could use the same technology, to show a space with a small indicator in it. But you could also use ␢, ␣, or ␠. You could also show extra spaces besides the single space needed to separate words. —Długosz (talk) 19:47, 18 February 2009 (UTC)

wikEd is not (and cannot?) be compatible with non-breaking spaces in the text, it converts them no normal spaces (please see also Wikipedia:Manual of Style (dates and numbers)#Non-breaking_spaces). Długosz: Which OS and browser do you use? It works for me in Firefox and Chrome under Windows. Cacycle (talk) 22:43, 18 February 2009 (UTC)

The only problem with the current solution occurs when you delete the dash/space and do not move the caret (cursor) before continuing to type and the cursor disappears (Firefox bug). Then the first char of the new text has the marker above it until you push . Cacycle (talk) 14:44, 19 February 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)

Version 0.9.74

Hi Cacycle. I saw in Upper Sorbian version wikEd_international_hsb.js that you added the following strings:

• wikEdFixRedirect alt
• wikEdFixRedirect title

and

• wikEdTableMode alt
• wikEdTableMode title

But those 4 strings have already been part of the file. They are double now. Is it correct? Regards, --Michalwiki (talk) 18:55, 23 February 2009 (UTC)

Thanks for catching that. I will fix it tonight. In the meantime it will not hurt. :-) Cacycle (talk) 19:18, 23 February 2009 (UTC)

Maybe that it was because of the different script versions that the languages are using. I'd propose that you better provide a changelog page informing all script translators that there are new changes and every script translator should update his script himself. Regards, --Michalwiki (talk) 21:01, 23 February 2009 (UTC)

So far I have just added the new additions in English so that translators only have to check their watchlist or check if there are new English strings. With a growing number of translations it becomes a bit more work for me, but it keeps the translations in a 'defined state' for easier maintenance. Cacycle (talk) 13:43, 25 February 2009 (UTC)

Works G r e a t under Safari 4 Beta (Tiger). Congratulations!

Hi, long time no comment. Kudos! wikEd runs fast under the new Safari beta (so far). Very quick load; will report any anomalies.
- - - Schweiwikist (talk) 08:07, 25 February 2009 (UTC)

Thanks, good to hear :-) Cacycle (talk) 13:45, 25 February 2009 (UTC)

Apparently it caches the script! Clicking to add this reply, there was zero load-time: all the tools are ready immediately. What a difference. Another thing I wanted to mention is that this is running on a Titanium PBG4 @ 1MHz with only 512MB RAM, and OS X Tiger. Will wikEd move toward supporting the resizeable edit box? ;) - - - Schweiwikist (talk) 14:36, 25 February 2009 (UTC)

I have to agree. Enabling WikEd on the edit page of Barack Obama has never been this lightning quick. --TheDJ (talk • contribs) 20:49, 28 February 2009 (UTC)

I have added a cool new input box resizing grip to the rich text frame in the next release. Cacycle (talk) 15:42, 1 March 2009 (UTC)

As of version 0.9.75 (Shift-Reload to update) the edit area now has a resize grip in the bottom right corner. A double click on it resets to initial dimensions. This does not work in the current Google Chrome (1.0.154.48) and possibly older Safari and WebKit versions due to a browser bug (frame body innerHeight is erroneously scrollHeight). Cacycle (talk) 15:53, 2 March 2009 (UTC)

Small rendering bug under Safari 4 beta (Tiger/PowerPC & Leopard/Intel):Edit summary text entry box

Hi, I can report a small rendering/interface glitch for the current version when running inside Safari 4 public beta (4528.16). This occurred under Leopard (10.5.6 with the security update, of course) on a MacBook (unibody) and also under Tiger (10.4.11 with the current Java version) on a Titanium Powerbook. Specifically, when going into edit mode while wikEd is enabled, or toggling wikEd (master switch by my live clock) while in edit mode, the edit summary text box/interface "drops out" (i.e., hides) until and unless the window is resized (just by a single pixel does it, so it redraws the contents) or fullscreen mode is invoked/uninvoked (producing the same redrawing and unhiding). This doesn't happen in Firefox. - - - Schweiwikist (talk) 01:30, 28 February 2009 (UTC)

I cannot replicate this under Windows XP using the same version. Therefore it is difficult to find a fix or workaround. But I'll try. Cacycle (talk) 15:40, 1 March 2009 (UTC)

bug: disabling and reenabling wikiEd

i found an annoying bug with wikiEd, if i edit a page, then i disable the gadget and reenable it, all the changes in the edit field made after this will not be saved or previewed.

here are the exact steps:

• the wikiEd gadget is enabled
• click "edit this page" button to start editing a page
• add some text (for example: "123")
• click the gadget's icon on the top of the page to disable it
• click again to enable it
• add other text (ex: "456")
• save or preview the page, you'll see that only the "123" text will appear

the wikiEd version is 0.9.74 G (February 21, 2009) and i'm using Firefox 3.0.6: Mozilla/5.0 (Windows; U; Windows NT 6.0; ro; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729) i have this problem both on english and romanian wikipedia. Dany 123 (talk) 12:57, 28 February 2009 (UTC)

Thanks for reporting, I was not aware of this and are currently trying to fix it. BTW, it does not happen if you use the button bar button to temporarily switch to the standard input box. Cacycle (talk) 15:38, 1 March 2009 (UTC)

Fixed in version 0.9.75. Cacycle (talk) 15:48, 2 March 2009 (UTC)

Bug in diff pages

In diff pages wiked makes links lickable right? But there's a bug for which external links work wrong (see for example this) Lenore (talk) 19:21, 28 February 2009 (UTC)

It seems to work for me. Which link are you talking about and what happens? Cacycle (talk) 15:36, 1 March 2009 (UTC)

Try for example http://www.minsocam.org/ammin/AM75/AM75_1290.pdf: only http://www.m is active, and brings to http://www.m. I use FF3 Lenore (talk) 19:13, 1 March 2009 (UTC)

That is actually a Firefox 3 bug and they do not care enough to fix it (it is bug 440926). Feel free to vote for it - see the big box on top of this page. Cacycle (talk) 06:14, 2 March 2009 (UTC)

I'll vote it on the confidence (I don't understand nothing of HTML), but take a look at this, it works for me (even if has some bugs I don't know how to fix) Lenore (talk) 12:56, 2 March 2009 (UTC)

I will add a workaround. Cacycle (talk) 14:42, 2 March 2009 (UTC)

Has been fixed a while ago. Cacycle (talk) 02:33, 30 March 2009 (UTC)

How can I color text (not synthax highlighting!)

I would like to add a text marker to a custom button. How can I achieve this? —Preceding unsigned comment added by 91.50.191.41 (talk) 12:22, 1 March 2009 (UTC)

That needs changes in the program, e.g. in the highlighting code. You cannot do it with a plug-in alone. Can you give some background? Theoretically, I could add support for it in one of the upcoming releases if it is really important. Cacycle (talk) 15:35, 1 March 2009 (UTC)

Way too slow for minor corrections

It takes many seconds before I can make a simple spelling correction. Disabling. DCDuring (talk) 17:54, 5 March 2009 (UTC)

It should not be that slow, maybe something is wrong or incompatible. It would be a big help if you could provide some information to track this down. Most importantly, what kind of computer, operating system, and browser do you use. Is it a slow and/or old computer? Which other gadgets, userscripts, and addons are you running? (Please also see the top of this page for important informations). Does it happen on all pages? what happens if you disable syntax highlighting ( button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 03:36, 6 March 2009 (UTC)

Firefox 3.0.7: Problem with edit-box resizing widget (the little corrugated square thingy)

Well, Firefox just got incremented to 3.0.7, and your recent update broke. Here's my info:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

The quad-pointers pointer that used-to-appear when hovering over the resize square no longer appears, and now the best way to describe the response is that the resizer is slow and slippery: edit-box refresh is very slow, and once the pointer leaves the grab box (and crosses another interface element), refresh halts. Very weird. Obviously Firefox made some major change under the hood, because it used to work just fine. More info once I test on the other Mac, where we haven't updated Firefox. - - - Schweiwikist (talk) 19:15, 7 March 2009 (UTC)

UPDATE: Found source for "downgrading" back to FF 3.0.6. Will report results shortly. Schweiwikist (talk) 19:28, 7 March 2009 (UTC)

UPDATE: Same problem with FF 3.0.6 running, so it's not FF's problem. Apparently this interface bug might have to do with the initial edit box row/column setting in a logged-in user's prefs. Mine are recently set to 20 rows, thanks to your widget. Only enlarging the edit box (down-and/or-right) exhibits this bug. Up and/or left is fine (i.e., into the edit area). Will test ASAP with higher row setting. Schweiwikist (talk) 19:50, 7 March 2009 (UTC)

UPDATE: Nope, doesn't matter what the user prefs are (sorry, my rows setting was 12, not 20!). Confirming the bug in the resize grip is present under FF. Safari, you get a quad pointer which responds fine in all directions. Schweiwikist (talk) 19:59, 7 March 2009 (UTC)

Cursor changing bug fixed in next release. Cacycle (talk) 04:24, 11 March 2009 (UTC)

It only happened with short texts that did not fill the whole edit area. I have also fixed the resizing problems in 0.9.75a. Cacycle (talk) 04:47, 13 March 2009 (UTC)

Yup, it’s okay now even with the Firefox 3.1 beta. - - - Schweiwikist (talk) 21:42, 15 March 2009 (UTC)

Why?

Why did you remove the feature that puts the tabs at the top of the page that lets me easily put CSD, AFD, or other tags on the page? That's all I used WikED for, and now it's gone! No warning, no changelogs, no nuthin. Vistro (talk) 23:42, 7 March 2009 (UTC)

I am not sure what kind of feature you are talking about, it does not sound like a wikEd feature. Please could you explain this in more detail? Thanks, Cacycle (talk) 05:07, 8 March 2009 (UTC)

Are you talking about Twinkle? Cacycle (talk) 05:22, 8 March 2009 (UTC)

Fixing Tools

I have some questions and problems with the Fix tools. Why does Fix HTML or Fix All sometimes insert (-- and --) into pages? Also, Fix Caps seems to act on the entire page instead of just the paragraph as the help page describes. Fix Caps and Fix All often break the behavior of templates such as {{infobox}} by capitalizing the parameters. —Ost (talk) 15:51, 9 March 2009 (UTC)

Hi Ost, please could you try to find a page where (-- and --) are inserted, I cannot find an obvious reason and without an example I cannot fix this. I will check into the other problems later. Thanks in advance, Cacycle (talk) 01:44, 10 March 2009 (UTC)

Thanks for replying to my question and I think fixing the scope of Fix Caps to match the documentation. Most recently I noticed (-- and --) inserted into Muhammad Ali around the infobox, making the characters visible at at the top of the lede. Fix All also breaks the awards table at the bottom of Ali's page by capitalizing the parameters; the achievements table remains intact. —Ost (talk) 20:48, 12 March 2009 (UTC)

Thanks for your help, I have fixed the (-- and --) insertions in 0.9.75a. For me Fix Caps works on the current paragraph as stated (the current "paragraph" can be long if an article has no no empty lines...). The simple logic behind the fix buttons cannot distinguish between table cells and template dividers for lines starting with "|". Never use these buttons on the whole text and check with the diff button before submitting. Cacycle (talk) 04:45, 13 March 2009 (UTC)

Thank you for the fix and for answering my questions. I'm a big fan of the tool and I appreciate your work. —Ost (talk) 12:44, 16 March 2009 (UTC)

Removing buttons

What is the right way of removing some of the default buttons (to make the page less cluttered and faster to load)? Using a custom wikEdButtonBar is not reliable because the script expects the id of some buttons to exist, and dies if the getElementById call returns null. --Tgr (talk) 20:13, 10 March 2009 (UTC)

Click the grips on the left side of the button bars to semi-hide the bar. Completely removing buttons wold not have any effect on page load times. Disable syntax highlighting if you want to speed it up a bit. Cacycle (talk) 04:22, 11 March 2009 (UTC)

Disabling certain buttons should be possible. Not for page loading reasons but for usability. Lots of buttons the editor doesn't need scares the editor. It should be possible to keep the editor simple :) I guess disabling buttons is the first thing ppl check on the customization page. In case you care it would be cool to build the sections yourself e.g. remove all buttons from the fixing buttons section and move WikEd_fix_caps to the main section. --Subfader (talk) 21:14, 17 March 2009 (UTC)

WikEd_fix_caps is only for advanced users, therefore I will keep it in the fixing section. How should users know about the more advanced features when they become more experienced if the buttons are removed? Cacycle (talk) 02:21, 30 March 2009 (UTC)

Incremental find in Google Chrome

Incremental find does not work right in Google Chrome (wikEd 0.9.75, Chrome 1.0.154.48). Here's how to reproduce:

1. Go to e.g. this page
2. In the wikEd search box, type letter by letter: wiked
3. Notice that with each keypress the focus jumps to the next word matching the entered string, instead of staying on the same word. So, typing "wiked" gets you to the fifth instance of the word in the edit window, instead of the first.

This works as expected in Firefox 3. GregorB (talk) 14:13, 11 March 2009 (UTC)

Thanks for reporting, I will check into this (might be a tricky one...) 23:36, 12 March 2009 (UTC)

Lag

WikiED, along with other extra editing tools, causes the edit page to lag, at least for me it does.

-Axmann8 (Talk) 22:25, 12 March 2009 (UTC)

It should not be too slow, maybe something is wrong or incompatible. It would be a big help if you could provide some information to track this down. Most importantly, what kind of computer, operating system, and browser do you use. Is it a slow and/or old computer? Which other gadgets, userscripts, and addons are you running? (Please also see the top of this page for important informations). Does it happen on all pages? what happens if you disable syntax highlighting ( button)? Your help would be greatly appreciated. Thanks in advance, Cacycle (talk) 23:35, 12 March 2009 (UTC)

how to remove buttons?

(Moved here from User_talk:Cacycle/wikEd_customization)

How can I remove edit buttons (as I do not need them)? Loading of buttons is very very slow.... I use only the syntax-highlight function which is very useful. 88.209.142.83 (talk) 21:06, 13 March 2009 (UTC)

You cannot disable the loading of the button images, but that should not be a problem as they are loaded only once and are then kept in the cache. Other than the loading of the actual button images they do not slow down page loading. Please see also the above question. Please could you give some more informations about your system, your connection, and other details (see the top of this page for relevant information) - maybe there is something I can do to improve wikEd. Thanks in advance, Cacycle (talk) 03:57, 14 March 2009 (UTC)

---

1. wikEd version - 0.9.75b G March 14, 2009
2. browser id - Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
3. Error console errors - (nothing relevant)
4. browser add-ons - (all disabled now): AutoPager, Calculator, ColorfulTabs, DownThemAll, FEBE, Flagfox, Forecastbar Enhanced, Googlepedia, GooglePreview, Hungarian dictionary, NoScript, SecurePasswordGenerator, StumbleUpon, SunCult, WOT

• Optional: What happens if you disable your add-ons and restart the browser - WikEd works as intended: the buttons are loaded just once!

1. user scripts in monobook.js - (nothing relevant)
2. operating system - Windows XP SP3
3. Describe the problem - the buttons were loaded at every page
4. Steps to reproduce - opening for edit a Wikipedia page

It seems the problem is gone with one of my Firefox add-ons (I try to narrow it to one add-on with enabling them one-by-one) 88.209.143.46 (talk) 11:24, 15 March 2009 (UTC)

I enabled all of the add-ons in Firefox and WikEd works well! Maybe you did something beneficial during the last couple of days? 88.209.143.46 (talk) 11:36, 15 March 2009 (UTC)

---

Strange things again... For a while all worked well, but today I noticed that WikEd loads again the buttons at every page I open for editing.

I disabled all the Firefox add-ons, then enabled them all, and everything goes well again with WikEd (I suppose: for a while). Maybe yesterday it was OK, I don't remember exactly, so 1 or 2 days passed without this failure.

What can I do now to find the cause? 88.209.147.7 (talk) 18:38, 17 March 2009 (UTC)

I have no idea. It could be a cache or proxy problem. Do you have enough local cache space and what happens if you clear it? Do you use a proxy server? I have recently fixed wikEd to work with WOT and WOT manipulates the pages in strange ways - does it still happen when you disable it? Cacycle (talk) 02:30, 27 March 2009 (UTC)

Firefox "Security Error"

1. Steps to reproduce:
   1. Follow site-wide installation instructions
      1. Edit MediaWiki:Common.js
      2. Paste in installation code
         1. <// install User:Cacycle/wikEd in-browser text editor
         2. document.write('<script type="text/javascript" src="'
         3. + 'http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js'
         4. + '&action=raw&ctype=text/javascript"></' + 'script>');
      3. Refresh page in browser
      4. Error console shows following two errors
         1. Security Error: Content at http://www.xyz.com/wikidev/index.php?title=MediaWiki:Common.js may not load data from http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd_current_version&action=raw&maxage=0.
         2. Error: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 10540"]
            1. Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript
               
            2. Line: 10540
2. Browser version:
   1. Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5

--JonnyIncognito (talk) 05:00, 18 March 2009 (UTC)

You have to set up a local version page similar to User:Cacycle/wikEd current version and point wikEd to it (var wikEdAutoUpdateUrl = 'http://www.xyz.com/enwiki/w/index.php?title=wikEd_current_version&action=raw&maxage=0';) or disable auto-update (var wikEdAutoUpdate = false;, see User:Cacycle/wikEd installation#Wikis without internet connection). Cacycle (talk) 02:38, 27 March 2009 (UTC)

IE6 "Expected identifier, string or number"

IE6 throws "Expected identifier, string or number" on WikEd.js line 326 because of the last line of the above object ends with a comma. (That is only allowed for arrays and not for objects according to ECMAScript, though every other browser seems to understand it.) --Tgr (talk) 09:20, 26 March 2009 (UTC)

Fixed in 0.9.76 - not that this makes it run under IE unless they start supporting the standard range object in a future version. Cacycle (talk) 00:15, 30 March 2009 (UTC)

Tab order broken for new sections

FF3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7), wikEd 0.9.75b G. Steps to reproduce:

• start new section
• focus cursor in "Subject/headline" field
• press tab; focus should pass to the main edit area but some invisible element is focused instead.

A related, more peculiar bug:

• start new section
• focus cursor in "Subject/headline" field, enter some text
• focus on the main edit area
• press shift-tab; focus should pass to the "Subject/headline" field but some invisible element is focused instead.
• press shift; focus returns to the main edit window, and some random text is appended to the the "Subject/headline" field (probably the previous edit summary).

--Tgr (talk) 09:27, 26 March 2009 (UTC)

I have fixed the tab order in 0.9.76b. Cacycle (talk) 02:16, 30 March 2009 (UTC)

Template in edit window

If you try to embedd a code like {{/Archive 001}} in this page, and you Ctrl-cl on it, you'll go in the page Template:/Archive_001 instead of the right one (User_talk:Cacycle/wikEd/Archive 001). wikEd 0.9.76, Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) on win XP Lenore (talk) 17:04, 31 March 2009 (UTC)

Short question

I'm using a costum skin on my Wiki and the Button for turning wikEd on and off does not appear. What needs to be in the skin to display the button? --DaSch (talk) 22:51, 31 March 2009 (UTC)

If your skin differs from common skins (especialy by missing or renamed element id's) then wikEd cannot install itself. Please could you give me a link to your wiki so that I can check into this (you may use email). Cacycle (talk) 00:00, 1 April 2009 (UTC)

http://www.wecowi.de here you can see it. wikEd is installed as a Gadget. --DaSch (talk) 10:20, 1 April 2009 (UTC)

I have fixed the support for Cavendish and Gumax skins in 9.9.77. It is also possible to customize this using the wikEdMediaWikiSkinIds setting (see source code). Cacycle (talk) 04:00, 2 April 2009 (UTC)

How to move wikEd Enable/Disable button for GumaxDD

I just want to know how to move the enable/disable button up or down the page. It's currently in a non-aesthetic place in the GuMaxDD skin that puts it below the navigation toolbar and above the edit toolbar. —Preceding unsigned comment added by 67.169.137.199 (talk) 06:51, 1 April 2009 (UTC)

• Basically, how do you move the wikEdLogo elsewhere? Or how do you not show the logo at all and it, by default, enables wikEd? Fader05 (talk) 16:30, 1 April 2009 (UTC)

I have fixed the support for Cavendish and Gumax skins in 9.9.77. It is also possible to customize this using the wikEdMediaWikiSkinIds setting (see source code). Cacycle (talk) 03:59, 2 April 2009 (UTC)

Chinese translation of wikEd

The current Chinese translation of wikEd, User:Shibo77/wikEd international zh.js, is actually in Simplified Chinese. I have made a Traditional Chinese translation for wikEd. Please take a look at User:Quest for Truth/wikEd international zh-hant.js. --Quest for Truth (talk) 09:52, 16 April 2009 (UTC)

Thanks a lot! wikEd automatically detects the wiki's language by checking the the variable wgContentLanguage = "xyz" in the page source where xyz is the language code. I am somewhat confused which Chinese translation should be used for which Wikipedia. Is there a Wikipedia that uses traditional Chinese as its official language? Which translation should be the default and which an option for which some code has to be added to monobook.js. Cacycle (talk) 02:48, 17 April 2009 (UTC)

The Chinese Wikipedia (zh:) is "bilingual". At the top of every page you can find tabs for users to select Simplified Chinese or Traditional Chinese. The variable wgContentLanguage always equal to "zh" but ueser can specify their preference in wgUserLanguage. There are 7 options: zh, zh-hans, zh-hant, zh-cn, zh-hk, zh-sg, zh-tw. You may like to set that zh, zh-hans, zh-cn, zh-sg use Simplified Chinese and zh-hant, zh-hk, zh-tw use Traditional Chinese. --Quest for Truth (talk) 15:24, 19 April 2009 (UTC)

Google Chrome problem

WikEd is checked in my preferences, but it's not showing up on my navbar as normal. There's no WikEd symbol at all I mean; it's not just the red X. Chrome is version 1.0.154.53, Windows XP, Modern skin. — Levi van Tine (t – c) 14:11, 17 April 2009 (UTC).

It works fine for me under the modern skin using the same Chrome version. Please could you go through the bug report checklist at the top of this page to pin this down? Thanks, Cacycle (talk) 21:53, 17 April 2009 (UTC)

Default: disabled

There is extra code that lets the WikEd disabled by default so I can activate it later? HyperBroad (talk) 20:03, 17 April 2009 (UTC)

Just click the logo at the top of the page once to disable wikEd. This setting is permanently stored in your browser. Does this address your problem? Cacycle (talk) 21:48, 17 April 2009 (UTC)

Not resolved. I set it in my monobook.js. HyperBroad (talk) 22:51, 17 April 2009 (UTC)

Please could you try to explain your problem in more detail, I am not sure what you need :-) Cacycle (talk) 03:45, 18 April 2009 (UTC)

What I need is a command to leave the wikEd disabled as default so I can activate it by clicking the top of the page when I need it. I always clear the browser cache before closing it. HyperBroad (talk) 16:32, 18 April 2009 (UTC)

You can add "var wikEdDisabledPreset = false;" to your monobook.js page and then click the logo to turn wikEd on and off during the session. Cacycle (talk) 17:30, 18 April 2009 (UTC)

Thanks! HyperBroad (talk) 18:44, 18 April 2009 (UTC)

Internet Explorer

Why don't you add suppor for Internet Explorer. I beleive the codes for internet explorer has changed with the onset of IE8, and it is now up to the Standards. --Tyw7‍ ‍‍ (Talk ● Contributions) Leading Innovations >>> 17:46, 19 April 2009 (UTC)

IE 8 does not support the standard range object that is heavily used in wikEd for functionality that could not (or only very difficultly) be simulated in IE. It is a shame that they are still not able to support web standards. Cacycle (talk) 18:27, 19 April 2009 (UTC)