Jump to content

User talk:Cacycle/wikEd/Archive 011

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


Inserting/deleting newlines spuriously

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

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

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

Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)
When pasting rich text it is not always easy to see the number of line breaks. Push the Wikify or Textify button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)
Here's what "works" for me:
  1. Open e.g. this page in a new tab.
  2. Type #<Enter>#<Enter>#<Enter>
  3. Click on "Preview" (or on Textify).
  4. "#" characters from the step 2 are now separated by empty lines
The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)
Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)
I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)
Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)
Here it is:
  • WikEd version: 0.9.68a
  • Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19
  • Console errors: none (hope I'm getting it right: ctrl-shift-J window)
  • Add-ons: none
  • User scripts: none
  • OS: Windows XP SP3
  • Problem and steps to reproduce: as described above
Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)
Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)
Safari and Chrome use <div>...</div> tags for linebreaks instead of <br>. I have no idea why they do this. It seriously messes things up and there is no easy workaround for it other than using browser detection as far as I can see :-S Cacycle (talk) 04:29, 27 January 2009 (UTC)
Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)
I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)
Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[1], then inserts too many.[2] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)
It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)
Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)
I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)
The problem still seems to exist with same version of Safari as my last report, and with 0.9.78G (build April 26/2009). Viktor Haag (talk) 16:31, 28 April 2009 (UTC)

Please be as specific as possible so that I can reproduce your problem - what do you mean by "sticking around" and when does it "appear to get deleted"? Do you also experience the Safari bug that turns the text blue after pushing the [T] button? Cacycle (talk) 20:53, 28 April 2009 (UTC)

The first thing I tried in the new Google Chrome (2.0.172.28) was the four-step process to reproduce the problem described above. WikEd is 0.9.78 at the moment. Unfortunately, the behavior is the same... GregorB (talk) 09:52, 22 May 2009 (UTC)
I too have tried 0.9.79c with the four-step process above with Safari (v4 Public Beta on Mac), and the behaviour is still the same, as with Google Chrome. Here is a process to describe the problem I'm seeing on Safari in addition to the test listed above:
  1. Open e.g. thispage in a new tab.
  2. Type "== This is a heading ==" on the top line of the text box (line one).
  3. Type "This is some plain text following the heading." on the very next line (line two).
  4. Click "Preview" : the text in the editing window changes so that there's a newline inserted above the heading text and between the heading text and the line of plain text.
This is what I mean by "spurious newlines". Viktor Haag (talk) 14:20, 27 May 2009 (UTC)
With WikEd 0.9.80 G, running on Safari Version 4.0 (5530.17), this behaviour is partially fixed; from the immediately preceding example, now there's a newline inserted between the heading text and the line of plain text, but no extra line inserted above the heading text. Viktor Haag (talk) 19:32, 15 June 2009 (UTC)
Ditto for Chrome 2.0.172.33 (Win XP), wikEd 0.9.83a. Unfortunately this is still enough for me to refrain from using Chrome. GregorB (talk) 09:22, 29 June 2009 (UTC)
With WikEd 0.9.85d G, running on Safari Version 4.0.2 (5530.19), the immediately preceding test still inserts a spurious newline between the heading text and the line of plain text. I have noticed anecdotally that, when creating table markup, WikEd inserts newlines between "rows" of table text as well. This bug is not a critical fault, but it is a major pain for usability.Viktor Haag (talk) 14:59, 6 August 2009 (UTC)
I am currently working on a new highlighting engine, let's see if it persists after the move. If not, I will try to fix it then, promised. Cacycle (talk) 17:23, 6 August 2009 (UTC)
This is good news; it would be useful to know when the target date for this new engine is; I'm using WikEd 0.9.88b G with Safari Version 4.0.3 (5531.9), and the problems described above in this thread are still present. Viktor Haag (talk) 13:55, 1 October 2009 (UTC)
I'm now using 0.9.90f G with Safari 4.0.4 and the example above still has problems. Viktor Haag (talk) 14:37, 17 February 2010 (UTC)
I came here to report that an other user and I have this problem too at the hungarian wikipedia. We use Chrome, personally I use the 6.0.427.0 beta, I really love wikEd, I didn't want to turn it but this bug is very annoying... I hope you the fix come soon (either from chromium dev's or wikEd's). ~ Boro (talk) 18:29, 10 August 2010 (UTC)
Please could you file a bug report (see top of this page) with wikEd and Chrome versions at the bottom of this page and a link to this section? Thanks, Cacycle (talk) 21:59, 10 August 2010 (UTC)

Please see below, should be fixed in 0.9.91k. Cacycle (talk) 21:10, 16 August 2010 (UTC)== Inserting/deleting newlines spuriously == It appears that wikEd sometimes inserts or deletes a newline in the edit window. Typical scenario is as follows:

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

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

Funny, it happened without a copy/paste, just as I was writing this. See the diff to the previous edit. GregorB (talk) 22:40, 18 January 2009 (UTC)
When pasting rich text it is not always easy to see the number of line breaks. Push the Wikify or Textify button to remove the original formatting of your pasted text. I could not reproduce your problem in Chrome, please provide a detailed how-to so that I can reproduce it. Thanks, Cacycle (talk) 00:26, 19 January 2009 (UTC)
Here's what "works" for me:
  1. Open e.g. this page in a new tab.
  2. Type #<Enter>#<Enter>#<Enter>
  3. Click on "Preview" (or on Textify).
  4. "#" characters from the step 2 are now separated by empty lines
The same happened with the numbered list items from my edit as I was writing it. :) GregorB (talk) 17:01, 19 January 2009 (UTC)
Confirmed -- this also reproduces the bug on Safari. Viktor Haag (talk) 13:29, 22 January 2009 (UTC)
I also echo the suspicion that this may be a WebKit issue: this behaviour also happens to me when using wikEd on Safari (Safari 3.2.1/5525.27.1 running on Mac OSX 10.5.6 on a Dual2 PPC G5). This is not limited to pasting rich text for me. This happens to me during the normal course of editing a page, and usually seems to be clustered around lines with headings and/or templates in them. Unfortunately, it doesn't seem to me to be entirely reproducible or predictable. Viktor Haag (talk) 13:54, 19 January 2009 (UTC)
Maybe it is a Mac-only problem. GregorB: please could you fill out the bug report form on the top for your system information. Thanks, Cacycle (talk) 14:46, 22 January 2009 (UTC)
Here it is:
  • WikEd version: 0.9.68a
  • Browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.43 Safari/525.19
  • Console errors: none (hope I'm getting it right: ctrl-shift-J window)
  • Add-ons: none
  • User scripts: none
  • OS: Windows XP SP3
  • Problem and steps to reproduce: as described above
Apparently not Mac-related... GregorB (talk) 15:29, 22 January 2009 (UTC)
Thanks, I can now reproduce this and will try to fix this as soon as I find the time. Cacycle (talk) 02:55, 26 January 2009 (UTC)
Safari and Chrome use <div>...</div> tags for linebreaks instead of <br>. I have no idea why they do this. It seriously messes things up and there is no easy workaround for it other than using browser detection as far as I can see :-S Cacycle (talk) 04:29, 27 January 2009 (UTC)
Divs are inserted indeed; this behavior can be seen at e.g. http://www.kevinroth.com/rte/demo.htm. I could not find this reported at http://code.google.com/p/chromium/issues/list - which is a bit odd, since one would expect this to hurt other rich text editors too. It's probably a some sort of WebKit misfeature. I'm currently doing 25% of editing in Chrome, 75% in Firefox. This could force me back to 100% Firefox - no big deal perhaps, but still... GregorB (talk) 09:36, 27 January 2009 (UTC)
I have probably fixed this with browser detection in 0.9.71. Please report back if you still experience problems related to this. Thanks, Cacycle (talk) 03:15, 2 February 2009 (UTC)
Just found this thread. This is still happening to me (Feb 4, Chrome/WinXP). First it deletes the breaks[3], then inserts too many.[4] I've turned off wikEd and it works fine. Incidentally, in Chrome misspelled words are only highlighted when wikEd is turned off... don't know if you aware of this or not. NJGW (talk) 07:08, 5 February 2009 (UTC)
It works fine for me with Chrome >= 1.0.154.43 / WinXP. Please could you fill out the full bug report form on top of the page so that I can reproduce your problems. Missing spellcheck is a browser problem not related to wikEd. Thanks in advance, Cacycle (talk) 04:53, 19 February 2009 (UTC)
Unfortunately, the problem persists for me in 0.9.73a (i.e. I can still reproduce it from steps given above). My version of Google Chrome is now 1.0.154.48, and the rest is the same (Win XP SP3, etc.). GregorB (talk) 09:07, 19 February 2009 (UTC)
I still have the problem here as well. Using Safari 4 5528.16, with default user agent (which I assume is Safari Public Beta - Mac), with 0.9.76b (built Mar 29/09). If I insert a new line in front of a paragraph (on the same line just before its first character), the newline seems to stick around. If I try to insert a newline by adding it to the end of the preceeding paragraph, it appears to get deleted. Viktor Haag (talk) 15:54, 30 March 2009 (UTC)
The problem still seems to exist with same version of Safari as my last report, and with 0.9.78G (build April 26/2009). Viktor Haag (talk) 16:31, 28 April 2009 (UTC)

Please be as specific as possible so that I can reproduce your problem - what do you mean by "sticking around" and when does it "appear to get deleted"? Do you also experience the Safari bug that turns the text blue after pushing the [T] button? Cacycle (talk) 20:53, 28 April 2009 (UTC)

The first thing I tried in the new Google Chrome (2.0.172.28) was the four-step process to reproduce the problem described above. WikEd is 0.9.78 at the moment. Unfortunately, the behavior is the same... GregorB (talk) 09:52, 22 May 2009 (UTC)
I too have tried 0.9.79c with the four-step process above with Safari (v4 Public Beta on Mac), and the behaviour is still the same, as with Google Chrome. Here is a process to describe the problem I'm seeing on Safari in addition to the test listed above:
  1. Open e.g. thispage in a new tab.
  2. Type "== This is a heading ==" on the top line of the text box (line one).
  3. Type "This is some plain text following the heading." on the very next line (line two).
  4. Click "Preview" : the text in the editing window changes so that there's a newline inserted above the heading text and between the heading text and the line of plain text.
This is what I mean by "spurious newlines". Viktor Haag (talk) 14:20, 27 May 2009 (UTC)
With WikEd 0.9.80 G, running on Safari Version 4.0 (5530.17), this behaviour is partially fixed; from the immediately preceding example, now there's a newline inserted between the heading text and the line of plain text, but no extra line inserted above the heading text. Viktor Haag (talk) 19:32, 15 June 2009 (UTC)
Ditto for Chrome 2.0.172.33 (Win XP), wikEd 0.9.83a. Unfortunately this is still enough for me to refrain from using Chrome. GregorB (talk) 09:22, 29 June 2009 (UTC)
With WikEd 0.9.85d G, running on Safari Version 4.0.2 (5530.19), the immediately preceding test still inserts a spurious newline between the heading text and the line of plain text. I have noticed anecdotally that, when creating table markup, WikEd inserts newlines between "rows" of table text as well. This bug is not a critical fault, but it is a major pain for usability.Viktor Haag (talk) 14:59, 6 August 2009 (UTC)
I am currently working on a new highlighting engine, let's see if it persists after the move. If not, I will try to fix it then, promised. Cacycle (talk) 17:23, 6 August 2009 (UTC)
This is good news; it would be useful to know when the target date for this new engine is; I'm using WikEd 0.9.88b G with Safari Version 4.0.3 (5531.9), and the problems described above in this thread are still present. Viktor Haag (talk) 13:55, 1 October 2009 (UTC)
I'm now using 0.9.90f G with Safari 4.0.4 and the example above still has problems. Viktor Haag (talk) 14:37, 17 February 2010 (UTC)
I came here to report that an other user and I have this problem too at the hungarian wikipedia. We use Chrome, personally I use the 6.0.427.0 beta, I really love wikEd, I didn't want to turn it but this bug is very annoying... I hope you the fix come soon (either from chromium dev's or wikEd's). ~ Boro (talk) 18:29, 10 August 2010 (UTC)
Please could you file a bug report (see top of this page) with wikEd and Chrome versions at the bottom of this page and a link to this section? Thanks, Cacycle (talk) 21:59, 10 August 2010 (UTC)

Please see below, should be fixed in 0.9.91k. Cacycle (talk) 21:10, 16 August 2010 (UTC)

Incremental find in Google Chrome

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

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

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

Thanks for reporting, I will check into this (might be a tricky one...) 23:36, 12 March 2009 (UTC)
Works in wikEd 0.9.91o. Cacycle (talk) 19:24, 24 August 2010 (UTC)

Basic fixes breaks CATSORT

When I use the single check button, it removes the space following the pipe in a Category link on an article that is supposed to be at the top of its category (e.g., "[[Category:History of Louisville, Kentucky| ]]" --> "[[Category:History of Louisville, Kentucky|]]"). It took me a while to realize this as the diff before saving is nearly identical, but if the space isn't reinserted before saving, the link is saved as with the page title inserted after the pipe. This screws up the sorting in the category and it would be helpful if you could get the script to skip fixing spaces following a pipe in category links. I realize it must be wikimedia software adding the pagename after the pipe when saving—causing the discrepancy between diffs before and after saving—but tweaking the script would prevent accidental changes to the sorting. Thanks. —Ost (talk) 18:39, 14 July 2009 (UTC)

Would you happen to know more about the reason for this behavior? It's really annoying to repair similar miscategorizations at a later stage. Thanks. -- —Preceding unsigned comment added by 217.227.116.77 (talk) 08:09, 5 June 2010 (UTC)
Fixed in 0.9.91i. Cacycle (talk) 20:44, 22 July 2010 (UTC)

Possible Firefox 3.6 bug?

I've been using Firefox 3.6 for a while, and I've had a problem with the search function. When I type a letter in the search box, my cursor jumps to the first occurrence of that letter. When I click again in the search box and type a second letter, the cursor jumps to the first occurrence of that two-letter combination; and so on.

I don't see this behavior in Firefox 3.5.7, but I'm not 100% positive every extension and setting is the same between the two installations. Any ideas? — Malik Shabazz Talk/Stalk 17:44, 20 January 2010 (UTC)

I will check into this next week :-) Thanks for reporting, Cacycle (talk) 18:50, 20 January 2010 (UTC)
Thanks. — Malik Shabazz Talk/Stalk 18:52, 20 January 2010 (UTC)
Same here (Firefox 3.6, Windows XP). Also, initially there is no cursor in the edit box. It appears only when you go to the search box, then return to the edit box. GregorB (talk) 21:43, 21 January 2010 (UTC)
On a more positive note, this appears to be fixed in 3.6. GregorB (talk) 22:12, 21 January 2010 (UTC)
I can confirm both bugs on FF 3.6 (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6) (Leopard 10.5.8). Search & replace are useless this way, unless a user types data into the main edit box and/or drag-selects, then drags/drops into the search/replace fields where appropriate. Very cumbersome workaround, for fast typists anyway.
---Schweiwikist (talk) 07:15, 23 January 2010 (UTC)
Followup: Bugs gone under: (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5)
---Schweiwikist (talk) 07:23, 23 January 2010 (UTC)
Editbox cursor bug still present under Windows Vista and 7. Can be corrected on an edit-by-edit basis by turning off WikiEd (top right of the page) and turning it back on. --King Öomie 15:10, 25 January 2010 (UTC)
Fixed with a workaround in 0.9.90c and filed the Mozilla bug report 543204. Cacycle (talk) 13:55, 30 January 2010 (UTC)

wikEd adds 2 return characters at the top of the page

wikEd has always done some weird doubling of return characters when typing a return character or pasting something in the page, but I just turn of wikEd for a second paste it in and turned it back on, no problem. But recently, don't know exactly when, wikEd started to ad two return characters at the top of the page, this is extremely annoying as the only way to get rid of them, since they don't show initially, is to do a full preview (not inline) which then reveals them, so I can see them, if I just delete them them there, they're not gone. Removing them, deactivating wikEd, and reactivating it just makes them pop up again. The only way is to remove them, preview the page again and then it's only one, and then I can remove that one too. Editing a page and saving it in one turn is out of the question at this point. This is, as you can imagine, extremely annoying as it adds a blank space at the top of the page. I use Mac OS X 10.6, Safari 4.0.4 (6531.32.10), no changes on my end as far as I can remember. Xeworlebi (t•c) 14:09, 25 January 2010 (UTC)

This is a known problem with Webkit-based browsers (Safari and Chrome). See this. GregorB (talk) 17:02, 25 January 2010 (UTC)
Didn't see that, apologies. Looking trough it it seems a pretty old problem, I never had that much of a problem with it, but recently with the hidden double return at the top of the page it is getting to the point that I have wikEd turned off more than on, which is a shame. Xeworlebi (t•c) 00:58, 26 January 2010 (UTC)
This drives me away from using Google Chrome. Still, Firefox is fine, so it's not that bad in my case. GregorB (talk) 14:38, 27 January 2010 (UTC)
It is a Webkit (Safari, Chrome) bug, I have filed the Webkit bug report 34377. Cacycle (talk) 19:26, 30 January 2010 (UTC)

Bug with preview of <syntaxhighlight lang="xxx"> ... </syntaxhighlight> construct

Before I get to that bug, WikiEd refuses to load when I click on the New Section tab on the discussion page. So I will create this section and then edit it. ("Loading error - wikiEd 0.9.90a G (January 15, 2010) Click to disable" in browser Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12) Hgrosser (talk) 23:49, 26 January 2010 (UTC)

