Jump to content

User talk:Cacycle/wikEd/Archive 009

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


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)

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)

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, ManishEarthTalk 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.wiki.x.io/w/index.php?title=K%C4%ABlauea&action=submit
Line: 0

and one

Warning: Expected ':' but found '='. Declaration dropped.
Source File: http://en.wiki.x.io/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 Fix all 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.
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! /skagedaltalk 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

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;
    }
}

// Line 133-134, Parser.php
        $this->mExtLinkBracketedRegex = '/\[(\b(' . wfUrlProtocols() . ')'.
            '[^][<>"\\x00-\\x20\\x7F]+) *([^\]\\x0a\\x0d]*?)\]/S';
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? /skagedaltalk 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)
I had a similar error when using the Greasemonkey script "Wikipedia with NoScript". Ensure that your Greasemonkey install is current, and the script to add WikiEd doesn't conflict with another you're using. --King Öomie 17:41, 21 August 2009 (UTC)

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)

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)

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)

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.wiki.x.io/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 Textify. Cacycle (talk) 14:44, 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)
Works OK on OS X 10.5.7 & Safari 4 (build 5530.17) for me. UncleDouggie (talk) 07:00, 20 July 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 Use wikEd 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 (Syntax 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)


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 (Syntax 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.wiki.x.io/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.wiki.x.io/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.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 10540"]
          1. Source File: http://en.wiki.x.io/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/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)

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)

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)
I have added support for this in version 0.9.78. Please could you test if it works correctly? Thanks, Cacycle (talk) 03:26, 27 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)

Case sensative support for other lanquages

First off all thank you for the great Extension (I use greasemonkey version).
The problem is that the "Toggle between lowercase, uppercase first, and uppercase" doesn't support non-English Alphabet characters, like German "ä,ü,ö" or the whole Cyrillic alphabet(my case). I thought, that it wasn't a big deal and tried to fix it by myself: I replaced all *"a-zA-Z"* strings in the source with *"a-zA-Zа-яА-Я"* and it worked... well halfway (or 2/3way to be precise) - It only works with words, that begins with upper case and if the word begins with a capital letter - it converts it to full-upper case, than to full lower case, but than the cycle breaks. It looks like this: "Арбуз" -> "АРБУЗ" -> "арбуз" -> stays lower case. What should I do?
Thanks. —85.176.25.24 (talk) 01:36, 22 April 2009 (UTC)

I will try to fix this in the next release. Cacycle (talk) 12:47, 22 April 2009 (UTC)
Fixed in version 0.9.78. Cacycle (talk) 03:24, 27 April 2009 (UTC)

Wiked breaks wikimedia secure connection

Using/enabling wiked breaks wikimedia's encrypted connection at Secure Wikipedia. Is there a solution?Smallman12q (talk) 21:47, 22 April 2009 (UTC)

The gadget seems to use document.write instead of importScript() --TheDJ (talk • contribs) 15:47, 23 April 2009 (UTC)
WikEd loads other helper scripts dynamically (providing diff, RegExpTypoFix, and live preview functions) through unencrypted connections, that is what triggers the warning. This does not break any wikEd functionality. You could change the respective URLs to the secure server, see User:Cacycle/wikEd installation#Wikis without internet connection. We can actually add some code to the gadget page to do that. TheDJ: wikEd must not be loaded through importScript(), it has its own loading mechanism. Cacycle (talk) 22:49, 23 April 2009 (UTC)
I still see no reason why wikEd cannot use importScript (and uses the documented broken document.write), but that is beside the point. importScript has detection for the secure server and corrects local links of scripts when needed. That is more the point that I was trying to make. --TheDJ (talk • contribs) 23:57, 23 April 2009 (UTC)
Oh wait, we didn't actually commit that in MediaWiki I just remember. Well, with a wgScript check, It would still be fairly easy to load from a different URL. Especially in the case of the gadget loader. --TheDJ (talk • contribs) 00:12, 24 April 2009 (UTC)
wikEd loads helper scripts/content dynamically, so there is no way that importScript can correct these URL's. Also, wikEd uses its own loader so that it can initialize during page load to shorten startup time. It is also necessary for Greasemonkey compatibility. And document.write is NOT broken in any way for wikEd, trust me, I have invested quite some thought into this extremely complex matter. Cacycle (talk) 01:29, 24 April 2009 (UTC)
I have just added https / secure server support to the upcoming version of wikEd. Cacycle (talk) 01:29, 24 April 2009 (UTC)
Fixed in version 0.9.78. Cacycle (talk) 03:24, 27 April 2009 (UTC)

Expanding Editing Field

  • 0.9.77
  • Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
  • Error: WikEdEvent is not defined

Source File: http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 3332

  • dAmn XPCOM, dAmnAutoJoin, Greasemonkey, Japanese-English Dictionary for rikaichan, Raikaichan, Speed Dial, TwitterFox, Xmarks, Zotero
  • User:Mr.Z-man/refToolbar.js,User:AndyZ/peerreviewer.js, User:Lightmouse/monobook.js/script.js,User:Dr pda/prosesize.js, User:Dr pda/prosesize.js, User:Cameltrader/Advisor.js, and this one.
  • Windows Vista
  • The entire toolbar still works. It's just that when I open an editing window, the edit field expands to take up the entire screen. To reduce it to its original size, I have to double click the gray box used for sizing the edit field. I believe its a problem with the script as I disabled it and this problem did not occur.
  • Open any editing window

~Itzjustdrama ? C 01:48, 25 April 2009 (UTC)

What do you mean by "the edit field expands to take up the entire screen" - the wikEd fullscreen mode? By "... I have to double click the gray box used for sizing the edit field." are you talking about the fullscreen button Table mode? But wikEd buttons do not need double clicks?! Cacycle (talk) 02:23, 25 April 2009 (UTC)
Sorry for being unclear. But I meant to say that it would automatically go to fullscreen mode without me doing anything. It seems to have resolved itself though. Sorry for taking up your time. ~Itzjustdrama ? C 15:35, 25 April 2009 (UTC)

Possible bug with the ' key.

I don't know if this is a wikEd bug or not, but I occasionally get the quick find feature in Firefox when hitting the ' (straight single quotation mark) button. It comes and goes, but I cannot pinpoint the source or cause, but as far as I can tell it's only happened to me within editing a MediaWiki website with wikEd enable. For instance, I was just editing Wikinews and I kept getting this bug, but reporting here it is fine. I then went back to check Wikinews and it's not happening anymore. Thanks. Calebrw (talk) 04:53, 27 April 2009 (UTC)

Edit summary hidden in Google Chrome Beta

Edit summary hidden in Google Chrome Beta YayaY (talk) 19:58, 1 May 2009 (UTC)

I cannot replicate this in Chrome beta 2.0.172.30. Cacycle (talk) 20:53, 23 May 2009 (UTC)

Component returned failure code

On http://de.wiki.x.io I recieve the following error using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10.

Fehler: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandEnabled]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 6223" data: no] Quelldatei: http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Zeile: 6223

Matthias M. (talk) 13:28, 2 May 2009 (UTC)

Thanks for reporting this. Does it cause any problems and when does it happen (see the bug form on top of this page). Cacycle (talk) 15:43, 2 May 2009 (UTC)
The error-message is logged every time when you have a look at the firefox console, but there is nothing visibly broken. Matthias M. (talk) 19:15, 2 May 2009 (UTC)

Font selection

Can WikEd be extended with more formatting options like fonttype and coulor? Columbus56 (talk) 07:42, 5 May 2009 (UTC)

Sure, see User:Cacycle/wikEd customization. Cacycle (talk) 19:39, 12 May 2009 (UTC)

