User talk:Cacycle/wikEd

Please support wikEd

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

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

• Webkit/Chrome:
  • None.

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

Archives

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

wikEd Bug reports

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

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

Request - Pipes and Bangs

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

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

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

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

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

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

Wikia link suggest

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

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

Template in edit window

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

Fixed in upcoming release 0.9.91p. Cacycle (talk) 20:56, 24 August 2010 (UTC)

Popups with wikEd

I am a devout user of WP:POPUPS here. Normally when in the edit page, I can highlight a wikilinked word with my cursor and I get a popup like on articles. But wikEd does not allow me to do that. The ctrl-click works, but I don't want to open a new page for it, just see a preview with popups. How can I do this? Thanks! Reywas92^Talk 00:31, 24 May 2009 (UTC)

I will try to implement this, it might take a while though. Cacycle (talk) 17:56, 24 May 2009 (UTC)

_talk suffix

Suffixes for talk pages may vary by namespaces. For example, in MessagesJa.php, "‐ノート" and "‐会話" are used. So uniform "talk namespace suffix" (_talk) might not work as expected. --Hatukanezumi (talk) 14:54, 21 July 2009 (UTC)

Problems with fix html

In "fix html" () I found two issues

• tables don't inherit attributes (example <table class=wikitable> doesn't turn into {|class=wikitable)
• when converting, it converts new lines into <br /> in some tags like pre and math, causing malfunctions (try for example here; after fixing html, substitution <br /> -> \n gives the correct conversion) --93.47.29.46 (talk) 13:37, 18 August 2009 (UTC)

wikEdSummaryText bug

• wiked version : wikEd 0.9.88.b - no change when update
• Firefox : Firefox/3.0.14
• console errors

1. Avertissement : Virgule attendue dans une liste media, mais « and » a été trouvé. Règle « at » non reconnue ou erreur d'analyse de la règle « and ». Fichier Source : http://fr.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 Ligne : 362
2. Avertissement : Propriété « zoom » inconnue. Déclaration abandonnée. Fichier Source : http://fr.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 Ligne : 1407
3. Avertissement : Propriété « zoom » inconnue. Déclaration abandonnée. Fichier Source : http://fr.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 Ligne : 1441
4. Avertissement : Propriété « zoom » inconnue. Déclaration abandonnée.Fichier Source : http://fr.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 Ligne : 1492