When the <syntaxhighlight lang="xxx"> ... </syntaxhighlight> construct is used, wikiEd does not show the syntax coloring in its preview unless Wikipedia’s built-in Preview function is used to preview the page first (and this preview contains a <syntaxhighlight lang=""> block in the same language as the wikiEd preview). Here’s a sample (from Rm (Unix)#User-Proofing): 

if [ -n "$PS1" ] ; then
  rm () 
  { 
      ls -FCsd "$@"
      echo 'remove[ny]? ' | tr -d '\012' ; read
      if [ "_$REPLY" = "_y" ]; then
          /bin/rm -rf "$@"
      else
          echo '(cancelled)'
      fi
  }
fi

Hgrosser (talk) 00:11, 27 January 2010 (UTC)

I have added GeSHi support for local previews in 0.9.90d. The new section issue has already been fixed in a previous release. Thanks for the suggestion, Cacycle (talk) 22:08, 30 January 2010 (UTC)

Firefox 3.6

When I use WikEd on my laptop it turning off the cursor. Anything one can do about this as I prefer the cursor on? Doc James (talk · contribs · email) 14:23, 27 January 2010 (UTC)

That seems to be a Firefox 3.6. bug. The cursor appears after pushing wikEd buttons, e.g. Textify. Cacycle (talk) 23:46, 27 January 2010 (UTC)
I have filed Firefox bug report 542727. Cacycle (talk) 08:48, 28 January 2010 (UTC)
Thanks hopefully they will fix it soon. Makes it a little hard to edit.Doc James (talk · contribs · email) 08:51, 28 January 2010 (UTC)
Fixed with a workaround in 0.9.90c and filed the Mozilla bug report 542727. Cacycle (talk) 13:53, 30 January 2010 (UTC)
Awesome job, thanks for the fix. Glycerine102 (talk) 18:39, 31 January 2010 (UTC)
The workaround does not work all the time :-( Cacycle (talk) 23:36, 31 January 2010 (UTC)

Edit summary

I am using WikEd with Safari and I have a problem with the edit summary field. When I go to edit a page the editor comes up with WikEd, however, this particular field is off the screen to the far left requiring me to scroll over to type a summary and then scroll back to the right to click save. What can I do? Supertouch (talk) 14:35, 27 January 2010 (UTC)

I do not see this with wikEd 0.9.90b as a Gadget and Safari 4.0.4. Please could you fill out the bug form (top of this page)? Thanks, Cacycle (talk) 23:52, 27 January 2010 (UTC)

(wikEd version: 0.9.90b G; browser id: Mozilla/5.0 (Windows; U; Windows NT 5.1; el; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7)

Although they work just fine when previewing or saving a page, italics within links do not show properly within the edit window. For example, writing [[Italics (film)|''Italics'' (film)]] ought to show as [[Italics (film)|''Italics'' (film)]], but instead shows as [[Italics (film)|''Italics'' (film)]]. It is a rather odd reversal.

Note: although the above text is admittedly rather more complicated than regular syntax, it also displays erroneously: it interprets the (real) closing apostrophes for the second example link's Italics as opening apostrophes for the rest of my message. It seems to be the same problem: a confusion between opening and closing apostrophes. Waltham, The Duke of 18:47, 29 January 2010 (UTC)

The upcoming release of wikEd has a new highlighter that should be able to handle this. Thanks for reporting, Cacycle (talk) 21:11, 29 January 2010 (UTC)
Yes, the new wikEdbeta3 handles that correctly, see the top of the page for how to test that version :-) Cacycle (talk) 23:35, 31 January 2010 (UTC)

wikEd options don't work with the beta

I tried the wikEd beta. My wikEd options don't work with it, apparently. Here they are if you want to take a look. They do indeed work with the current wikEd, though. Also, regarding wikEd beta, the buttons that appear to represent hidden templates and references on a Mac in Firefox have text that is a bit too small to read. It looks like they are using &lt;input&gt;, as they look just like how buttons are formatted in Firefox on a Mac. Gary King (talk) 22:47, 31 January 2010 (UTC)

The new wikEd version has a completely new highlighting system, therefore several of the old css styles do no longer work. The buttons are no real input elements, they are actually no real html elements, they are completely realized in css :-) Maybe they are too small to read because of your custom setting? BTW, I have just published beta3, please update with Shift-Reload. Cacycle (talk) 23:31, 31 January 2010 (UTC)
No, the buttons aren't affected by my custom settings because as I said, my custom settings don't even work anyway. Gary King (talk) 19:36, 1 February 2010 (UTC)

Usability Initiative beta uses a new skin called vector. User scripts for that skin are on User:Gary King/vector.js, not on User:Gary King/monobook.js. Cacycle (talk) 08:45, 15 February 2010 (UTC)

Diff takes 3-4 minutes to load

I've got the latest version of Firefox, not using any odd skins, Core 2 Duo laptop. When I pull up this month's diff (with WikEd diff enabled, WikEd otherwise disabled) of WP:MOS ("220 intermediate revisions not shown"), I get "Firefox not responding". It looks like the system responds again after 3 to 4 minutes, and the diff appears to be correct. Thought you'd want to know; I don't know whether there's something odd about this month's WP:MOS diff (this has never happened before, and I've used WikEd's diff button a lot) or whether something has changed in WikEd. - Dank (push to talk) 00:25, 1 February 2010 (UTC)

P.S. If it matters, I don't have a slow machine: 4 Gigs of RAM, Windows 7, Dell. - Dank (push to talk) 01:18, 1 February 2010 (UTC)
Please could you provide the diff link for two specified revisions from the history page where it takes so long (e.g. http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style&action=historysubmit&diff=341159534&oldid=334949000). BTW, with that link I do not see the problem. It could be a server / connection problem as wikEdDiff has to load both revisions from the server in the background in order to create the diff. Cacycle (talk) 08:21, 1 February 2010 (UTC)
http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style&limit=250&action=history, click on 11:26 Dec 31, click on any version around the end of January (I tried several), push the button. - Dank (push to talk) 13:23, 1 February 2010 (UTC)
Out of curiosity, I tried this. Takes c. 15-20 seconds or so on my 2006 laptop. GregorB (talk) 15:29, 1 February 2010 (UTC)
That would be this link: http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style&action=historysubmit&diff=341159534&oldid=335090526 which takes less than 2 s for me (including the backgrount article text loading). Looks like a server/connection problem on your side to me... Cacycle (talk) 23:22, 1 February 2010 (UTC)

Loading error

wikEd 0.9.90d (January 30, 2010) - on Firefox 3.6 and Google Chrome 5.0.307.1. No adding a script or switching on and off works... – Kochas (talk) 03:14, 5 February 2010 (UTC)

I get the same error, both with Firefox 3.0.15 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15) Gecko/2009101601 Firefox/3.0.15 (.NET CLR 3.5.30729)] and 3.6 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)]: "Loading error - wikEd 0.9.90d G (January 30, 2010) Click to disable" – Hgrosser (talk) 04:28, 5 February 2010 (UTC)
Still not working for me. —Aaroncrick (talk) 06:25, 5 February 2010 (UTC)
Same problem here. Waltham, The Duke of 07:45, 5 February 2010 (UTC)
And for me too. Is it related somehow to Wikipedia:Help desk#Lost toolbar and Wikipedia:VPT#Edit box & monospace style changes? - ukexpat (talk) 15:05, 5 February 2010 (UTC)
OK I got it working again by disabling "Enable navigable table of contents" in the edit tab of Special:Preferences. – ukexpat (talk) 15:08, 5 February 2010 (UTC)
I had the same problem. Had to disable "Enable enhanced editing toolbar" as well before wikEd worked again. No experimental features for wikEd right now, I suppose. OdinFK (talk) 15:49, 5 February 2010 (UTC)
That worked for me, too, Odin. Thanks. Waltham, The Duke of 17:52, 5 February 2010 (UTC)
Thanks for the hint guys, it worked. Seems the problem appeared after I played with the setting mentioned. But can any of you tell what do I miss with the two of those unchecked? – Kochas (talk) 00:27, 7 February 2010 (UTC)

It is related to the newest Usability Initiative release, I have already filed the bug 22400 and work on a temporary workaround / fix. 00:38, 6 February 2010 (UTC)

Would you consider making the duplicate edit notices optional?

I know you explained further up the page (October) that you do it on purpose so that people will see the edit notices even though the focus moves to the main edit box, but getting it to line up right is pretty hit or miss, and for pages with long editnotices it means scrolling down through two or three more screens to get to the edit box. Obviously it's just a minor annoyance, nothing major, but since this is a behavior you added with a particular piece of code I would think it would be easy to disable. -- Soap Talk/Contributions 13:32, 5 February 2010 (UTC)

Thanks for your suggestion, in wikEd 0.9.90e you can now add var wikEdDoCloneWarnings = false; to your monobook.js/vector.js. Cacycle (talk) 08:41, 15 February 2010 (UTC)
Thanks! —Soap— 22:29, 15 February 2010 (UTC)
Thanks for the option. However, I did notice that when wikEd duplicated edit notices, it actually showed TWO copies of the edit notice below the preview. Please fix this, thanks. Gary King (talk) 18:37, 21 March 2010 (UTC)
Gary King: I cannot reproduce that, please provide more information about your problem (at least a link to a page where it happens and your skin, please see the top of the page for required infos). Thanks, Cacycle (talk) 19:26, 21 March 2010 (UTC)
It doesn't seem to have a problem on most pages. It does have a problem here though. Gary King (talk) 19:33, 21 March 2010 (UTC)
That is because the text between the two notices, i.e. the {{Statustop}} template, has been positioned out of the normal text flow to the top of the page. Cacycle (talk) 22:58, 21 March 2010 (UTC)
So why does that cause wikEd to create a second edit notice below the preview? Gary King (talk) 00:24, 22 March 2010 (UTC)b
The two edit notices are intended. If you have another problem you need to explain it in detail as requested above. Cacycle (talk) 07:42, 22 March 2010 (UTC)
On the link that I gave above (and in this screenshot), there is one edit notice that appears above the preview, as is expected. And then wikEd creates a second edit notice below the preview, as is expected. But then wikEd creates a THIRD edit notice, which appears below the preview (I call it the "second" edit notice to appear below the preview because there are two that appear below the preview now). Gary King (talk) 16:49, 22 March 2010 (UTC)
I see, thanks for mentioning this, I will check into it. In the future, would you mind to be more elaborate with your your bug reports, it is always a bit frustrating and time consuming to have to squeeze the facts out of you - I cannot read your mind :-) Cacycle (talk) 08:12, 23 March 2010 (UTC)

wikiEd on wikia (3)

Wikia made this change, and now there's another <ul> element inside #wikia_header, making the wikEd icon go inside there, and not being shown (because of the special style that ul element has).

The logo should go inside #userData, but the way it's done you can't define #userData for the mocaco skin, because that's the ID of the <ul> element, and your code gets the <ul> with a getElementsByTagName, not picking the current element. You should do that instead: 

if (logoContainer.tagName == 'UL') {
	list = logoContainer;
} else {
	list = logoContainer.getElementsByTagName('ul')[0];
}

Also, at the next line you evaluate if (list != null ), and firefox accessing a getElementsByTagName( ... )[0] when there's an empty array evaluates it as undefined and not null. It probably should never occur, though.

Here you can view the DOM node tree of the wikia skin, where it's currently loaded the WikEd icon and where it should be placed (at the end of the bottom list) --Ciencia Al Poder (talk) 17:25, 5 February 2010 (UTC)

I have added your changes to wikEd 0.9.90e, please could you check if it works? Cacycle (talk) 08:39, 15 February 2010 (UTC)
Yes! Now works like a charm!. Many thanks! --Ciencia Al Poder (talk) 21:08, 15 February 2010 (UTC)

Extra spaces inserted

Hi lately im experiencing that WikEd is inserting extra spaces both in the editbox and summary line, except those spaces are not regular spaces.
Example in summary line: "Copy-over from [[some wiki page with spaces]]", next time you try to re-use that text, the link will be shown as red in preview-mode of the summary, while the first time it was a correct link.

  • WikEd used: v0.9.90d (30 January 2010)
  • Browser used: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
  • WikEd is remote loaded by personal skin-js at FoM-Wiki

⇐⇑©TriMoon™ Talk @ 10:54, 4 February 2010 (UTC)

My experience also. Happens when I copy and paste something within the editbox. I made a test edit here: I wanted to duplicate the line, but extra whitespace was somehow introduced in the process. This was done with wikEd 0.9.90g, Firefox 3.6 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)). Apparently works fine with wikEd 0.9.90g and Firefox 3.5.8 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8). GregorB (talk) 23:24, 13 March 2010 (UTC)
Also, extra spaces are visible only upon saving or previewing the page. Clicking on "[T]" apparently does not have any effect. GregorB (talk) 15:40, 15 March 2010 (UTC)
Hopefully fixed in 0.9.90h. Please could start a new topic at the bottom of this page if you still experience this problem. Thanks, Cacycle (talk) 18:18, 20 March 2010 (UTC)

References segregator vs. wikEd beta ref hiding

I have written an alternative script to hide refs, since wikEd Beta doesn't work on Firefox 3.6 yet. It really doesn't hide refs completely, but rather it takes a simpler approach that works with plain text boxes: it replaces the first occurrence of a ref with the short code as if it were already used. Then it puts the ref's old code in a box below the main edit box. I have tested the final script on several featured articles and Comparison of Windows and Linux and with no changes to the textboxes, it does not affect the page (doesn't change the citation style on other editors unnecessarily). For more details (including how it handles unnamed refs), you will have to read the documentation and the script itself (the latter both includes informative comments and passes JSLint). The script is limited to just looking at the first ref for the contents, but this limitation should not impact its usefulness to remove the clutter of a hundred unnamed refs, for example. Despite its limitations, would you find such a script useful, since citation templates can be quite lengthy? If so, maybe the MediaWiki software itself should incorporate this idea (of course simplifying the ref format so that the content is automatically in the first ref).

My script, however, doesn't work with the Wikipedia Beta editor, which seems to be some strange code that actually removes the textarea and replaces it with an iframe (according to a quick glance at Firebug). How can I make my script Beta-compatible (like wikEd is supposed to be)?

And had you thought of the idea of moving refs into a separate box when you designed wikEd's reference hiding? PleaseStand (talk) 05:39, 6 February 2010 (UTC)

I found the ref-hiding feature in the stable version (the "R" button at the upper right). However, as noted at User talk:SlimVirgin/templates, it can be cumbersome to use. I still support my idea of replacing refs with short codes for editing purposes but believe that the ref format should be simplified for automatic parsing. So I'd like to see this in wikEd, but preferably, I'd like to see this in MediaWiki so that it is available to all editors. PleaseStand (talk) 23:53, 14 February 2010 (UTC)
The only way to make your script compatible under standard textarea and the Usability Initiative beta iframe is have to separate parts of your code for them... Their iframe solution will break all existing textarea-related userscripts. I am not planning a separate ref editing window, I think the current ref hiding in wikEd beta (will be made compatible with UI-beta and Firefox 3.6 today or tomorrow) is a more intuitive and easier to edit solution.Cacycle (talk) 08:35, 15 February 2010 (UTC)

WikEd beta doesn't work in FF 3.6? Huh?

Damn. What else can I say...? Three days ago I installed the beta, since for several days WikEd had not been working, and the default editor or whatever that thing is which I keep seeing instead is rather painful. The beta didn't work either. I've tried a number of things to try to better understand it. Just tonight I disabled all my addons, theme, etc. and the result was rather underwhelming. Then, just now, coming here to post a report and ask for help, I read the comment about the beta not working with FF 3.6 - in the text of the post immediately above. Incredible. That's NOT where I should be learning about this.

Could someone put a notice up in VERY plain sight so that someone else doesn't have the experience I just had? I can't believe that this problem exists, yet at the top of this page people are still being invited to install the beta. I appreciate WikEd, and all the time that surely must have been invested in it, but people really shouldn't be installing code known to be bad, yes? Tom Cloyd (talk) 05:01, 7 February 2010 (UTC)