::Let's say, for example, hypothetically, that a user didn't know HTML... what would be required to change the font to Arial? --King Öomie 16:08, 13 August 2009 (UTC)

Disregard... found above. --King Öomie 16:11, 13 August 2009 (UTC)

List-friendly feature

Can WikEd sort lists?

If not, would you add this incredibly useful feature?

Sorting lists manually is a real pain, and cutting/pasting them into 3rd-party sorters is very inconvenient.

The Transhumanist 18:50, 14 May 2009 (UTC)

I think I added the Sort button just for you a while ago... :-) Cacycle (talk) 13:32, 15 May 2009 (UTC)

RegEx ^ and $

The regular expression used in find and replace should always execute in multi-line mode. This would make it more useful. I can't think of any cases where it is useful to restrict ^ to matching only at the very beginning of the page. For example, this would simplify the replace-all of (^|\n)(.+) → $1* [[$2]] to the more straight-forward ^(.+) → * [[$1]]   —GregU (talk) 05:50, 15 May 2009 (UTC)

Good idea! It will go into the next release. Cacycle (talk) 13:31, 15 May 2009 (UTC)
Added to version 0.9.79a. Cacycle (talk) 20:25, 24 May 2009 (UTC)

Size limit on syntax highlighting

What is the size limit for an article’s wikitext above which syntax highlighting doesn’t work? It’s definitely less than 32K, since Standard electrode potential (data page) is only 32,014 bytes, and it doesn’t work even when doing a section edit on the main section. Hgrosser (talk) 13:32, 19 May 2009 (UTC)

The preceding note was on Firefox Windows, on Safar1 3.1.2 the limit is definitely greater, somewhere between 82 and 109 kilobytes as reported at the top of the preview Hgrosser (talk) 21:35, 19 May 2009 (UTC)

It is a time limit of about 2 s. You can still highlight fragments. The upcoming release has a way to force highlighting by pushing Shift-[T}. Cacycle (talk) 03:17, 20 May 2009 (UTC)
Shift-[T] added to version 0.9.79a. Cacycle (talk) 20:24, 24 May 2009 (UTC)

Special extension tags

A wiki I'm on uses special parser extension tags that WED whines about. Solutions?--Ipatrol (talk) 19:06, 23 May 2009 (UTC)

If it still happens after updating (Shift-Reload) then please give me a link to that wiki and the name of that extension. Thanks, Cacycle (talk) 16:29, 24 May 2009 (UTC)

What happened?

The way wikEd highlights the text changed suddenly. What happened? mynameincOttoman project 00:19, 24 May 2009 (UTC)

Updated text style and ref highlighting

This morning it worked fine, but now, after the update, it is different. I am unable to use wikEd in the default monospace font. When I have it enabled, i.e. letting it highlight things, it forces the sans-serif font, but I prefer the monospace. I would like this option. Also, the previous choices to highlight reference text were either gray background or gray words. Now it is gray background or gray words with superscript. I really hate the superscript so I'd rather have just the light colored words. Thanks, Reywas92Talk 00:23, 24 May 2009 (UTC)

I wanted to say the same thing about monospace. I want my monospace, dammit :P Circeus (talk) 01:54, 24 May 2009 (UTC)
Monospace is back as well as well as some other changes. I might remove the ref superscript soon. Please Shift-Reload to update. Cacycle (talk) 16:31, 24 May 2009 (UTC)
Fixed in 0.9.79a. Cacycle (talk) 20:23, 24 May 2009 (UTC)

Edit summary area

I'm somewhat new to wikiEd, and your page about costomization is very confusing. My concern is about the edit summary and save page region below the edit box. I significantly prefer the dafault Wikipedia format of having the save page/preview/changes buttons directly under the minor edit checkbox, which is directly under the edit summary box. I think that's dumb to have them all separate with the minor edit checkbox below the save page and the edit summary being way on the right. How can I customize to have the standard layout there? Thanks! Reywas92Talk 00:27, 24 May 2009 (UTC)

If you can live without the summary combo box and the additional space that the rearrangement frees you up for editing then you could add "var wikEdNoRearrange = true;" to your monobook.js. Cacycle (talk) 20:34, 24 May 2009 (UTC)

New Code

Hello Cacycle,

I am a German Wikipedian, we are using directly the code from wikEd.js from your Page as a Gadget. I've seen that you've changed the display of the code in the Textarea. Personally I think the old code was much better, but thats not the main reason I am talking to u. At previously deleted Pages there is shown the deletion log in top of the textarea. With your code update, the deletion log is shown twice. (Compare e.g. [1] with activated Gadget). Could you please have a look at it please. Thank you -- Joschi90 (talk) 01:00, 24 May 2009 (UTC)

wikEd now copies messages from the page top to above the edit area so that can see them when jumping straight to editing. This is obviously confusing when the message is the only content... I will think about it... Thanks, Cacycle (talk) 15:36, 24 May 2009 (UTC)
Fixed in 0.9.79a. Cacycle (talk) 20:21, 24 May 2009 (UTC)
Thank you! -- Joschi90 (talk) 23:15, 24 May 2009 (UTC)

New text area layout

I like it :) Matthewedwards :  Chat  05:48, 24 May 2009 (UTC)

Sadly, I really don't and I think it might introduce issues for users with some forms of colour blindness. treelo radda 11:50, 24 May 2009 (UTC)
Please point me to the problems and we can improve it. Cacycle (talk) 15:28, 24 May 2009 (UTC)
Studying it a little further it's not really a colour blindness issue that I'm seeing, just one where the grey text on grey background for wikilink markup might be too similar to each other for some to see easily. For the rest though, that's merely personal inclination towards the previous scheme. I think I might be alone in disliking the new style but a "classic" CSS could be thrown together so people can just paste it into their monobook.js should they prefer the other markup style. Really do miss that blue... treelo radda 16:21, 24 May 2009 (UTC)
I am still making changes. Please try the new scheme on articles (after a Shift-Reload) for a while and report back :-) Cacycle (talk) 18:32, 24 May 2009 (UTC)
Ah, you're still listening to me! I like the changes done but I think it's the drabness of it which is making me cold towards it. Another thing is the new style given to items in the File: namespace (as a note, the image button still creates a link to the old Image: namespace) which I don't get as it throws me off because it doesn't feel like it fits in anymore. I think that's probably all the issues I have really, nice to know you're still receptive to comments. treelo radda 19:50, 24 May 2009 (UTC)
The image is still there for compatibility with older Mediawiki installations. Cacycle (talk) 12:24, 26 May 2009 (UTC)
Ah, I know what I'm missing! Wikilinks and template markup used to be bold and now they're not making everything for my blue and red accustomed eyes to ignore those parts rendering it useless to me. Call it an odd form of blindness if you like but for the mehness the new scheme brings it really would benefit from the bold elements. Given all the problems only I seem to have with the new things, any chance of some CSS I can use to get some of the old scheme back? treelo radda 21:51, 26 May 2009 (UTC)
You can set up any color scheme by customization. I suggest you wait until the new scheme has stabilized (plus you might get used to it...). One problem with the old scheme was for users without display anti-aliasing/ClearType where the bold red links where massive. It should now be more intuitive for beginners as all links are blue as in the final article text. The displayed link is bold, the hidden target article is normal. Non-mainspace links are dark-background non-bold. This scheme is optimized for articles where the only non-mainspace links are the interlanguage links at the end. And I am always open for constructive (and preferably tested) suggestions. Cacycle (talk) 22:25, 26 May 2009 (UTC)
Guess I'll have to sit and wait, like you say I might get used to it but right now I get less benefit from it than I did before and that's purely down to the colours utilised. I'm aware of the customisation ability hence why I've been requesting for some CSS to replicate the previous look, I'd do it myself but my CSS skills aren't that good. I fully don't expect any changes to be made on the basis of one lone voice but I do have a suggestion, the markup for images and other file: namespace content doesn't sit right because of the outline which makes it feel incongruous with the other markup, might consider removing it. treelo radda 23:14, 26 May 2009 (UTC)

