User talk:Cacycle/wikEd

xcen > de

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.

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)[reply]

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

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:

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

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

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

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

The error message complains about lyricwikicleanerv2.user.js. Cacycle (talk) 20:11, 18 June 2008 (UTC)[reply]

Please update your Greasemonkey add-on under https://addons.mozilla.org/en-US/firefox/addon/748. Cacycle (talk) 02:59, 19 June 2008 (UTC)[reply]

Cacycle (talk) 02:45, 19 June 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Implemented in 0.9.63. Cacycle (talk) 05:31, 21 June 2008 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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

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)[reply]

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

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

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)[reply]