• Add-ons :FoxClocks/2.5.35 ; Magic's Video - Downloader/2.2.280608 no change when disabled
• Monobook : .usermessage {background-color: transparent; border: 0; font-weight: normal; margin: 0 0 1em 0; padding: 0 0 0.5em 0; border-bottom: 1px solid #999}
• Kubuntu/9.04
• Description : only on french wikipedia the width of the summary text is too small only when wikEd is enabled. I can only see 21 caracters ( 56 caracters when wiked is desabled ). P-e (talk) 09:43, 19 September 2009 (UTC)

Does this also happen under Windows? Do you have any gadgets selected? Cacycle (talk) 15:24, 19 September 2009 (UTC)

Sorry for the answer coming late, I was busy IRL Under Windows it is OK - normal length (I didn't try before). I disabled gadgets in preferences (except wikEd) but this didn't change the length of the box under kubuntu P-e (talk) 09:18, 21 September 2009 (UTC)

FixDashes contribution

I've been working on code for converting hyphens to dashes, and have something I think works well. I was hoping you could use it in wikEd. I've extensively tested it and false positives are rare. The code and a test harness are in my monobook.js. Some specific tests are in my sandbox. —GregU (talk) 06:43, 30 September 2009 (UTC)

I will check this for the version after the next big update. Thanks, Cacycle (talk) 21:43, 13 October 2009 (UTC)

I have just checked the code. Unfortunately, it is highly specific for the English Wikipedia. Since wikEd is used in many languages and outside Wikipedia it cannot be added to wikEd. Please see User_talk:Cacycle/wikEd_customization#Custom_buttons and User_talk:Cacycle/wikEd_development#wikEd_API for how to make the code compatible with wikEd (you could also make it a custom button for wikEd). Feel free to cantact me for any help or for discussing things - Cacycle (talk) 19:47, 25 August 2010 (UTC)

Thanks for getting back to this. I see what you mean. —GregU (talk) 16:10, 4 September 2010 (UTC)

Changes are lost upon navigating to another page and returning

I don't know if there's a solution for this, but in Firefox 3.5 on Windows Vista and version 0.9.88 of wikEd, when I hit the Back button to reference an earlier page, or when I navigate to another page (when using Search to look for an appropriate template, for example), when I return I find all my changes have been lost. This never happened before I activated wikEd. Is this something fixable or is it an unavoidable consequence of the way wikEd works? If worse comes to worst, I can just hit the Preview or Show Changes button to post the current contents and make the changes thus far permanent, but it would be nicer not to have to do that and then have to find my place again. —Largo Plazo (talk) 14:36, 11 November 2009 (UTC)

As a workaround: CTRL-click to open links in a new tab, SHIFT-click to open links in a new window. This works not just with links on the displayed page, it works with any link or folder button in the bookmark toolbar (for folders, it opens every link in the folder in a separate tab), the Homepage button, the Reload button, the "Go forward/back one page" buttons, and every entry in the pulldown history menu. And there are always the options of Wikipedia:Text editor support and mw:Manual:External editors. Regards, Paradoctor (talk) 16:32, 11 November 2009 (UTC)

Good point. I guess my real problem was with the Search feature, but I can always open up an arbitrary link in a new tab and work from there. Thanks. —Largo Plazo (talk) 16:51, 11 November 2009 (UTC)

WikEd parsing in diffs

Hi, I would to know if is possible to set a variable to disable wikEd in diffs, as I use it as gadget and it makes some trouble in diffs' code. Thanks --93.47.18.81 (talk) 20:40, 17 December 2009 (UTC)

• Try the following:

var wikEdLoadDiffScript = false;
var wikEdDiffStartup = true;

• Please could you describe your problems with wikEdDiff so that I can try to fix them? Thanks, Cacycle (talk) 07:48, 21 December 2009 (UTC)

[1], and URLs in older versions of FF as I have pointed to you earlier in this discussion (not in newer ones though, as I noticed few minutes ago) --Lenore (talk) 21:22, 21 December 2009 (UTC) (IP above is mine)

Preview background-color

Where can i change the background-color for the Preview function mentioned in Preview and changes?
Is this only possible using a css-rule or is there also a variable i can modify?
⇐⇑©TriMoon™ Talk @ 06:51, 4 February 2010 (UTC)

• PS: maybe you could change the default background-color to be "inherrit" instead of the white as it is now, that way it will look better on all wiki's because it will use the site's default colors.
  ⇐⇑©TriMoon™ Talk @ 09:11, 5 February 2010 (UTC)

wikEd problems with wikia

When I initially edit a page on wikia, the cursor appears at the beginning (as expected) of the editbox area for editing. Using the mouse scroll eliminates the cursor (as well as not allowing me to scroll the edit field). After this I cannot do any editing whatsoever as there is no cursor and it acts as if I am no longer in the edit field at all. Clicking on the scrollbar with my mouse after this happens does nothing (won't scroll the editbox). After I initially click on edit page, if I use the arrow keys, I am able to move around the editbox and edit normally. Using FF 3.6.2 on Wikia with Windows XP (SP2). Doing this edit here, and on other Wikipedia pages does not give me the same results and acts normally. 68.101.94.165 (talk) 00:50, 2 April 2010 (UTC)

Please could you give us a link to a page where it happens and report which skin and which edit settings you are using. Thanks, Cacycle (talk) 12:05, 6 April 2010 (UTC)

Any page on any Wikia site seems to give me the same issues. Random page from Aion wikia. Once I click Edit this page, if I attempt to use the scroll wheel on my mouse to navigate the edit box of the page, my cursor disappears and I no longer have control of the edit box. Using arrow keys after this has happened ends up scrolling the entire page instead of moving around in the edit box. If I go into edit mode and leave the mouse alone, I can move around with the arrow keys and edit normally. Another random wikia page on another wikia that demonstrates the same problem. 68.101.94.165 (talk) 19:26, 6 April 2010 (UTC)

Correction. The behavior I described only happens when I click the mouse in the edit box or use the mouse wheel while over the edit box. I can use the mouse wheel outside of the edit box to scroll the page, but not inside the edit box. Even after I have scrolled the page, I can move the cursor (with the arrow keys) around in the edit box normally, but once the mouse clicks anywhere in the edit box (or changes focus to it via the mouse wheel) the cursor disappears and I have to disable wikEd or reload the page. 68.101.94.165 (talk) 19:30, 6 April 2010 (UTC)

It appears that this bug only gives me this behavior on Main Space articles. Editing this page in the Forum namespace does not exhibit the same behavior and acts like it should. 68.101.94.165 (talk) 22:42, 17 April 2010 (UTC)

It's been quite some time since I posted this and no recent comments on it. I am not able to use WikEd on 90% of the pages of the wikis I edit because of this. I recommended WikEd to a friend and they get the same problems. Please respond on this bug. 68.101.94.165 (talk) 17:42, 6 May 2010 (UTC)

wikEd works fine for me on the example pages. Please could you fill out the complete bug report form from the top of the page? Maybe it is an interaction with another gadget, setting or addon. Thanks, Cacycle (talk) 12:00, 9 May 2010 (UTC)

I'm running into the same issues on the Inheritance Wiki on Wikia. I'm running Firefox 3.6.8, WinXP SP3, Addons: Tab Mix Plus, Coral IE Tab (not using wikEd in IE, btw), GMail Notifier, Forecast Fox, Download Statusbar, and Colorzilla. There are more, but they are disabled. Default theme. As far as I know, we don't have any other gadgets on the Wiki, and what options I had turned on in the Edit preferences are now turned off with no results. I've tried both the .js script and the Greasemonkey script, and both do the same thing. If I create a new page/section, it works OK, but if I try to edit an existing one, it doesn't allow me to click in the box, and I have the exact behavior as listed above by the other user. 192.236.21.228 (talk) 18:25, 13 August 2010 (UTC)

Sorry, I cannot help you if you do not provide a full bug report, including the completed form on top of this page, your complete Wikia preference settings, links to your Wikia user scripts... I have tried hard, but I could nor replicate your problems. Cacycle (talk) 18:34, 10 September 2010 (UTC)

Disable autoscroll?

Is it possible to selectively disable the autoscroll feature that causes the page to jump down to the edit box when loaded? I saw the previous discussion that this behavior is disabled when there's an edit notice, but I really would rather it not happen at all. I use Friendly and Twinkle, and often find myself opening a non-existent talk page to welcome or warn someone. However, wikEd jumps down to the edit box, causing the tabs to go off-screen, and I have to manually scroll back up to use my other tools. Since my browser is big enough to see the whole edit box anyway, the scrolling is more annoying than useful for me. --Darkwind (talk) 05:37, 16 April 2010 (UTC)

I will work on this as soon as I find the time after the upcoming major change to version 0.9.91. Cacycle (talk) 20:28, 20 April 2010 (UTC)

Hebrew Translation

I've translate it to Hebrew, you can find the translation here. Sometimes it's cannot find the translation because of the Hebrew letters in my user name If it continue makes problems I'll move it to my English-letter UserName. שמוליק (talk) 09:38, 19 April 2010 (UTC)

Great, thanks a lot! I have updated the translation to the current version (0.9.91), feel free to add the missing translations. I have added the translation page link to the code and will update the translation page in a moment. I have no problems so far with the Hebrew username (beside these funny direction reversals when trying to edit or select it :-) ). Please let me know if you need any changes to make it work better in Hebrew or if you need help setting it up as a gadget there. Cacycle (talk) 20:04, 19 April 2010 (UTC)

thanks, there is a bug on RTL: #wpSummary hide the arrow button of #wikEdSummarySelect. i'd try fix it by change the direction to lrt but it's continue. שמוליק (talk) 08:42, 20 April 2010 (UTC)

I am not sure what exactly your problem is and how I could help to fix it. Please could you provide some more explanations and background information? :-) Cacycle (talk) 22:04, 26 April 2010 (UTC)

Can't customize wikEd to work with dark-on-light Gadget.

I've been attempting to fix the invisible (black-on-black) text that appears in wikEd with the dark-on-light Gadget enabled (in Wikipedia...my preferences...Gadget tab): I've tried customizing variables, as you can see at User:Elvey/monobook.js, but can't find the right thing to change to make the default text change from black-on-black to something readable and dark-on-light (e.g. green-on-black).

Answers to standard questions:

• wikEd version: When I hover, it flashes up too fast to read. But it's whatever's current here on en.wikipedia.org.
• browser id Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
• browser add-ons installed: Xmarks (not the culprit)
• Wikipedia skin: monobook
• NOT using the experimental Wikipedia Beta.
• User scripts installed on my Special:Mypage/skin.js page? User:Elvey/monobook.js, i.e.:
  • Twinkle, wikEd customizations, wikEd refToolbar, popups, furme, friendly. I think this is NOT an interaction bug with these scripts.
• OS: Mac OS X 10.6.3 (latest)
• what is wrong? (including when it happens, what happens, what is broken, and what still works)

See line 1 for what's broken. Consistent/Reproducible.

Works: Syntax highlighting works - so I can see URLs (and managed to figure out how to change their color), but they are in a sea of black.

• Steps to reproduce:

Enable the gadget (and wikEd); full refresh to clear cache; try to edit.

• What exactly happens if I follow these steps

I can't edit; invisible (black-on-black) text appears in wikEd. I can select it, which makes it visible, as does turning off wikEd. And I can type and edit blindly.--Elvey (talk) 07:33, 23 April 2010 (UTC)

It actually works fine for me, wikEd is black on white, the rest of the page is green on black. So it might actually be a an interaction. Does it work if you remove all wikEd customization and other scripts and gadgets? What is the wikEd version and installation mode (hover over top right icon)? Cacycle (talk) 20:15, 25 April 2010 (UTC)

As I mentioned, "# wikEd version: When I hover, it flashes up too fast to read. But it's whatever's current here on en.wikipedia.org."

Thanks for trying to replicate. I tried what you suggest... Ok... It's my monobook.css that's the culprit...

div {     background:     #000000 !important;    /* hmmm. why didnt i think of this before? */ } 

was in there with a cryptic comment. Commenting it out brought me back to what you saw. I managed to figure out that

div.wikEdFrameInner.wikEdFrameInner {    background:             #FF0000 !important;   /* testing */}

will give me black text on a red background, just in the edit box. I tried a bunch of stuff to change the text color, without success.--Elvey (talk) 20:47, 7 May 2010 (UTC)

UploadForm.js not working when wikEd is enabled

Is there any way to switch of wikEd for selected articles? I have a problem with running the UploadForm-Script when the wikEd Option is active. I tried disabling loading wikEd.js (which does work wrt. wikEd not showing up), but the new upload form is still not applied. When switching off wikEd (user preferences), the new upload form is correctly applied. Thanks --StefanSchulzDe (talk) 18:30, 27 April 2010 (UTC)

How do I install UploadForm-Script? I don't think it loads when I try this and I cannot find any installation instructions. Cacycle (talk) 20:33, 28 April 2010 (UTC)

The script is loaded via the MediaWiki:Common.js script. Has some pre-requisits though, as can be seen, and I am not sure whether it can be applied via User-Scripts. I assume there is a reason, why WikEd is not available in commons. --StefanSchulzDe (talk) 17:56, 2 May 2010 (UTC)

wikEdDiff does not appear when using "Show changes" on a .js page

I've noticed this for a long time now; wikEdDiff does not appear when I use "Show changes" on a .js page. Any chance it could be fixed? Gary King (talk) 07:23, 4 June 2010 (UTC)

wikEd icon

wikEd icon does not behave as expected. When I click on it, it doesn't turn gray. However, if I press F5 afterwards, it becomes gray. Clicking on it again does work as expected, i.e. wikEd is enabled and the icon gets its colors back. Tested on Windows 7 in Firefox 3.6.3 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3) and Chrome 5.0.375.55 - same behavior. Might have something to do with the new Vector skin. GregorB (talk) 13:52, 4 June 2010 (UTC)

Fixed in 0.9.91o. Cacycle (talk) 21:22, 23 August 2010 (UTC)

Safari Five checks: Quick Preview "offline", edit summary field still problematic

Hi Cacycle, Safari 5 is running on my fairly new Mac Mini with Snow Leopard, and while 0.9.91 is perfectly stable and speedy, the quick preview seems to have a problem. The edit summary box still requires a window refresh (resize) to display.
Schweiwikist (talk) 07:18, 8 June 2010 (UTC)

Should be fixed with version 0.9.92. Cacycle (talk) 06:25, 27 September 2010 (UTC)

Preview button must be clicked twice

When I'm editing a page with wikEd enabled, the preview button must be clicked twice to see a preview of the page with the most recent edits made (the "show preview below" button works fine, however). Clicking it once will show a preview of the page without any of your new edits. The easiest way to reproduce this is to the blank the edit box on a page. The first click of the preview button will show the page exactly how it looked before, and the second click will show a blank page. Another easy way is to click the "+" on a talk page, where clicking preview once will show a blank page after typing in the box. This is not an issue with wikEd disabled, and seems to be a problem on all computers.

• OS's tested: Windows XP, Vista, 7
• Browsers tested: Firefox 3.5x-3.6x (both with and without any add-ons)
• wikEd version: 0.9.90r G
• Wikipedia skins tested: Vector (my default), Monobook

–Dream out loud (talk) 00:45, 13 July 2010 (UTC)

I had this problem, but disabling the Use live preview option ended it. Train2104 (talk) 20:38, 17 July 2010 (UTC)

I will contact the Use live preview developers to make this feature compatible with wikEd. Thanks for reporting, Cacycle (talk) 20:34, 22 July 2010 (UTC)

See Bug 24860. Cacycle (talk) 20:03, 18 August 2010 (UTC)

Announcement

Finally, a major overhaul of wikEd has gone online. Version 0.9.91i now features template, reference, and character entity hiding (try the button!) and embedded image preview. Highlighting is powered by a real wikicode parser written in JavaScript. Native WYSIWYG table editing will soon to be rolling out! Please report any problems you might experience below. Thanks, Cacycle (talk) 22:10, 21 July 2010 (UTC)

Sweet! only just noticed that button - no problems so far :) Lee∴V (talk • contribs) 15:26, 29 July 2010 (UTC)

Do have one suggestion - I has a bit of an interface fight, but there was nothing wrong with it. With my mouse over a hidden item - it displays, but the alt text say click to display - which confused me 'it already is!', maybe change the hover over text to say something like 'click to stay shown' might help? Lee∴V (talk • contribs) 15:48, 29 July 2010 (UTC)

Fixed in next release, thanks for noticing and reporting - Cacycle (talk) 21:11, 3 August 2010 (UTC)

WikEdInsertTags end of line problem

wikEd hijacks MediaWiki's insertTags and replaces it with WikEdInsertTags to work with the custom frame. When I use anything that calls insertTags (e.g. the buttons at the bottom of the edit form for inserting your sig) at the end of a line with a special character (e.g. ]] or ==), the insertion is made on the next line and the cursor seems to have trouble deciding where it is. The problem only occurs when syntax highlighting is enabled. As an example, go to [2] and click at the end of the line linking to Bermuda and then click the ~~~~ at the bottom of the edit form. The insertion is made on the next line and it becomes difficult to fix the placement of the insertion. I believe the error lies somewhere in the WikEdInsertTags function, or a subsequent call, because I made my script call WikEdFrameExecCommand('inserthtml', "your text goes here") which worked fine, albeit without any syntax highlighting. --Odie5533 (talk) 03:00, 31 July 2010 (UTC)

Thanks for reporting, I think I know what's causing the problems and will try to fix it. Cacycle (talk) 21:16, 3 August 2010 (UTC)

Fixed in 0.9.91k. Cacycle (talk) 22:09, 15 August 2010 (UTC)

Inserting/deleting newlines spuriosly 2 (bugreport)

• Wiked version: wikEd 0.9.91j G (July 22, 2010)
• Browser version: Google Chrome 6.0.472.33 beta
• Skin: Vector
• Link to section: User talk:Cacycle/wikEd#Inserting/deleting newlines spuriously

Here you go. ~ Boro (talk) 09:42, 12 August 2010 (UTC)

Hopefully fixed in 0.9.91k, please could you verify this? Thanks everybody for reporting and insisting on this :-) Cacycle (talk) 21:55, 15 August 2010 (UTC)

Could not reproduce the steps from the section above (Chrome 5.0.375.126/Win 7), so it looks like it's finally fixed! GregorB (talk) 07:27, 18 August 2010 (UTC)

However, it appears that newlines do creep in in some situations, i'll try to construct a test case. GregorB (talk) 10:15, 18 August 2010 (UTC)

It's a variation of the earlier test case:

1. Open e.g. this page in a new tab.
2. Type #<Enter>#<Enter>#<Enter>
3. Click on "Preview" (or on ).
4. "#" characters from the step 2 are now separated by empty lines Not any more, this has been fixed
5. Add the fourth "#" in the last line, directly below the third "#" in the edit window
6. Click on "Preview"
7. The third and fourth "#" are separated by an empty line. GregorB (talk) 11:37, 18 August 2010 (UTC)

I hope I could fix it in 0.9.91m. Cacycle (talk) 00:25, 22 August 2010 (UTC)

Cannot reproduce this in the new Google Chrome 6.0.472.53. Might be considered fixed. GregorB (talk) 22:23, 4 September 2010 (UTC)

Midori

• wikEd version = 0.9.91j G (July 22, 2010)
• browser id = Midori 0.2.6, WebKitGTK+ 1.2.1
• Error console errors = Doesn't appear anything
• add-ons installed:
  • Advertirement blocker
  • Colorful tabs
  • Feed panel
  • Shortcuts
  • Toolbar editor
  • User addons
  • Web Cache
• What happens if you disable your add-ons and restart the browser: Nothing different
• skin = vector
• Wikipedia Beta user interface = no
• scripts installed on /vector.js = Friendly
• OS = Ubuntu 10.04

Hi, I'm using midori and your useful script seems that does not work under this browser. Is it possible to make it suppporting? Thank you, --→ Airon 15:21, 15 August 2010 (UTC)

It should work now in 0.9.91k, please could you verify that after Shift-Reload? Thanks for reporting, Cacycle (talk) 22:08, 15 August 2010 (UTC)

No, it doesn't work :(

It says that my browser is not supported yet.

Take your time and thank you for your great work! :) --→ Airon 20:15, 16 August 2010 (UTC)