JavaScript error when starting with IE7

  1. Microsoft Internet Explorer 7 on Vista SP1 i386
window.wikEdProgramVersion = window.wikEdProgramVersion || '0.9.79';
window.wikEdProgramDate    = window.wikEdProgramDate    || 'May 23, 2009';

Hello, there is a small glitch - one gets a Javascript error in line 845 when starting up in IE7 (tried with Vista). This happens before wikEd has a chance to shut itself down in the unsupported browser mode.

This fixed this for me: 

diff -r cb639c56fc30 plwiki/sk/wiked.js
--- a/plwiki/sk/wiked.js        Sun May 24 16:38:46 2009 +0200
+++ b/plwiki/sk/wiked.js        Sun May 24 16:50:36 2009 +0200
@@ -841,7 +841,7 @@
                        67: ['g', 71], // scrolltoedit2
                        72: ['g', 71], // scrolltoedit3
                        74: ['g', 71], // scrolltoedit4
-                       32: ['g', 71], // scrolltoedit, overwrites previous wikEd buttons for same key
+                       32: ['g', 71]  // scrolltoedit, overwrites previous wikEd buttons for same key
                });
        }

 « Saper // @talk »  14:53, 24 May 2009 (UTC)

Thanks, fixed in the shortly upcoming next release. Cacycle (talk) 15:27, 24 May 2009 (UTC)
Fixed in 0.9.79a. Cacycle (talk) 20:20, 24 May 2009 (UTC)

Use old syntax highlighting

How can I use the old syntax highlighting? The new version have a bug by editing references.--Video2005 (talk) 17:34, 24 May 2009 (UTC)

Use the gray button on the top right after Shift-Reload. Cacycle (talk) 19:34, 24 May 2009 (UTC)
Thanks, but how can I use the better OLD syntax highlighting?--Video2005 (talk) 20:09, 24 May 2009 (UTC)
Wait until the new scheme and the changes required for it has stabilized, the check User:Cacycle/wikEd customization to create a custom css scheme. Cacycle (talk) 20:19, 24 May 2009 (UTC)
So is there no way to use custom CSS at the moment? My custom CSS at User:Gary King/config.js doesn't work anymore. Gary King (talk) 03:43, 31 May 2009 (UTC)
Bump, can I just get a confirmation on this? Gary King (talk) 01:11, 4 June 2009 (UTC)
Custom CSS should work, please use the new source code definitions for changes as some classes and schemes have changed. Cacycle (talk) 15:39, 10 June 2009 (UTC)

Very odd Ctrl-click issue

Thanks to WWGB for catching this. I logged in tonight and started doing my disam work. WWGB caught that for whatever reason (Ctrl-click)" is being added to my edits in random places. Here is an example. Anyone else seeing this issue? --User:Woohookitty Diamming fool! 05:52, 25 May 2009 (UTC)

And I know that WikEd is the culprit because I turned it off and the issue went away. Of course, I don't WANT that. :) WikEd makes disamming much, much easier. --User:Woohookitty Diamming fool! 05:54, 25 May 2009 (UTC)
Well upgrading to the newest version of Chrome seems to have resolved the issue for now. --User:Woohookitty Diamming fool! 06:17, 25 May 2009 (UTC)
I have reverted wikEd to the previous version until this is fixed. Please update with Shift-Reload. So far, I cannot replicate the problem. It would help a lot if users experiencing this problem (insertion of "Ctrl-Click" before external links) could report their browser type and version as well as additional gadgets they have checked under My preferences - Gadgets here. Sorry and thanks in advance, Cacycle (talk) 13:21, 25 May 2009 (UTC)
I think it's worth noting that the bug may have existed in some form in the past, as I found this discussion from March 2008 talking about exactly the same thing: [[2]] Soap Talk/Contributions 20:04, 25 May 2009 (UTC)
Yes, I have found several of these. I currently think it is caused by the use of a rare broken browser version (maybe Chrome or Safari (beta)?). Therefore it is important to find out the browser that causes this in order to implement a work-around. Cacycle (talk) 21:17, 25 May 2009 (UTC)

Mine stopped today. I even have WikiEd on. (I checked) --Abce2|AccessDenied 19:41, 25 May 2009 (UTC)

Thanks for your reply. Please could you report your browser name and version and possible other gadgets that you might have checked on User talk:Cacycle/wikEd#Very odd Ctrl-click issue. This is essential to locate the problem in order to fix it - even if it now works for you. Thanks, Cacycle (talk) 21:17, 25 May 2009 (UTC)

Likely caused by Chrome it seems. —TheDJ (talk • contribs) 21:13, 25 May 2009 (UTC)

I am running Chrome v. 1.0.154.65. I use Friendly, refTools, and Twinkle. TallNapoleon (talk) 21:26, 25 May 2009 (UTC)

I too run chrome, same version, all of the same scripts as TallNapoleon plus wikiED. Bizarre. Anyway, I also started a thread on Wikipedia:Village pump (technical) Valley2city‽ 21:30, 25 May 2009 (UTC)

I run Twinkle, Friendly, Wikied, and reftools. I don't know if this helps, but after I asked for my monobook to be deleted and it got deleted the problem went away. Does that have any connection? --Abce2|AccessDenied 23:49, 25 May 2009 (UTC)

Possibly. Unless you also upgraded Chrome. It's either that specific Chrome version, or Chrome icw another gadget/script. If you can clarify if you also updated Chrome, then that might help Cacycle pinpoint the issue further. —TheDJ (talk • contribs) 00:09, 26 May 2009 (UTC)

The WikEd extension is really annoying.. it's all screwy. At the same time it's too useful to really disable though, for me at least. Someone should really take a look at it. Disable text formatting while editing in the text box for example, and strip the formatting when pasting. That would help tremendously. Anyway, for my settings and browser and such, see here: Click Rocknroll714 (talk) 01:23, 26 May 2009 (UTC)

I have found the possible cause and will put the 'new' wikEd (0.9.79c) back online. Chrome/Safari users, please click Shift-Reload to update! Sorry and thanks for the help, Cacycle (talk) 02:41, 26 May 2009 (UTC)

Awesome. Yeah I am using 2.0.172.28 for Chrome. The version I was using was the one right before that...I'm not sure what the version # was. --User:Woohookitty Diamming fool! 04:10, 26 May 2009 (UTC)
I use Safari Version 3.2.1. Wiked is the only gadget I'm using. Smatprt (talk) 04:56, 26 May 2009 (UTC)

Safari syntax highlighting

When I enable, and then disable syntax highlighting, the following is left for my supposedly "unhighlighted" editor view. <font class="Apple-style-span" color="#0000E0">. It's a while since I used WikEd last, so i'm not sure how long this problem exists. —TheDJ (talk • contribs) 20:23, 25 May 2009 (UTC)

I'm not 100% sure, but I think the return values before "if (isRemove.pop() == true)" in the Apple-style-span removers, need to be removed... —TheDJ (talk • contribs) 21:07, 25 May 2009 (UTC)
Thanks, I will fix this. Cacycle (talk) 21:09, 25 May 2009 (UTC)
I cannot reproduce this with the current Safari beta. Can you describe exactly what you do to see those tags? Thanks, Cacycle (talk) 01:14, 26 May 2009 (UTC)
I have this issue with both Safari 4 beta2, and nightly builds. I enter the edit view with wikEd disabled and syntax highlighting off (trough the wikEd controlbuttons toolbox). I enable WikEd mode, I enable syntax highlighting mode, I disable syntax highlighting mode. And then I have the problem. —TheDJ (talk • contribs) 09:14, 26 May 2009 (UTC)
Works OK for me on OS X 10.5.7 & Safari 4 (build 5530.17). UncleDouggie (talk) 07:07, 20 July 2009 (UTC)

