Jump to content

User talk:Cacycle/wikEd/Archive 012

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


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)

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

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/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/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/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/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;
[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)

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)

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 wiki.riteme.site.
  • 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 wiki.riteme.site."
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)

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 [REF, TEMPL 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)

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 Syntax button, update/textify pasted text with the Textify button, and wikify pasted text with the Wikify 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 Textify 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)

The Feature: Pasting, import, and wiki code conversion of formatted text, is also a hard (horrible) problem for me, it makes WikEd unusable! Do you have a option to deactivating this feature? Best regards --Perhelion (talk) 20:16, 24 June 2011 (UTC)

That is also a problem for me: I need the format import only in about 0.5% of all cases (in those 0.5% it is useful). In 99.5% I have to paste it first in a plain stupid texteditor to get rid of formatting (especially titles of files) and then paste in WikEd. The [T] button works but needs also an additional click and mostly inserts unnecessary line breaks. Cheers --Saibo (Δ) 21:03, 24 June 2011 (UTC)

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://wiki.riteme.site/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://wiki.riteme.site/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)

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)

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!--OsamaKReply? 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 /w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:10382
window.WikEdHighlightSyntax /w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:10382
window.WikEdUpdateFrame /w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:12699
window.WikEdTurnOn /w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:3032
window.WikEdMainSwitch /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:

— 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]] 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://wiki.riteme.site/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://wiki.riteme.site/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)

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://wiki.riteme.site/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/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/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/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/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/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/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/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/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/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://wiki.riteme.site/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://wiki.riteme.site/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://wiki.riteme.site/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/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 .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)
Retrieved from "https://wiki.riteme.site/w/index.php?title=User_talk:Cacycle/wikEd/Archive_012&oldid=1140403351"