Are you sure you are using version 0.9.91k? What is your exact browser's user agent? Cacycle (talk) 21:06, 16 August 2010 (UTC)

I'm sure: I use wikEd 0.9.91k G (updated the 15th of August) and my user agent is Midori/0.2 (X11; Linux; U; eo) WebKit/531.2+ (I found it there :S). Actual version of Midori is 0.2.7 with WebKitGTK+ 1.2.3 (and GTK+ 2.20.1 but I think that it doesn't influence) --→ Airon 13:42, 20 August 2010 (UTC)

With that user agent, wikEd 0.9.91k (after a fresh Shift-Reload) should accept your browser and it does it for me with user agent faking. What is the popup message of the grey logo on top of the page? Do you have additional instances of wikEd installed such as a userscript or Greasemonkey script? Cacycle (talk) 13:23, 21 August 2010 (UTC)

I don't know how many times I pressed CTRL+R purging the cache before the message and now but it does not work. The message is the same but today the version changed "Browser not supported - wikEd 0.9.91m G (August 21, 2010)". The list of add-ons installed are the one listed before. I never used Greasemonkey even with Firefox. If you have Windows you could install Midori and try it in order to see that it does not work :S --→ Airon 18:13, 21 August 2010 (UTC)
PS: I see this edit. You could link to buzilla by using [[bugzilla:24860]] :P --→ Airon 18:16, 21 August 2010 (UTC)