Copy-pasting

I love Wik-Ed, but I would like to suggest 1 minor improvement. When I copy-paste text from another page, the original formatting is retained in the edit window—a copy-paste of a header appears really big, for example. I can put up with this, although I would rather it were corrected.

The bigger issue is that some copy-pastes (usually of multi-line template code), have dodgy line breaks in. For example, a copy-paste of: 

{{Template:Example
 |1=abc
 |2=def
 |3=ghi
 }}

would come out with an extra line break above it. Deleting this line break causes the formatting to change to the following: 

{{Template:Example
  
 |1=abc
 |2=def
 |3=ghi
 }}

If I delete that line break, it moves between the |1=abc and the 2=def. With larger chunks of code, this gets rather annoying.

I don't know if this is deliberate, or if it has been addressed before, but I thought I'd suggest it in case it was annoying anyone else. Dendodge T\C 21:56, 25 May 2009 (UTC)

Those extra "linebreaks" are actually margins around the pasted block. You have to push the [T] button to get rid of that space. Cacycle (talk) 22:10, 25 May 2009 (UTC)
That simple? Thanks! Dendodge T\C 22:12, 25 May 2009 (UTC)

Fixes problem

Just a small problem, when highlighting text that includes an image, pressing either the Fix Caps or Fix all buttons changes File: to the older Image: namespace. While this doesn't break anything, if there's the time it would be nice if this was fixed.

On another note, I prefer the new colouring, it is much clearer and less distracting. QueenCake (talk) 21:31, 26 May 2009 (UTC)

Fixed in next release. Thanks, Cacycle (talk) 02:01, 29 May 2009 (UTC)
Fixed in 0.9.80. Cacycle (talk) 15:35, 10 June 2009 (UTC)

Bug - Find/Replace text box overflow into editing area

  • My wikEd version : 0.9.79c (May 25, 2009)
  • My browser id : Safari Version 3.2.3 (4525.28.3)
  • Error console errors : Couldn't find an error console on Safari's Menu list
  • Which browser add-ons have you installed : Couldn't find this info either
  • Which user scripts have I installed on my monobook.js page: None
  • Which operating system do you use: Mac OS X 10.4.11 (8S165)
Thanks for reporting this. Unfortunately, I cannot reproduce this under Windows with Safari 3.2.3 (525.29). Does anybody else experience similar problems? Cacycle (talk) 02:48, 2 June 2009 (UTC)

This appears to be a Mac OS X interaction bug, since I experience the same problem with FireFox 3.0.4 on my Mac. Dnessett (talk) 15:20, 2 June 2009 (UTC)

Problem identified (probably), but a not solution: This behavior seems to have nothing to do with Mac OS X. It appears to arise because I am using a DELL 30" monitor connected to my Mac (screen resolution = 2560x1600). I think the problem is CSS pixels are not screen pixels (see CSS pixels). The definitions of the Find and Replace combo boxes in wikEd.js use the px dimension, which do not map directly to screen pixels. The problem is the layered Find and Replace Select boxes (defined in wikEd.js as #wikEdFindSelect and #wikEdReplaceSelect) are not aligning properly to the top of the bounding box. They are then pushing the material below them into the edit area. This is seen in this screenshot. I have loaded wikEd locally on my personal wiki and played around with the parameters in WikEd.js, but have not been able to adjust them to get a good placement. To test my theory that this is related to my 30" monitor and not Mac OS X, someone with a 30" monitor connected to a PC should see if they have the same problem. (Note: there is a possibility that the problem has something to do with my graphics card, but I would like to eliminate the 30" monitor hypothesis before going down that alley.) Dnessett (talk) 01:44, 6 June 2009 (UTC)

Then again, maybe not: I decided to wade through the explanation of CSS reference pixels given in CSS pixels. A CSS reference pixel is about 1/96 inch on a screen display meant for viewing at arms length (~28 inches). The DELL 30" display has a viewable width of ~26.25 inches. At 2560 pixels of width that means it provides 97.5 screen pixels per inch. So, a CSS reference pixel = 97.5 screen pixels per inch * 1/96 inch = 1.01 screen pixels. This is practically identical to a normal display and therefore insufficient to explain the FindSelect and ReplaceSelect field pushdown into the edit area. So, I am back at square one. Dnessett (talk) 16:21, 6 June 2009 (UTC)

Problem Fixed: This was an extremely difficult problem to identify and fix. That I am not an expert in HTML or CSS is a gross understatement. So, I can only report my findings and hope those with a better understanding of both can elucidate. OK, enough whining. The problem is there is an interaction between class and id styles that leads to improper vertical alignment of the buttons and Find/Replace Select fields in the Find/Replace Button Bar. Some relevant styles specify vertical-alignment of text-bottom, others of text-top and still others 0%. The fix makes the vertical-alignment consistent by specifying vertical-alignment : text-top in the following style definitions - .wikEdButton, .wikEdButtonDummy, .wikEdFindComboInput, .wikEdCombo, .wikEdReplaceComboInput, .wikEdButtonUnchecked, .wikEdButtonChecked, .wikEdSummaryComboInput, .wikEdSummaryText, .wikEdSummarySelect, #wikEdFindText, #wikEdFindSelect, #wikEdReplaceText, and #wikEdReplaceSelect. One problem is I have no way of testing this fix on PCs (I use a Mac for most of my work). While I have a PC, my local test wiki on my Mac is not set up to serve other computers. Rather than going through the trouble of setting up a local network wiki server, I assume wikEd is installed on testwiki. Someone can make the indicated changes there to wikEd.js and test the fix on PCs. If the changes cause problems for PCs, at least the problem is identified and I assume some other approach can fix it for both PCs and Macs. As a side note, it is interesting that both Safari and Firefox on my Mac experienced the same problem. I can only assume that both browsers use a common library that causes the common vertical alignment problem. Dnessett (talk) 00:02, 11 June 2009 (UTC)

I notice that the Toolbar Hide cookies expire after 30 days. Why not 30 years? I don't want to have to re-hide a toolbar I never use. Thanks. --Armchair info guy (talk) 01:33, 1 June 2009 (UTC)

I have changed it to 2 months in version 0.9.80. It should be that short so that the interface is reset to default for irregular and/or unexperienced users. You can always add the following code to your monobook.js page: "var wikEdCookieExpireSec = 30 * 365 * 24 * 60 * 60;". Cacycle (talk) 15:34, 10 June 2009 (UTC)
Ah, yes, makes sense. I should've put 2&2 together before since I already modify several wikEd vars in monobook.js. So thanks for obliging me here. --Armchair info guy (talk) 00:45, 11 June 2009 (UTC)

Unresponsive

As of recent, the script has been causing my browser(s) to become unresponsive while attempting to edit some articles.

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:8823

This is happening with both Firefox 3.x.x under Windows 7 and with Firefox 3.0.9 under Ubuntu 9.04. wikEd version is 0.9.79c.   — C M B J   19:16, 2 June 2009 (UTC)