Also, it seems that under Firefox 3.6, the stable version of wikEd is adding extra spaces into wikitext, as if it is trying to fully justify the wikitext. This is hard to find (spaces aren't red colored on diffs of course) and doesn't make a difference in the page as seen in a Web browser, but nevertheless, the issue seems to exist. (wikEd has had other Firefox 3.6 issues: the text cursor used to not show in Firefox 3.6.) I agree, a big notice should be posted that wikEd (neither stable nor beta) does not work properly in Firefox 3.6 and users should use Firefox 3.5 instead, and wikEd should then be fixed. PleaseStand (talk) 20:04, 7 February 2010 (UTC)
A diff and/or a test case would be really helpful to reproduce the issue and try to fix it. --Ciencia Al Poder (talk) 19:07, 8 February 2010 (UTC)
"diff"? Don't know what that is. As for test case - well, ANYTHING on Wikipedia fails, for me. I'm running Kubuntu Linux 9.10, and Firefox 3.6. Is that enough for a replication? Tom Cloyd (talk) 22:06, 8 February 2010 (UTC)
I have diffs, here are the links: [5][6]. Note that the text isn't the same in both diff links, but the common link is that I copied wikitext out of wikEd, then pasted it back in (with or without wikEd active). I'm running wikEd stable, on Firefox 3.6 on Windows 7. PleaseStand (talk) 22:10, 8 February 2010 (UTC)
I should add, I ran a binary compare using frhed (compares values of corresponding byte locations, not like a text diff) and the first difference I found between raw text downloads [7] and [8] is that {{cite web| changed to {{cite web |. And the issue only occurs when the text is copied from wikEd, not copied from the plain text editor, which has me suspecting that the browser is not copying correctly from wikEd's iframe. Bug in wikEd or in Firefox? I don't know. Cutting/pasting text is so common to reorganize pages, perhaps that's why I noticed. PleaseStand (talk) 22:30, 8 February 2010 (UTC)
Yeah, cut and paste is a huge problem. EOLs get inserted, and when text is pasted they are still there and have to be manually removed. A large pain. I've removed that importScript('User:Cacycle/wikEd_dev.js'); line from my skin.js page, and reloaded all pages in Firefox. It didn't fix the problem. A real mess, as I'm doing editing for hours, right now, and those renegade EOLs are a significant problem. Tom Cloyd (talk) 06:54, 9 February 2010 (UTC)

It is difficult to describe how awful this problem has become! I simply cannot cut and put in the default editor without having huge problems in randomly inserted EOLs. I do NOT know what is causing this, and certainly am not capable of figuring it out.

Can someone please attempt to replicate this? In Firefox (ver. 3.6), remove all traces of WicEd, and see if the default editor is inserting these EOLs for you as well. We need to figure this out. My thanks to anyone who can help. Tom Cloyd (talk) 10:43, 9 February 2010 (UTC)

Yes, I have already tried that. There is no change in the page when copying and pasting an article (tested in my sandbox #2). No diff for you though since if there's no difference in the saved text, MediaWiki doesn't save the page; there is no change. This is using Monobook skin with the plain text (not experimental/Usability) editor. PleaseStand (talk) 22:04, 9 February 2010 (UTC)
To add, I just tested the "Babaco" editor (the latest version of the Usability/Beta editor with the section jump links on the right side). You are certainly correct—it's far worse than wikEd stable in that it is actually breaking the formatting with copy-paste. Again this is on FF 3.6 and here's the diff from cutting all then pasting: [9]. You might want to note that on the watchlist page they are warning not to use "experimental features" including the new Beta text editor. PleaseStand (talk) 22:15, 9 February 2010 (UTC)

The standard wikEd has been made compatible with the Usability Initiative beta in version 0.9.90e, I will update wikEd beta in the next few days so that it will become compatible with the Usability Initiative beta. I will also check for the EOL problem. Cacycle (talk) 08:18, 15 February 2010 (UTC)

wikEd beta has been updated to version 0.9.91beta3.2 and is now compatible with the Usability Initiative beta changes. Please update with Shift-Reload. Cacycle (talk) 21:18, 15 February 2010 (UTC)
!!!! It's working! Yahooo! So nice to have it back. Thanks for all your work. Tom Cloyd (talk) 19:42, 22 February 2010 (UTC)

Erratic cursor movement

I have serious problems with erratic cursor movements. When I run the cursor to the end of the line, it often jumps to a location much farther ahead then the beginning of the next line. Scrolling back past the beginning of a line move the cursor to a place forwards in the text. I am using window 7 and chrome 4.0.249.78. It may be related to pasting.

Can be reproduced as follows. Put "one two three four five six" in the edit buffer. Go to an empty edit screen. Paste several times to fill a few lines. Now put the cursor in the first line and scroll right past the end of it. The cursor skips the remainder of the pasted string and moves forward to the first following "one". Now scroll backwards past the begin of the reached line. The cursor does not go up one line, but reverts to the same "one" forward.

After pressing [w], I see several nested "div" blocks. Now scrolling to the right skips all remaining text.

P.S. I also experience the seemingly random insertion/deletion of empty lines mentioned by many in earlier sections.

−Woodstone (talk) 05:23, 11 February 2010 (UTC)

This is a Webkit/Chrome bug that has already been reported (https://bugs.webkit.org/show_bug.cgi?id=34377 bug 34377). Cacycle (talk) 08:16, 15 February 2010 (UTC)

WikiEd is not working with Wikipedia's beta features

Few days ago, WikiEd could work with Wikipedia's beta features. But now, it's not working with it. So I turned WP beta off, and WikiEd works well. What should I do? -- JSH-alive talk • cont • mail 07:13, 11 February 2010 (UTC)

I am working on it, please give me a few more days :-) Cacycle (talk) 13:46, 12 February 2010 (UTC)
Fixed in version 0.9.90e. Cacycle (talk) 08:12, 15 February 2010 (UTC)

wikEd beta Safari 4.""

I have the following error: HIERARCHY_REQUEST_ERR: DOM Exception 3: A Node was inserted somewhere it doesn't belong. Line has: "wikEdCaptchaWrapper.appendChild(node);" after comment "fill captcha wrapper with elements between form and textarea (table)" —TheDJ (talk • contribs) 15:32, 12 February 2010 (UTC)

The standard wikEd has been made compatible with the Usability Initiative beta in version 0.9.90e, I will update wikEd beta in the next few days so that it will become compatible with the Usability Initiative beta. Cacycle (talk) 08:11, 15 February 2010 (UTC)
Fixed in wikEd 0.9.91beta3.2. Cacycle (talk) 08:10, 16 February 2010 (UTC)

I'm trying to use 0.9.91beta3.2 with Safari 4.0.4, and when I try to edit a page WikEd seems to load the toolbar, but the little icon in the monobook title bar at the top shows a red X and says "load error"; Safari's error console reports "ReferenceError: Can't find variable: regExpComments". I'm loading WikEd from my "monobook.js" page with this code: var wikEdUseLocalImages = true; var wikEdImagePathLocal = 'http://hhappsweb/wiki/images/wikedimg/'; document.write('<script type="text/javascript" src="' + 'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd_dev.js' + '&action=raw&ctype=text/javascript"></' + 'script>'); I'm not sure if this is a bug with WikEd itself, or a problem with the way I'm attempting to load it. Viktor Haag (talk) 14:54, 17 February 2010 (UTC)

wikEd is disabling signature button

Started today. With wikEd enabled, neither the signature button nor the insert javascript at the bottom of the edit box works for inserting four tildes. All other buttons and pieces of insert javascript appear to work. Reproducible - turn off wikEd and the sig button works. Turn it does and it doesn't. This has affected both myself and ukexpat. Any more info needed, just ask --Elen of the Roads (talk) 19:43, 15 February 2010 (UTC)

For me, wikiEd disabled the javascript Wiki markup insertions below the edit box (all the ones I tried) except the paired tags; the insertion point disappears when I click on a symbol to insert. This happened around the same time that wikiEd stopped working with Mediawiki's beta interface, and the javascript still does not work even after I stopped using the beta interface. I enabled wikiEd from the gadgets in my preferences. I'm curious what broke wikiEd, which quickly became indispensable to me as soon as I started using it a month or two ago.—Finell 21:32, 15 February 2010 (UTC)
Just fixed with 0.9.90f, please update with Shift-Reload. Cacycle (talk) 21:49, 15 February 2010 (UTC)
Confirm it's fixed for me, thanks. – ukexpat (talk) 21:52, 15 February 2010 (UTC)
Fixed for me too. Thanks so much, fantastic piece of kit. Elen of the Roads (talk) 22:43, 15 February 2010 (UTC)
Thanks, it's also fixed for me. I'm still curious as to what happened, if you don't mind a very brief explanation.—Finell 01:36, 16 February 2010 (UTC)
Check the diff, it was just a random bug, nothing special :-) (the .html instead of the correct .plain crashed the custom insert function). No need for more confirms but it is nice to hear that people actually use and like wikEd :-) Cacycle (talk) 08:00, 16 February 2010 (UTC)
Thanks. And, thanks very much for wikEd!—Finell 05:04, 18 February 2010 (UTC)

wikEd trouble with regular expressions and jumping insertion point in find box

I had the same problem as above with javascript insertions until I restarted Firefox today, which fixed it, but now regular expressions in the find box don't work, and the insertion point erratically jumps to the start of the find box. I'm dead in the water. Chris the speller (talk) 17:04, 17 February 2010 (UTC)

If there is a way for me to use the version of February 15, or even a few days before that, I'd love to hear about it. Chris the speller (talk) 17:21, 17 February 2010 (UTC)
Fixed in 0.9.90g, please update with Shift-Reload. Thanks for reporting, Cacycle (talk) 18:28, 17 February 2010 (UTC)
Magnificent! Chris the speller (talk) 03:43, 18 February 2010 (UTC)

But now I can't use recently invoked expressions from the drop-down list in the find box; the down arrow key just flashes right though the entries without any real chance of selecting one of them. For the record, I upgraded to Firefox 3.6 yesterday, about the same time this started. This isn't a show-stopper for me, since I keep a list of useful regular expressions in an external file, so I can cut and paste into the find box, it just slows me down from warp 7 to warp 3. Chris the speller (talk) 22:53, 20 February 2010 (UTC)

Please disregard that complaint. I had to restart Windows, and now the problem can not be reproduced. Go back to sleep. Chris the speller (talk) 15:59, 22 February 2010 (UTC)

Customization question

Hi Cacycle, I have a (probably stupid) question for you. I have WikEd installed as a gadget via my preferences menu. Can I still customize WikEd features by pasting the codes specified on the customization page into my Monobook.js file? Or do I have to do it another way?

Thanks,

--Eastlaw talk ⁄ contribs 01:14, 21 February 2010 (UTC)

Cacycle appears to be taking a well-deserved rest, so I will say that I added the sample customization code for custom buttons to my monobook.js page, and it works with wikEd selected as a gadget in my preferences page. See User:Chris the speller/monobook.js         Chris the speller (talk) 18:13, 21 February 2010 (UTC)
Thanks, I took your advice and it appears to be working just fine. --Eastlaw talk ⁄ contribs 07:12, 22 February 2010 (UTC)
UPDATE: It was working yesterday, but now it isn't! WTF?! --Eastlaw talk ⁄ contribs 18:36, 22 February 2010 (UTC)
UPDATE #2: I got it working again...the .js code is really persnickety. --Eastlaw talk ⁄ contribs 23:13, 22 February 2010 (UTC)
Most gadgets cannot be configured via your monobook.js / vector.js, but wikEd is an exception. Check the error console of your browser to check for errors in your code. Cacycle (talk) 08:02, 24 February 2010 (UTC)

Any plans to support WikEd in Opera

As above - I'd just like to know if I should hope or give up. Thanks. Dougweller (talk) 13:25, 22 February 2010 (UTC)

Opera had a notoriously poor support for web standards (Javascript, CSS) and scripts ran rather slow. I am currently working to make wikEd compatible with their next release, Opera 10.50, which is still in beta. Looks doable so far :-) Cacycle (talk) 18:02, 26 February 2010 (UTC)
In theory, Opera's upcoming 10.50 version should be compatible with wikEd BUT the currently available Opera 10.50 Beta (3273) has some serious bugs (e.g. related to inserhtml and parentNode) and I have given up on finding workarounds. I have reported these bugs, but it is impossible to know if they will fix these bugs due to their completely intransparent closed bug tracking system which is a BIG nuisance for web developers. I will monitor their upcoming releases. Sorry, Cacycle (talk) 17:57, 20 March 2010 (UTC)

Edit summary

(Moved here from User_talk:Cacycle/wikEd help)

I am using WikEd with Safari and I have a problem with the edit summary field. When I go to edit a page the editor comes up with WikEd, however, this particular field is off the screen to the far left requiring me to scroll over to type a summary and then scroll back to the right to click save. What can I do? Supertouch (talk) 14:34, 27 January 2010 (UTC)

Please could you fill out a bug report (see the top of this page) as I cannot reproduce that. Thanks, Cacycle (talk) 18:02, 26 February 2010 (UTC)

Load problem

(Moved here from User_talk:Cacycle/wikEd help)

Wikied is not loading properly. I have a flame in the little box on the top right. Any suggestions as to the solution? 15:52, 7 February 2010 (UTC)

I've gone through the documentation, and finally clicked the Beta off. It's working fine now, but it used to work with Beta. Auntieruth55 (talk) 16:19, 7 February 2010 (UTC)
wikEd has been updated and should now be running fine under beta. Cacycle (talk) 18:02, 26 February 2010 (UTC)
Yes, for me it is again working. Many thanks! Tom Cloyd (talk) 13:43, 4 March 2010 (UTC)

wikiEd on wikia (4)

Hi!

Wikia today has changed part of the design of the monaco skin. Now, the #userData element is no longer a list, but a div with each link inside a span. This change makes the wikEd icon to not appear.

I've debugged it and the solution is to change the second parameter of the wikEdMediaWikiSkinIds object from true to false (line 1414) so it simply appends the icon instead of trying to find a UL element. I've tested it myself and works.

Thanks in advance! --Ciencia Al Poder (talk) 20:12, 17 March 2010 (UTC)

PS: I mean the monaco skin --Ciencia Al Poder (talk) 17:01, 19 March 2010 (UTC)

Fixed in 0.9.90h. Thanks for reporting, Cacycle (talk) 17:44, 20 March 2010 (UTC)
I'm afraid, but the change wasn't pushed (see diff), although you mentioned it in the edit summary. --Ciencia Al Poder (talk) 13:11, 22 March 2010 (UTC)
Any follow up on this? It's a simple change: only swap true to false --Ciencia Al Poder (talk) 17:11, 26 March 2010 (UTC)

Finally fixed in the current version 0.9.90l, thanks for reporting this :-) Cacycle (talk) 10:12, 28 March 2010 (UTC)

Many thanks. --Ciencia Al Poder (talk) 17:28, 28 March 2010 (UTC)

Newlines in copypasting

There seems to be some problem with copy-pasting in wikEd, which causes newlines to appear: [10], [11]. Some other users have the same problem. I use Firefox 3.6 on a Mac OS X 10.5. Ucucha 03:56, 21 March 2010 (UTC)

I'm having the same problem.[12] I use FF 3.6 in Windows Vista. — Malik Shabazz Talk/Stalk 05:36, 21 March 2010 (UTC)
Hopefully fixed in 0.9.90i, please push Shift-Reload to update. Cacycle (talk) 12:25, 21 March 2010 (UTC)
Yes, no problems now. Thanks! Ucucha 12:26, 21 March 2010 (UTC)

Extra spaces inserted - part II

Unfortunately the problem with extra spaces is made even worse with 0.9.90h - it now inserts line breaks (example). I believe this is limited to Firefox 3.6, 3.5.x is not affected. GregorB (talk) 10:45, 21 March 2010 (UTC)

Hopefully fixed in 0.9.90i, please push Shift-Reload to update. Cacycle (talk) 12:24, 21 March 2010 (UTC)
I see now it has been reported already... Anyway: looks good to me too, thanks! GregorB (talk) 19:30, 21 March 2010 (UTC)
I’ve just lived with this glitch since it appeared perhaps more than a year ago. Since spaces don’t affect the rendering (AFAICT) I let it go, and watched for "buggy linefeeds", fixing them as they turned up. I will updat this entry if I notice that the plague has come to an end.
Schweiwikist (talk) 11:55, 28 March 2010 (UTC)

highlight HTML entities

Could HTML entities be highlighted in some fashion, please? There is a discussion here which tangentially discusses the reasons for this request. Thank you.
— V = IR (Talk • Contribs) 09:08, 23 March 2010 (UTC)

Good idea, I will add this. Cacycle (talk) 07:44, 25 March 2010 (UTC)

Proposed integration of parts of wikiEd into the Usability Initiative

I've proposed the addition of parts of wikiEd into the beta prototypes at the Usability Wiki. Just letting you know... ManishEarthTalk • Stalk 09:15, 23 March 2010 (UTC)

WikEd doubling bug

As reported here, WikEd seems to be causing double-uploads of files and doubling of editnotices. I can confirm the editnotice effect (in FF 3.6.2). Algebraist 13:43, 25 March 2010 (UTC)

wikEd is purposely doubling the edit notice below the preview, just in case you missed it when wikEd jumps you to the edit box. At least you aren't getting triple editnotices, heh. Gary King (talk) 14:54, 25 March 2010 (UTC)
There is no preview. I just click "edit" (on WP:HD, for example) and get an edit page with two editnotices (with me jumped to the top of the second), with the "This page is 80 kilobytes long." note between them. Anyway, the real problem is the upload doubling. Algebraist 14:58, 25 March 2010 (UTC)
Okay; I don't know if wikEd still creates the second editnotice or not if there hasn't been a preview yet. Personally, I've got it setup so that I see a preview when I first click edit. Gary King (talk) 15:07, 25 March 2010 (UTC)

I can now confirm that wikiEd is the gadget that causes the double upload error. I've just uploaded this logo after disabling the wikiEd option (using FF 3.6.2). Arteyu ? Blame it on me ! 15:18, 25 March 2010 (UTC)

Well, I've tried another method, by disabling wikiEd and enabling the "Firefogg" option (under User interface gadgets) upon uploading this image. Found that the firefogg option by itself doesn't upload the image twice, but it adds this "== Summary ==" word to the comment. Arteyu ? Blame it on me ! 15:43, 25 March 2010 (UTC)

The tripling has been fixed in 0.9.90j, the doubling is intentional so that you see the notices after autoscrolling to the edit field. Cacycle (talk) 08:18, 26 March 2010 (UTC)

So how about the doubling of images? As per examples above, the image doubling bug occur only when user enables both firefogg and wikiEd together; and I don't think that was intentional; I also do think that it has something to do with the doubling of editnotices. Arteyu ? Blame it on me ! 11:05, 26 March 2010 (UTC)

When you do a test upload with only wikEd enabled, do you still see double uploads of images? Cacycle (talk) 13:27, 26 March 2010 (UTC)

Nope, I've tried it just now. See here. Imho, the double upload only happens when user enables both gadgets. Arteyu ? Blame it on me ! 14:26, 26 March 2010 (UTC)

Fixed in the current version 0.9.90l, thanks for reporting this :-) Cacycle (talk) 10:11, 28 March 2010 (UTC)

Wow! Is it? Thank you very much Arteyu ? Blame it on me ! 19:35, 1 April 2010 (UTC)

Funny cursor movement

Here's how to reproduce:

  1. Go e.g. here
  2. Position the cursor at the end of the first line
  3. Press Arrow down repeatedly until the cursor reaches the penultimate line
  4. Press Arrow down once again
  5. The cursor jumps to the third line, instead of the last line

This is reproducible on both Firefox 3.5.8 (Win2k machine) and 3.6.2 (WinXP machine), but - interestingly enough - works fine in Google Chrome 4.1.249.1042. I'll supply more details if necessary.

Backspace also works funny:

  1. Edit any page
  2. Go to the end of the last line and press Enter
  3. Type: 123
  4. Press Backspace three times
  5. All digits should be deleted, but "1" remains

Again: broken in Firefox 3.5 and 3.6, works fine in Chrome. GregorB (talk) 20:56, 28 March 2010 (UTC)

Problem #1: Confirmed on Firefox 3.6 on a Mac. Problem #2: Confirmed. However, step #5 is a bit more complicated than that. Type "12345", then hit backspace once, "5" is deleted. Hit backspace once more, however, then nothing happens; so, for some reason you need to hit backspace twice to delete the penultimate character in that line. Gary King (talk) 21:04, 28 March 2010 (UTC)
Whoa, that was quick... Yes, that's what I'm seeing too. There is also a problem when one tries to merge two lines by going to the beginning of a line and pressing Backspace. It's as if some invisible characters are being deleted, and nothing happens after the first keypress. Probably the same as problem #2. GregorB (talk) 21:34, 28 March 2010 (UTC)

Fixed in 0.9.90m, please Shift-Reload to update. Thanks for reporting this, it was a bug in the new feature that prevents highlighted code to "bleed out" if you start typing right before or after a colored/highlighted block. Cacycle (talk) 23:09, 28 March 2010 (UTC)

Looks good - could not reproduce any of the above problems in Firefox 3.6.2. Thanks! GregorB (talk) 08:54, 29 March 2010 (UTC)

Bug with inserting the 4 tildes

When I'm editing a talk page and I click on the link below the editing window labeled "Sign your posts on talk pages: ~~~~" which links to javascript:insertTags('~~~~','','') (“Insert” selected from popup menu), the 4 tildes get inserted at the beginning of the edit text even if the insertion point is at the end (Firefox 3.6) Hgrosser (talk) 07:00, 30 March 2010 (UTC)

Fixed in 0.9.90n, please update with Shift-Reload. Thanks for reporting this! Cacycle (talk) 20:57, 30 March 2010 (UTC)

Don't know if you want to still support Firefox 2, but in that version, which is the one on library computers at UC Berkeley and required for Macs running Mac OS X 10.3, the 4 tildes (or any other character) insertion doesn't work (does nothing) when the insertion point is at the end of a line (which is where you'd usually insert them). This is both in 0.9.90q and the beta version. You can get Firefox 2 at ftp://archive.mozilla.org/pub/firefox/releases/2.0.0.20 . As for the beta version, I like the image preview, but it's really annoying to have the wikitext right over the image. Can you make the text wrap around the image? Thanks. Hgrosser (talk) 02:42, 29 April 2010 (UTC)

Losing content of edit window upon navigating away from page and returning

Is there any way to prevent one from losing the content of the edit window when one navigates away from the page and comes back? When WikEd is disabled, this doesn't happen, in Firefox anyway. Tisane (talk) 08:37, 2 April 2010 (UTC)

It is a bug with the Usability Initiative Beta, see bug 22680. It looks as if they did not have the time to check into it :-( Cacycle (talk) 12:03, 6 April 2010 (UTC)

Examples of regular expressions

I haven't seen any place to share knowledge about regular expressions for searching and replacing text in Wikipedia using WikEd. I can offer a few examples on User:Chris the speller/regular for those who are new to the subject. If there is another place to find examples, please let me know. I will also accept requests to produce expressions for those who would like help. Chris the speller (talk) 23:00, 2 April 2010 (UTC)

More funny cursor movements

WikEd is 0.9.90n, tried in Firefox 3.5.9 (likely the same in 3.6 - can't test at the moment).

Problem #1:

  1. Click e.g. here
  2. Position the cursor at the first character of the first line
  3. Press Enter
  4. Go to the beginning of the first (now empty) line
  5. Type in any character
  6. It is displayed in the second line, not in the first, as would be expected

Problem #2 (possibly related):

  1. Click e.g. here
  2. Go to the end of the last item in the first numbered list ("The cursor jumps to the", etc.)
  3. Press Enter
  4. Go back to the same position (i.e. end of the last item)
  5. Type any character
  6. It is displayed in the following line, not in the same line, as would be expected

GregorB (talk) 16:51, 8 April 2010 (UTC)

Thanks, will check :-) Cacycle (talk) 21:25, 8 April 2010 (UTC)
Tried in Firefox 3.6.3, indeed the same behavior. Also, works fine in Google Chrome 4.1.249.1045, just like the original funny cursor movements. :-) GregorB (talk) 14:11, 9 April 2010 (UTC)
Still having the same problem - any news on this one? GregorB (talk) 19:27, 25 May 2010 (UTC)
It's on the list :-) Cacycle (talk) 19:42, 25 May 2010 (UTC)
Works fine in 0.9.91i, thanks! GregorB (talk) 07:57, 22 July 2010 (UTC)

wikEd and beta toolbar interference

Hallo, did you ever seen (fixed) this problem of incompatibility at the pic? --Perhelion (talk) 20:53, 7 April 2010 (UTC)

Fixed in next release (0.9.90o), thanks for reporting, Cacycle (talk) 22:27, 14 April 2010 (UTC)

Problem in French Version

WikiEdit bugs the French Wikipedia, but only on firefox. That is what he writes me 

Bad Request

Your browser sent a request that this server could not understand.
Size of a request header field exceeds server limit.

Cookie: wikEdAutoUpdate=Thu%2C%2015%20Apr%202010%2016%3A23%3A27%20GMT; wikEdFindHistory=%25E2%2597%258A%25E2%2597%258A%2520l'athl%25C3%25A8te%2520%255B%255Balg%25C3%25A9rie%255D%255Dnne%2520la%2520plus%2520titr%25C3%25A9e%2520est%2520%255B%255BHassiba%2520Boulmerka%255D%255D%2520%2520est%2520devenu%2520la%2520premi%25C3%25A8re%2520femme%2520africaine%2520%25C3%25A0%2520gagner%2520un%2520titre%2520mondial%2520en%2520%255B%255BAthl%25C3%25A9tisme%255D%255D%252C%2520et%2520la%2520premi%25C3%25A8re%2520%255B%255Balg%25C3%25A9rie%255D%255Dnne%2520%25C3%25A0%2520gagner%2520un%2520titre%2520olympique%2520%253F%257C%250A%25E2%2597%258A%25E2%2597%258A%2520AS%2520A%25C3%25AFn%2520Melila%250A%25E2%2597%258A%25E2%2597%258A%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%25201998-1999%250A%25E2%2597%258A%25E2%2597%258A%2520---%2520align%253D%2522left%2522%250A%25E2%2597%258A%25E2%2597%258A%2520%257C-----%2520align%253D%2522left%2522%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%257C-----%2520align%253D%2522center%2522%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%257C%257C%2520%257B%257B; wikEdReplaceHistory=%25E2%2597%258A%25E2%2597%258A%2520l'athl%25C3%25A8te%2520%255B%255Balg%25C3%25A9rie%255D%255Dnne%2520la%2520plus%2520titr%25C3%25A9e%2520est%2520%255B%255BHassiba%2520Boulmerka%255D%255D%2520%2520est%2520devenu%2520la%2520premi%25C3%25A8re%2520%255B%255Balg%25C3%25A9rie%255D%255Dnne%2520%25C3%25A0%2520gagner%2520un%2520titre%2520olympique%2520%253F%257C%250A%25E2%2597%258A%25E2%2597%258A%2520AS%2520Ain%2520M'lila%250A%25E2%2597%258A%25E2%2597%258A%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%25201997-1998%250A%25E2%2597%258A%25E2%2597%258A%2520---%2520align%253D%2522center%2522%250A%25E2%2597%258A%25E2%2597%258A%2520%257C-----%2520align%253D%2522center%2522%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%257C-----%2520align%253D%2522left%2522%2520%2520%250A%25E2%2597%258A%25E2%2597%258A%2520%257C%257C%2520align%253D%2522center%2522%2520%257C%257B%257B%250A%25E2%2597%258A%25E2%2597%258A%2520%2520align%253D%2522center%2522%2520; wikEdSummaryHistory=mise%2520en%2520page%250Aalg%25C3%25A9rie%2520pas%2520tunisie%250AEffectif%2520en%2520Mod%25C3%25A8le%2520!%250A%252BSmain%2520Ibrir%250AModification%2520de%2520la%2520cat%25C3%25A9gorie%2520%255B%255BCat%25C3%25A9gorie%253ANaissance%2520%25C3%25A0%2520Alg%25C3%25A9rie%255D%255D%2520%25E2%2586%2592%2520%255B%255BCat%25C3%25A9gorie%253ANaissance%2520en%2520Alg%25C3%25A9rie%255D%255D%2520(avec%2520%255B%255BMediaWiki%253AGadget-HotCats.js%257CHotCats%255D%255D)%250A%252B%2520H.Bouchache%250A%255B%255Ben%253ACar%2520classification%255D%255D%250Aproposition%2520de%2520cessesion%2520des%2520articles%250Addn%2520defnoun%250A%252Blien%2520Defnoun; wikEdButtonBarFindHidden=0; wikEdRefHide=0; wikEdUseClassic=1; frwikiUserID=585589; frwikiUserName=Clapsus; botsDeluxeHistory=ABotSupreme||AHbot||AStarBot||Aca-bot||Adlerbot||AdrilleBot||Aibot||AkhtaBot||Albambot||Alecs.bot||Alexbot||AlleborgoBot||Almabot||AlmabotJunior||AlnoktaBOT||AmaraBot||Amirobot||Analphabot||ArthurBot||AsgardBot||AstaBOTh15||AttoBot||BOT-Superzerocool||BOTarate||BOTijo||Badmood||BenjiBot||BenoniBot||BenzolBot||BetBot||Bocianski.bot||BodhisattvaBot||BokimBot||Bot de Sept Lieues||Bot de paille||BotMultichill||BotSottile||BotdeSki||Botozor||Broadbot||Bub's wikibot||CaBot||CarsracBot||ChenzwBot||Chicobot||Chlewbot||Chobot||CommonsDelinker||D'ohBot||DSisyphBot||DaBot||DanBot||Darkicebot||DeepBot||DirlBot||DixonDBot||DodekBot||DorganBot||Dr Bot||DrFO.Tn.Bot||DragonBot||DroopigBot||DumZiBoT||EivindBot||ElMeBot||EleferenBot||EmausBot||EpopBot||Escalabot||Escarbot||Estirabot||Eybot||FANSTARbot||Ficbot||FiriBot||FlaBot||Gerakibot||GhalyBot||GnawnBot||Gpvosbot||GrouchoBot||GrrrrBot||H92Bot||HAL||HRoestBot||HariBot||HasharBot||HerculeBot||Hexabot||Hxhbot||HyuBoT||Idioma-bot||Ir4ubot||JAnDbot||Jbot||Je suis trop bot||Jotterbot||Jujubot||Kal-El-Bot||KelBot||Ken123BOT||KhanBot||Korribot||Kwjbot||Kyle the bot||LSG1-Bot||LaaknorBot||Lait ribot||Le Pied-bot||Le plus bot||LinkFA-Bot||Liquid-aim-bot||Lockalbot||LordAnubisBOT||Louperibot||Loveless||LucienBOT||Luckas-bot||Ludo Thécaire||MMBot||MSBOT||MagnusA.Bot||Maksim-bot||MastiBot||MauritsBot||MediaWiki default||Melancholie

For information, the site was buggy when I made a replacement of words by another on the WikEd Clapsus (talk) 22:02, 15 April 2010 (UTC)

As a quick fix please push the [X] button in the top right button bar to delete the cookie. I will have a closer look at it when I find some time. Thanks for reporting, Cacycle (talk) 20:11, 18 April 2010 (UTC)

WikEd breaks RevisionDelete diff message

If RevisionDelete is enabled, you have the revisiondelete right, and you view a diff where one of the revisions has been hidden, a message appears inside the diff table, and WikEdDiffLinkify breaks links in that message. The structure looks like this: 

<table class="diff">
<tr>
<td class="diff-otitle" colspan="2"><div id="mw-diff-otitle1">
[navigation links, left side]
</div></td>
<td class="diff-ntitle" colspan="2"><div id="mw-diff-ntitle1">
[navigation links, right side]
</div></td>
</tr>
<tr>
<td colspan="4"><div class="mw-warning plainlinks">
[RevisionDelete warning message with links which are broken by WikEdDiffLinkify]
</div></td>
</tr>
<tr>
[usual diff structure with diff-lineno, diff-marker, diff-context etc. classes]
...

Maybe diff linkification could be limited to the diff-context class.

WikEd version: 0.9.90n (disabled)
Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
skin: Vector

--Tgr (talk) 16:21, 17 April 2010 (UTC)

I have fixed wikEdDiff.js as you suggested. Please could you check and report back if it works (Shift-Reload)? Thanks, Cacycle (talk) 21:02, 20 April 2010 (UTC)
You also disabled diff linkification outside the diff-context for people without revisiondelete, like me, which is rather annoying as the links were very useful. Any chance they're coming back? Ucucha 20:34, 22 April 2010 (UTC)
Has already been fixed yesterday :-) (Shift-Reload this link to update). Cacycle (talk) 06:54, 23 April 2010 (UTC)
Thanks. Yes, it's working now. Ucucha 11:09, 23 April 2010 (UTC)

AfD bug

See thread at Wikipedia:Administrators'_noticeboard/Incidents#Someone_has_broken_AfD ... I am really stumped on this one. My browser is Firefox 3.0 (kind of behind the times, I know) and Im using monobook (ditto). It says there's a "loading error" when editing any AfD page (but every other page seems to be fine) and the problem disappears when I disable WikEd (and refresh teh cache). —Soap— 21:13, 17 April 2010 (UTC)

I'm using Modern. and Firefox 3.6.3. I don't get an error message, but the editbox comes up blank, and any edits I make don't appear. Disappears when WikEd is disabled. Might be related, any page that has a message on the edit page (as ANI has), the edit message appears in between the editbox toolbar and the WikEd toolbar. Hadn't noticed it doing this before, but perhaps I just missed it.Elen of the Roads (talk) 21:40, 17 April 2010 (UTC)
I have reverted wikEd back to the previous version, please push Shift-Reload to update. Sorry for that, Cacycle (talk) 00:00, 18 April 2010 (UTC)

wikEd fails on some articles; script busy or stopped responding

Script: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:11085

It fails every time on West Ham United F.C. with Firefox 3.6.3. Chris the speller (talk) 19:46, 25 April 2010 (UTC)

Works fine for me - please could you post a complete bug report (see top of this page), maybe it is some kind of incompatibility. Thanks, Cacycle (talk) 20:05, 25 April 2010 (UTC)
I removed custom button code from my monobook.js, and now I can edit this and other pages, such as Racine Unified School District that gave me trouble. You may look at the February 23 version of my custom code if you like, to see if I did something exceptionally stupid. The strange thing is that the custom code caused me no problems for two months, and then suddenly I hit 4 or 5 articles in the last couple of days. I'm OK now, so don't hit your head against a wall, unless you want to satisfy your curiosity. I'm on Windows Vista, and the only Firefox add-ons are Linky 3.0.0, Java console 6.020, .NET Framework Assistant 1.1. and Norton IPS 1.0. If you want me to dig up any other bug report info, I can do that. Chris the speller (talk) 18:44, 26 April 2010 (UTC)
Even works with your code for me... Cacycle (talk) 22:08, 26 April 2010 (UTC)
I only use that custom button code once in a thousand articles. It seems like delving further into this would be a great waste of your talent. Thanks anyway, and happy editing! Chris the speller (talk) 03:50, 27 April 2010 (UTC)

Beta version

I absolutely love the new HTML character entity hiding, as well as the click-to-hold-open feature! You should change the rollover text for the button so that it mentions char. ent. hiding as well as [REF] and [TEMPL]. I see now that it also gets rid of text over image preview — fantastic! One bug though, when I apply <sup>.../<sup> to something within the ref block using your toolbar's button, it completely messes up WikiEd's conception of where the boundaries of the ref block are, and I have to use the textify button to fix it.

In the info block on the beta version, you got rid of the instructions on how to install it. Perhaps you could restore these, as well as mentioning that one could switch between versions easier by just changing the name of the .js file in one's Monobook.js, rather than re-enabling it as a gadget. Hgrosser (talk) 03:38, 29 April 2010 (UTC)

Oh, and the image preview doesn't work when it is referenced by some templates w/o image tag, such as Phi Beta Kappa Society Hgrosser (talk) 03:55, 29 April 2010 (UTC)

Requested 'bug log'

  • Your wikEd version: 0.9.90n GM
  • Your browser id: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3")
  • Error console errors: way too many to list... is there something specific I should be looking for? no errors, but a lot of warnings
  • Which browser add-ons have you installed: Adblock Plus, BitDefender QuickScanner, Firebug, Greasemonkey, .NET Framework Assistant, Web Developer
  • Which Wikipedia skin do you use: Monaco
  • Are you using the experimental Wikipedia Beta user interface: no
  • Which user scripts have you installed on your Special:Mypage/skin.js: none
  • Which operating system do you use: XP SP 2
  • Describe the problem, please be as specific as possible about what is wrong: detailed at [13] same problem as before. Won't allow me to edit in the edit box once the mouse interacts with the box. Moving around via tab and arrow keys work fine.
  • Steps to reproduce: Click edit and move mouse over edit field and click or scroll mouse wheel.
  • What exactly happens if you follow these steps: edit box renders itself useless.

-- 68.101.94.165 (talk) 06:33, 12 May 2010 (UTC)

What are your Wikia settings, userscripts, and gadgets? Have you tried to uncheck Wikia's editing extensions and additions? Cacycle (talk) 20:27, 24 May 2010 (UTC)

Gadget installation still uses old version

When I tried to install wikEd as a Gadget, the old version, wikEd version 0.9.90 (forgot the letter, but the date is Apr. 19, 2010) appears. Both wikEd.js and wikEd_dev.js added to my .js file give the same new version. Hgrosser (talk) 01:00, 14 May 2010 (UTC)

There were some delays with the new version (0.9.91x). Seems to be working now, but I will give it a few days more beta-testing... Cacycle (talk) 20:24, 24 May 2010 (UTC)

Edit Notices

  • Version 0.9.90Q G (April 19 2010)
  • Firefox/3.6.3 (.NET CLR 3.5.30729)
  • Using Vector (link below)
  • No Beta (unless it's default)
  • Both script pages listed below

"Here" is the quick version of my problem. I think this is enough information to explain it. Here are some links for research purposes.

  • This is what I see (assuming your version is the same)HERE

Here are my .js Pages (I might have the wrong script)

I sure hope there's a fix for this, I love wikEd, Please I need help with this, If there's no fix, Patch there needs to be ! Thank you very much, if you need to make any changes to any of my pages Please Do of course I need to what was done so I can work with it in the future... Mlpearc pull my chain Trib's 19:11, 24 May 2010 (UTC)

  • I just read this doubling bug. I'm using the "gadget" form do I need to switch to a java script ? If so could you please leave a link to the page ? Or is something else ?
You probably have to remove the "<syntaxhighlight lang="JavaScript">...</syntaxhighlight>" tags as these are not valid javascript and are probably breaking your code (check your browser's error console for JavaScript errors). I would not suggest to disable the doubling because you might miss important messages that are sitting on top of the page. Cacycle (talk) 20:21, 24 May 2010 (UTC)
No, removing "<syntaxhighlight lang="JavaScript">...</syntaxhighlight>" tags did not work. But there must be a patch for this override ? Mlpearc pull my chain 'Tribs 17:49, 25 May 2010 (UTC)
Did you push Shift-Reload to update to the new skin.js versions? Cacycle (talk) 19:47, 25 May 2010 (UTC)
Yes, after each change with Monobook and Vector. Mlpearc pull my chain 'Tribs 20:55, 25 May 2010 (UTC)
You have an error in your vector.js (missing "]"), pleease check your browser's error console and fix your code. Again, I suggest not to use that override, better do not (mis)use an edit notice for your talk page. Cacycle (talk) 06:56, 26 May 2010 (UTC)

WikEd completely broken!

I don't know what happened, but all of a sudden I can't edit with WikEd at all. I'm using Firefox 3.0 (old, I know, I'll test with other browsers when I get a chance), and it seems to happen on all skins that support WikEd. What happens is that the little toolbar above the edit window is magnified to the size of an entire screen, a horizontal scrollbar appears at the bottom window, even if it isn't needed, pressing [tab] to get to the Edit summary field doesnt work, and all edits fail to go through even if it looks like they did. (Previewing an edit shows no changes.) This all happened suddenly around 22:00 GMT on May 24. I appreciate all the work youve done on WikEd, and if this problem is just isolated to me (which I imagine it might be since if it was global I'd expect a flood of comments here), I will try to find out the source of the problem and do what I have to do to get it fixed, even if it means upgrading/switching to a new browser. Thank you. —Soap— 12:10, 25 May 2010 (UTC)

Comment: Problem not appearing on another computer w/ very similar browser (FF 3.0.15). Still checking other stuff. 3 ¢ soap Talk/Contributions 12:36, 25 May 2010 (UTC)
It seems to happen only on Firefox 3.0 for me. Again, the skin I use doesnt seem to matter, so I dont think this is a Vector/Monobook thing. Unless a bunch of other people start complaining I wouldnt worry about this. I'll try upgrading FF and see if it helps. —Soap— 13:09, 25 May 2010 (UTC)
Hmm, upgrading the browser didn't help. It only seems to happen on this user account (not 3centsoap) so it might be something to do with the cache, but it doesnt seem possible to clear the cache. I'll just have to stop using WikEd. —Soap— 13:51, 25 May 2010 (UTC)
Okay, this is the last message I hope. I restored functionality of WikEd by unclicking in the Prefs page under editing "Widen the edit box to fill the entire screen" and "Enable enhanced editing toolbar", "Enable dialogs for inserting tables, links, and more", and "Enable navigable table of contents". Yet, none of those features caused any problems under another computer ,even with the same browser, skin, css, js, and every other conceivable setting the same. —Soap— 14:20, 25 May 2010 (UTC)

Unresponsiveness with certain articles...

...such as D8 (Croatia). Attempting to edit at various places in the article leads to general unresponsiveness and high (or at least higher-than-normal) CPU usage. Can be reproduced with Firefox 3.6.3 on both Windows 7 and Windows XP SP3, but seems to work fine with Google Chrome 5.0.375.55 on Windows 7. GregorB (talk) 13:59, 4 June 2010 (UTC)

I can not reproduce this any more on either the June 4 or the current version of the article with Firefox 3.5.11, so it is apparently fixed now. GregorB (talk) 21:36, 23 August 2010 (UTC)

Category sort

Could you please fix this bug. It's really an annoying bug. --Schnark (talk) 09:02, 14 June 2010 (UTC)

Fixed in the next release. Cacycle (talk) 21:12, 21 June 2010 (UTC)
Fixed in 0.9.91i. Cacycle (talk) 20:43, 22 July 2010 (UTC)

Bug: Editor locks on Programmer's Wiki mainpage

wikEd 0.9.90q (April 19, 2010)

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3

No errors were displayed.

My only add-on is Ubuntu Firefox Modifications (unless you're counting plug-ins as well as extensions).

The skin in use is Monaco.

I am not using Wikipedia Beta.

Your script is the only one installed as my userscript, and I believe there are no custom scripts used wiki-wide.

I am running Ubuntu 9.10 "Karmic Koala."

Manual editing and manual scrolling within the editor are completely disabled. Undo/redo and the buttons, both the standard ones and the special wikEd ones, still work, and effect scrolling when the text they affect is outside the current editor viewport. I managed to accidentally highlight a character while playing with the buttons and undo, but otherwise this is not possible and I can't manually change the highlighted text anyway. Fortunately I can disable/enable the script while on the page in question, a very wise feature. The editing page also displays a notice of anti-anon protection twice.

To reproduce the problem, create a Wikia account, paste your script here (or skip this step and use Greasemonkey), and visit the problem page's editor. I also noticed the behavior on a subpage as well as the original with only a redirect in it, but not a duplicate page. The name of the main page happens to also be the alias for the Project: namespace.

When you open the editor for the page in question with wikEd enabled, you should experience the same issues as I described above. --Jesdisciple (talk) 16:38, 14 June 2010 (UTC)

It seems to work for me with the newest wikEd version (0.9.91j) using Greasemonkey as well as monaco.js installation. Do you still have problems? Cacycle (talk) 20:42, 22 July 2010 (UTC)

Not working

For a private (non-web) wiki on my computer, I’ve tried to install the latest version of WikEd following the steps of the procedure ‘Wikis without internet connection’, but I can’t get it to work. I’m using: Windows XP Professional, MediaWiki 1.15.4, IIS 5.1, PHP 5.3.2, MySQL 5.1 Essentials, phpMyAdmin 3.3.3 and Mozilla Firefox 3.6.3.

The memory limit is ok; I added ‘$wgUseSiteJs = true;’ to the local settings (and also tried ‘$wgAllowUserJs = true;’); created the required pages (‘wikEd.js’, ‘wikEd current version’, etc.) as well as the optional ‘AutoWikiBrowser typos’, but not the translation page; manually uploaded the 88 images; copied the installation code at ‘MediaWiki:Common.js’, replacing the relevant lines with http://localhost/mediawiki and http://localhost/mediawiki/images; and protected the .js pages. After restarting the IIS server and refreshing the Firefox cache, no WikEd logo or WikEd buttons appear in the editing box.

The JavaScript error report says:

Error: syntax error
Source file: http://localhost/mediawiki/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook
Line: 28, Column: 113
Source code: var wikEdAutoUpdateUrl = 'http://localhost/mediawiki/index.php?title=wikEd_current_version&action=raw&maxage=0'; }

Any thoughts? Cavila (talk) 10:58, 15 June 2010 (UTC)

Incidentally, I've also tried setting wikEdAutoUpdate to 'false', but that gives us another error:
Error: syntax error
Source file: http://localhost/mediawiki/index.php?title=-&action=raw&smaxage=0&gen=js&useskin=monobook
Line: 31, Column: 106
Source code: var wikEdRegExTypoFixURL = 'http://localhost/mediawiki/index.php?title=AutoWikiBrowser_typos&action=raw'; }
Cavila (talk) 12:36, 15 June 2010 (UTC)
Maybe it is the "}" at the end of the lines? Cacycle (talk) 19:55, 15 June 2010 (UTC)
Odd as that may sound, it is! I copied the text just as I found it at User:Cacycle/wikEd installation#Wikis without internet connection. Do you think that those braces were intended to be at the line directly below or did javascript change its preferences (I'm only guessing)? The extra images do not (yet) appear on my screen, possibly because the uploads were automatically stored in subfolders of /images/, but I'm happy to have short descriptions instead, as I have now (the reason being that it works better with my display preferences). Thanks! Cavila (talk) 21:24, 15 June 2010 (UTC)
I have fixed the code, sorry for that. Also make sure to read the customization options at the top of the wikEd code. For the image page you have to use the newest release 0.9.90r. Cacycle (talk) 21:35, 15 June 2010 (UTC)