wikEd works fine for me under Midori/0.2 (Windows; Windows; U; en-us) WebKit/531.2+. Unfortunately, I cannot fix the problem if I cannot replicate the problem :-( Could you try to disable Wikipedia features, userscripts, and gadgets as well as addons and see if it helps? Cacycle (talk) 21:54, 21 August 2010 (UTC)

Nothing changed. Should it be a bug of JS-support of Midori?

Maybe, sadly, I'm going to change the browser (not Firefox!). --→ Airon 15:10, 22 August 2010 (UTC)

Even creating a new account it does not work :S --→ Airon 15:22, 22 August 2010 (UTC)

Finally, I have fixed it! It works now in 0.9.91n and was caused by a wrong/unconventional browser generation version identification by Midori (it says Midori 0.2 when it should say Mozilla 5. Unfortunately, Midori does not work correctly and you have to enlarge the wikEd edit window manually. Cacycle (talk) 19:18, 22 August 2010 (UTC)

Yes, now it works! Thank you very very much! I know that Midori does not work correctly: it is too buggy but I love helping in small projects (even if I'm not a programmer). I don't know (and I don't want to know the answer! :D) why it worked under Windows but not under Linux...

Is it a bug to be reported to Midori-devs?

Thank you again! --→ Airon 20:04, 22 August 2010 (UTC)

Yes, the browser identification is something that should be reported as it has the potential to break other sites or scripts too. Thanks for helping the wikEd project - Cacycle (talk) 06:24, 23 August 2010 (UTC)

I must thank you! :) --→ Airon 09:13, 24 August 2010 (UTC)

Let's give it a try

Hi, some days ago Midori grew to the 0.2.8 version and WebKitGTK+ grew to the 1.2.4 version. Could you try to restore the deleted code in order to see if the problem is solved? If not, just a rollback to restore the correct version. Thank you, --→ Airon 14:58, 26 September 2010 (UTC)

Few questions/concerns

User:Cacycle/wikEd_announcements still lists i as the latest version, but I seem to be using k. I'd also like to mention that previewing does not work in Google Chrome, and sometimes the toolbar does not load. I have not looked in to this much, yet, but I believe refToolbar 2.0 uses jQuery for AJAX which is working for them. AJAX for the search bar suggestions does work in Chrome, so perhaps taking a look at what they are using will help. I fired up Wireshark and the request is being sent to the server but Wireshark reports it is malformed. The proper response is not being sent from Wikipedia servers so the error is in the request packet. I am using Google Chrome 6.0.490.1 dev channel, and it also does not work on the Canary build 6.0.493.0. I was also wondering if there was a way to disable pasted text from being marked up always. I never like using wikEd's automarkup, I always end up pasting the text into Notepad before into wikEd so I don't have to deal with problems of automarkup. Or I use my browser's search bar to first paste text to, then paste into wikEd to avoid it. --Odie5533 (talk) 23:25, 16 August 2010 (UTC)

What preview buttons do you refer to? Maybe it is this problem (see User_talk:Cacycle#Preview button must be clicked twice)? try to uncheck experimental live preview in your Wikipedia preferences.

Which toolbar do you mean by 'the toolbar does not load'? What happens? What do you mean by 'automarkup'? wikEd does not change any pasted text on itself without a button being pushed. You can turn off highlighting with the button, update/textify pasted text with the button, and wikify pasted text with the button, see User:Cacycle/wikEd_help for more explanation. Cacycle (talk) 06:44, 17 August 2010 (UTC)

The preview never loads at all. As I said, the packet is malformed and the HTML response is not being received from the server. Experimental live preview is not checked. "The toolbar" refers to the WikEd toolbar. In fact, wikEd does not seem to load at all sometimes (no button in the upper right corner either). I have no idea how to reproduce this one, perhaps just try editing some different pages in different tabs in Chrome. When I say automarkup I mean the visual representation of pasted text, where it matches the source as large or small font size. I do not want to turn off highlighting, but turn off the interpreting of the source style. --Odie5533 (talk) 07:48, 17 August 2010 (UTC)

RE loading: Please could you check the JavaScript console of Chrome for related error messages and report them here?

RE preview: It works for me with the current Chrome 5.0.375.126. Do you have access to that version? Would you mind filling out a complete bug report form (see top of the page)? Is there something strange with wikEd's AJAX request? What exactly is the full ('malformed') request?

RE 'automarkup': You have to push the button to get rid of the original formatting (please see the help page). Cacycle (talk) 19:06, 17 August 2010 (UTC)

No errors in the JS console. The preview works for 5.0.375.126, but it is not working on the dev channel or the Canary builds. I realize I can click the [T] button, but I end up having to click it every time I paste content. --Odie5533 (talk) 23:23, 17 August 2010 (UTC)

Links and colons

Hello. I have been using wikEd on Wookieepedia for about a year now and find it extremely useful, but I cannot figure why clickable links in the edit box handle colons the way they do. When a link containing a colon (e.g. Star Wars Episode III: Revenge of the Sith) is parsed, wikEd treats the part before the colon as a namespace, even if it isn't, and automatically removes the space from immediately after the colon in the link target, breaking the link if it points to a main namespace article. For one, this behavior is redundant, as when the part before the colon is a namespace, MediaWiki does this automatically (e.g. http://en.wikipedia.org/wiki/User_talk:_Cacycle/wikEd automatically resolves to this page despite the extra space/underscore after the colon). Additionally, this breaks any link to a mainspace article containing a colon (as I already mentioned), of which there are plenty on Wookieepedia, such as books, movies, comics, etc. Any chance you could disable this behavior and just let MediaWiki handle the space itself? 99.138.181.76 (talk) (Master Jonathan on Wookieepedia) 02:18, 19 August 2010 (UTC)

Should be fixed in 0.9.91m, thanks for pointing this out - Cacycle (talk) 21:58, 21 August 2010 (UTC)

Esperanto

Ah! I remember that tehre is a problem in esperanto wikis. They have a JS-code which automatically, before saving, converts all cx, gx, hx, jx, sx and ux in ĉ, ĝ, ĥ, ĵ, ŝ, ŭ (cxx, gxx, hxx, jxx, sxx and uxx in cx, gx, hx, jx, sx and ux, cxxx, gxxx, hxxx, jxxx, sxxx and uxxx in ĉx, ĝx, ĥx, ĵx, ŝx, ŭx and so on). I use too many times the funcion which transforms the text in "wiki" links in order to go to the pages in the text (by using [w] and [t]) but when there is a page with those simbols (examble [[mangxajxo]], food) it links me to the page with x, without converting it into simbols (so it links me to "Mangxajxo" not to "Manĝaĵo"). Could you fix it? I hope you understand and sorry for my English. --→ Airon 18:23, 21 August 2010 (UTC)

Please could you point me to the javascript code? Thanks, Cacycle (talk) 21:57, 21 August 2010 (UTC)

eo:MediaWiki:Gadget-WikEd.js. Please tell me if I have to translate something. Thank you for your hard work, --→ Airon 15:12, 22 August 2010 (UTC)

I was refering to the code that converts your letters :-) Please see also eo:Uzanta_diskuto:ArnoLagrange#wikEd_gadget. Cacycle (talk) 18:36, 22 August 2010 (UTC)

Oh, sorry! I think (I'm pretty sure) that the code converter is hardcoded because if you create your own wiki in esperanto using LAMP, WAMP or similia it automatically converts the code. However, in Commons I can see a script which does that work --→ Airon 20:04, 22 August 2010 (UTC)

Added accentuation to linkification in 0.9.91o. Cacycle (talk) 21:18, 23 August 2010 (UTC)

Thank you! --→ Airon 09:28, 24 August 2010 (UTC)

Misinterpreted < in table

WikiEd messed things up here when I clicked the "Fix HTML to wikicode" button, apparently misunderstanding "<30 minutes||<5 minutes||<1 minute" in the table on that page. I'm using WikiEd 0.9.91o G, Linux Ubuntu, Firefox (probably not interesting in this context). --Gongoozler123 (talk) 12:52, 24 August 2010 (UTC)

Please see the wikEd help page which states: After using these buttons always check the changes with the button for unexpected collateral damage. Always use the smallest possible selection. Keep in mind that the applied rules are very simple. Only the Unicode character fixing is completely safe. :-) Cacycle (talk) 18:37, 24 August 2010 (UTC)

Right, I'll use the diff button more carefully. However, isn't it a simple task to avoid this kind of errors? I'm not a coder, but it looks like a simple rule would prevent this from happening. Thanks for your work. --Gongoozler123 (talk) 03:42, 25 August 2010 (UTC)

Heads-up! Do you know about this? Found it at the Village Pump (tech)

(quote)

UserAgent pop-up window

I started getting a pop-up window on every click in Wikipedia, and nowhere else. The window heading states:

The page at http://en.wikipedia.org/says:

Then the actual window text is 7 lines long. The first line says:

userAgent:Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US}

Any suggestions? --Wikiwatcher1 (talk) 05:51, 26 August 2010 (UTC)

I got these as well, briefly. They seem to have disappeared. Perhaps they were added by someone who wished to do some debugging and mistakenly submitted them to the production site? Gary King (talk · scripts) 07:22, 26 August 2010 (UTC)

Clue: it only pops up when I'm logged in. Is there any other tech area that can look into this? --Wikiwatcher1 (talk) 19:50, 26 August 2010 (UTC)

Your monobook.js pulls in User:Cacycle/wikEd_dev.js. That has

alert('userAgent: ' + navigator.userAgent + '\nappName: ' + navigator.appName + '\nappVersion: ' + navigator.appVersion);

in it, which is what is causing the message. Ze must be debugging zer scripts. CS Miller (talk) 21:40, 26 August 2010 (UTC)

Thanks! That did it. --Wikiwatcher1 (talk) 22:48, 26 August 2010 (UTC)

(end quote)

I have the same issue; in Firefox it triggers multiple page refreshes . . . please check this out ASAP, thanks. I have the script installed from before it became a gadget.
---Schweiwikist (talk) 05:32, 27 August 2010 (UTC)

UPDATE: Fixed it by switching to the release script instead of the "dev" (See my monobook.js page). Whew. Going to your "dev" script page locks up Safari, btw.
---Schweiwikist (talk) 05:44, 27 August 2010 (UTC)

wikEd_dev.js is for developing and debugging, non-developers should not call it and use the wikEd gadget instead. Please check your User:YourUsername/monobook.js or User:YourUsername/vector.js page and comment out or remove the respective lines. But for now I have copied the current wikEd version to wikEd_dev.js. Sorry for that, Cacycle (talk) 07:05, 27 August 2010 (UTC)

Bug using wikEd on a specific website

On this website : http://fr.nvcwiki.com wikEd can be activated via gadgets preferences, but doesn't work properly.

With Firefox one can only have the right part of wikEd but not functionnal. And with Camino or Safari the edit window is to small to be visible except when set to full screen.

Thanks for your help.

--Dieudo (talk) 22:31, 6 September 2010 (UTC)

Thanks for reporting this. I could replicated this and will fix it as soon as I find some time. Cacycle (talk) 06:46, 10 September 2010 (UTC)

Where to put custom variables

I've installed wikEd as Gadged. Where should I place custom variables like var wikEdFollowLinks = false; ?

When I paste it into MediaWiki:Gadget-wikEd.js (before installation code) and Ctrl-F5 (on Firefox) it doesn't work. Session13 (talk) 17:50, 12 September 2010 (UTC)

It goes in your skin js file. — Train2104 (talk • contribs • count) 19:26, 12 September 2010 (UTC)

That is true for a user. If yoy install wikEd on your own wiki for all users as a gadget, you should be able to add that config setting to MediaWiki:Gadget-wikEd.js (before or after does not matter). Can you give me a link to your wiki so I could check into it? Please note that with the next release in a few days (0.9.92) it must be var wikEdConfig = { 'followLinks': false, 'example': 'value' };. You can add both versions if you want. Cacycle (talk) 21:28, 12 September 2010 (UTC)

Thanks for reply. The address is lowiki.co.cc. Session13 (talk) 05:24, 13 September 2010 (UTC)

wikEdFollowLinks is no longer available as a config option. I have removed it from the wikEd configuration page. You can check the top of the wikEd code for all available options with explanations. Cacycle (talk) 06:57, 13 September 2010 (UTC)

I managed to change MediaWiki link color with wikEdFrameCSS['.wikEdLinkName']. Now, I'll spend some time doing necessary customizations. Thanks for help. Session13 (talk) 08:16, 13 September 2010 (UTC)

Soon to be var wikEdConfig = { 'frameCSS': { '.wikEdLinkName': 'color: #f00;', 'cssOption': cssValue }, 'wikEdOption': wikEdValue }; Cacycle (talk) 20:46, 13 September 2010 (UTC)

Text highlighter on view source page?

Would it be possible to implement the font/text highlighter on the view source page? (without the toolbars of course). — Train2104 (talk • contribs • count) 19:25, 12 September 2010 (UTC)

What is the "view source" page? Cacycle (talk) 21:36, 12 September 2010 (UTC)

The one a user gets when they try to edit a page and they don't have permission to . — Train2104 (talk • contribs • count) 21:46, 12 September 2010 (UTC)

Sure, I will add it as soon as I find some time. Thanks for the suggestion - Cacycle (talk) 22:06, 12 September 2010 (UTC)

Arabic translation

Hello, Cacycle. I've made the changes you sent to Ahmad and the script is now working again so thank you for that. Now I think it's the best to move the Arabic translation to local MediaWiki messages so admins can still modify and improve the translations. I wonder if that is possible. Thank you for the work that you do!--OsamaK^{Reply? on my talk page, please} 23:40, 12 September 2010 (UTC)

Thanks for helping out! The translations must be on the English Wikipedia so that I (as an en-admin) can update and fix them. But we can move it to another user space, e.g. yours. If you copy and improve the page I will adjust the program and the documentation. Please see User:Cacycle/wikEd_international for details. Cacycle (talk) 06:45, 13 September 2010 (UTC)

Preview not working in Chrome 7

I'm using wikEd 0.9.91o. My browser is Google Chrome 7.0.503.0 on Windows 7 Ultimate. I have no scripts installed in my Vector.js file. The problem persisted even after I uninstalled extensions in Chrome.

Everything in wikEd is working fine except for the quick preview button. Although the standard preview works without a problem.

I also found some erratic behavior when trying to deal with the problem. If in edit mode, the "preview" and "changes" buttons stay on the page after disabling. They go away when I pres the standard Preview button. But then when i try to re-enable wikEd, it makes the following load error:

Uncaught TypeError: Cannot set property 'lastIndex' of undefined /enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:10382

window.WikEdHighlightSyntax /enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:10382

window.WikEdUpdateFrame /enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:12699

window.WikEdTurnOn /enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:3032

window.WikEdMainSwitch /enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:12952

I don't know if this is due to Chrome 7 being a beta release. If this is not fixable in the time being, I'd appreciate if you could at least post the newest release of Chrome where wikEd works flawlessly.

Best regards, -- Orionist ★ talk 00:15, 13 September 2010 (UTC)

I will check into this after the next release 0.9.92 as some internal things related to the preview have changed. Thanks for reporting! Cacycle (talk) 20:53, 13 September 2010 (UTC)

Fixed in version 0.9.92. Chrome/Webkit has a bug and does not accept custom made xmlhttprequest body container strings, it requires a FormData object. Cacycle (talk) 05:59, 23 September 2010 (UTC)

Great! The quick preview button is working now. The weird behavior I described is still there, but since I don't need to do the steps that cause it (disable WikEd -> press standard "Preview" -> enable WikEd) it doesn't bother me anymore. The only problem I can see now is with the "minor edit" check box described below, everything else is working great. Many, many thanks! -- Orionist ★ talk 13:44, 23 September 2010 (UTC)

Firefox 3.6.9

Resolved

It's not working at all for me in Firefox 3.6.9. Mike Allen 03:34, 14 September 2010 (UTC)

I'd die to hear details... Please check the form at the top of this page. Cacycle (talk) 21:20, 14 September 2010 (UTC)

No need. Somehow it got disabled (just enabled it from the top of the page). How embarrassing... Mike Allen 21:27, 14 September 2010 (UTC)

:-) Cacycle (talk) 21:46, 14 September 2010 (UTC)

Toolserver and other stuff

I've hack of WikEd on the Toolserver. And here are some issues I've encountered.

• Links are always relative paths, it would be nice to have an option for absolute paths
• wikEdGreasemonkey = false otherwise InstaView does not work
• Using "Preview below" after "Changes below" with InstaView overflows vertically in Firefox 3.6 and Chrome
• It would be nice if InstaView would mark external links with classes

On Wikipedia:

• Close standard toolbar button does not work with the regular toolbar
• The redirect button fills an edit summary, this is not nessacary since we've had automatic edit summaries for like ages
• And WikEd will be featured in Wikipedia:Wikipedia_Signpost/2010-09-13/Dispatches

— Dispenser 21:51, 17 September 2010 (UTC)

I will check into those issues. I will also make a better image for the Signpost. Thanks for notifying me, Cacycle (talk) 22:47, 17 September 2010 (UTC)

These are the fixes I have made to the next release 0.9.92. Please note that the config variable scheme will change with that release from wikEdXyz to wikEdConfig.xyz (also note upper/lowercase).

• Relative paths: wikEdConfig.linkifyArticlePath = 'http://test.wikipedia.org/wiki/$1'; ("$1" is an article name placeholder).
• Toolbar: The UI toolbar now closes when the wikEd button is pushed.
• Auto summary: #R does not fill out the summary if $wgUseAutomaticEditSummaries == true.

Cacycle (talk) 18:02, 18 September 2010 (UTC)

Image adding button is broken

It gives [[filename)">Image:filename|thumb|widthpx| ]] can you please fix? Thanks Doc James (talk · contribs · email) 05:52, 18 September 2010 (UTC)

It's already fixed for the next release. Thanks, Cacycle (talk) 15:41, 18 September 2010 (UTC)

Great Doc James (talk · contribs · email) 17:05, 18 September 2010 (UTC)

Fixed in version 0.9.92. Cacycle (talk) 06:02, 23 September 2010 (UTC)

"This is a minor edit" box suddenly moved down, away from edit summary

A few minutes ago, the box moved, and is now below the boilerplate copyright notice, I am using Firefox 3.6.10, and have been for weeks, at least. The box moved about the same time as 0.9.92 was installed here? This is rather inconvenient, as it involves even more scrolling in order to finish an edit. Chris the speller (talk) 00:21, 23 September 2010 (UTC)

I noticed this also. IMO it's not just inconvenient, it's a royal pain in the *** because the minor edit box also ends up beneath the wikEd preview. The "watch this page" box joins it down there. I am using whatever the latest version of Firefox is currently, and I'm using Monobook over on Wikia. I really hope this is fixed quickly. Also while you're at it, those two boxes have always been down there when adding a new section (i.e. &section=new in the URL); I'd appreciate it if that could be fixed as well. Thanks. 99.139.149.215 (talk) 02:18, 23 September 2010 (UTC)

Sorry, this is not intentional and I will fix it as soon as I find the time. BTW, you can close the preview box with a double click. Cacycle (talk) 06:06, 23 September 2010 (UTC)

Fixed in 0.9.93. Cacycle (talk) 14:27, 26 September 2010 (UTC)

Superb! Chris the speller (talk) 00:48, 27 September 2010 (UTC)

Thanks! 99.139.149.215 (talk) 03:55, 27 September 2010 (UTC)

Stopped working altogether this morning

Was working fine last night, gone this morning. Details: Installed as gadget in Monobook in Firefox 3.6.10 under XP, all fully updated. Also checked with IE, not working there, either. Regards, TRANSPORTERMAN (TALK) 14:11, 23 September 2010 (UTC)

Update: Am getting the following javascript error:

Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 1845"]

— TRANSPORTERMAN (TALK) 14:25, 23 September 2010 (UTC)

Same here (Firefox 3.6.10 openSUSE, at de.wikipedia): Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript Line: 1845"]

Cheers --Saibo (Δ) 16:43, 23 September 2010 (UTC)

Which line of code does it point to if you click the link in the error message? If it is the one with "window.localStorage": what happens if you re-enable offline storage under Tools :: Options :: Advanced :: Network :: Offline Storage with a reasonable number of MB? Cacycle (talk) 21:39, 23 September 2010 (UTC)

There's no link, it's all plain text, and my offline storage was already enabled with 50MB. Regards, TRANSPORTERMAN (TALK) 00:04, 24 September 2010 (UTC)

You have probably disabled offline storage in about:config. Try to load about:config in your browser and set dom.storage.enabled to true. I will also hack a wrapper into the code so that wikEd will run fine even if that error is triggered. Thanks for reporting, Cacycle (talk)

The dom.storage.enabled setting was the key. Are you saying that the wrapper will allow wikEd to run even if dom.storage.enabled is set to false? Regards, TRANSPORTERMAN (TALK) 13:50, 24 September 2010 (UTC)

Yes. I have also filed a Firefox bug report: Bug 599479. Cacycle (talk) 20:28, 24 September 2010 (UTC)

I checked and also had dom.storage.enabled == false. Probably it was (and keeps!) disabled due to privacy concerns or by my Addon BetterPrivacy. WikEd works if I enable it temporarily. Thanks you very much, Cacycle! Cheers --Saibo (Δ) 01:51, 25 September 2010 (UTC)

I have fixed this by adding a Firefox bug workaround. But that said, it does not make sense to me to disable DOM storage per config setting, they work like improved cookies in that they do not send your private data out with *every* page request (for everybody to sniff on the network!). Cacycle (talk) 14:26, 26 September 2010 (UTC)

Thanks again, it works! As long as there is no easy option to see and manage those DOM cookies I dislike enabling them. Or do they appear in the normal cookie list? Cheers --Saibo (Δ) 21:14, 26 September 2010 (UTC)

Tools - > Options -> Advanced -> Network. Cacycle (talk) 21:38, 26 September 2010 (UTC)

Thanks! I enabled it and will see what I can config there. In addition I have read that the add-on BetterPrivacy simply empties DOM storage periodically - so it is okay with it. Cheers --Saibo (Δ) 14:23, 28 September 2010 (UTC)

Appropedia

It stopped working for me too, on Appropedia - I tried about 2 days ago and there's no sign of the wikEd boxes, but it may have stopped weeks ago for all I know, as I hadn't used it since Aug 20.

I've got it set up to work on a single page, here. The code is at appropedia:MediaWiki:Common.js. I've tried it in two different Mozilla browsers (Firefox 4 and Swiftweasel 3.6, both on Linux). Any ideas? Many thanks --Chriswaterguy talk 17:58, 25 September 2010 (UTC)

That's because wikEd detects the FCKeditor ("Rich Editor") that is installed on Appropedia (see the wikEd logo hover error message). Cacycle (talk) 20:48, 25 September 2010 (UTC)

Ah thank you. Hadn't noticed the wikEd logo before - very handy for troubleshooting.

Is this a new incompatibility? We've had the FCKEditor installed for ages (more than a year I think), and wikEd only broke sometime after Aug 20. If so, is there a way we could load an old version of wikEd?

Thanks again for an awesome tool. --Chriswaterguy talk 21:24, 25 September 2010 (UTC)

Not sure if you changed something, but if so, thanks - it's working now. --Chriswaterguy talk 09:25, 26 September 2010 (UTC)

You can use the config setting "var wikEdConfig = { 'skipScriptTest': true };". And I had not changed anything. Cacycle (talk) 14:20, 26 September 2010 (UTC)

Do you mean I add this line to appropedia:MediaWiki:Common.js somewhere within the wikEd wikEd import code? I can't tell where it should go. --Chriswaterguy talk 12:12, 27 September 2010 (UTC)

Yes. But edits will get lost when switching from wikEd directly to FCKeditor, one has to toggle wikEd off manually before switching. Cacycle (talk) 19:17, 27 September 2010 (UTC)

Click to disable

I have a problem when disabling the wikiEd during editing.

Clicking the wikEd logo button “Click to disable” (in the first line of the page) during editing causes the disappearance of the wikEd-specific buttons above the edited text. This is expected behavior and is similar to that of the button “Toggle between classic text area and wikEd”.

However, the line containing the standard editing buttons above the edited text disappears as well. This is not correct.

Karmela (talk) 20:15, 25 September 2010 (UTC)

Fixed in 0.9.93 (September 26, 2010). Thanks, Cacycle (talk) 14:17, 26 September 2010 (UTC)

Thanks for Your fast reaction! Karmela (talk) 17:43, 26 September 2010 (UTC)

Firefox 4 clash?

I was using wikEd no problem in my Firefox 3 series browsers, including current Swiftweasel for Linux: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20090921 Firefox/3.5.3.

However when I use the wikify button in Firefox 4 Beta for Linux - Mozilla/5.0 (X11; Linux i686; rv:2.0b6) Gecko/20100101 Firefox/4.0b6, downloaded from Mozilla, not via repo - the browser hangs, and the RAM usage of the firefox process cycles up and down. I tried waiting for 10 minutes, one time even 30 minutes, but it didn't recover. I have to kill the process via my system monitor.

I get this in:

• Appropedia (setup as mentioned above - when I said it was working, I meant the buttons had appeared, but I hadn't used "wikify" yet)
• in Wikispecies, via settings in the .js for the skin I use there: species:User:Chriswaterguy/simple.js
• in Wikipedia, where I have wikEd selected in my preferences (at least I think so - I can check if you need, but have to run now)

Thanks again --Chriswaterguy talk 12:41, 26 September 2010 (UTC)

Works for me on Wikipedia under Windows 4.0b7pre and wikEd 0.9.93a. Cacycle (talk) 21:54, 26 September 2010 (UTC)

I've been playing with this, but can't find a consistent pattern. (Now using Firefox 4.0b7.)

Here are screenshots of the failure, with content copied from this page, here and from the wikEd instructions page, and text from an Archive section (on a Wikipedia page, I can't recall where).

Some weird things I've found - when I removed the "to" in the wikEd instructions example, it works - so at first I thought there was something about the space character causing a problem. But at times, it has not worked even with spaces (on both the header line and the one below, or not worked even when removed. Just now I repeated the with the same text as that wikEd instructions example, reming the to (and the trailing space) and this time it didn't work.

I've never been able to get a conversion of the yellow box in the first screenshot, but if I copy the contents of the box and just convert those, it sometimes works.

That may or may not be useful to you - for now I'll just use another Mozilla 3.6 based browser when I need wikEd. Thanks. --Chriswaterguy talk 16:53, 3 December 2010 (UTC)

Please could you check if it works under Linux on Wikipedia and under Windows on Appropedia? I highly suspect an incompatibility with the "Rich Editor". Actually, the current version of wikEd does not load and displays a warning if it detects that Rich Editor (aka FCKEditor). What happens if you disable loading of the Rich Editor under Preferences::Misc? Cacycle (talk) 12:21, 4 December 2010 (UTC)

Ctrl click not working on wikilinks

Hi, in the last few days the ability to ctrl and click on wikilinks in the editing window seems to have stopped working. I haven't changed anything in my browser and the function still works for weblinks. I'm using firefox 3.0.15 if that makes any difference. Cheers Smartse (talk) 16:45, 26 September 2010 (UTC)

It works for me... Does it persist if you update to the newest version (Shift-Reload)? If not, would you mind filling out a bug report (see the form at the top of this page? Thanks, Cacycle (talk) 19:37, 27 September 2010 (UTC)

Hmm, it's still not working after updating. My version = 0.9.93c G, browser = firefox 3.0.15, OS = Windows Vista, skin + scripts = User:Smartse/vector.js (Friendly, checklinks, reflinks, dykcheck and igloo)

Console errors (when loading this section):

Extended content

Warning: Unknown property 'word-wrap'. Declaration dropped. Source File: http://en.wikipedia.org/enwiki/w/index.php?title=MediaWiki:Common.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=2678400&action=raw&maxage=2678400 Line: 49 Warning: Unknown pseudo-class or pseudo-element '-webkit-input-placeholder'. Ruleset ignored due to bad selector. Source File: http://bits.wikimedia.org/skins-1.5/vector/main-ltr.css?283u Line: 368 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 18 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 74 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 76 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 282 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 283 Warning: Unknown property 'zoom'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 285 Warning: Error in parsing value for property 'filter'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 347 Warning: Unknown property 'zoom'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 360 Warning: Unknown property 'zoom'. Declaration dropped. Source File: http://bits.wikimedia.org/enwiki/w/extensions/UsabilityInitiative/css/vector/jquery-ui-1.7.2.css?1.7.2y Line: 398 Warning: Error in parsing value for property 'font-size'. Declaration dropped. Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=47 Line: 0 Warning: Expected end of value for property but found ':'. Error in parsing value for property 'float'. Declaration dropped. Source File: http://en.wikipedia.org/enwiki/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&section=47 Line: 83

I've tried using the old skin and disabling my add ons (Adblock Plus 1.1.1, HTTPSeverywhere and wpcite) and it still doesn't work. Simple to reproduce (for me) open an edit window, ctrl click on a wikilink and it doesn't do anything, as I said before, ELs do still work. I'm afraid I'll be away for a couple of weeks from tonight so won't be able to answer any queries you have til then. I'll check back here once I'm editing again. Thanks for writing and maintaining such a useful tool! Smartse (talk) 22:58, 1 October 2010 (UTC)

Then it is probably a bug in your outdated browser version. Since using an outdated browser is a huge security risk, I'd suggest to update the browser and to enable automatic updates. Please could you report back if it works after that? Thanks, Cacycle (talk) 14:35, 7 October 2010 (UTC)

Ok thanks, I'll update. Just tried it again and it works again now, even in the old version that I'm still using, so something else must changed with the other updates since. Anyway problem solved, so thanks! Smartse (talk) 19:06, 17 October 2010 (UTC)

wikEdDiff not working without wikEd

I use wikEdDiff without the rest of wikEd. Since you fixed the problem reported in #Stopped working altogether this morning the Delta appears again and works on normal diffpages. But when I edit something and use "Show changes" the Delta button on the following diffpage only produces this entry into the error console: wikEd.wikiGlobal is undefined Quelldatei: http://en.wikipedia.org/enwiki/w/index.php?title=User:Cacycle/wikEdDiff.js&action=raw&ctype=text/javascript Zeile: 477. I use Firefox 3.6.8 (Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 ( .NET CLR 3.5.30729; .NET4.0C), but I don't think that this has anything to do with the bug. --Schnark (talk) 08:39, 27 September 2010 (UTC)

Fixed, please Shift-Reload to update. It was a typo. Thanks for reporting! Cacycle (talk) 19:36, 27 September 2010 (UTC)

Disable function not working

Usually, when I first log on, I click the "disable" button, the WikiEd function turns off and stays off (unless I toggle it back on again). Recently, however, even after I initially turn it off, it turns on again each time I go to a new page. FYI, I use the Monobook skin on Mozilla Firefox 3.6.3. Dabomb87 (talk) 02:30, 28 September 2010 (UTC)

Fixed in 0.9.93c. Thanks for reporting, Cacycle (talk) 21:46, 28 September 2010 (UTC)

wikEdDiff.js have a DOM Exception 8

• Browser: Chrome 6 (& Firefox 3.6.10)
• Script: wikEdDiff.js (0.9.11)
• Line: 1127
• Console: Uncaught Error: NOT_FOUND_ERR: DOM Exception 8

Please, check variable 'script' by null.--Frozen-mikan (talk) 06:59, 29 September 2010 (UTC)

Fixed in wikEdDiff 0.9.11c. Thanks, Cacycle (talk) 21:43, 29 September 2010 (UTC)

Hiding image preview

I used to have this code in my vector.js, and it worked:

var wikEdFilePreview = false

Why is it no longer working? The file previews are getting really annoying. — Train2104 (talk • contribs • count) 02:25, 2 October 2010 (UTC)

It is now var wikEdConfig = {'filePreview': false };. Please see also the announcement on top of this page and the wikEd customization page for details. Cacycle (talk) 08:40, 2 October 2010 (UTC)

After clicking preview button redirect to Main_page

(Moved from User_talk:Cacycle/wikEd_dev). Cacycle (talk) 09:53, 2 October 2010 (UTC)

Thanks for great plugin. I have installed wikEd as Gadget for http://ta.wikinews.org/enwiki/w/index.php?title=%E0%AE%AE%E0%AF%81%E0%AE%A4%E0%AE%B1%E0%AF%8D_%E0%AE%AA%E0%AE%95%E0%AF%8D%E0%AE%95%E0%AE%AE%E0%AF%8D&action=historysubmit&diff=9839&ids[9839]=1&oldid=9838&ids[9838]=1, whenever i create a new page and clicking the preview button of WikEd, then clicking on Normal Preview button it replaces Main page content. Can u pls help me to fix. -- Mahir78 (talk) 16:50, 26 September 2010 (UTC)

I have tried to replicate this bug and it seems to be fixed in the newest version 0.9.95a. Would you mind to test and verify this? Thanks in advance - Cacycle (talk) 20:46, 13 October 2010 (UTC)

Thanks for your response. but still seems not working, I tested with this version 0.9.95b. [3] Am I doing anything wrong? -- Mahir78 (talk) 17:58, 15 October 2010 (UTC)

sorry it worked perfectly, but i had issue in http://ta.wikinews.org/wiki/User:Mahir78/முதற் பக்கம் page only where முதற் பக்கம்=Main Page, may be an issue in that page not in your script. -- Mahir78 (talk) 18:49, 19 October 2010 (UTC)

Suggestion:Math quick insert

I often need to write math formulas, and am tired of write tags ${\displaystyle }$.Could you add a button in wikEd to quick insert the tag? I don't wanna scroll down.--Netheril96 (talk) 13:27, 4 October 2010 (UTC)

Thanks for your suggestion. It is probably too specialized to be inserted into the standard wikEd toolbar. However, you can add it for yourself as a custom button as described on User:Cacycle/wikEd_customization#Custom_buttons. Good luck, Cacycle (talk) 15:48, 7 October 2010 (UTC)

I tried the customized button, but it didn't work. I copied the exactly same code from your example to my monobook.js, changed my appearance to MonoBook and Shift-Reload, but no more button appeared. What is wrong?--Netheril96 (talk) 09:23, 16 October 2010 (UTC)

There are no linebreaks on User:Netheril96/monobook.js, making the whole code a comment line. Cacycle (talk) 23:36, 6 November 2010 (UTC)

integrate into vector toolbar

Is it possible to integrate wikEd functions into the new modern light blue toolbar? Matthias M. (talk) 07:52, 6 October 2010 (UTC)

Everything is possible... But I am not sure if that makes sense at this time. The Vector/beta tools are brand new. They have probably not stabilized enough to rely on for such an integration, and, most importantly, are not yet installed on most MediaWiki installations. Therefore, wikEd would still need its own toolbar as a backup. Also, the "design philosophy" of both toolbars is fundamentally different: The vector toolbar tries to hide as much functionality as possible to keep the bar simple for beginners. In contrast, wikEd tries to keep as many useful tools in sight as possible to speed up editing for experienced editors. This results in a much more bloated user interface, smaller buttons, and the absence of menus. But if somebody could convert the button images to vector format that would be greatly appreciated... 07:30, 7 October 2010 (UTC)

URLs in diffs not clickable within a cite template

Hi, Cacycle; thanks for your great add-on. I appreciate your work, very much. I created a bugzilla account, btw, and "voted" for everything I could. Couldn't figure out how to vote for WebKit Bugzilla 34377, though; there doesn't seem to be a "vote" button there. Anyway, I do have a feature-request or a bug-report, depending on one's perspective:

Say you're looking at a diff of a deletion edit where someone has left the edit summary, "Not supported by source cited". So you want to look at the URL for the source to verify that. If the ref was given as just a bare URL between two "ref" tags then all you have to do is click on the URL to open it, courtesy of wikEd, as you know. (I really like that feature, btw; it's really convenient.)

But if the URL is embedded within a "cite" template then the URL won't be "clickable". If you try to click on it you'll get directed to Template:cite_news or Template:cite_web or whatever. And if you try to "highlight" the URL with your mouse so you can copy-paste it to your browser's "destination address" field, you'll find that you can't easily do so: The highlighting behavior is all wonky, and you'll invariably end up grabbing more characters than you want. You'll have to paste the whole mess that you're able to grab into your browser's "destination address" field, and then trim off the extra characters there before trying to access the web site. This makes verifying sources from diffs much harder than it needs to be.

Here's a diff where I encounter the problematic behavior. The first ref to The Guardian occurs without a "cite" template being used, and I can click on the target URL to reach the corresponding web page. The second ref to The Guardian occurs within a "cite news" template, and clicking on the URL there just takes me to Template:cite_news. Further, wherever I "hover" over the cite template in a diff I always have the "hand" icon for my cursor, never the "vertical line" ("select text"?) cursor. When I uninstall wikEd I get just the "select text" cursor over the cite template, or course, (i.e. the default MediaWiki behavior). But I also lose the on-click behavior associated with URLs that aren't embedded in a "cite" template.

With wikEd installed, the only way I can grab part of the contents (e.g. a URL) embedded within the cite template is to start with the cursor placed outside the darker green "diff column" on the right (in my example link), press the mouse button, and then move the cursor into the darker green diff column. In the example I've given here the resulting behavior is predictable and unsurprising: As I move the cursor horizontally across the darker green diff column, text is progressively highlighted in the direction corresponding to the direction of travel of my mouse/cursor. In other instances, though, the behavior as to what gets highlighted as I do so is not predictable; sometimes a dozen or more lines will be highlighted. I haven't been able to figure out what differentiates the circumstances in which the "predictable" versus the "wonky" behavior in this regard occurs, btw.

I'm using wikEd 0.9.94b G (October 3, 2010), with Firefox 3.6.10 on Ubuntu Linux 8.04 ("Hardy Heron") with all updates installed. I have the usual Ubuntu Firefox Modifications Pack version 0.9rc2 installed; I believe this is the default for Ubuntu users. I also have Adblock Plus 1.2.1 installed, and two other add-ons, Ghostery 2.2.1, and "TACO with Abine" ver 3.10. These latter two are privacy and cookie opt-out browser add ons. I'm using the MonoBook skin, no scripts, and am not using Wikpedia Beta. Thanks again for your fine work; I really appreciate it. Best,  – OhioStandard (talk) 02:19, 8 October 2010 (UTC)

I second that. In general, would it be possible to restrict the extent of wikEdDiff-inserted links to templates only to the actual template names, excluding their parameters?—Emil J. 11:32, 8 October 2010 (UTC)

It already works for me exactly as you both request. Maybe a browser issue? I use wikEd 0.9.94c in Firefox 3.6.10 and Chrome 6.0.472.63 under Windows XP. Cacycle (talk) 21:53, 8 October 2010 (UTC)

Well that's strange. We're using the same version of Firefox, and I'm using wikEd 0.9.94b. ( I'd try installing "c", but don't know how: I just have the "gadget" enabled in my Wikipedia "preferences". ) I've tried resetting my Wikipedia preferences to the default, and looked at everything else I can think of, as well. Is it an O/S specific thing, then, I wonder, i.e. does Firefox 3.6.10 for Ubuntu Linux differ enough from the same version number for WinXP to cause the problem? @Emil J, what operating system, browser and browser version, wikEd version, WP skin, etc. are you using?  – OhioStandard (talk) 05:53, 9 October 2010 (UTC)

Firefox 3.5.5, Linux (Fedora Core 6), wikEd 0.9.94b G, Vector.—Emil J. 15:01, 10 October 2010 (UTC)

BTW, if it helps, I noticed that internal links within templates do work as expected: in this diff, the link to Template:cite news in the second ref spans up to the "...|work=" (including the text of the intervening url), then [[Ministry of Foreign Affairs (Norway)]] is linked to itself, and the rest of the template is not linked to anything.—Emil J. 15:10, 10 October 2010 (UTC)

Thank you, Emil. Yes, I see the same behavior. A wikilink "truncates" the thrall spell that the evil cite template holds over the lowly parameters. Either that or it's a plot by Steve Balmer to get us to switch back.  – OhioStandard (talk) 16:45, 10 October 2010 (UTC)

It's now fixed as suggested in 0.9.95. Plus: all other diffs are now linkified too. Sorry that I didn't realize earlier that you were talking about diffs and not the edit text. (You might have to Shift-Reload [this page) Cacycle (talk) 22:46, 10 October 2010 (UTC)

Thank you for your work! Links in the improved diff below the delta button now work correctly. However, the old MediaWiki diff is now not linkified at all. Was this intended?—Emil J. 16:02, 11 October 2010 (UTC)

Strange, it worked yesterday... I'm on it... Cacycle (talk) 22:05, 11 October 2010 (UTC)

Fixed in 0.9.95a. Cacycle (talk) 06:45, 13 October 2010 (UTC)

Excellent. Thank you very much!—Emil J. 14:54, 13 October 2010 (UTC)

		The Sherlock Holmes Award for Exceptional Sleuthing to Discover an Obscure and Hard-to-Reproduce Software Malfunction
		Conferred for your tenacity in tracking down and correcting an obscure bug in wikEd, your extraordinary editor of outstanding and excellent excellence! We Linux users often get short shrift from developers and would have been all to seek without your very thoughtful assistance and your willingness to take the time to understand and correct a bug resulting from a rather complex series of interactions. Thanks for your fine editing tool (it makes Wikipedia editing ever so much more fun!) and for fixing the bug that was keeping some of us from enjoying it to the full. You should be very proud of your fine contribution. Thanks!  – OhioStandard (talk) 15:07, 14 October 2010 (UTC)

I'm moved, thank you! :-) Cacycle (talk) 21:37, 14 October 2010 (UTC)

define keyboard shortcuts

Hello Cacycle, I read wikEd customization and this Q&A but I am unable to define any keyboard shortcuts for WikEd. I would like to set up Alt+Shift+P to be my preview shortcut - or maybe another key. I tried the examples but they did not work.

Could you please give me a hint? Which lines do I have to add to my monobook.js (yes I am using the monobook skin)? Is "var wikEdConfig = {};" required for any customization again? Thank you! --Saibo (Δ) 16:14, 8 October 2010 (UTC)

Please use wikEdConfig.buttonKey instead of wikEdConfig['wikEdButtonKey']. I have corrected the customization page. The definition var wikEdConfig = {}; must only be used once, otherwise you would overwrite your previous customization. I have added that too. Sorry for the trouble, Cacycle (talk) 21:05, 8 October 2010 (UTC)

Thanks for correcting! Is the replace all example working for you? If I use it and press ctrl+alt+a it just marks all text in the text box. (Firefox 3.6.10 on Linux) I had a look at the shortcut list of Mediawiki. Apparently nearly all keys are already taken. Does the WikEd config then overwrite the Mediawiki keys? Cheers --Saibo (Δ) 01:24, 10 October 2010 (UTC)

Of course it works, 'replace all' with nothing in the find and replace boxes results in an unchanged, fully selected text. And yes, it overwrites the MediaWiki shortcuts. Cacycle (talk) 17:53, 10 October 2010 (UTC)

Oooh - sorry for being stupid.

But where to find the button codes? I looked in User:Cacycle/wikEd.js and searched for "format top". There are some codes. But no code for preview. Where to find it? Maybe you can add a pointer where to find the codes to your manual.

However, I tested it with "jump to preview" now: It works but the shortcut of Mediawiki is also active. So if I hit Alt+Shift+p it jumps to the Wiked preview position but also - short after - reloaded the whole page to show the Mediawiki preview. Cheers --Saibo (Δ) 21:44, 10 October 2010 (UTC)

I will try to find a way to disable the built in accesskeys. Cacycle (talk) 21:56, 11 October 2010 (UTC)

This should work now in 0.9.95b. Cacycle (talk) 22:33, 13 October 2010 (UTC)

You are great! Thanks a lot. Now only the WikEd function is executed when pressing the shortcut.

But, how to find the button number for the WikEd Preview? Cheers --Saibo (Δ) 22:15, 17 October 2010 (UTC)

I don't understand it either. How do I know the number for a particular WikEd button? And can I assign a shortcut other than Alt+Shift+Something? That is too long.--Netheril96 (talk) 09:11, 16 October 2010 (UTC)

You have to check the program code (under User:Cacycle/wikEd.js) starting with "// format top", currently in line 873. Currently, you can only use accesskeys. Cacycle (talk) 21:09, 19 October 2010 (UTC)

Do I see this correctly that there is no number for the WikEd preview button? Cheers --Saibo (Δ) 12:10, 25 October 2010 (UTC)

Yes - sorry. Cacycle (talk) 22:08, 25 October 2010 (UTC)

Thanks - although it would be useful! :) Added this info to wikEd customization. Feel free to revert. Cheers --Saibo (Δ) 02:07, 30 October 2010 (UTC)

I have added numbers to the local preview and local diff buttons (82 and 83) in wikEd 0.9.95c. Cacycle (talk) 22:58, 1 November 2010 (UTC)

Thank you! Works perfectly now! Cheers --Saibo (Δ) 03:40, 12 November 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)

Matching error at linkify links and templates

• 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)

Links in diff link to template

Safari 5.0.2 (6533.18.5). The wiki-links in the diff link to the template of that link, so if the diff has [[Joss Whedon]] and I click it I go to [[Template:Joss Whedon]]. Templates aren't clickable at all, so this doesn't work at all, which would be extremely helpful. c Not sure when it started acting this way, maybe a week or so ago. Any thoughts?

Also, quick diff (Is that the name?) and quick preview haven't worked for a long time, I think since Safari 5. Thanks. _Xeworlebi ^(talk) 17:07, 18 October 2010 (UTC)

Will check, but it will take a while. Safari 5 seems to have several issues. Cacycle (talk) 20:49, 19 October 2010 (UTC)

Mostly fixed in 0.9.95c, still working on wikEdDiff for Safari 5... Thanks for reporting, Cacycle (talk) 23:06, 1 November 2010 (UTC)

Thanks. _Xeworlebi ^(talk) 12:37, 2 November 2010 (UTC)

DiffLinkify: external links fixes

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

• Interface: User:IGW/wikEd_international_ru.js (for this version, last on this moment);
• Main page (partly): ru:user:IGW/wikEd (for this version);
• Help: ru:user:IGW/wikEd помощь ( for this version).

--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/enwiki/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)

• Just putting in a link to a topic on wikia-central forum about this issue: (for reference)
  Forum:Anyone still able to use WikEd?
  ⇐⇑©TriMoon™ Talk @ 18:08, 21 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 Levels^Talk 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/enwiki/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: [4]. 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 [5] 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:

• Messages: User:SpeedyGonsales/wikEd_international_hr.js
• Main page: hr:User:SpeedyGonsales/wikEd (work not finished, but somewhere you need to start :))

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)