On which articles or article sections does it happen? Cacycle (talk) 00:32, 3 June 2009 (UTC)
I (re)noticed the problem while trying to make some changes to hydrocodone. If it's not reproducible for you, I will check to be sure that the problem is not exclusive to these two machines -- so that I do not send you on a wild goose chase.   — C M B J   06:18, 3 June 2009 (UTC)
I can reproduce this on this revision and will try to fix this as soon as I find the time. Thanks for reporting it, Cacycle (talk) 12:51, 3 June 2009 (UTC)
That revision is really bad, but it's happening even on the most recent revision. The script doesn't go completely unresponsive, but the interface is lagged and Firefox is using up lots of processor time.   — C M B J   20:47, 3 June 2009 (UTC)
Fixed in 0.9.80. Cacycle (talk) 15:22, 10 June 2009 (UTC)

Lightweight highlighter

I tried wikiED and I found that it was too cumbersome (sophisticated?) for me. But I really like the text highlighting feature. Can you make a version, or a customization, that strips out all the buttons and leaves just the text coloring? (In a totally separate matter, is it possible to optionally hide refs so they don't clutter article text?) Thank you in advance.--HereToHelp (talk to me) 22:39, 3 June 2009 (UTC)

No, please check User:Cacycle/wikEd help#Can I have only some wikEd features. Cacycle (talk) 16:40, 4 June 2009 (UTC)

Alterations to Bibleverse and Infobox templates create error conditions

Infobox insists on first letters of fieldnames to be lowercase. wikEd changes them all to uppercase. Example:

{{Infobox Saint | Name=Saint Paul

is changed by wikEd to: {{Infobox Saint |Name=Saint Paul **which does not work**

John 3:16 becomes John 3:16 **which does not work**

The issue seems to be that the empty parameter "||" which is used for a numbered Bible book like "|1|Corinthians" must be left blank for "||John"

Thanks...Afaprof01 (talk) 17:16, 6 June 2009 (UTC)

This happens only if you use the Fix Caps and Fix All buttons which should only be used on selected text. I am planning to fix this by detecting templates and tables. Cacycle (talk) 03:07, 8 June 2009 (UTC)

spell check does not work in chrome

description: when wikiEd is enabled chrome's built in spell check does not underline misspelled words. All other functionality of wikiEd works when enabled. Disabling wikiEd and typing new misspelled words shows them underlined.

steps to reproduce: Edit an entry and type a misspelled word.

attempts to trouble shoot:

  • restarted chrome
  • disabled all other wiki gadgets (then restarted)
  • checked spell check on other websites (works)
  • right clicked and un-check 'Spell check options > Check the spelling of this field'. When highlighting the word this would sometimes cause the misspelled word to be underlined.

Setup:
wikiEd: 0.0.97c G
browser: google chrome 2.0.172.30
script errors: none
browser add-ons: none
user scripts: none
OS: windows vista business SP1
—Preceding unsigned comment added by R.Vinson (talk • contribs) 23:13, 6 June 2009 (UTC)

Unfortunately, this is a Chrome issue and I cannot do anything about it. Cacycle (talk) 04:10, 9 June 2009 (UTC)
Have you been able to quantify the problem? If you know exactly what the issue is, perhaps I can help. R.Vinson (talk) 17:30, 9 June 2009 (UTC)
It is probably just not yet implemented as there is also no spell checking for other rich text editors such as http://www.kevinroth.com/rte/demo.htm. Cacycle (talk) 20:08, 9 June 2009 (UTC)

Problem with tables

If I have this

  1. Head
    • Part 1
    • Part 2

# Head
#* Part 1
#* Part 2

wiked formatter gives this

  1. Head
  2. * Part 1
  3. * Part 2

# Head
# * Part 1
# * Part 2

then, comments (<!-- -->) should not be modified inserting empty lines between them and the rest of the text, because it could lead to malfunctions. Example

  • Part 1
    • Part 2

* Part 1
<!-- Hidden text -->
** Part 2

will be modified in this way

  • Part 1


    • Part 2

* Part 1

<!-- Hidden text -->

** Part 2

--93.47.32.238 (talk) 21:37, 10 June 2009 (UTC)

It's possible this is related to the bug I reported recently. Dnessett (talk) 00:10, 11 June 2009 (UTC)
Fixed in 0.9.80 - empty lines before and after lists are still inserted but this does not change the rendered article. Cacycle (talk) 04:37, 11 June 2009 (UTC)

How to disable wikEdFollowLinks?

How do I disable wikEdFollowLinks? Following links do not work in Firefox on a Mac, so I want to disable the feature. Using wikEdFrameCSS['wikEdFollowLinks'] = false; did not disable it. Gary King (talk) 01:35, 12 June 2009 (UTC)

Which feature are you talking about exactly? If it does not work we should try to fix it... (check the top the page for a bug report form). Cacycle (talk) 00:05, 16 June 2009 (UTC)
When I mouse over a wikilink, it says "ctrl-click", which I assume means when I hold the ctrl button and click on the link, it will open it in a new window. However, this does not work in Firefox on a Mac, so I want to just remove the text that says "ctrl-click" since it is inaccurate. I also want to remove the underline on wikilinks since they are not clickable. Gary King (talk) 00:19, 16 June 2009 (UTC)
If you file a complete bug report I will try to fix this for you :-) Does anybody else on a Mac have similar problems? You could disable linkification with "var wikEdFollowLinks = false;". Cacycle (talk) 02:22, 16 June 2009 (UTC)
Maybe it is a popup blocker addon? Cacycle (talk) 01:31, 22 June 2009 (UTC)
I don't have any Firefox addons enabled right now. Gary King (talk) 01:35, 22 June 2009 (UTC)
var wikEdFollowLinks = false; doesn't do it for me. I still get "ctrl-click" when I hover over links in the textbox. Gary King (talk) 02:48, 22 June 2009 (UTC)
I have now fixed wikEdFollowLinks to disable this feature (0.9.81). Does Ctrl-click work for other users on a Mac? Cacycle (talk) 04:34, 22 June 2009 (UTC)
FYI by default, ctrl-click on a Mac is the same as right-clicking on a Mac, which might be why the script's use of it does not work. Gary King (talk) 15:03, 22 June 2009 (UTC)

Added Cmd-Click for Macs in version 0.9.82. Please could you check if it makes sense and if it works. Thanks, Cacycle (talk) 03:39, 23 June 2009 (UTC)

 Fixed Works perfect now. Gary King (talk) 15:31, 23 June 2009 (UTC)

Autoscroll bug

wikEd automatically scrolls down to the editbox. However, if a page has an editnotice, this can cause you to miss it.

I propose the implementation of a simple check for <div id="editnotice

I have not closed the tag, as the id attribute ends in several different ways, depending on the namespace. If that string is found anywhere in the page, wikEd should not automatically scroll down to the editbox, as the editnotice should be read.

I have reproduced this on the latest version.

This is a bug with wikEd, and is common to all browsers.

fahadsadah (talk,contribs) 14:56, 14 May 2009 (UTC)

Added to upcoming release. Cacycle (talk) 03:18, 20 May 2009 (UTC)
wikEd should also not scroll down on pages with protection notices. fahadsadah (talk,contribs) 10:13, 17 May 2009 (UTC)
Why? Cacycle (talk) 03:18, 20 May 2009 (UTC)
Same reason as the editnotice one. You should read the notice. fahadsadah (talk,contribs) 08:47, 23 May 2009 (UTC)
Fixed in 0.9.79a. Cacycle (talk) 20:26, 24 May 2009 (UTC)
The same should apply to deletion notices, to stop you recreating deleted pages. fahadsadah (talk,contribs) 10:16, 28 May 2009 (UTC)

Moved to botton, as this is still a problem, but now unnoticable.

What is the best way to reliably detect these notices? Cacycle (talk) 00:03, 16 June 2009 (UTC)
I think, to be more futureproof, the best thing to do would be to treat everything unusual above the editbox as an editnotice. fahadsadah (talk,contribs) 18:29, 22 June 2009 (UTC)
That's probably a not very futureproof idea with respect to future changes and compatibility with other gadgets :-) Cacycle (talk) 03:45, 23 June 2009 (UTC)

Idea for making editbox text more readable and less daunting for newcomers

Hi, I was wondering if it would be possible to make an alteration to how wikEd treats non-textual elements (inline citations, nav- and infoboxes, other templates, etc., maybe even tables) in the edit box. Right now, you color those differently, which helps definitely, but I'm wondering if you could encapsulate them in a show/hide collapsible <div>? It would be very helpful for some workshops for scientists that I've been invited to give.

I floated the idea yesterday at the Village Pump. The basic idea is to replace the "special" texts with a two-state tag like [citation]. By default, everything non-textual (e.g., the ref tags and the citation between) would be hidden within such a tag. But if the editor clicked on a particular [citation] tag, it would show everything within, and could be edited. Once the editing was done, the editor could click that tag again and it'd collapse again.

This approach might make the editbox version of the article more readable (inline citations can be a bear!) and closer to the appearance on the article itself. Do you think it's feasible? We wouldn't need wikEd's other amazing powers (although they'd be a big win), so if you needed to disable something to make this one trick work, it would be OK by us.

I really appreciate your help on this, and I think it could benefit the scientists as they take their first steps into Wikipedia. Please feel to e-mail me, if you think it'd be better. Thanks! Proteins (talk) 23:04, 25 June 2009 (UTC)

That is a good idea. I assume that you are familiar with the button? One big problem with your idea is that wrong wikicode syntax can hide large chunks of the article in those invisible folded-in passages. In general, do not underestimate the abilities of new users to quickly learn wiki editing, especially if taught. Cacycle (talk) 04:14, 26 June 2009 (UTC)

Thanks! I do know the [1] button, but sometimes scientific/mathematical articles are so dense with references, that they still hamper readability despite the smaller text. Some citation templates can take up several lines each. Here's an illustration of what I mean. Another motivation is that many articles begin with an infobox, which occupies the full first screen; if that could be collapsed, so that the editor saw the lead text immediately...

I agree that these scientists can and will pick up wiki-markup quickly; I'm doing my best to put together good teaching materials. :) But at one workshop in particular, we've been allotted only 90 minutes. So I'd really like to "hit the ground running" with them, and not have to explain citation templates and infoboxes immediately. They'll be editing a variety of existing articles, so the problem of dense refs is real. WikEd will be turned on by default on their accounts.

During an earlier lecture to non-editors, I'll also be opening an edit window on a scientific article to demonstrate how Wikipedia works. If the content were readily understandable by them, that would be a huge win.

I appreciate the badly-formatted-wiki-text problem, but I really believe that the advantages of this approach outweigh its risks. The basic goal is to make the editbox article easier to read and navigate by showing simple wiki-markup (such as sections, wikilinks and italics) but hiding advanced wikimarkup (such as references, templates and infoboxes). Is it feasible, do you think? Thanks again for your time and help, Proteins (talk) 05:49, 26 June 2009 (UTC)

You can already do this by redefining wikEd's CSS schemes and switching all hidden passages on or off with the [1] button instead of opening and closing those passages separately with a double click. It is not possible yet to display a placeholder with this approach, but I could add something to do that. I will probably not incorporate that into the main wikEd as it is too risky with users that do not know exactly what they do and has the potential to break existing articles, but we could make it an optional plugin. Cacycle (talk) 13:20, 26 June 2009 (UTC)

Thank you very much, Cacycle; I'm grateful for your help. I'll work on adapting the CSS schemes and e-mail you with more details on the scientific workshops early next week. Proteins (talk) 15:52, 27 June 2009 (UTC)

I have just finished something cool for you :-) give me some time to update wikEd... Cacycle (talk) 01:17, 28 June 2009 (UTC)
Please update with Shift-Reload for the new version 0.9.83, please let me know how you like it and how it could be improved. Cacycle (talk) 04:26, 28 June 2009 (UTC)

Simply awesome! That's just what I was hoping for. It should really help newcomers to read/navigate the page and to make their first edits. I tested the new feature on several pages and it worked great. I did notice two glitches, which I hope won't be difficult for you to fix. The first was the second long template on Amanita phalloides, {{mycomorphbox}}; somehow the body of the template wasn't included in the TEMPL placeholder, perhaps because of some non-standard formatting?

The second was the coloring of tables, e.g., this edit section. Once a table is started, the coloring seems to extend for the rest of the article, i.e., it doesn't seem to recognize the table end symbol |}.

Would it be possible to collapse tables in the same way that you've collapsed references and long templates? I think that they're the last major impediment to readability, being unfamiliar in syntax and stretching over many lines.

Your work is exciting, and will be very helpful at these workshops. I have a few more ideas, but I'll send those by e-mail on Monday, if only to give you a breather. :) Thanks again! Proteins (talk) 13:30, 28 June 2009 (UTC)

Problems fixed in 0.9.83a, please update with Shift-Reload. Cacycle (talk) 15:51, 28 June 2009 (UTC)

wikEd doesn't load on Konqueror

wikEd which worked ok on my Win7+FF3.6a1pre doesn't load on Kubuntu9.04+Konqueror (KDE4.2.2). No plug-ins. SkyBonTalk\Contributions 16:15, 28 June 2009 (UTC)

What do you mean by "does not load", do you see a wikEd logo on top of the page? What happens if you add "var wikEdSkipBrowserTest = true;" to your monobook.js page? Are there errors in the error console? Please see the top of the page for the informations that I need to help you. Thanks, Cacycle (talk) 18:26, 28 June 2009 (UTC)
wikEd actually starts loading in Konqueror but then encounters problems. Since Konqueror does not have an error console I cannot work on this under KDE on Windows. Maybe you can provide command line error messages. Cacycle (talk) 02:15, 29 June 2009 (UTC)
Hmmm... I haven't managed to find any console in Konqueror. SkyBonTalk\Contributions 12:16, 30 June 2009 (UTC)

References and template hiding

A superb idea. I thought wikEd more or less had everything, but I was wrong!

Just a small suggestion: when references are hidden, a mouseover displays its content, but hides the templates within. Since templates such as {{cite web}} are widely used for referencing, perhaps it would make sense to automatically expand the templates within a reference when it's expanded on mouseover.

On a side note: when is 1.0 due? :-) GregorB (talk) 09:49, 29 June 2009 (UTC)

1.0 is reserved for when MS IE becomes compatible with web standards (selection model!) and wikEd can finally be used under it. Cacycle (talk) 12:47, 29 June 2009 (UTC)

More suggestions for wikEd

Hi Cacycle,

Great work on wikEd! I have a few more suggestions for your consideration, which might be helpful. The first one is the most important for the workshops, but also the most work. I'm grateful for whatever you can do, and leave all of these suggestions to your discretion whether they'd improve wikEd or not. Thanks, Proteins (talk) 18:35, 29 June 2009 (UTC)

  • If you could combine the "in-text reference" button with the template-filling tool of Diberri, that would be awesome. Diberri's tool builds a named reference from a PMID code (and many other types of codes). Here's an example:
http://toolserver.org/~diberri/cgi-bin/templatefiller/index.cgi?ddb=&type=pubmed_id&id=17890307&add_ref_tag=1&full_journal_title=1

Perhaps you could add a special button that requests the PMID, launches an XML request and inserts the resulting full reference into the Wikipedia page?

Cool tool and a great idea. Somebody should make a wikEd-compatible Wikipedia gadget for this. But it is probably a bit outside the scope of the wikEd project. See User:Cacycle/wikEd customization#Custom buttons and User:Cacycle/wikEd development#wikEd API for how to add custom buttons and functions to wikEd. Cacycle (talk) 02:31, 12 July 2009 (UTC)
  • Some of the best articles on Wikipedia use both in-text references to the literature and explanatory footnotes, such as <ref group=note> (see WP:FOOT for more details and Mary Shelley for an FA example.) Could you add a button for footnotes similar to that used for in-text references? Footnotes can also be named.
An extra button would be overkill, but maybe as a Ctrl-click option. Cacycle (talk) 02:31, 12 July 2009 (UTC)
  • I'd like to encourage newcomers to make their contributions accessible to visually impaired readers and others who can't see images. Perhaps you could add an ALT attribute to images and math-mode formulae, e.g., [[Image:filename|thumb|alt=|widthpx| ]]?
For images the alt attribute is taken from the last parameter: [[Image:filename|thumb|alt=|widthpx|ALT-TEXT]]
  • The tag is easy to learn, but perhaps it'd be helpful to have a button for inserting math-mode tags, something like
:<math alt="">
Add formula here.
</math>

Clicking one button is faster than typing it out, and I believe the format is standard.

This is probably too exotic for a normal button but would be an ideal candidate for a custom button, see User:Cacycle/wikEd customization#Custom buttons. Cacycle (talk) 02:31, 12 July 2009 (UTC)
  • Perhaps you could add a collapsible menu for links to common help pages, e.g., table markup? The editing page already has a cheatsheet link ("Editing help"), I know, but it's not obvious to newcomers and I think one could do better. I was experimenting with something along these lines here (look in the upper right corner and scroll the page), but it's very rudimentary.
Good idea for a gadget. Cacycle (talk) 02:31, 12 July 2009 (UTC)

Again, thanks for your help, Proteins (talk) 18:35, 29 June 2009 (UTC)

Thanks for the suggestions, please see my replies above. Cacycle (talk) 02:31, 12 July 2009 (UTC)

Error in templates or tables

If I have something like this

{{Stub
| arg
|}}

(last argument missing) button returns an error

{{Stub
| arg
|}

}

probably because |} is treated like a table element. Can you fix? --93.47.34.59 (talk) 21:52, 29 June 2009 (UTC)