how to call a function in onkeypress event

Thanks for great tool. I wish to create a transliteration, language editor I still don't know how to call a function onkeypress of this editor. I have the js files and want to call a function (addCharKeyPress(thisobj, keypress,engToTam)). Please help me. Mahir78 (talk) 12:53, 29 June 2010 (UTC)

Please could you elaborate on what exactly you want to accomplish? Thanks, Cacycle (talk) 20:55, 29 June 2010 (UTC)

Wiked is only working sometimes

Right now, in this post, it is not working at all. However, I just opened Wikipedia talk:WikiProject Professional wrestling and it was fine. Before that, I was editing Wikipedia:Administrator's Noticeboard and it wasn't working either. I thought it was in certain pages, but I have now noticed it is completely random. Help? Feedback ☎ 03:28, 3 July 2010 (UTC)

variable misnaming, I think.

In the order asked: The balloon that pops up for that widget next to "log out" reads"Loading error - wikEd 0.9.90r G (June 14, 2010) Click to disable" (I was able to get the properties of it and copy/paste that text in FF)

Not that it would matter much, but my one browser says it's "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20", and the other "Opera/9.80 (X11; Linux i686; U; en) Presto/2.6.30 Version/10.60" (wikiEd does not work in either/both)

...and now the key: the FF error console says: "Error: tag is not defined Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 12178" From what I saw, you define a variable "tags" and then reference tag[i]; don't know if that's what you wanted, and somehow I don't think so. I think you wanted "tags[i]", not "tag[i]".

Y'know, considering what I found from FF's error console, I didn't try disabling add-ons. Sorry 'bout that, but I didn't think it was relevant.

I use the Monobook skin. I actually tried putting in a simple alert() call into monobook.js, but I never saw an alert. Hmmmm...dunno why not.

What happens is, I no longer see the wikiEd toolbars, just the pretty much standard ones (bolding, italic, link, advanced, special characters, help, and so on.)

I might also add that for several months now, using the case-changing widget (at least in FF) loses the selection after using it. In other words, after selecting some text and clicking the case-change widget, it would for example change all the highlighted text to upper case, but then the text just operated upon would become deselected. Therefore I couldn't step to the next "case case", for example all lower without reselecting that text. It didn't used to do that; the text would remain selected and highlighed in the textarea, up until a few months ago anyway.

Source File: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 6447 This could very well be a FF bug that was fixed in later versions. As you have seen, this is a rather old version. That error looks nasty. Still, it could have been an addon. This line looks like it's frobbing the range object. Ohwell.

Oddly enough, I started experimenting with that a little bit, by going in and disabling wikiEd in my prefs, and reenabling it, then editing my user page. Wikipedia showed the wikiEd toolbar once, but now it pretty much doesn't show it anymore. Odd indeed that it seemed to work once.

  • It also appears I may have toggled the little beastie on and off with that widget near the top right of the page. Sometimes I click on it and the wikiEd toolbar will appear. Hmmm...dunno what causes that "load error" stuff though.

hope that helps.

-- Joe (talk) 23:07, 5 July 2010 (UTC)

Thanks, I have fixed that typo in the next release. The selection code will change in the next release. You probably want to update your browser anyway for security reasons. Cacycle (talk) 21:22, 7 July 2010 (UTC)
Fixed in 0.9.91i. Cacycle (talk) 20:32, 22 July 2010 (UTC)

Error

Vector on Windows XP, no clue what version my WikEd is: I tried the Search and Repla{{red|[[user:ce feature, {{red|[[user: replacing {{red|[[user: with [[user:
and I got this:

User Day Time (UTC) Article / Summary
Suomi Finland 2009 17 June 2010 15:16 Signature[[user:TFOWR 17 June 2010 15:19 Si[[user:Berean Hunter 17 June 2010 18:25 S[[user:White Shadows 18 June 2010 00:01 S[[user:SuperHamster 19 June 2010 04:29 S[[user:MPJ-DK 19 June 2010 12:10 S[[user:A. di M. 19 June 2010 14:24 S[[user:OlEnglish 19 June 2010 15:11 S[[user:Christine 19 June 2010 20:44 S[[user:S Marshall 20 June 2010 02:22 Si[[user:Daniel Case 20 June 2010 Si[[user:Mifter 20 June 2010 Si[[user:Abce2 20 June 2010 Si[[user:Jclemens 20 June 2010 Si[[user:Spencer 21 June 2010 Si[[user:FT2 21 June 2010 Si[[user:OhanaUnited 21 June 2010 Si[[user:True Pagan Warrior 22 June 2010 Si[[user:Hidividedby5 22 June 2010 Si[[user:WVRMad 22 June 2010 Si[[user:Thelmadatter 22 June 2010 Si[[user:Fetchcomms 22 June 2010 Si[[user:Kayau 23 June 2010 Si[[user:Resident_Mario 23 June 2010 Si[[user:TitanOne 23 June 2010 Si[[user:Nifky 23 June 2010 Si[[user:ceranthor 23 June 2010 Si[[user:NSD 23 June 2010 Si[[user:Duncan 24 June 2010 Si[[user:Enigma 28 June 2010 Sig[[user:Jack1956 28 June 2010 19:51 Si[[user:Lear's Fool 29 June 2010 12:42 Si[[user:Spanglej 30 June 2010 06:40 Si[[user:Wizardman 01 July 2010 22:40 Si[[user:Jack Merridew 03 July 2010 19:55 Si[[user:M4gnum0n 04 July 2010 22:55 Signature
IdaShaw 05 July 2010 07:17 Signature
WVRMad 06 July 2010 19:50 Created Elms Bridge Halt railway station

hidividedby5 (talk) 22:19, 6 July 2010 (UTC)

Fixed in next release, thanks for reporting. Cacycle (talk) 21:35, 7 July 2010 (UTC)
Fixed in 0.9.91i. Cacycle (talk) 20:34, 22 July 2010 (UTC)

Bug: Find and replace, code highlighting not working on wikia.com

Applogies, it was my error - managed to get the functionality back by removing a global javascript setting RandomTime 00:36, 9 August 2010 (UTC)

Syntaxhighlight tag

Hello, thanks for this great tool. I have seen, in wikEd source code, that it takes into account this tag for preview displays. But when I use the "<>" button for check html, the WikifyHTML function remove the syntaxhighlight tag. This tag is not in the list of allowed wiki tags (it's after this line //<> remove not allowed tags in the source code of wikEd). Can you add this tag please ?
Instead I can use the source tag which is used by the SyntaxHighlight_GeSHi extension. But, an other issue is that source allow to write html tags like this : 

<myTags>
   MyText
</myTags>

So, wikEd removed the tag myTags. But all tags nested in source tag and syntaxhighlight tag are transformed in text by SyntaxHighlight_GeSHi extension. So, I think that it should not be deleted by wikEd. Have you an idea for this issue ? Thanks (and sorry for my english) --Gobygoba (talk) 22:17, 10 October 2010 (UTC)

I have just added the syntaxhighlight tag to the next release of wikEd. I am not sure what you mean with myTags. Visible text will not be deleted by wikEd, only invisible formatting. Cacycle (talk) 21:54, 11 October 2010 (UTC) (Added to 0.9.95b, Cacycle (talk) 21:32, 14 October 2010 (UTC))
Thanks. I just want to says that the tag myTags is deleted by "<>" button. For exemple, if you edit this section, and if you use the "<>" button, then the tag myTags is deleted. Yet, this tag is not a html tag, it's a simple text because it's in between a source tags (so this tag is parse by syntaxhighlight extention). So, I think that it should not be deleted by wikEd. But it may be complex to be taken into account. --Gobygoba (talk) 21:19, 17 October 2010 (UTC)
Ah, I see. The [<>] button uses the same logic as the [W]ikify button. Unknown tags are stripped during wikification and therefore also during html fixing. This is done with text pattern matching, not with real parsing, and nested tags are not handled differently. Cacycle (talk) 21:03, 19 October 2010 (UTC)

magic Words

is it possible to create magic words with wikiEd?? A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 17:37, 14 October 2010 (UTC)

I'm not sure what you mean, please could you elaborate? Thanks, Cacycle (talk) 21:31, 14 October 2010 (UTC)

Double stringcourses and categories

Sory for my english, I'm french and my first ask is here
In the modification of article by the editor with 3 windows, but without the wikEd preference, when I prévisualise or publish, the stringcourses and Infoboxs of the window of high edit-window are also at the beginning of the main edit-window ; and the gates and categories are at the end of the main edit-window and in the low edit-window. That causes doubled text when one preview or validate. Of course, one can temporarily empty the windows high and low to benefit from this editor, but rigth fonction is better. Thanks in advance. --Ricima (talk) 14:20, 16 October 2010 (UTC)

Some little point : In wikEd the field of summary is too short, perharps "width:500px;" or "rigth:50px;" is better. --Ricima (talk) 14:20, 16 October 2010 (UTC)

For the main question: I am not exactly sure what you mean. Is it about duplication of warning boxes from the top of the page above the edit box? This is a feature as you would not notice them otherwise with wikEd's autoscrolling to the edit bix. As for the summary field: its size is always be the maximum length (it is dynamically scaled). Which browser and OS are you using? Cacycle (talk) 20:58, 19 October 2010 (UTC)
The bug exist only when internal editor has 3 windows, that is to say :
  • in internal editor, not in wikEd,
  • one edit areas for stringcourses and Infoboxs, one for main text, one for categories
  • in fr.wikipedia, not in en.wikipedia,
  • in main space and not in edit user page,
  • in editing whole the page and not only a chapter.
  • I don't know the version of internal editor now in french WP
  • I use the last Firefox 3.6.10 on last MacOSX 10.6.4.
(to day with wikEd 0.9.95b G(13 oct 2010) the summary is OK) --Ricima (talk) 12:44, 20 October 2010 (UTC)
Sorry, but I have no idea what the first problem is. Where can I find edit pages with three windows? Is the problem caused by wikEd? Maybe somebody from the French Wikipedia could jump in and help translating the problem. Cacycle (talk) 18:51, 30 October 2010 (UTC)
By email I explained to you how to edit with 3 windows. I changed my english count for SUL from Ricima to : --Rical (talk) 08:35, 31 October 2010 (UTC)
Modify your french preferences/gadget/without wikEd, then edit a french page with banner and categories, edit has 3 windows, then preview 2 or 3 times, banners are mutiplied. --Rical (talk) 09:53, 2 November 2010 (UTC)
The problem was the less edit clutter gadget. wikEd now stops loading and displaysan error message. Cacycle (talk) 22:01, 8 December 2010 (UTC)
Sorry, but when I just tried, the issue continue with my account and the french page gave 3 lines above. --Rical (talk) 22:54, 11 December 2010 (UTC)
That is because you have selected the less edit clutter gadget under your preferences. This has nothing to do with wikEd. Cacycle (talk) 12:15, 12 December 2010 (UTC)
It's OK. Thanks. --Rical (talk) 07:19, 13 December 2010 (UTC)
  • wikEd.programVersion = '0.9.95b'
  • Browser: Chrome 6
  • Error message: Uncaught TypeError: Cannot call method 'replace' of undefined
  • line : 7216

Case of templates only. title is undefined. Please fix this.--Frozen-mikan (talk) 17:11, 17 October 2010 (UTC)

Fixed in wikEd 0.9.95c and wikEdDiff 0.9.13b. Thanks, Cacycle (talk) 22:55, 1 November 2010 (UTC)

[REF] and [TEMPL] hiding

It seems only templates whose name is more than one word are hidden. Is there anyway to hide all templates?--Netheril96 (talk) 14:44, 18 October 2010 (UTC)

Templates are not hidden if they do not have parameters or are shorter than wikEdConfig.templNoHideLength characters. If you set var wikEdConfig = {}; wikEdConfig.templNoHideLength = 0; you would at least hide all templates with parameters. See also User:Cacycle/wikEd customization. There is currently no switch to always hide even short no-paramater templates. Cacycle (talk) 20:36, 19 October 2010 (UTC)
With the newest release 0.9.95c all templates are hidden, independent of their length and number of parameters. Cacycle (talk) 22:54, 1 November 2010 (UTC)
  • wikEd.programVersion = '0.9.95b';
  • in wikEd.DiffLinkify as function
            title = title.replace(/<.*?>/g, '');
            title = title.replace(/^.*>|<.*$/g, '');
            title = title.replace(/^\s+|\s+$/g, '');
+           title = decodeURI(title);
            var url = title.replace(/\s/g, '_');
            url = encodeURI(url);
            url = url.replace(/"/g, '%22');
            url = url.replace(/'/g, '%27');

Now, URL is bad links, and title is encoded string. --Frozen-mikan (talk) 09:37, 20 October 2010 (UTC)

Thanks, I have added this to wikEd 0.9.95c and wikEdDiff 0.9.13b. Cacycle (talk) 22:52, 1 November 2010 (UTC)

Preview to clic twice in fr.wikipedia

  • In wikEd, when I modify a page, one clic on Preview reload the page but before the modification. Another clic reload and show the modification.
  • I try to empty the cache without succes.
  • This happen, for about a week, only in fr.wikipedia, not in en..., not in fr.wikibooks and other,
  • in Firefox 3.6.11 and 3.6.12 and Safari 5.0.2, on iMAC MacOSX 10.6.4 --Rical (talk) 11:00, 30 October 2010 (UTC)
Please see https://bugzilla.wikimedia.org/show_bug.cgi?id=24860 for the filed bug report about this incompatibility. Cacycle (talk) 18:38, 30 October 2010 (UTC)
Fixed in wikEd 0.9.95c, now waiting for the Wikipedia software fix to get live. In the meantime, please disable "Use live preview (requires JavaScript) (experimental)" in your Wikipedia edit preferences. Cacycle (talk) 22:51, 1 November 2010 (UTC)
wikEd or not wikEd, that is the question. I choose it, understand and thank you. --Rical (talk) 10:24, 2 November 2010 (UTC)

Russian Translate

This is translate wikEd in Russian:

--IGW (talk) 13:37, 31 October 2010 (UTC)

Cool, thanks a lot! Cacycle (talk) 22:59, 1 November 2010 (UTC)

Wiked.head.baseURL error

We have our own Wiki and in IE8 i get the following javascript error (in Dutch). In Chrome I don't get the error. The problem is that we have a lot of Wiki readers, who use IE. The editors use Chrome. 

Bericht: 'wikEd.head.baseURI' is leeg of geen object
Regel: 1747
Teken: 2
Code: 0
URI: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd dev.js&action=raw&ctype=text/javascript

What can I do? Ploegvde (talk) 14:14, 3 November 2010 (UTC)

You are using the test version "wikEd_dev.js" that it is outdated and is used for experiments and tests. The correct URL is http://en.wikipedia.org/wiki/User:Cacycle/wikEd.js. The baseURI bug has been fixed a few days ago. Cacycle (talk) 23:56, 3 November 2010 (UTC)

Thanks, problem solved Ploegvde (talk) 11:08, 4 November 2010 (UTC)

Usage of the test version is now indicated through the main logo on top of the page in 0.9.96. Cacycle (talk) 23:32, 6 November 2010 (UTC)

broken on Appropedia

Hi Cacycle,

Something has changed, where we use wikEd on our Appropedia page: http://www.appropedia.org/index.php?title=Wikedbox&action=edit

E.g. if I copy a link on Wikipedia to the Singapore article, "wikify" converts it to: 

title="Singapore" href="http://en.wikipedia.org/wiki/Singapore" _moz_dirty="",

I think the best option for us is probably to directly copy the code from an older version that worked, and hack it to show the wikify button and as little else as possible (since that's all we use it for, on that page). I'll look at this later when I have time - if you have any tips, they're very welcome.

Thanks --Chriswaterguy talk 05:44, 4 November 2010 (UTC)

Looks easy to fix for me, I will check later. Cacycle (talk) 09:15, 4 November 2010 (UTC)
Fixed in 0.9.96. Sorry, Cacycle (talk) 23:30, 6 November 2010 (UTC)
Thanks. It seems to handle links fine now, but has trouble with other formatting, such as headings and indents. I've had trouble finding the exact pattern, and when it's triggered, but the most common thing is that if I select a section including a header or maybe an indent and click wikify, it hangs, until I get a browser alert about an unresponsive script, which lets me stop it running.
For cases where it works - I've noticed bold and links - the conversion is almost instant, and there is no problem.
I tried both in the Appropedia page and on Wikimedia (using the .js page in userspace, not the gadget). Thanks. --Chriswaterguy talk 08:05, 11 November 2010 (UTC)


In order to fixthis I need to replicate the problem. Please could you find me an article and the exact text fragment (still in the clipboard after a crash) that crashes the script? Thanks in advance, Cacycle (talk) 09:14, 13 November 2010 (UTC)
I've been looking at this again - I seem to be getting it mixed up with the "#Firefox 4 clash?" issue, above. The lack of a consistent pattern that I can make out has been confusing. I'll comment again in that section. --Chriswaterguy talk 16:29, 3 December 2010 (UTC)

wikEd entirely gone

Safari 5.0.2 (6533.18.5) – wikEd just doesn't show up at all anymore, it's on in my preferences, I purged the website a couple of times, but wikEd doesn't show up anymore. Xeworlebi (talk) 09:48, 10 November 2010 (UTC)

Oops, should be fixed in 0.9.96a. Sorry, Cacycle (talk) 22:03, 10 November 2010 (UTC)
  • My browser is Google Chrome 8.0.552.200 (auto-updated). I use wikEd on FFXIclopedia with the On-wiki Complete method. Yesterday, wikEd disappeared -- along with the regular edit bar. All I had left was the edit box. Today, the standard editing tools reappeared, but wikEd has not.
    I double-checked that my monobook.js is still intact, and it is. I also inspected the page with Google Chrome (Developer Tools). The script tag is being rendered, and the loaded source shows a version of 0.9.96a. The only error in the Console is for a Wikia JS in the restoreWatchlistLink function..
    I can't pinpoint anything that would stop yours. Any ideas? AbbydonKrafts (talk) 14:57, 18 November 2010 (UTC)
Happening to me too (Firefox, on es.pokemon.wikia.com). I think I know what the problem is. Debugging the code it reaches line 1888 (wikEd.AddEventListener(window, 'load', wikEd.Setup, false);) but wikEd.Setup is never called. Calling wikEd.Setup() manually initializes wikEd correctly. This could happen because wikEd.AddEventListener relies on the browser event handling, and maybe when this line is reached the page was already loaded, so the load event isn't fired again. You probably have to detect if the load is complete and fire the functions that you want to attach to the window.load inmediately, maybe having a separate function to add events to the window.load that would do this special check. --Ciencia Al Poder (talk) 20:42, 20 November 2010 (UTC)
I will check into this as soon as I find some time (probably later this week - sorry). Cacycle (talk) 07:28, 22 November 2010 (UTC)
I don't know why, but now it's working for me... Before writing here I did several reloads of the cache and didn't work. --Ciencia Al Poder (talk) 21:30, 22 November 2010 (UTC) (I forgot to login)
I also was missing wikEd on Wikia for a few days, but it's working for me now. I think it was a Wikia issue and not a wikEd issue, as there were a couple of other JS things that stopped working at the same time as wikEd and were fixed at the same time wikEd started working again. 99.139.146.60 (talk) 01:03, 23 November 2010 (UTC)
  • It is also working for me now. I have to agree that the problem with the Wikia scripts was halting the wikEd script. Perhaps there is a way to get wikEd to work even if an unrelated script bombs out? AbbydonKrafts (talk) 14:17, 23 November 2010 (UTC)
The next release would have loaded on Wikia (at least with Firefox 3.6)... Cacycle (talk) 22:58, 24 November 2010 (UTC)

Automatically highlighting text matching predefined string

With my dabfix tool it would be incredibly useful to highlight what text was added by machine. The text strings are already stored to do automatic removal. Is there a quick way of implementing this (i.e. I don't feel like reading threw your parser code)? — Dispenser 04:55, 24 November 2010 (UTC)

Please could you explain a bit more what you are trying to accomplish? I am not sure if I understand how a wikicode parser could help highlighting text added by a tool. Do you want general syntax highlighting? Do you have links to the dabfix tool and its help page? Thanks, Cacycle (talk) 22:48, 24 November 2010 (UTC)
Dabfix is a Toolserver tool with WikEd integration for improving disambiguation pages. It adds a description to the entry which needs to be copy edited by a human. Sometimes it is hard to tell which to copy edit with a large number of entries. So I would like WikEd to highlight the added text as shown below:
*[[Cirrus (rocket)]], a German sounding rocket
You can try the tool on William Fowler to get an idea of what it does and how well WikEd integrates into it. — Dispenser 05:09, 25 November 2010 (UTC)
I have added support for keeping html code in version 0.9.97, just use span, div, ins, or del tags with an id, name, or class name starting with "wikEdKeep". See the following code for how to add your highlighted text to the wikEd edit area. Please feel free to ask here if you have any questions.
// style the wikEdKeep class in edit box
wikEd = { config: { frameCSS: { '.custom1': 'background:red;' } } };

// get original text
var html = wikEd.textarea.value;
html = html.replace(/&/g, '&amp;').replace(/>/g, '&gt;').replace(/</g, '&lt;');

// add your insertions here in span, div, ins, or del tags with id, name, or class starting with "wikEdKeep"
html = html + '<ins class="wikEdKeep custom1">insertion</ins>';

// save text
if (wikEd.useWikEd == true) {
    wikEd.UpdateFrame(html);
}
else {
    wikEd.UpdateTextarea(html.replace(/\n/g, '<br/>'));
}
Cacycle (talk) 00:53, 28 November 2010 (UTC)
One small problem UpdateTextarea(html) removes the newlines in Firefox and Chrome when using the regular textarea. You can try it out on the Fowler page above. — Dispenser 04:01, 19 December 2010 (UTC)
Have you tried to replace newlines with <br>? If that doesn't help, please give me a detailed and stepwise description so that I can try to replicate the problem. Cacycle (talk) 22:37, 19 December 2010 (UTC)
Yes that did the trick. I've updated the sample code above to include it. — Dispenser 04:50, 23 December 2010 (UTC)

Disable on Personal Level

Hello Cacycle,

I am an administrator of a wiki where WikiEd is enabled wiki wide using [[MediaWiki:Common.js]], but as an experienced user, WikiEd only annoys me. I have disabled it using the logo next to the log out button, but it randomly decides to enable itself, which is annoying. Is there any way to disable it on a personal level using [[User:MyName/vector.js]]? I also know of at least on other admin who would like to do this. Thanks! Multiple Protection LevelsTalk 10:51, 24 November 2010 (UTC)

You can add var wikEdConfig = { 'scrollToEdituseWikEdPreset': true }; to your vector.js page. That sets the default state after the settings cookie has been lost to disabled. You will still be able to enable wikEd with a logo click if you wish so. Hope that helps, Cacycle (talk) 22:33, 24 November 2010 (UTC)
Oops, typo - see correction above. Cacycle (talk) 21:24, 29 November 2010 (UTC)

wikEd does not stay off when turned off

Sometimes I turn off wikEd by clicking the button at the top right corner of the page. However, the next time I edit a page, it turns itself on again. I am using version 0.9.96a of wikEd in Google Chrome 7.0.517.44. I have no add-ons installed, nor any user-scripts that might be interfering with wikEd. Intelligentsium 23:08, 25 November 2010 (UTC)

That might be a problem with the persistence or detection of web storage and/or cookies. I will check into it. Cacycle (talk) 08:00, 29 November 2010 (UTC)

Callback on preview

(Moved from User_talk:Cacycle/wikEd_development. Cacycle (talk) 22:33, 27 November 2010 (UTC))

Does wikEd support a callback mechanism such that I can execute custom scripts when the "preview below" is activated? Thanks, Nageh (talk) 11:42, 23 November 2010 (UTC)

Not yet, but I could add it. What do you want to accomplish? Should it fire before or after the preview has finished? Cacycle (talk) 23:00, 24 November 2010 (UTC)
Thanks for the reply. Ideally, it would fire after processing so custom scripts can go through the newly added text. What do you think would be a good way to implement this? I was thinking of registering on a callback chain a function that takes a single argument, which would be the newly added DOM wiki text element (wikEdBox, I think). Nageh (talk) 10:12, 28 November 2010 (UTC)
Please see wikEd API, I will probably add the last two event hooks to the next release. What exactly do you want to do with them? Cacycle (talk) 22:45, 28 November 2010 (UTC)
I was looking for an easy way to render maths elements in the wikEd preview box instead of going DOM level 2 event programming for my MathJax port. (See discussion here.) Thanks to the new hook it was easy enough to do this. Thanks a lot! Nageh (talk) 16:46, 2 December 2010 (UTC)

Update to install code

Hi, it me again, this time with an updated install code: 

// install [[wikipedia:User:Cacycle/wikEd]] in-browser text editor
importScriptURI("http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:Cacycle/wikEd.js");

This will look, and hopefully work, much better as the non-DOM version "as-is-now"...
PS: I already use this on wikia and it seems to work with no problem on FF4.0b7
⇐⇑©TriMoon™ Talk @ 00:08, 28 November 2010 (UTC)

Yupp, that works fine. Actually, it does *exactly* the same as the long code, importScriptURI generates the long code internally for you. The reason for the long version is that not all wiki installations have the importScriptURI function implemented. Cacycle (talk) 00:57, 28 November 2010 (UTC)

Having to disable/enable greasemonkey

I have this really weird issue where I get a red cross over the icon in the top right this not letting me edit pages unless I disable the script by clicking the icon in the top right then disable grease monkey, then reload the page, enable grease monkey and reload again and then enable the wikEd. I had no problems until it prompted me to update a few hours ago. --salle —Preceding unsigned comment added by 80.217.241.142 (talk) 00:43, 29 November 2010 (UTC)

It might be fixed now, to bypass old copies in the cache, please open this link with GM enabled: [14]. Sorry, Cacycle (talk) 07:52, 29 November 2010 (UTC)
It does not work in some cases, I have to check this later. Cacycle (talk) 08:03, 29 November 2010 (UTC)
Fixed in 0.9.97a, open [15] to update. Cacycle (talk) 22:37, 29 November 2010 (UTC)

Updating image template

When I use the image button, it generates this code:
[[Image:filename|thumb|widthpx| ]]

I always have to add <br style="clear:both" /> at the end so text wraps correctly. Is it possible to add this to the emplate so clicking on the image buttons generates this:
[[Image:filename|thumb|widthpx| ]]<br style="clear:both" />
Is this something I can do myself in my own wiki (I have one with siteground)?

Better yet, it would replace filename with the most recent image that was uploaded.
Scott216 (talk) 22:12, 29 November 2010 (UTC)

You can add your own custom buttons, please see User:Cacycle/wikEd_customization#Custom_buttons. The last image uploaded idea is interesting, but probably too difficult to implement. Cacycle (talk) 21:55, 8 December 2010 (UTC)

Croatian translation

Here you can find translation of wikEd in Croatian language:

Good job with wikEd! SpeedyGonsales (talk) 13:25, 11 December 2010 (UTC)

Great, thanks! I have added it to the next release. Cacycle (talk) 07:30, 15 December 2010 (UTC)

WikEd inline preview container should be inserted outside edit form

WikEd inline preview container should be inserted outside edit form, because some MediaWiki extensions insert HTML forms onto the page, and when inline preview is loaded, these forms are inserted into editform, which causes different bugs, i.e. extension could handle the submmited editform like its own form and discard text changes.

I propose inserting wikEd.localPrevWrapper after editform.

The one problem here is that preview block goes below edittools, templatesUsed and hiddencats, which is not just after textarea. So I think wikEd could also move templatesUsed and hiddencats after editform.

VitaliyFilippov (talk) 15:19, 14 December 2010 (UTC)

Moving the original page elements around could also cause havoc. Maybe it is easier to fix the extension. Please could you give me the name of the incompatible extension(s) and an example wiki / page with the problems so that I can get a better idea of what exactly is happening? Thanks, Cacycle (talk) 07:36, 15 December 2010 (UTC)

Opera

Do you think making WikEd compatible with Opera? I like these two very much but isn't usefull to switch to Firefox every time when I use Wikipedia.Aku506 (talk) 18:40, 26 December 2010 (UTC)

In general, wikEd is compatible with Opera, it is just that the last time I checked, Opera had some nasty bugs. I will check again next year, maybe they have fixed some bugs (nobody can know because they have no public bug tracking system %@#) or I can find some new workarounds. Cacycle (talk) 21:36, 26 December 2010 (UTC)
that would be rally cool. thanks for u're work =) greetings Shadak (talk) 15:12, 27 December 2010 (UTC)

WikEd not displaying in FireFox

At some point in the fall of 2010 WikEd stopped displaying for me when using Firefox 3.6.xx. I have not changed my preferences, in fact, it is still selected as an option in my preferences. WikEd shows up fine in Chrome but not at all in IE. How do I get it working in FF? (And did something happen external to my account that caused it stop working?) -- btphelps (talk) (contribs) 01:20, 5 January 2011 (UTC)

Are you using the monobook or the vector skin? (BTW, there is a missing semicolon after line 10 in your monobook.js). Are you seeing a wikEd icon on top of the page next to the logout link? Are you trying to load via monobook.js or via Wikipedia preferences as a gadget? Please could you fill out a complete bug report form from the top? Thanks, Cacycle (talk) 09:47, 5 January 2011 (UTC)
Fixed the missing semicolon, thanks. I am not seeing a WikEd icon at the top of the page next to the logout link. For a screen shot of what my editing page looks like, see here. I am trying to load WikEd via monobook.js. I'd be happy to fill out a bug report. How do I do that? -- btphelps (talk) (contribs) 04:30, 7 January 2011 (UTC)
Please check wikEd help; pushing the Use wikEd button right above the edit area turns wikEd on :-) Cacycle (talk) 02:33, 8 January 2011 (UTC)
Ah! Duh! <forhead slap> -- btphelps (talk) (contribs) 04:54, 11 January 2011 (UTC)

Hi

It seems the "Cite" drop down has disappeared - any reason for this ?

It used to say "advanced" "Special characters" "XX" "Cite"

Chaosdruid (talk) 00:23, 10 January 2011 (UTC)

Fixed Chaosdruid (talk) 00:52, 10 January 2011 (UTC)

wikEd Compatibility

Hello Cacycle,

Thank you for developing and maintaining wikEd. I am currently planning on using it with a wiki for my team at work and there are strict rules in place regarding programs and browsers that are in use.

Is there any way that I can get the "wikify" button to work on the latest IE? I highly agree that IE is far from the recommended, but that is outside of my hands.

Specs:

  • IE 8.0.6
  • mediaWiki software
  • Monobook probably

Thank you for your time,
Andrew. — Preceding unsigned comment added by AndrewM90 (talk • contribs) 14:57, 10 January 2011 (UTC)

Hi Andrew, I am sorry, there is no way to get wikEd working under IE 8. It might be possible with version 9, but I cannot test or develop for that because it requires Windows 7 @#$!. Somebody could also invest a few days of programming to dissect out the wikify logic which should run under IE (the incompatible parts are related to the selection model (needed for grabbing and inserting text into the edit area) and, as I just noticed, to events). The easiest solution would probably be to ask for a special permit to run Firefox. Sorry, Cacycle (talk) 23:57, 12 January 2011 (UTC)

Wikia's new skin

After only playing with WikiEd for a little bit I can see that it will be very useful the highlighting is superb. My only gripe is that it has not been updated for the new Wikia skin so I have to switch to monobook to use it. Thank you for creating and developing this great code and I hope to see it working under the new Wikia skin soon. (Awesome3000 on Wikia)125.237.165.60 (talk) 08:34, 17 January 2011 (UTC)

I will try to adapt wikEd to the new skin, might take a few days, though. Cacycle (talk) 07:42, 21 January 2011 (UTC)
No rush at all. Good luck with the coding. 222.155.206.208 (talk) 07:47, 21 January 2011 (UTC)

Problems with Firefox 4

I had to disable wikEd because of some problems that it had in Firefox 4 beta 9. First of all, the script takes by far the longest time to load, on any page. When a page is loaded, it still says "Waiting for en.wikipeida.org" so I began wondering what was taking so long. Then I noticed that the wikEd icon in the top-right corner had not appeared yet, and only shows up when the page finishes loading. Secondly, I usually have wikEd disabled (by clicking on the wikEd logo), but every once in a while it will reactivate itself and so I have to disable it again. I didn't have these problems in Firefox 3.6. Gary King (talk · scripts) 02:02, 26 January 2011 (UTC)

Current wikEd doesn't work for me in Chrome on Mac

Cacycle, hats off to you for such a useful tool! But I'm stuck and hope you can help me: I was earlier using wikEd 0.9.91j (from July 22, 2010) in Firefox 3.6.13 on Mac and it worked fine across all wikis I noticed. I upgraded to the newest one 0.9.97a ("Last update Nov 29, 2010") and it seems to work in Firefox (it didn't at first but I kept refreshing), yet doesn't show up for me in Chrome (9.0.597.84 beta). Across all wikis, it gives me deformed, small text areas like this and that.

So I decided to downgrade to the older 0.9.91j in Chrome to see what would happen.

More strangeness: in Chrome on the lindenlab.com company internal wiki (MediaWiki 1.14.1) that's connected to the web, wikEd doesn't appear. However, wikEd still works on the public http://wiki.secondlife.com (MediaWiki 1.15.5), but ONLY if all lindenlab.com wiki tabs are closed. Otherwise, having a tab with the lindenlab.com wiki editor open makes wikEd disappear on all open tabs that have a working wikEd (after refreshing them) and it seems I have to close the lindenlab.com wiki tab, restart Chrome, and refresh the wiki.secondlife.com tab for wikEd to come back. This earlier confused me into thinking that wikEd wasn't working at all. Furthermore, I disabled the FCKeditor in the lindenlab.com wiki preferences and that didn't bring back wikEd.

I wonder what factor is "breaking" it? The lindenlab.com wiki does use the FCKeditor extension, so I wonder if that in some way is wreaking havoc? Strange that an earlier version played fine with it though in Firefox, but not Chrome.

To sum up in Chrome: older 0.9.91j works partially. 0.9.97a doesn't work for me at all, and gives the deformed text areas I reported above.

Thanks in advance for your help. Torley (talk) 16:18, 7 February 2011 (UTC)

I cannot login into these sites to trouble shoot this problems - would you mind emailing me a username/password? Also, in order to replicate this, please could you fill out a structured bug report (see the top of this page)? Thanks in advance, Cacycle (talk) 08:28, 9 February 2011 (UTC)

Redirects in galleries

I am working on cleaning up issues where an image was renamed and a redirect created, but the article was not updated. The Fix redirect button works great unless the image is enclosed within a <gallery> tag. ---— Gadget850 (Ed) talk 16:11, 15 February 2011 (UTC)

I cannot replicate this. Please could you give me a link to an article version where it does not work? Thanks, Cacycle (talk) 20:50, 16 February 2011 (UTC)

wikED broken for mediawiki 1.17wmf1?

Hi, wikipedia recently upgraded to mediawiki 1.17wmf1. On LI wiki (my home wiki) gadgets are not enabled, so I enable WikED by including it in vector.js. It however doesn't seem to load anymore. Is there a fix for this? - Pahles (talk) 15:04, 16 February 2011 (UTC)

It looks like gadgets have been disabled on your wiki. Please use the On-wiki installation code (complete version) on your li:User_talk:Pahles/vector.js page. This works for me. Good luck, Cacycle (talk) 20:40, 16 February 2011 (UTC)
I've found the problem. There was a javascript error in my personal common.js, preventing wikED to load. Strange thing is this javascript was there since 2009, and I did not have a problem before the switch to mediawiki 1.17wmf1. Anyway, it is working now! Sorry to have bothered you. - Pahles (talk) 09:50, 17 February 2011 (UTC)

refToolbarPlus Compatibility

Please add a link to Wikipedia_talk:RefToolbar_1.0#wikEd_compatibility under the compatible scripts section of the project page. If User:Apoc2400 picks up the change in the gadget version, a link to the gadget can then be substituted. However, User:Apoc2400 hasn't been active recently so I don't know when this might happen. —UncleDouggie (talk) 07:51, 18 February 2011 (UTC)

Convert the png buttons to svg?

I love WikiEd, but one thing I notice is that the buttons are very ugly and pixelated. Any way to make them into .svg? We could ask the Graphic Lab to create the icons if needed. Headbomb {talk / contribs / physics / books} 22:22, 18 February 2011 (UTC)

Yes, svg would be nice, but there would be a lot of work involved. It would be great if sombody would help out with this, and I would gladly support that project as good as I can. Cacycle (talk) 01:05, 20 February 2011 (UTC)
Well if you give me a list of the files, that would probably all that is needed to kickstart things. Headbomb {talk / contribs / physics / books} 01:39, 20 February 2011 (UTC)
They're all in commons:Category:WikEd. And speaking of buttons, could we perhaps rearrange and remove some of them. — Dispenser 04:31, 20 February 2011 (UTC)

Well here's a list of what currently exists (minus screenshots and gifs). Cacycle can remove what is uneeded for conversion, and then it would be off to the Graphic Lab. Headbomb {talk / contribs / physics / books} 04:49, 20 February 2011 (UTC)

PNG SVG
  1. File:WikEd ajax preview.svg
  2. File:WikEd align buttons.svg
  3. File:WikEd align down.svg
  4. File:WikEd align preview down.svg
  5. File:WikEd align preview.svg
  6. File:WikEd align top.svg
  7. File:WikEd bar dash.svg
  8. File:WikEd blank.svg
  9. File:WikEd bold.svg
  10. File:WikEd bullet list.svg
  11. File:WikEd buttonbar collapsed.svg
  12. File:WikEd buttonbar expanded.svg
  13. File:WikEd case sensitive.svg
  14. File:WikEd case.svg
  15. File:WikEd classic.svg
  16. File:WikEd clear find.svg
  17. File:WikEd clear history.svg
  18. File:WikEd clear summary.svg
  19. File:WikEd close toolbar.svg
  20. File:WikEd close.svg
  21. File:WikEd combo input.svg
  22. File:WikEd ctrl.svg
  23. File:WikEd decrease heading.svg
  24. File:WikEd definition list.svg
  25. File:WikEd diff.svg
  26. File:WikEd disabled.svg
  27. File:WikEd dummy.svg
  28. File:WikEd em dash.svg
  29. File:WikEd em space.svg
  30. File:WikEd en dash.svg
  31. File:WikEd en space.svg
  32. File:WikEd error.svg
  33. File:WikEd figure dash.svg
  34. File:WikEd find ahead.svg
  35. File:WikEd find all.svg
  36. File:WikEd find next.svg
  37. File:WikEd find prev.svg
  38. File:WikEd fix all.svg
  39. File:WikEd fix basic.svg
  40. File:WikEd fix caps.svg
  41. File:WikEd fix chars.svg
  42. File:WikEd fix chem.svg
  43. File:WikEd fix dash.svg
  45. File:WikEd fix math.svg
  46. File:WikEd fix pipes.svg
  47. File:WikEd fix punct.svg
  48. File:WikEd fix redirect.svg
  49. File:WikEd fix reg-ex-typo.svg
  50. File:WikEd fix unicode.svg
  51. File:WikEd fix units.svg
  52. File:WikEd font size.svg
  53. File:WikEd fullscreen.svg
  54. File:WikEd get selection both.svg
  55. File:WikEd get selection.svg
  56. File:WikEd grip.svg
  57. File:WikEd heading.svg
  58. File:WikEd ideographic space.svg
  59. File:WikEd image.svg
  60. File:WikEd increase heading.svg
  61. File:WikEd indent list.svg
  62. File:WikEd italic.svg
  63. File:WikEd jump next.svg
  64. File:WikEd jump prev.svg
  65. File:WikEd jump top bottom.svg
  67. File:WikEd logo32x32.svg
  68. File:WikEd logo39x40.svg
  69. File:WikEd logo64x64.svg
  70. File:WikEd minus dash.svg
  71. File:WikEd no file.svg
  72. File:WikEd nowiki.svg
  73. File:WikEd number list.svg
  74. File:WikEd preview.svg
  75. File:WikEd redirect-mk.svg
  76. File:WikEd redirect.svg
  77. File:WikEd redo all.svg
  78. File:WikEd redo.svg
  79. File:WikEd ref hide.svg
  80. File:WikEd ref.svg
  81. File:WikEd references.svg
  82. File:WikEd regexp.svg
  83. File:WikEd replace all.svg
  84. File:WikEd replace next.svg
  85. File:WikEd replace prev.svg
  86. File:WikEd resize grip.svg
  87. File:WikEd soft hyphen.svg
  88. File:WikEd sort.svg
  89. File:WikEd source.svg
  90. File:WikEd strikethrough.svg
  91. File:WikEd subscript.svg
  92. File:WikEd superscript.svg
  93. File:WikEd syntax.svg
  94. File:WikEd tab.svg
  95. File:WikEd table edit.svg
  96. File:WikEd table.svg
  97. File:WikEd textify buttonbar.svg
  98. File:WikEd textify.svg
  99. File:WikEd thin space.svg
  100. File:WikEd underline.svg
  101. File:WikEd undo all.svg
  102. File:WikEd undo.svg
  103. File:WikEd unknown.svg
  104. File:WikEd using.svg
  105. File:WikEd weblink.svg
  106. File:WikEd wikify.svg
  107. File:WikEd wikilink.svg
  108. File:WikEdCnt.svg
  109. File:WikEdDiff.svg
  110. File:WikEdF&RButt.svg
  111. File:WikEdFixButt.svg
  112. File:WikEdFormButt.svg
  113. File:WikEdPrvChg.svg
  114. File:WikEdSubmitButt.svg

Poke? Headbomb {talk / contribs / physics / books} 02:24, 22 June 2011 (UTC)

localstorage memory issue? WikEd not loading after find/replace in a big article

Hi, I tried translating 2010 Indian Premier League into ta:User:Mahir78/2010 இந்தியன் பிரீமியர் லீக் using a js tool. Everything went fine. But at one stage if try to find/replace words i get this error. is there any memory issue in localstorage? please add try catch at line 14347. Let me try and give u feedback. After this error happen WikEd never loaded into my user area in both enwiki and tawiki. In enwiki also shows this error and not loaded, but the error initiated while editing in tawiki. I use FF3.6.14 and vista home.

uncaught exception: [Exception... "Component returned failure code: 0x80630002 [nsIDOMStorage.getItem]" nsresult: "0x80630002 (<unknown>)" location: "JS frame :: http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript :: anonymous :: line 14347" data: no] — Mahir78 (talk) 11:06, 4 March 2011 (UTC)

Wgat happens if you delete content in Tools - Options - Advanced - Network - Offline Storage? Cacycle (talk) 07:36, 11 March 2011 (UTC)

MS Word to Wiki Conversion Freezes

WikEd versin: 0.9.98 Browser: Google Chrome 10.0.648.127 errors: None, other than the browser asking if I want to kill a frozen script Add-Ons: Flashblock (with this page whitelisted), adblock, personal blocklist, sexy undo close tab, google speed tracer, web developer Wikipedia beta: no User scripts: None OS: OSX 10.6.6 Theme: Classic Description: When I paste content from Microsoft Word or Textedit into WikEd running on Chrome or Firefox and then click the MS Word->Wiki button, it stalls and after a while tells me that the script is unresponsive.

When debugging, I can see that the loop in the code never gets past: 

while ( (regExpMatch = /(\w+)\s*=\s*(('|")(.*?)\3|(\w+))/g.exec(attributes)) != null) {

With local vars of: attrib: "class" attribValue: "MsoNormal" attributes: "class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto; mso-outline-level:1"" common: "dir" regExpMatch: Array[6] relaxed: false sanitized: "" table: "|border|cellspacing|cellpadding|align|bgcolor" tablealign: "|align|valign" tablecell: "|rowspan|colspan|nowrap|bgcolor" tag: "p" this: Object valid: false


As far as I can tell, it never modifies the attributes or breaks out of the loop, so there is no way this loop could ever end. —Preceding unsigned comment added by 173.161.6.33 (talk) 17:53, 8 March 2011 (UTC)

That is strange, it works fine for me, even with the provided values. Also, I do not see a reason why the loop would ever run more than a few times: It works its way through the attributes string till the end, then exec return null, and the loop terminates. Maybe something else is broken. Can you find a test case so that I can exactly repeaqt your problem? Also, it might help if you fill out the bug report form from the top of this page. Thanks in advance, Cacycle (talk) 07:58, 10 March 2011 (UTC)

New script to view references rendered in section?

Any chance that the feature that wikEd provides which previews a section and shows the references in it rendered in the preview page, could be split off into its own script for those of us that only want to install that feature? wikEdDiff is great, for instance, and this would be, too. Thanks in advance! Gary King (talk · scripts) 05:27, 14 March 2011 (UTC)

There is User:Anomie/ajaxpreview.js that takes extra care of the references when editing a section: if it finds a <ref name="xxx" /> which is defined in other section it will pull the whole article from the server, find that ref and still display it properly in the preview. If you don't care that much about refs then there is also my script User:Js/ajaxPreview which simply inserts <references /> like WikEd but has some other features: Ajax "changes" button, preview of edit summary and other areas, executing sortable and collapsible scripts on the preview, etc. — AlexSm 21:51, 15 March 2011 (UTC)
Thanks, I'll try the former first. I copied it and modified it because the spinner immediately annoyed me when I first used it. I think either static "Loading" text or at least slower animation (1000+ ms rather than 250 ms) should be better. Gary King (talk · scripts) 18:02, 16 March 2011 (UTC)

Replace buttons by menus?

I think it would improve usability if the tool bars (except maybe the replace tool bar) are replaced by menus. The biggest advantage is that the function descriptions would be obvious without having to hover over the mouse the buttons. Some of the button icons are difficult to memorize simply because the concepts they represent appear only in wikEd. Another advantage is that the controls would take up less space in the browser window. Yes, it is possible to collapse the tool bars, but they still take up the same amount of vertical space. Also, then you have to remember which collapsed tool bar holds which buttons, because the collapsed tool bars are not labeled. -Pgan002 (talk) 08:04, 17 March 2011 (UTC)

Yes, that'd be great idea! :) I love wikEd but that's a bit weird, that bars are collapsible vertically so that there's no space spared for other uses... :l Vinne2 (talk) 18:51, 13 August 2011 (UTC)

wikEd always on, problem with Safari+quick-preview

  • These days, wikEd's editing formatting is always on, I have to turn in off every-time I edit a page due to the WebKit issue of magically added enters. This quit bothersome, it didn't used to do this.
  • The quick-preview doesn't work fully in Safari (5.0.3 (6533.19.4)), it shows, but templates stay as text formatted, in Chrome it takes a second and then they also get the correct formatting, in Safari they just stay as the text as you typed it. Signatures (~~~~), don't format as eventually shown but just gives the basic formatting (for me it looks like "Xeworlebi 14:53, 18 Mar 2011 (UTC)", in quick preview, instead of the way it eventually turns out as you can see at the end of this message. Making the feature quite useless in a lot of cases.
  • var wikEdDoCloneWarnings = false doesn't work anymore, edit-notices still show up twice. Xeworlebi (talk) 14:59, 18 March 2011 (UTC)
Cacycle: I think I can explain the Safari issue which I tracked to this explanation when I had to fix my own script; all you have to do is replace
headers['Content-Type'] = 'multipart/form-data; boundary=' + boundary;
with
headers['Content-Type'] = 'multipart/form-data; charset=UTF-8; boundary=' + boundary;
Or you could switch from using index.php to api.php which requires even less code; I can show you the code if you're interested. — AlexSm 15:48, 18 March 2011 (UTC)
Xeworlebi: what do you mean by " WebKit issue of magically added enters."? There are problems with cookie/web storage that probably cause these problems. I am already working on it, but it may take a while due to real life commitments and another programming project I am working on.
Alex: Thanks, I will try to add that.
Xeworlebi: Please see the new syntax for configuration settings under [User:Cacycle/wikEd customization]. Essentially, you now have to use var wikEdConfig = { 'doCloneWarnings': false }; Cacycle (talk) 16:09, 18 March 2011 (UTC)
Ah, thanks. And this Webkit "bug". Xeworlebi (talk) 21:00, 19 March 2011 (UTC)
The charset=UTF-8 fix has been added to 0.9.99. Thanks, Cacycle (talk) 21:45, 8 May 2011 (UTC)

Not working in Vector

I tried to paste the text from monobook.js into vector.js and got a load error. Now when I am in Vector Wikipedia won't let me edit any pages at all. Could someone please help me? (In the meantime I'm using MonoBook.) Someone the Person (talk) 18:40, 27 March 2011 (UTC)

Scratch that, it doesn't work in any skin. My best guess is that the regular edit box is being updated, and this is messing up wikiEd somehow. The only way I can get it to work is to reload the page with wikiEd off, and then turn it on, which it wasn't letting me do before... Someone the Person (talk) 18:49, 27 March 2011 (UTC)
It works fine for me... Please could you fill out the bug report form from the top of this page? Does it give an error message popup on hovering over the logo on top of the page? Are there wikEd-related JavaScript console errors? Thanks in advance, Cacycle (talk) 20:05, 28 March 2011 (UTC)

How to set default font size

The font size in WikEd edit area are too large and I have to cycle two times whenever I open a new editing form. I don't want to adjust the browser zoom level because that will shrink the font in preview and reading area. What is the option of default zoom level?--Netheril96 (talk) 01:09, 2 April 2011 (UTC)

What browser are you using? Is the browser zoom set to 100 %? Have you used wikEd's zoom button (Text zoom)? Cacycle (talk) 21:41, 8 May 2011 (UTC)

Firefox 4 Preview Problem

  • Windows 7 x64 and Windows XP x86 SP 3
  • Firefox 4.0 Final
  • Greasemonkey 0.9.1/0.9.2

Since the Firefox 4 Final Release its not possible to use the wiked preview function. Instead of the preview content it shows "..." in the preview window. Can you confirm this issue? Legend811510 (talk) 08:27, 2 April 2011 (UTC)

It works fine for me. —UncleDouggie (talk) 00:06, 5 April 2011 (UTC)
Hmm ok i've made some ​​tests: A fresh new windows xp x86 machine, install firefox 4.0, greasemonkey 0.9.1 and latest wiked script - same problem, no preview, still "..." in the result! An other fresh new windows xp x86 machine, install latest firefox 3 (3.6.16) version, greasemonkey 0.9.1 and latest wiked script - no problem with the preview, the output is correct. Mysterious ^^ Legend811510 (talk) 16:52, 10 April 2011 (UTC)
Any JavaScript console errors? Please see the top of this page for the bug report form, it contains some important questions in order to figure this out. Cacycle (talk) 06:55, 13 April 2011 (UTC)
ok sorry i understand what u mean. I followed the steps and here the result:
→ Wiked Version: 0.9.98 GM
→ Brower ID: Mozilla/5.0, Windows NT 5.1 rv 2.0 Gecko/20100101 Firefox/4.0 (from the xp machine)
→ Error Console: (one warning message only) Warning: Expected end of value but found ':'. Error in parsing value for 'float'. Declaration dropped. Source File: (wiki link), Line: 83 (internal and offical wiki page, both the same warning)
→ Browser Addons: Greasmonkey 0.9.2, Java Console 6.0.23, Java Quick Starter 1.0
→ Wiki Skin: standard
→ Special User Scripts: none
→ Operating System: Windows 7 x64 SP 1 and Windows XP x86 SP 3 (both the same problem)
hope this is what u need to figure out the problem Legend811510 (talk) 08:40, 13 April 2011 (UTC)
I'm getting the same thing (no JS preview), firefox 4, 9.98 GM, using Monobook at Wikia.com, but it works fine when editing at Wikipedia. I got this error in firebug's console:
functionsHook is undefined

for (var i = 0; i < functionsHook.length; i ++) {
RandomTime 15:13, 18 April 2011 (UTC)
Might be fixed with 0.9.99. Please could you check and report back? Thanks, Cacycle (talk) 21:42, 8 May 2011 (UTC)

Compatible scripts

Could someone change 

* Lupin Navigation popups
* AzaToth Twinkle

to 

* Lupin
* Navigation popups
* AzaToth
* Twinkle

unless it is wrong to (in which event I'd appreciate to know why). Thanks. kcylsnavS{screechharrass} 23:44, 4 April 2011 (UTC)

Lupin and AzaToth are (were) the (original) authors of these tools. I have removed their names. Cacycle (talk) 17:04, 8 May 2011 (UTC)

Remove some maths characters

I believe the support of some maths characters is so bad that they should not be be offered in the menu 'Math and logic'. The ones I think should be removed are the blackboard bold symbols because they look so dreadful with the default of Times Roman going to MS Mincho on IE, and the angle brackets which are not supported with the default on IE. The other browsers do them fine so it is yet again Microsoft causing problems. To try them out yourself I'll list the characters here: standard non-serif ℂ ℍ ℕ ℙ ℚ ℝ ℤ ⟨ ⟩ serif using {{math}} ℂ ℍ ℕ ℙ ℚ ℝ ℤ ⟨ ⟩. Dmcq (talk) 10:06, 5 April 2011 (UTC)

That function is not provided by wikEd, that is the standard toolbar. Cacycle (talk) 07:09, 6 April 2011 (UTC)
Thanks, okay I better have a look for that then. Dmcq (talk) 08:10, 6 April 2011 (UTC)

Reference expansion distracting?

Currently, if a user hovers over a hidden reference or template, it immediately expands. In my experience, hovering happens too easily by accident and the expanded reference is distracting. I find myself being careful not to move the mouse over a hidden reference. What do you think about showing a tool tip on hover but showing the reference if the hidden reference is clicked. It's a button anyway. -Pgan002 (talk) 22:18, 13 April 2011 (UTC)

I have added a customization option that unhides only when the shift or ctrl key is pressed at the same time. You can test it by adding var wikEdConfig = {}; wikEdConfig.unhideShift = true; to your vector.js page (please see also User:Cacycle/wikEd_customization). What do you think? Cacycle (talk) 21:36, 8 May 2011 (UTC)
Thank you. It sounds good, though it does not seem to work for me. I will investigate what I'm doing wrong. -Pgan002 (talk) 08:09, 14 May 2011 (UTC)

Script does not respond

Hi ! This message appears after a few minutes using WikEd :

The script doesn't answer
You can stop or waiting for it to answer (french translation)
http://en.wikipedia.org/w/index.php?title=User:Cacycle/WikEd.js&action=raw&ctype=text/javascript&dontcountme=s:10512.

Then, sometimes when i press "Stop the Script", it works and I can continue (1/4), or sometimes, Firefox doesn't answer either, and I have to close it and restart from the beginning.

What's wrong ?

(Firefox 4.0, Windows 7 (64)

Thanks for your answer, JRibaX (talk) 14:23, 21 April 2011 (UTC)

  • It works fine for me with Firefox 3.6.16 on Linux. Does this behavior happen when you have just one window and one tab open, and no Firefox extensions? Does it happen every time? -Pgan002 (talk) 03:41, 26 April 2011 (UTC)
VitaliyFilippov (talk) 13:43, 27 April 2011 (UTC) See "Firefox 4 infinite loop" below.
No, I don't think that's it (i.e. that's another problem). I experience the same problem on the same combination of OS and Firefox 4 (Firefox 5 has the same problem). It occurs after I highlight a portion of the text. Not every time, but often enough (say, once in 10 selections, and I select quite often; when my connection is slower, failure rate seems higher) that I had to turn WikEd off. Sometimes "stop the script" helps, sometimes not even that. FF 4 seems to have one thread per window so I don't always have to kill the whole browser, but I lose the work I had done in the edit window.
I am a programmer (not in web/scripting area though) so maybe I could help debugging, if only I knew how. No such user (talk) 08:10, 12 July 2011 (UTC)

Firefox 4 infinite loop in [Wikify]

VitaliyFilippov (talk) 13:40, 27 April 2011 (UTC) WikEd does an infinite loop in Firefox 4, for example, when wikifying copy-pasted tables. This is because WikEd uses the following code (in 2 places): while (//g.match() != null). ECMAScript 5 standard tells us // is not a special literal regex syntax (as it was in ECMAScript 3), but is a constructor for a new regexp object, and a new regexp object always has last match position = 0. So if there is even a single match, this would be an infinite loop, which is incorrect. All other browsers behave differently Not really, Opera now also conforms to ECMAScript 5, Chrome and IE do not. See Mozilla Bug 98409. Nevertheless, the following code: var re = //g; while(re.match() != null) is correct for Firefox 4 and other ECMAScript5-compliant browsers.

The following patch fixes this problem: 

--- WikEd.js	Wed Apr 27 09:23:39 2011 +0000
+++ WikEd.js	Tue Apr 26 14:48:02 2011 +0000
@@ -10172,8 +10172,7 @@
 					// parse hrefUrlParam and check for special parameters
 					if (hrefUrlParam != null) {
 						var regExpMatchHref;
-						var re = /(^|&amp;)(\w+)=([^"\&]+)/g;
-						while ( (regExpMatchHref = re.exec(hrefUrlParam)) != null) {
+						while ( (regExpMatchHref = /(^|&amp;)(\w+)=([^"\&]+)/g.exec(hrefUrlParam)) != null) {
 							var param = regExpMatchHref[2];
 							var value = regExpMatchHref[3];
 							switch (param) {
@@ -10572,8 +10571,7 @@
 	tag = tag.toLowerCase();
 	var sanitized = '';
 	var regExpMatch;
-	var re = /(\w+)\s*=\s*(('|")(.*?)\3|(\w+))/g;
-	while ( (regExpMatch = re.exec(attributes)) != null) {
+	while ( (regExpMatch = /(\w+)\s*=\s*(('|")(.*?)\3|(\w+))/g.exec(attributes)) != null) {
 		var attrib = regExpMatch[1];
 		var attribValue = regExpMatch[4] || regExpMatch[5];
 		if (attribValue == '') {
Thanks, I will add it this weekend. Cacycle (talk) 06:58, 6 May 2011 (UTC)
Fixed in 0.9.99. Thanks again! Cacycle (talk) 16:52, 8 May 2011 (UTC)

0.9.35h removal

Hi. I have inherited some MediaWiki administration tasks for my company's internal wiki and am having a terrible time locating and removing and old version of wikEd which is installed on it (their version is ancient - 0.9.35h and I want to upgrade it). Despite the fact that it appears to be a site-wide install the code is not located in MediaWiki:Common.js, there are no preferences options for Gadgets or wikEd. Also, no code shows up under User:<any user>/monobook.js or any of our other skins. I have also done a "grep -R -i wikEd ." through my wiki installation directory without getting any hits. I am at a loss! I can install the newest version by adding your code into MediaWiki:Common.js but then both versions are active (or at least the little icon for both show up in the top right). Am I missing something? Where can I locate and obliterate the old version? Does the "h" at the end of the version number signify an installation type that I missed?

Thank you so much for any help you can provide!

Xaev (talk) 21:16, 16 May 2011 (UTC)

You could try to find out from where the code is loaded, e.g. using the Web Developer add-on for Firefox. Or check the source code for Javascript links and then check their source codes. You could also cearch the database for the wikEd code... Cacycle (talk) 21:39, 16 May 2011 (UTC)

Templates required in external wiki to run wikEd

I'm preparing to install wikEd on a MediaWiki on an intranet which may or may not be connected to the Internet. So I'm copying the whole wikEd program code. WikEd is to be active for all users, so I'm installing the scripts in the MediaWiki namespace.

For now, I'm experimenting with wikEd on a live on-line wiki that I control, because it's available. I realize I should set that up differently, but then it wouldn't help me understand how to set up the intranet version.

The most obvious problem is that on the page http://www.informationtamers.com/WikIT/index.php?title=MediaWiki:WikEd.js The following are reported as used but missing:
Template:FUNCTION:parameter
Template:Function:param
Template:Lang
Template:Modifier:...
Template:TABLE
Template:Variable
Template:Variable:R
Template:\s*lang\s*\

But I can't find most of these in Wikipedia and those I can find lead to a cascade of dependencies. And ones I do include look very different once in my wiki. When I get beyond content editing and basic setup, my wiki fu is not so hot!

Is there a recognized way of acquiring the full tree of templates required for wikEd?

I can't get any sign that wikEd is active - editing appears in plain text as normal. I'm using Chrome 12.0.742.100 on WinXP SP3 and refreshing after any changes. The problem occurs in IE8 and FF3.6 as well. The wiki is on v.1.16.5, monobook (with very minor customization) and wikEd is the version on the wikEd Installation page now.

There's a full list of what I've done for the installation here: http://www.informationtamers.com/WikIT/index.php?title=User_talk:WikITSysop#wikEd_installation and apart from the templates, I think everything has been done.

Thanks Argey (talk) 06:46, 21 June 2011 (UTC)

Addendum. I have noticed now that most of the templates that were redlisted at the foot of http://www.informationtamers.com/WikIT/index.php?title=MediaWiki:WikEd.js were actually mentioned in comments and were not really template invocations. I was caught out by the wiki code parsing text after the "//"

The only use of template code that looks as if it might indicate the need for a template are the following: 


var regExp = /{{\s*lang\s*\|(.|\n)*?}}/gi;

and
return('{{doi|' + regExpMatchDOI[1] + '}}');
['\\{{2,}',                         'paramTempl',          'open'], // template or parameter start

Argey (talk) 08:42, 24 June 2011 (UTC)

wikEd itself does not need any templates. The problem is in your MediaWiki:Common.js, simply remove the semicolon at the end of the line starting with 'wikEdHelpPageLink', list items are separated by commas. Also, check your JavaScript error console for errors. Cacycle (talk) 20:49, 3 September 2011 (UTC)


Oh! I see. Thank you very much for your wisdom infusion, I'll do that. Argey (talk) 03:35, 5 September 2011 (UTC)

Helper programs?

Hello Cacycle, is it possible to make your code from "Syntax highlighting" as a separate user script like "wikEdDiff". Best Greetings --Perhelion (talk) 10:40, 27 June 2011 (UTC)

Slow to load in HTTPS wiki

I'm 90% sure that it's so slow because it loads each icon one at a time, at about half a second each, which totals maybe 20-30 seconds on my system. Problem is icons are flushed from cache fast on my system, for whatever reason. It would be vastly more efficient from a network perspective and much faster to load to make them all views on a single large png strip/box. There are some online tutorials for this. Also, making it SVG per the earlier suggestion would slow the loading time down well beyond what it is now, so I vote against that (although some of the icons are nicer and could definitely replace the current ones). Foxyshadis(talk) 05:53, 17 July 2011 (UTC)

Fixes for regex rules parsing

{{editprotected}} Hi!

Could someone sync the "regExp" used to detect the rules with the AWB source code and also add a mw.log command to the loop which is used to parse the regex rules? 

		// parse regexp rules
		var regExp = /<(?:Typo)?\s+(?:word="(.*?)"\s+)?find="(.*?)"\s+replace="(.*?)"\s*\/?>/g;
		while ( (regExpMatch = regExp.exec(rulesTxt)) != null) {
 
			// check if this is a valid regexp
			var regExpFind;
			try {
				regExpFind = new RegExp(regExpMatch[2], 'gm');
			}
			catch (err) {
				mw.log( 'Invalid regex:\nfind=' + regExpMatch[2] + '\nreplace=' + regExpMatch[3]);
				continue;
			}
 
			// save regexp and replace
			wikEd.typoRulesFind.push(regExpFind);
			wikEd.typoRulesReplace.push(regExpMatch[3]);
		}

The regex change would make the name of the word optional and white spaces to be ignored (as it is on AWB) and the log command would allow users to use ?debug=1 to review the set of rules and find out which ones needs to be fixed (and would do nothing on production mode). Helder 16:10, 30 July 2011 (UTC)

Umm, I don't understand what you mean by several different things you've said, including <sync the "regExp">. Could you perhaps create a sandbox page, copy/paste the current text into it, make the changes, and then post a link to it here with a note of "just copy/paste it over"? Nyttend (talk) 12:50, 1 August 2011 (UTC)
Ok. Take a look at this diff which shows the proposed changes. The first change is to make sure AWB and WikEd use the same regular expression to detect the rules on Wikipedia:AutoWikiBrowser/Typos. Helder 13:01, 1 August 2011 (UTC)
Done, I hope. Please check to make sure that I did the right thing. Nyttend (talk) 14:36, 1 August 2011 (UTC)
Almost done: the script should go to the page User:Cacycle/wikEd.js, not to User:Cacycle/wikEd ;-) Helder 14:40, 1 August 2011 (UTC)
So what do I do with User:Cacycle/wikEd? Simply undo the edit? Nyttend (talk) 14:52, 1 August 2011 (UTC)
Yep!
PS: I just posted my request on this page because the User talk:Cacycle/wikEd.js redirects here. Helder 14:58, 1 August 2011 (UTC)
I was going to ask why you posted here, so thanks for telling me :-) Such a large page makes my browser lock up, but rollback makes the process easy. For future reference: when you have a complicated requested edit, ALWAYS provide the exact code that you want — in your initial request, either give the entirety of the code that should be deleted and the entirety of the code that should replace it (make sure that the code to be deleted is unique on the page), or simply provide the entire code in a sandbox. As well, PLEASE specify the page to be edited if it's not the one on whose talk page you're posting the request. Nyttend (talk) 15:06, 1 August 2011 (UTC)
Indeed, my browser also has the same problem. I kind of did what you suggested in the initial request, but I could have made it more explicit (I've copied the part of the code which should be changed, added the new code and used the highlight="2,11" parameter of the <syntaxhighlight lang=""> tag to indicate which lines would change). But next time I will provide a usual diff to avoid confusion ;-). As for the page redirect, I only noticed it after seeing that the wrong page was edited accidentally. Helder 15:27, 1 August 2011 (UTC)
Could you change the position of the mw.log? It should be executed only in case of an error in the regex (when I've copied the code above to the sandbox I changed this accidentally). Helder 16:30, 1 August 2011 (UTC)

Done. --Closedmouth (talk) 05:45, 20 August 2011 (UTC)

Thanks! Helder 18:40, 20 August 2011 (UTC)
Added a check for the availability of mw.log to wikEd 0.9.100. Cacycle (talk) 20:35, 3 September 2011 (UTC)

Some bugs in WikEd 0.9.99 and Firefox 5

In Firefox 5, wikifying copy-pasted text often gives things like: 

name="cutid6" _moz_dirty=""

Also, the cursor jumps to the end after wikifying. It didn't in Firefox 4. This is inconvenient.

VitaliyFilippov (talk) 15:13, 4 August 2011 (UTC)

Does it still do this in Firefox 6? Please could you give me an example of pasted text where this happens? Thanks, Cacycle (talk) 20:29, 3 September 2011 (UTC)

Cannot install script

Hi there,

I've used the wikEd script before (with FireFox 3.6) On my new system I'm running firefox 5.0 and I cannot run the script anymore. I've installed Greasmonkey and when I try to install the wikEd Script the following error msg. pops up:

"Script could not be installed TypeError: match[2] is undefined"

I try to install it from this link: http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:Cacycle/wikEd.user.js — Preceding unsigned comment added by 82.92.248.212 (talk) 14:05, 12 August 2011 (UTC)

I have the same issue with Firefox 6. My workaround was to make a bookmarklet so I can at least turn it on when I need it (see below) --207.171.191.60 (talk) 18:06, 23 August 2011 (UTC)
Greasemonkey loading has been fixed in wikEd version 0.9.100. It is a Greasemonkey bug for empty metadata blocks, in this case the empty @exclude. Cacycle (talk) 20:21, 3 September 2011 (UTC)

wikEd button doesn't really hide old standard wiki toolbar (I give also solution)

Well, I think that would be a solution...)

The button hides wikEdToolbarWrapper. The problem is that, unlike the new standard wiki toolbar, You don't append the old one to that wikEdToolbarWrapper. You should change the code below. It says something like: "if there's a wikEd.toolbar then append wikEd.toolbarWrapper to wikEd.editorWrapper" and that's all. There is missing the appendig of the toolbar to wikEd.toolbarWrapper. Vinne2 (talk) 18:28, 5 September 2011 (UTC) 

    // create toolbar wrapper
    wikEd.toolbarWrapper = document.createElement('div');
    wikEd.toolbarWrapper.id = 'wikEdToolbarWrapper';
    wikEd.toolbarWrapper.className = 'wikEdToolbarWrapper';
    wikEd.toolbar = document.getElementById('toolbar');
    if (wikEd.toolbar != null) {
        wikEd.editorWrapper.appendChild(wikEd.toolbarWrapper);
    }
    else if (wikEd.wikiEditorBar != null) {
        wikEd.wikiEditorBar.parentNode.insertBefore(wikEd.toolbarWrapper, wikEd.wikiEditorBar);
        wikEd.toolbarWrapper.appendChild(wikEd.wikiEditorBar);
    }
    else {
        wikEd.editorWrapper.appendChild(wikEd.toolbarWrapper);
    }
This has been fixed a while ago. Cacycle (talk) 11:45, 4 January 2012 (UTC)

Why no signiature button?

I am really tempted to replace the original editing bar with wikiEd, but one key button is missing: the signature button. for talk pages. Could it be added to the wikiEd? Or, barring that, as wikiEd supports custom buttons, but frankly, User:Cacycle/wikEd_customization#Custom_buttons is to arcane for me to use, perhaps a kind soul would code this button as an option for me? Also, there are certain templates I often use, I'd love it if somebody could tell me how to add template buttons (i.e. a button that would add a template). I should be able to duplicate this for the several templates I care about, once I understand the basics. Thanks, --Piotr Konieczny aka Prokonsul Piotrus| talk 21:00, 20 August 2011 (UTC)

Why wasting precious button space for something simple as four tilde strokes? Cacycle (talk) 20:15, 3 September 2011 (UTC)
Because without it, the "Disable regular bar" is useless. Clicking signature button is faster than typing it. It is a useful and common feature. And WikiEd has plenty of space for buttons. --Piotr Konieczny aka Prokonsul Piotrus| talk to me 17:11, 4 September 2011 (UTC)

Bookmarklet Version

I had issues with installing the GreaseMonkey script, so instead I made a bookmarklet to load wikEd on demand: just drag this wikEd link to your bookmarks toolbar and click it to enable wikEd for the page you are currently on.

Source: 

javascript:(function(){_wikEd_script=document.createElement('SCRIPT');_wikEd_script.type='text/javascript';_wikEd_script.src='http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript';document.getElementsByTagName('head')[0].appendChild(_wikEd_script);})();  — Preceding unsigned comment added by 207.171.191.60 (talk) 18:11, 23 August 2011 (UTC)
Dragging the link doesn't work - apparently Wikipedia dislikes javascript links. To make the bookmarklet, you'll have to create a bookmark yourself with the above source code as the URL. — Preceding unsigned comment added by 207.171.191.61 (talk) 18:15, 23 August 2011 (UTC)
BTW, Greasemonkey loading has been fixed in wikEd version 0.9.100. Cacycle (talk) 20:13, 3 September 2011 (UTC)

Galician translation

I've just made the Galician translation for wikEd interface. You can find it here: User:Toliño/wikEd international gl.js.Could you add it please? Thanks a lot! --Toliño (talk) 11:48, 25 August 2011 (UTC)

Change made to User:Cacycle/wikEd template. — Martin (MSGJ · talk) 20:32, 29 August 2011 (UTC)
How much time do we have to wait to get the translation live? Thanks again. --Toliño (talk) 10:20, 30 August 2011 (UTC)
Not sure. I can see the new link. Perhaps you need to purge the page? — Martin (MSGJ · talk) 09:07, 31 August 2011 (UTC)
Added to version 0.9.100. Cacycle (talk) 20:11, 3 September 2011 (UTC)

Script could not be installed

I just installed Greasemonkey and than, after restarting FF, I tried to install the script and I got the following error message: "Script could not be installed TypeError: match[2] is undefined"
Since I have NoScript installed and the issue was with Javascript, I figured out, that that was the issue, so I allowed all script globally but I got the same error message. I run FF 4.0.1 on Kubuntu. Has anyone got an Idea? Or can I download the script in some other way? Thanks in advance! --Dia^ (talk) 10:12, 4 September 2011 (UTC) I just tried from here http://userscripts.org/scripts/show/12529 and I still get the same error message. Is it an incompatibility with Linux?--Dia^ (talk) 10:24, 4 September 2011 (UTC)

This has just been fixed with version 0.9.100, please push Shift-Reload to update and try again. Cacycle (talk) 12:36, 4 September 2011 (UTC)

Bug in September 4, 2011, version

There is a rather major bug in the most recent (4 Sept 2011) version of wikiEd. When editing pages with large lists, the editor removes newlines from the lists, or sometimes does not load the entire list. An example can be seen here. It initially will not load the entire page into the editor. Then if you click changes, it will load the entire page but it will have removed all the line breaks from the list at the bottom of the page. --Odie5533 (talk) 17:08, 4 September 2011 (UTC)

See also WP:VPT#My talk page got corrupted, which may show the same problem. I can't reproduce this using the gadget version of wikEd, in Firefox 6 on a Mac. Ucucha (talk) 17:12, 4 September 2011 (UTC)
Actually, it does happen now that I cleaned my cache. After the line :* http://www.eurogamer.net/articles/more-on-red-alert-3-expansion-in-09, all the newlines in the list get eaten. Ucucha (talk) 17:15, 4 September 2011 (UTC)
Confirmed, I had to disable wikiEd in my prefs. The bug is critical. PS. I was using Firefox 6.0.1 for Win, and the bug was not affected by the vector.js (I test blanked it before going to preferences when tracing the bug). --Piotr Konieczny aka Prokonsul Piotrus| talk to me 17:12, 4 September 2011 (UTC)
Workaround Upstream (Greasemonkey) had a recent bug for installing scripts that was only just fixed, so I installed that version. I was then able to install old versions of wikiEd from userscripts.org. However, the bug is in fact in wikiEd since the newest wikiEd contained the bug using GM 0.9.10, but the older versions of wikiEd on GM 0.9.10 did not have the bug (and the Gadget wikiEd exhibits the bug as well). The current workaround is to install GM 0.9.10 from the first link, and then install an old version of wikiEd from the userscripts.org link. --Odie5533 (talk) 17:29, 4 September 2011 (UTC)
I just realized that GM 0.9.10 has a fun bug where middle-clicking on webpage links no longer opens then in a new tab (a feature I use incessantly). GM 0.9.9 + wikiEd from May 8 seems to do the trick. --Odie5533 (talk) 17:45, 4 September 2011 (UTC)

I've reverted user:Cacycle/wikEd.js for now, since this is such a major bug. Cleaning your cache should now remove the bug. I hope Cacycle will be around soon to fix the underlying bug and restore the other fixes in version 0.9.100. Ucucha (talk) 17:47, 4 September 2011 (UTC)

Thanks for reverting and sorry for the problems. The version was actually tested on several pages (including Barack Obama). I have now put version 0.9.100a online with the highlighter changes reverted. Cacycle (talk) 20:23, 4 September 2011 (UTC)

Can wikEd be speed up (image loading problems)?

I am on the verge of giving up on wikEd. I like the syntax highlighting, but I am annoyed by the clutter of buttons I mostly don't use. I could live with clutter, but often when I edit a page, wikEd takes something like 3-4 seconds to load itself over the editing Window; what seems to take most of that is loading buttons (I use Firefox 6.0.1 on Win 7). It seems like they are not cached, or need to be generated every single time. Any ideas why this delay is occurring? (Also, how to kill most of the buttons I don't want...). --Piotr Konieczny aka Prokonsul Piotrus| talk to me 20:51, 4 September 2011 (UTC)

I have had this problem too. Perhaps if wikiEd employed CSS sprites, that would fix the problem? --Odie5533 (talk) 21:13, 4 September 2011 (UTC)
Looks like the following bug 22680 (page caching broken) which has been fixed on Wikipedia with standard settings. You might want to check your addons, user scripts, and gadgets for anything that breaks page caching. Cacycle (talk) 21:54, 4 September 2011 (UTC)
Well, neither of them "says" they break it. And it is in fact not broken in anything but wikiEd... --Piotr Konieczny aka Prokonsul Piotrus| talk to me 02:54, 5 September 2011 (UTC)
I (Firefox 3.6 with many addons, Linux, Monobook) have the same behavior (since ever - not appeared recently): Sometimes the buttons do not seem to be cached or whatever and load each after each. The whole button bar takes about ten seconds and the complete browser is frozen in the meantime. After all is loaded and I return to a page WikEd displays instantaneous. So it seems like the button images are not cached. But the loading of the images in the "failure" case takes far too long for a normal image load operation. Cheers --Saibo (Δ) 00:28, 6 September 2011 (UTC)
This problem is caused by other scripts, addons, or gadgets that break page caching in general. Youy only notice it for wikEd because of the many images. Therefore, I would be great if you could help to identify those problematic scripts so that we could then ask their authors to fix these issues. Thanks in advance, Cacycle (talk) 07:11, 7 September 2011 (UTC)
All right. I temporarily blanked my vector page, test loaded more than a dozen pages in edit mode, and you are right, the dalay was not there. This at least tells us it is not a gadget, but a js script. Perhaps if we compare mine, Saibo's and Odie's js pages, we will see the common culprit? I am going to restore my js page now. --Piotr Konieczny aka Prokonsul Piotrus| talk to me 17:33, 7 September 2011 (UTC)
Hmm - the problem is for me that I cannot reproduce the problem. At least I have not noticed the pattern. I will try to look at it.. Cheers --Saibo (Δ) 19:35, 14 September 2011 (UTC)

Error message about local diff script

When I click on the "Delta" box ("Show current changes below"), I see no changes, but instead get only error message "Error: Local diff script not installed." I am using FF 6.0.1 on Windows Vista, and have made no changes to anything, AFAIK. Chris the speller yack 03:56, 5 September 2011 (UTC)

Oops, fixed, please Shift-Reload this page to update. Cacycle (talk) 22:22, 5 September 2011 (UTC)
Thanks much! I was feeling like a fish out of water. Chris the speller yack 00:53, 6 September 2011 (UTC)
This error made me realize how dependent I became on this diff. Good opportunity to say thank you, and report that indeed the fix works for me as well. --Muhandes (talk) 17:42, 6 September 2011 (UTC)
I'm having this problem with Chrome (13.0.782.220 m). The Shift-Reload described above does not fix it for me. --Kvng (talk) 13:55, 8 September 2011 (UTC)
Working now for me. --Kvng (talk) 20:30, 11 September 2011 (UTC)

Loading error on Wikia

wikEd is not loading at all for me on Wikia. When I try to edit a page, the wikEd icon in the upper right corner displays a red X and its tooltip says "Loading error". My JS page is at wikia:starwars:User:Master Jonathan/monobook.js; I'm running Firefox 6.0.2 on Windows Vista.

Errors from my error console, all produced upon loading the edit page for wikia:starwars:Gricha:

(removed, Cacycle)

Any ideas as to what might be causing this? jcgoble3 (talk) 18:29, 9 September 2011 (UTC)

P.S. Have you thought about archiving this page? Just a suggestion, given that it's, oh, around TWO HUNDRED THIRTY KILOBYTES in size. :P Ya know, just a suggestion. ;). jcgoble3 (talk) 18:34, 9 September 2011 (UTC)
Wikia compatibility has been re-added to wikEd 0.9.100b. Please chose the monobook skin in your preferences, otherwise things get a bit funky and you will not have wikEd's local preview and diff buttons. Cacycle (talk) 21:27, 17 September 2011 (UTC)
Thanks for the fix. I already use Monobook; I hate the default Wikia skin. jcgoble3 (talk) 23:57, 17 September 2011 (UTC)

on mobile browser

When I use my Android 2.2's native browser to login to wikipedia and edit, the wikiEd still shown up and due to unknown reason it make me unable to edit normally...(without login and without wikiED I can edit with it...)C933103 (talk) 09:33, 17 September 2011 (UTC)

Please could you describe your problems in detail (feel free to use the bug form on top of the page). Do you see any error messages in the JavaScript console? Do you see the wikEd logo on top of the page? Do you see the wikEd editing toolbars? Cacycle (talk) 19:34, 18 September 2011 (UTC)

HTTPS images

- wikEd.config.imagePath = 'http://upload.wikimedia.org/wikipedia/commons/';
+ wikEd.config.imagePath = '//upload.wikimedia.org/wikipedia/commons/';

With the new HTTPS roll out across the Wikimedia verse, I thought I'd check what was "breaking the lock". The image repository now supports HTTPS ;-). You many also want to change the auto-linking for RFC and PMID to use protocol relative URLs. — Dispenser 13:20, 29 September 2011 (UTC)

Fixed with version 0.9.101, RFC and PMID will be fixed in 0.9.101a. Cacycle (talk) 19:52, 8 November 2011 (UTC)

Did the diff go away

The diff delta (the one that used to appear after the regular diff) suddenly does not appear. I also tried installed wikEdDiff manually, but it did not help. Thanks. --Muhandes (talk) 07:45, 5 October 2011 (UTC)

Looks like everything went away. What's up? --Kvng (talk) 13:28, 5 October 2011 (UTC)
Same for me. I assume it has to do with the recent MediaWiki version upgrade which just happened. Anyone have a link for information about that upgrade? —danhash (talk) 15:12, 5 October 2011 (UTC)
Many upgrade issues including this one have been reported at Wikipedia:Village pump (technical)#Improved diff view not working. PrimeHunter (talk) 15:15, 5 October 2011 (UTC)
wikEd has disappeared on me too. On Chrome and Firefox. TuckerResearch (talk) 16:44, 5 October 2011 (UTC)
I fixed wikEdDiff. This change needs to be made. You guys can either wait for an admin or Cacycle to make the edit, or just import my version for now. I haven't looked at wikEd because I don't use it, and it's probably a more complicated problem, anyway. Although it's also very likely going to be merely a problem with finding the right classes, because a lot of new classes and DIVs have been added in the latest MediaWiki update. Gary King (talk · scripts) 19:44, 7 October 2011 (UTC)
I have added the fix to wikEdDiff 0.9.15. Thanks, Cacycle (talk) 15:24, 8 October 2011 (UTC)
Works for me, thanks! --Muhandes (talk) 22:14, 8 October 2011 (UTC)
I still have the issue, with monobook and "Improved diff view" gadget. Regards, Freewol (talk) 07:11, 9 October 2011 (UTC)
I too still have the problem when viewing differences in history as the button does not show up. The button does work when editing an article, but not in the history view. --Odie5533 (talk) 03:04, 10 October 2011 (UTC)
MediaWiki:Gadget-wikEdDiff.js probably also needs to be updated. Gary King (talk · scripts) 17:22, 10 October 2011 (UTC)
By the way, with WikEd gadget enabled on Wikipedia in french (there is no "improved diff view" gadget there), the diff doesn't work either. Regards, Freewol (talk) 08:30, 11 October 2011 (UTC)
Just clarifying what I said above. For me wikEdDiff works, but "improved diff view" in WikEd does not. In other words, you need to enable wikEdDiff manually to get this capability. I hope this helps. --Muhandes (talk) 12:04, 11 October 2011 (UTC)
Thanks. Importing manually User:Cacycle/wikEdDiff.js works for me, on this Wikipedia and on the one in french. Freewol (talk) 20:41, 12 October 2011 (UTC)

I have fixed the wikEdDiff gadget code that previously used a completely outdated version from 2007 (!). Cacycle (talk) 19:15, 16 October 2011 (UTC)

WikEd not work anymore (German WP)

also not in an external wiki. Same problem? http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Helferlein/Extra-Editbuttons#Ausfall_des_Helferleins_mit_Monobook_am_06.10.2011 Thanks for helping. de:Tom Jac as IP: 194.94.134.90 (talk) 10:02, 8 October 2011 (UTC)

wikEd under vector as a gadget works fine for me on de:. Please could you provide more details (see bug report form on top of the page). Thanks for reporting, Cacycle (talk) 13:32, 8 October 2011 (UTC)
Works fine after generating a new profile for firefox. Reason for error was not to be reproduced. Thanks. Tom Jac. --194.94.134.90 (talk) 07:14, 3 January 2012 (UTC)

wikEd loads insecure images on new secure site

i.e. at least one http image (the one in the top right) even on the https site. Do protocol-relative URLs need to be inserted somewhere they're not being used at the moment? This triggers warnings in Chrome and prevents the "you are browsing securely" display in Firefox. Thanks, - Jarry1250 [Weasel? Discuss.] 16:33, 29 October 2011 (UTC)

It works fine for me in Firefox. Please could you give me more details about zour wikEd and Firefox versions and how to reproduce this error in detail (see form at the top of the page). Thanks, Cacycle (talk) 09:40, 30 October 2011 (UTC)
Okay, so steps to reproduce: 1) Load https://en.wikipedia.org/wiki/Main_Page . 2) Expected: URL for the image in the very top right of the screen (on/off button) begins https:// . Actual: it begins http://, triggering warnings. This occurs in Firefox 7.0.1. and Chrome 15.0 on my Windows Vista laptop. - Jarry1250 [Weasel? Discuss.] 09:59, 30 October 2011 (UTC) Oh, and I am using the standard install of wikEd via the gadget; it otherwise works as intended. - Jarry1250 [Weasel? Discuss.] 12:15, 30 October 2011 (UTC)
Reported a month ago, #HTTPS images. Basically images should be loaded over HTTPS. — Dispenser 01:22, 31 October 2011 (UTC)
Ah, yes. Then consider this a +1 on that bug :) - Jarry1250 [Weasel? Discuss.] 20:40, 31 October 2011 (UTC)
Fixed in 0.9.101, thanks for your patience. Cacycle (talk) 12:32, 7 November 2011 (UTC)

advanced diff not working anymore

Hello. I think that this change broke something, because the advance diff function stopped working for me yesterday afternoon. Regards, Freewol (talk) 08:25, 5 November 2011 (UTC)

Same thing for me. The advanced diff stopped working yesterday. --Tryptofish (talk) 20:46, 5 November 2011 (UTC)

Same trouble, I'm using it from fr.wikisource.org, Chrome give me an error "GET ... undefinedw/index.php?title=User:Cacycle/diff.js&action=raw&ctype=text/javascript 404 (Not Found), look like in 

wikEd.config.diffScriptSrc = wikEd.config.homeBaseUrl + ...

homeBaseUrl is now undefined. - phe 20:17, 6 November 2011 (UTC)

Seems to still work for me; I've got only User:Cacycle/wikEdDiff.js imported, without wikEd, also. Gary King (talk · scripts) 07:09, 7 November 2011 (UTC)
I checked again on en.wikipedia, it's still not working. I'm using https protocol with monobook, and I have the same line than Gary King in my monobook.js (that is, importScript('User:Cacycle/wikEdDiff.js');). The gadget, on the other hand, is currently working fine. Regards, Freewol (talk) 09:50, 7 November 2011 (UTC)
Still not working for me either. I use Firefox, Vector, and I have the same import in my vector.js file as Gary, also without full wikEd. --Tryptofish (talk) 18:23, 7 November 2011 (UTC)
I can't recall if it's necessary, but I also have User:Cacycle/diff.js, if that helps. It wouldn't hurt to also import that to try. Be sure to put it BEFORE User:Cacycle/wikEdDiff.js. Gary King (talk · scripts) 18:41, 7 November 2011 (UTC)
Yes, that made it work! Thanks Gary! --Tryptofish (talk) 19:17, 7 November 2011 (UTC)
Sorry. It's now fixed in wikEdDiff version 0.9.15c. It was the problem phe pointed out above. Use SHIFT-Reload to update. Cacycle (talk) 19:50, 8 November 2011 (UTC)
Thanks, it's now working fine. Freewol (talk) 09:10, 9 November 2011 (UTC)

Error on cross wiki requests

When I accessed gl:Especial:Lista_de_vixilancia I got the following message in my error console (on Google Chrome 15.0.874.106):

XMLHttpRequest cannot load https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd_current_version&action=raw&maxage=0. Origin https://gl.wikipedia.org is not allowed by Access-Control-Allow-Origin.

I wasn't able to reproduce this again, but it may be worth investigating. Helder 21:46, 8 November 2011 (UTC)

User-configured edit summaries

Is it possible to create a variable in common.js with our own edit summaries, or to pull a list of summaries from a user subpage? It would be very helpful to be able to configure the defaults. —danhash (talk) 13:48, 9 November 2011 (UTC)

Nvm, found it at wikEd customization. —danhash (talk) 14:40, 9 November 2011 (UTC)

Custom button to insert dated {{citation needed}} tags

I am relatively comfortable with basic JavaScript and have just started a little wikEd customization. I would like to add a custom button that inserts dated {{citation needed}} tags at the current cursor location. The current date could be determined with JavaScript and added to the tag or else you could use subst'ed magic words. (Or of course this could be integrated into the wikEd code.) Has this been done before? —danhash (talk) 15:25, 9 November 2011 (UTC)

At least on Wikipedia the date is automatically added by a bot as far as I know. Cacycle (talk) 11:01, 11 November 2011 (UTC)
It is, but it'd be very useful to have a button to insert {{citation needed}} (or other maintenance tags) so I don't have to type them each time (or copy/paste), and inserting dated tags would be little extra work to implement. —danhash (talk) 14:33, 11 November 2011 (UTC)
See User:Cacycle/wikEd_customization#Custom_buttons for how to make your own buttons. Cacycle (talk) 22:58, 16 November 2011 (UTC)

Double Edit Notice

I'm getting double edit notices when I turn on Wiked. My browser ID is Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2,I'm using Vector, my OS is XP, I'm using chrome and have no extensions, I'm not getting a console error message and I have Igloo, Twinkle, User:Js's ajax preview and watchlist on. I have Ale jrb's CSDH, userhist and Status Checker. I also have Splarka's ajax massrollback and Pathoschild's template script and regex menu framework. I also have a "custom" timer, Mike.Lifeguard's remote.js from meta and Johm254's mass rollback script along with some code that adds a portlet link in toolbox to link to Special:Abuselog. --Kangaroopowah 02:07, 28 November 2011 (UTC)

I've been getting this too for quite a while. It also doubles protection notices as well, but not editintros loaded through an &editintro= parameter in the URL (such as the JS-powered BLP notice). I'm using latest version of Firefox on Windows Vista, Vector skin. No errors in the error console. My JS page is here; I also have the lead section edit link and UTC clock gadgets enabled. This also affects me on Wikia (Monobook skin, JS page here). jcgoble3 (talk) 02:46, 28 November 2011 (UTC)
This is a wikEd feature, please see User:Cacycle/wikEd help#Double edit notice for help. Cacycle (talk) 22:17, 3 January 2012 (UTC)
Ah. I was not aware this was how it is intended to operate. Thanks for the reply. jcgoble3 (talk)


Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Cacycle/wikEd/Archive_011&oldid=1089947889"