Fixed in 0.9.84b. Cacycle (talk) 02:02, 12 July 2009 (UTC)

How to stop using wikEd by default?

wikEd remembers whether I have wikEd enabled or not and then applies that the next time I open an edit page. That's good, but I'd like to instead force it to be disabled by default because it slows down the loading of pages, especially long ones, too much. How do I disable it by default instead of having it remember whether or not it was previously disabled? Gary King (talk) 04:07, 30 June 2009 (UTC)

Please see User talk:Cacycle/wikEd#Default: disabled above. Cacycle (talk) 11:58, 30 June 2009 (UTC)
var wikEdDisabledPreset = false; does not work for me. wikEd is still enabled based on whether or not it was enabled the last time I was in an edit window. Gary King (talk) 15:54, 30 June 2009 (UTC)
If I change it to true then it does indeed disable wikEd, but there is no way to reactivate it when I need it because none of the buttons created by wikEd appear, so this does not help. Gary King (talk) 15:57, 30 June 2009 (UTC)
The main switch is the icon next to the logout link. Cacycle (talk) 01:30, 1 July 2009 (UTC)
I'm looking for an option to just set the Classic Text Area as the default option instead of the wikEd text area. It's easier that way so I don't have to be at the top of the page to enable it; it requires two clicks when doing it like that, too, because then I have to enable it in the text area, too. Anyway, it doesn't work when set to either true OR false; it stays enabled consistently. Gary King (talk) 01:36, 1 July 2009 (UTC)

Hidden templates?

Using wikEd 0.9.83a and Firefox 3.0.11, when I try to edit Rsync and expand the {{Infobox software}} within, the latest_release_date parameter appears empty, but it isn't, it is populated with {{release date}}, which is only visible once wikEd is turned off. GregorB (talk) 08:48, 1 July 2009 (UTC)

Working on it. Thanks, Cacycle (talk) 21:33, 11 July 2009 (UTC)
Fixed in 0.9.84b. Cacycle (talk) 02:01, 12 July 2009 (UTC)

Firefox 3.5

Reference/template unhiding is apparently broken in Firefox 3.5 (wikEd 0.9.83a, WinXP SP3); mouseover does nothing. GregorB (talk) 15:21, 1 July 2009 (UTC)

Yep, doesn't work in Firefox 3.5. I'd love to see this fixed. Gary King (talk) 01:05, 2 July 2009 (UTC)
I have filed a Firefox bug report. Cacycle (talk) 01:49, 6 July 2009 (UTC)
I have filed another Firefox bug report that prevents an alternative approach using mouseover events. Please vote to get these bugs fixed in Firefox 3.5, see the orange box on top of this page. Cacycle (talk) 21:58, 11 July 2009 (UTC)

Ideographic space

I recommend U+3000 IDEOGRAPHIC SPACE to be highlighted: it is occasionally treated as wide variant of U+0020 SPACE and therefore is forbidden on ja Wikimedia projects.

Regular square with dotted lines may be desirable for highlighting image (note that it is wide character --- as Chinese ideographs [kanzi] are wide). --Hatukanezumi (talk) 16:42, 1 July 2009 (UTC)

Added to next release. Cacycle (talk) 05:34, 5 July 2009 (UTC)
Fixed in 0.9.84. Cacycle (talk) 21:28, 11 July 2009 (UTC)

Change <pre> to <syntaxhighlight lang=javascript>

See title. Please change: (...) Please see edit window. —MC10|Sign here! 23:00, 1 July 2009 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. — Martin (MSGJ · talk) 06:13, 2 July 2009 (UTC)
Changed pre to source on User:Cacycle/wikEd. Cacycle (talk) 05:33, 5 July 2009 (UTC)

Hidden begin-end not working in preview

Content hidden with Template:Hidden begin isn't working in wikEd's preview. The template isn't broken - it works in articles, and in WP's "Preview". I'm using FF 3.0.1 and the version wikEd supplied by "my preferences."

For example, "{{hidden begin|title=my title}}hidden content{{hidden end}}" displays as 

my title    [show]

with WP Preview (where "[show]" is clickable), but as 

my title
hidden content

with wikEd. — eitch 21:22, 8 July 2009 (UTC)

Fixed in next release. Thanks for reporting - Cacycle (talk) 02:48, 10 July 2009 (UTC)
Excellent, thanks for a great tool! It'd be great if, when the next release comes out, you deleted the "Notes" section from Template:Hidden_begin-end/doc (right now it warns about this wikEd problem) — I'll try to notice and do it myself, but there could easily be a delay — eitch 20:13, 10 July 2009 (UTC)
Fixed in 0.9.84. Cacycle (talk) 21:27, 11 July 2009 (UTC)

Doubled protection warnings.

Safari 4. page. Whenever I have WikEd enabled, suddenly i see the protected page warning twice after wikEd has loaded. —TheDJ (talk • contribs) 18:37, 12 July 2009 (UTC)

The warning is mirrored above the edit area so that you see if when you start editing - it's a feature :-) Cacycle (talk) 04:56, 13 July 2009 (UTC)

Hi. The link for site-wide installation under "Installation" is not working. You have typed _ in stead of - between "site" and "wide". I'm not able to edit the page so I'm telling you. --79.160.203.21 (talk) 06:25, 15 July 2009 (UTC)

Thanks, fixed. Cacycle (talk) 12:43, 15 July 2009 (UTC)

Urls with ampersands

Hi, I installed wikiEd just now as a gadget through the Wikipedia preferences, and while it's unfortunate that ref (un)hiding is broken on Firefox, wikEd looks like a great idea. A bug: It seems that wikEd breaks URLs with ampersands in them (at least, URLs in refs). In Firefox, it turns each ampersand into � (that's Unicode 0002 "START OF TEXT") and in Safari it turns them into "%02" (same thing?). While strictly speaking ampersands in URLs must be encoded, in practice everyone uses ampersands and it's really ungainly to encode all of them. (And in any case, it's unlikely that existing links on a page have their ampersands encoded.) Is this a known bug? Regards, Shreevatsa (talk) 13:19, 16 July 2009 (UTC)

I cannot reproduce this, please could you provide an article link and fill out a detailed description of this bug (see top of the page). Thanks in advance, Cacycle (talk) 13:46, 20 July 2009 (UTC)

Sure. I should have been clearer: the bug is that when you click on the URL from within the wikEd textarea, it takes you to the wrong place. Here's a detailed description:

  • wikEd version: 0.9.84b G (July 11 2009)
  • Browser: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
  • Error console: No errors. (Lots of warnings, though, but nothing relevant AFAICT.)
  • Firefox add-ons installed: Adblock Plus, CacheViewer, Download Statusbar, DownThemAll, Firebug, Greasemonkey, Leechblock, Link Widgets, Live HTTP headers, Nightly Tester Tools, wiki auto-discovery button, Zotero.
  • User scripts installed on monobook.js page: User:Dr pda/prosesizebytes.js, User:Smith609/toolbox.js
  • Operating system: Mac OS X 10.5 ("Leopard")
  • Description of problem / steps to reproduce:
    • Turn on wikEd. Toggle automatic syntax highlighting on.
    • Go to (e.g.) Arthur W. Ryder and click Edit.
    • There is a link in the second line. Hovering over the text shows the URI and "(Cmd-click)"
    • Cmd-click. (Or Ctrl-click if not on Mac OS X, I guess.)
    • Expected result: A new page opens to that URL.
    • Actual result: Firefox is taken to a page whose URL is a transformation of the actual URL, in which all the ampersands have been replaced by � (U+0002 START OF TEXT).

Hope you can reproduce this, Shreevatsa (talk) 14:30, 20 July 2009 (UTC)

Fixed in current 0.9.85, Ctrl-Reload to update. Thanks, Cacycle (talk) 15:36, 20 July 2009 (UTC)
Excellent and amazingly quick, works now in both Firefox and Safari. Thanks! Shreevatsa (talk) 16:02, 20 July 2009 (UTC)

PS: Do you know if the "ref hiding" is broken in Safari too? Turning it on seems to hide {{quote}} content too (in both Firefox and Safari), which is usually part of the article proper and need not be hidden. Regards, Shreevatsa (talk) 16:02, 20 July 2009 (UTC)

Thanks for reporting this. I have fixed it in 0.9.85c, please Shift-Reload to update. Cacycle (talk) 04:20, 21 July 2009 (UTC)
Yes, it works now. (Before you fixed it, I was going to add that some other templates get hidden too, but they all seem to work now.) Thanks again, Shreevatsa (talk) 04:31, 21 July 2009 (UTC)
Only simple, single line, non-nested templates are not hidden. I am wondering if we should disply the template name in the TEMPL buttons. Cacycle (talk) 12:12, 21 July 2009 (UTC)


Edit area font grows when clicking buttons

Every time I click on "Toggle REF and template hiding" or "Toggle between classic text area and wikEd", the font size in the edit area grows. The only solution is to reload the page after clicking one of those buttons.

wikEd 0.9.84b G, Safari 4.0, Mac OS X 10.5.7, No user scripts --UncleDouggie (talk) 07:24, 20 July 2009 (UTC)

Have you changed your default text size from 100% in your browser? Cacycle (talk) 13:52, 20 July 2009 (UTC)
No UncleDouggie (talk) 06:34, 21 July 2009 (UTC)

It's working now with wikEd 0.9.85c! UncleDouggie (talk) 06:42, 21 July 2009 (UTC)

Don't automatically expand references and templates when mousing over

When I mouse over a reference or template it is automatically expanded. I'd prefer it if it only expanded when I click on it, because sometimes I accidentally hover over one and then it expands, and it's hard to make it collapse again because it doesn't always notice that I moused over it again. I usually have move the cursor a few times over it for it to recognize it. Gary King (talk) 21:53, 21 July 2009 (UTC)

Okay, at the very least, I have now figured out that I need to hover over the expanded text rather than the original button to make the box hide away. Gary King (talk) 19:01, 23 July 2009 (UTC)
Yupp, you have to leave the expanded box. Firefox 3.5 has some bugs that make this not work if you move the pointer out of the box back into the button (feel free to vote for the bugs 502527 and 503685...). Cacycle (talk) 01:21, 24 July 2009 (UTC)


I just discovered wikEd and it seems great so far, but I'm missing one function: besides the normal 'create article link' button, there should be one that autoinserts the "|" character between the double brackets, and maybe some empty spaces before it, so creating alternate text for links would be speedier. I know I should learn the alt-code for "|", but I always copy it instead from somewhere, and I bet many others do this too.

I could add a shift-click on that button for a piped link. Don't you have the pipe on your keyboard? Cacycle (talk) 00:34, 25 July 2009 (UTC)
Dumb me, I found out that alt-w serves as the pipe key on european keyboards, but, well, shift-click could be a more convenient solution for everyonePoisonborz (talk) 09:24, 25 July 2009 (UTC)

Also, why don't common functions, like boldening, italicizing, have keyboard shortcuts? Poisonborz (talk) 00:00, 25 July 2009 (UTC)

Because all possible keyboard shortcuts are already taken by the wiki. Cacycle (talk) 00:34, 25 July 2009 (UTC)
Strange, when I try to use them in FF or IE, shortcuts like ctrl-b trigger browser functions, I thought that meant that the site did not had taken them... I wonder what could be wrong Poisonborz (talk) 09:24, 25 July 2009 (UTC)

icon images stored locally

Hello, I'm using WikiEd (0.9.84b) with greasemonkey (firefox 3.5) on the french wikipedia, and I was wondering if this is possible to have the icon images stored locally, to speed up the load time.

Thanks for your work. MickaëlG (talk) 20:16, 4 August 2009 (UTC)

It is possible, but your browser should cache the images automatically so that they are only loaded once. Anything wrong with your browser cache? Load "about:config" and search for "browser.cache" bold values indicate problems. Cacycle (talk) 02:17, 5 August 2009 (UTC)
You're right. I reinitialised the configuration for my browser cache and it seems faster. Thank you ! MickaëlG (talk) 19:48, 5 August 2009 (UTC)
On long articles wikEd can keep your browser quite busy during page load. During those times the last status messages just freezes, thereby making you believe it is trying to load images when it is actually working through some JavaScript code. I am currently testing the improved and faster syntax highlighting engine, that might help you. Cacycle (talk) 03:16, 5 August 2009 (UTC)

How to enable wikEdDiff?

I've just recently re-enabled wikEdDiff after having it disabled for about a year. The button doesn't show up in diffs though, even after I've hard refreshed. Gary King (talk) 16:03, 7 August 2009 (UTC)

Please fill out the bug form on top of the page. If you do not provide any details then it is hard to help :-) Cacycle (talk) 21:13, 7 August 2009 (UTC)
Nevermind I found the problem; I had wikEdDiff purposely disabled in User:Gary King/custom functions.js, at the bottom. I probably put it there instead of my usual config.js file because I used wikEd with importScript before. Gary King (talk) 21:33, 7 August 2009 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=User_talk:Cacycle/wikEd/Archive_009&oldid=1257887149"