This is an archive of past discussions with User:Cacycle. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Latest comment: 16 years ago3 comments2 people in discussion
Frequently we prefer that the first row (and, less frequently, the first column) of a table to be wiki-ized as headers, i.e., with '!' delimiters instead of '|'. Do you have a way to make this happen by editing the rich text appropriately? If not, here are some suggestions:
If a cell is all bold, give it header style.
If the variable wikEdWikifyTableHeaderRow = true then header-ize first row
If the variable wikEdWikifyTableHeaderCol = true then header-ize first column
I like #1 the best, but of course this is your wikEd invention!
Latest comment: 15 years ago2 comments2 people in discussion
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)
Latest comment: 15 years ago2 comments2 people in discussion
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! Reywas92Talk00:31, 24 May 2009 (UTC)
Req: Sort (and normalize?) list entries contained in a single line
Latest comment: 13 years ago4 comments3 people in discussion
Hi! I've got a feature request for you. Hope it hasn't been up for discussion before (boy was that ToC long – didn't dare to cast an eye on the archives too..!) Sometimes, in navboxes for instances, there are lists contained in a single table cell (e.g., Template:Beta blockers, delimited by various methods involving a bullet. Could you make the sort function sort these single-line lists somehow?
Also, if possible, normalization would be neat to ensure that the method used for separating the entries (I guess " • " is the most common version) is consistent for a given line. Sometimes there is a bullet first on the line, where it's not supposed to be, sometimes people forget the or add double spaces after the item, etc. Sometimes this can make editing the list a minor nightmare.
For now, I sorted the Template:Beta blockers by replacing the bullet stuff with newlines, opening up another WikEd tab and sorted the newly-created lines, then re-replaced the newlines with the bullet goo and pasted back in the first tab. Not so practical. :) W n C? 11:35, 23 February 2011 (UTC)
A workaround is to replace "• " with "•\n" (regex mode) then sort it afterward undo the replacement. Now I've been asked to add extra sort method (sort by last name, date, link title) to Dab solver, it would be nice to have a more powerful sorting interface. — Dispenser04:25, 2 March 2011 (UTC)
Oddly, single-line sorting doesn't seem to work for me now anymore (Safari 5.0.5, OS X 10.6.7). It just seems to mess around with the whitespace. Tried it on Template:Peripheral vasodilators. Doesn't help if I replace the • with e.g. {{•}}, either (though I do think WikEd could clean the ampersand mess up though, but maybe that's just wishful thinking. ;) ). W n C? 12:55, 16 June 2011 (UTC)
Extra line is inserted with regular expression replacement function if text ends a line
Latest comment: 10 years ago7 comments4 people in discussion
Happens first time, every time. Suppose I change from blogg to blog (UTC), where 'blogg' is at the end of the line. It works fine unless the regular expression button is pressed. Then an extra, blank line is inserted. Same with changing \w\wogg to blog. Text in the middle of the line works fine with or without regular expressions. Firefox 3.615 on Windows Vista, my only gadgets are Navigation popups and WikEd. Christhe spelleryack19:00, 8 March 2011 (UTC)
Just to let you know that this is still a problem, and it effectively stopped me from cleaning up an article with a very long list. I can let the article wait, or do a whole lot of deleting lines by hand. Christhe spelleryack00:34, 25 June 2011 (UTC)
I omit this bug by adding "\n" at the end of the RegExp "Find" field and at the end of the "Replace" field. But it works only if You know and want to find expressions at the end of line. If that expressions are not only at the end You can add (\n?) to "Find" field and $1 (in the simpliest case) to "Replace" field. BUT: that doesn't changes the fact that I'd love that bug to be removed... q;) Vinne2 (talk) 19:10, 13 August 2011 (UTC)
The problem still persists and is rather annoying... However, while this doesn't work right in Firefox 23.0.1, there is no problem in Chrome 29.0.1547.57. GregorB (talk) 14:22, 21 August 2013 (UTC)
Latest comment: 10 years ago3 comments2 people in discussion
Hello! I'm using the WikEd, which is integrated into the German Wikipedia on Firefox 4.0 and Windows XP. I know the following two problems:
When I remove a term which is framed by ''', the cursor will skip the last '''.
The cursor also sometimes skips an entire line, after removing a term, which is framed by square brackets for instance.
I experience the same bug in the English Wikipedia. It is easily reproducible. Access the article Ermine_Street and try removing words out of any tag letter by letter. See what happens. --Aetas volat. (talk) 09:16, 29 April 2011 (UTC)
I will try if I can fix the first problen (it's a really tricky one). The second one seems to be a strange Firefox bug. Cacycle (talk) 21:19, 8 May 2011 (UTC)
Latest comment: 10 years ago5 comments2 people in discussion
wikEd version: 0.9.99 G; browser: Firefox 6.0; no JS errors in the console; skin: Vector; addons and other scripts: several, but problem persists when they are all disabled.
When I edit the page Template:Navbox with columns (unprotected copy at User:Ucucha/sandbox), a few empty comments get removed before I make any change to the wikitext. See the revert here. This can be reproduced by editing the page and clicking "Show changes"; it will show that these two comments are removed. This no longer happens when I disable wikEd and it does happen when I disable all other scripts and browser add-ons I have. Ucucha (talk) 23:17, 22 August 2011 (UTC)
Had to roll this back in 0.9.100a, but will hopefully be able to finally fix it soon. It is actually not a trivial problem... Cacycle (talk) 07:18, 7 September 2011 (UTC)
StasFomin: This seems to be a Chrome or MediaWiki problem. Under Firefox, the hotkey events do fire when editing inside wikEd's iframe. This is not the case under Chrome. The hotkeys do work if you have the focus outside the iframe. Cacycle (talk) 18:22, 6 May 2014 (UTC)
Problem with Word
Latest comment: 10 years ago3 comments3 people in discussion
Hello, when I copy text from MS Word 2010 or 2007, and then when i publish it, this sentence : Normal 0 21 false false false FR X-NONE AR-SA apperas on the top of my text. You can see that here
Little search & replace bugs in regual expression mode
Latest comment: 10 years ago3 comments2 people in discussion
When you try to search for a regular expression from the history drop-down list, it won't work if it contains a space. However, if you replace that space with a new space, it works. Example: search for the history in Regular expression mode. Now search for something else, then try to search for the history again by selecting it from the drop-down list. It won't work. Replace the space between the and history with another space. Now it works again.
When replacing text at the end of the line in Regular Expression mode, an extra new line is inserted after the replacement.
V111P: I have finally fixed both problems. For the second problem I reverted the "setEndNode testfix" introduced in version 0.9.99 (March 03, 2011). Cacycle (talk) 10:08, 7 May 2014 (UTC)
Latest comment: 10 years ago4 comments3 people in discussion
What exactly does the "fix dashes" function do? It doesn't seem to do much of anything related to dashes (for example it doesn't change spaced hyphens to spaced en dashes). It does, however, make totally unnecessary and annoying whitespace changes. Is its function supposed to be at all similar to dashes.js? —danhash (talk) 15:01, 10 April 2012 (UTC)
Currently, it does the following:
convert html character entities into actual dash characters
remove spaces around em dashes
convert -- to em dashes
convert hyphen next to lone number into a minus sign character
convert hyphen next to lone number into a minus sign character
This means "-([0-9]+)" → "−$1" (in regex, ignoring the quotes), right?
convert minus or en dashes to dashes with spaces
Does this mean "([^ ])[−–]" → "$1 –" and "[−–]([^ ])" → "– $1" (i.e. "dashes" means "en-dashes")? If so, the first replacement should have a " " instead of a space (0x20) per the MOS. Also, unspaced en-dashes are appropriate for some ranges of dates and other numbers.
convert dashes to en dashes in dates
What exactly does this mean?
Thanks. Any progress on this? It would be nice to not have to manually fix dash issues.—[AlanM1(talk)]— 15:16, 15 April 2013 (UTC) (edited —[AlanM1(talk)]—23:22, 8 June 2013 (UTC))
// convert hyphen next to lone number into a minus sign charactervarregExp=newRegExp('(['+wikEd.letters+'\'"”\\]>] ) *(\\u2212|–)(\\d)','g');obj.plain=obj.plain.replace(regExp,'$1\u2212$3');// convert minus or en dashes to dashes with spacesvarregExp=newRegExp('(['+wikEd.letters+'\'"”\\]}])( | )*(\\u2212|–)( | )*(['+wikEd.letters+'\'"“\\[{])','g');obj.plain=obj.plain.replace(regExp,'$1 – $5');// convert dashes to en dashes in datesobj.plain=obj.plain.replace(/(^|[ \(\|])(\d\d(\d\d)?)(\u2212|-|–)(\d\d)(\u2212|-|–)(\d\d(\d\d)?)([ \)\}\|,.;—]|$)/gm,'$1$2–$5–$7$9');
wikEd is unable to close the old edit toolbar on Wikia
Latest comment: 10 years ago2 comments2 people in discussion
I tried wikEd 0.9.105 Deutsch in http://de.memory-alpha.org which does not use Wikias GUI editor. The skin is called "Wikias new look" = Wikia.js/css. Pushing the close editing toolbar button has no effect. I am using Firefox 15.0.1 on Linux. It works on Wikias monobook. Matthias M. (talk) 12:41, 6 October 2012 (UTC)
Latest comment: 10 years ago3 comments2 people in discussion
I've been doing some editing, and the two remaining issues below are, I'm guessing, really just a variation of one problem - that pasting into the Edit Window inserts either an extra space, or a line break. All the other issues above seem to have been resolved. — Maile (talk) 21:25, 17 December 2012 (UTC)
1) Inserting into a table or into an Infobox - either Paste insertion, Toolbar link insertion, Toolbar Template citation insert - inserts a line break to the left of it, placing the insertion between the left-hand margin and the pipe character that begins the next entry space on the line below where it was supposed to insert
2) Inserting a citation into the body text from the drop-down "Templates" selection on the toolbar inserts an extra blank space to the left of the insertion. It doesn't matter which cite template is inserted.
3) Inserting a citation from the drop-down Template on the toolbar Instead of inserting where my pointer is, clicking the "Insert" button causes it to jump to the top of the section, in the margin to the left of section header, and inserts the citation there
Adding #3 today. Mentioned in above sections as one of the original issues, but I've only again used the feature with regularity in the last few days. — Maile (talk) 13:31, 6 January 2013 (UTC)
How to get and set the cursor/selection positions?
Latest comment: 10 years ago2 comments2 people in discussion
Hi, Cacycle. I was wondering, is it not possible to make UpdateTextarea() and UpdateFrame() to also update the cursor/selection position? Then everyone would be able to create user scripts compatible with WikEd. Is there any way at all to get the cursor/selection position (in number of characters from the start of the text - like with selectionStart/End in the normal textarea) in WikEd? --V111P (talk) 00:01, 15 January 2013 (UTC)
Special char gallery inserts into article editor, not edit summary or subject line, despite focus
Latest comment: 11 years ago1 comment1 person in discussion
Below the article editing area (selected with Alt-Shift-G) is the standard gallery of special characters and wiki markup codes that can normally (without WikEd enabled) be clicked on to insert those characters at the current cursor position. However, with WikEd enabled, the insertion always occurs in the last position of the cursor in the article editing area, even if the cursor is currently in the Subject/headline or Edit summary textboxes. This occurs on Win7Home, FireFox 15.0.1. —[AlanM1(talk)]—08:24, 29 January 2013 (UTC)
wikEd fails on a specific diff
Latest comment: 11 years ago1 comment1 person in discussion
Error console: ____ (Firefox: Tools → Web Developer → Error console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Problem description: Search/replace adds an extra newline before replaced string.
Click the "Find ahead as you type" button (with the binoculars on it) if necessary to the "unchecked" state.
Click /R/ if necessary to the checked state to indicate the search is a regex. Type "([0-9]{1,4})-([0-9]{1,4})" (without quotes) in the search box.
Type "$1–$2" (without quotes) in the replacement box. Note that the middle char is an endash, not a hyphen. It can be inserted from the Wiki markup list below the edit window or holding the Alt key down while typing Num-0Num-1Num-5Num-0 (on the numeric keypad).
Click the "Find next match" button, which should highlight "1992-93 NBA..."
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "31-10" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "19-7" should be highlighted.
Click the "Replace next match" button. In addition to replacing the hyphen, it incorrectly inserts a newline before the 19. Sometimes, it inserts the extra newline afterwards instead.
Click the "Find next match" button. "28-13" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "16-10" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash. It works correctly, and no extra newline is inserted, apparently because of the two extra spaces after "16-10".
Click the "Find next match" button. "31-10" should be highlighted.
Click the "Replace next match" button to replace the hyphen with an endash.
Click the "Find next match" button. "17-9" should be highlighted.
Click the "Replace next match" button. In addition to replacing the hyphen, it incorrectly inserts a newline before the 17.
AlanM1: This is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 15:25, 6 May 2014 (UTC)
Latest comment: 11 years ago1 comment1 person in discussion
Currently, the A-Z sort feature breaks multi-level bullet lists. The double (**), triple (***), and so on bulleted items do not stay under their parents.
It would be nice if WikEd sorted each level of a bullet list, keeping the branches under their respective parents.
Latest comment: 10 years ago7 comments3 people in discussion
What follows is copied from a thread I started on the Commons:Help desk.
Anyone have any further suggestions?
Is it possible (if so, how to?) use WikEd on Commons? I've started using it on en:Wikipedia and rather like it. The full screen mode is particularly nice with my old 1024x768 CRT monitors and I like the way it displays syntax highlighting. --Kevjonesin (talk) 13:38, 5 June 2013 (UTC)
I've added it to User:Kevjonesin/common.js but I haven't seen any icon or sidebar link show up (even after refreshing my page cache). How do I activate/access it? --Kevjonesin (talk)
On Wikipedia I have an icon to toggle the WikEd interface on and off up in the right corner of pages. And the preceding common.js Cropbot entry in my common.js had added a "crop" link to the sidebar so I thought that maybe that was plausible as well. Adding the code you gave me to my common.js has had no affect. I'm still getting the standard editing environment when editing in Commons. --Kevjonesin (talk) 18:54, 7 June 2013 (UTC)
Steps to reproduce: Try to delete {{fi}} (end space included) in my sandbox. The problem is I delete the space then I delete the end line between lien web and |url. Normally I delete the space the } then } and so.
Request : is there a way to get Automatic syntax highlighting rather then undo/redo option. I don't really use this option. My idea is to let us choose between thse two options.
Hi Hunsu, I cannot replicate your problems deleting "{{fi}} ". Please could you give me step-by-step instructions? Also, I am not sure what you mean by highlighting vs. undo/redo. wikEd does not implement any undo/redo, it just highlights in a way that is compatible with the browser's built-in undo/redo functionality. If you want an alternative highlighter, you could use the still experimental VisualEditor (Wikipedia references) or User:Remember the dot/Syntax highlighter (both are not compatible with wikEd). Cacycle (talk) 15:24, 16 December 2013 (UTC)
Put the cursor just before {{lien web
Use the delete button to delete {{fi}} (space included)
When you click on delete button you delete the space (normal) but the second time you click on delete button you don't delete } but instead you delete the \n between {{Lien web and | url. Why the cursor jumped there?
How do you tested it?
For the request I have thought that WikEd implements its own undo/redo so I suggested to choose between automatic highlighting and undo/redo. Hunsu (talk) 19:09, 17 December 2013 (UTC)
HunsuThis is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 14:37, 6 May 2014 (UTC)
Is cursor position that change when pasting is related to this? It happens to me when editing templates. Hunsu (talk) 09:19, 7 May 2014 (UTC)
No it's not fixed yet. It's hard to reproduce. I have tried to remove this content, so I placed the cursor at the beginning and started using delete button. Here's what I got. I couldn't remove all the text because the cursor jumped to the end. Try to reproduce it. Hunsu (talk) 12:12, 1 June 2014 (UTC)
internal “redlinks”
Latest comment: 10 years ago6 comments3 people in discussion
The new red redlinks are great! Thank you.
One improvement: If the link target starts with # then it is an internal one.
You might look for missing headlines, but fragment ids may be defined by anchor template as well, and it could be a single section which is edited.
However, internal links might get a different colour, e.g. green.
PerfektesChaos: I think that all point work just fine in 0.9.125. I was not able to test ../traversing as it seems not to be possible in MediaWiki. Do you have more infos on this? Cacycle (talk) 14:35, 6 May 2014 (UTC)
Thank you for these improvements; I will check them thoroughly as soo as possible.
Error console: none (Firefox: Tools → Web Developer → Error console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Problem description: try to replace something in this page using replace all option. the spaces in Infobox (juste before the | will be deleted).
I consider this a feature, not a bug. The spaces at the beginning of the line are not required and not part of any style recommendation. The button is specifically made to clean out unnecessary spaces. If you want to keep those spaces, you have to use the button only on selections around that section. Cacycle (talk) 09:11, 5 March 2014 (UTC)
Latest comment: 10 years ago4 comments2 people in discussion
I noted a problem (insertion of the signature at the wrong location here at VPT. User:Technical 13 asked a good question; when I removed wikEd the problem disappeared, when I reinstalled it the problem reappeared. Needless to say (no not needless, so I will say it) I love having the capabilities of WikEd, so I don't want to remove it, but I would like to have the ability to paste text, and add a signature using the icon. It only happens with Firefox. --S Philbrick(Talk)00:31, 28 February 2014 (UTC)
Sphilbrick: This is a known problem that sometimes happens. However, it is extremely difficult and complex to fix, so I will probably not do it soon. Thanks for reporting, Cacycle (talk) 12:55, 6 May 2014 (UTC)
Works fine for me - maybe it is related to one of your other scripts? Please could you complete the bug report (especially relevant error console messages)? Thanks, Cacycle (talk) 09:29, 9 March 2014 (UTC)
Cacycle, try looking at it from a non-admin account. Syntax highlighting only works for me when I have edit rights for the page; e.g. it doesn't work on protected pages here on Wikipedia, but it does work on protected pages on Wookieepedia, where I have admin rights. However, before I was promoted to admin at Wookieepedia, it didn't work there either. Here's my debug info from the example page cited by Rezonansowy:
jcgoble3's debug info
Date: 2014-03-13 21:23:17 UTC
wikEd version: 0.9.124a GM (March 08, 2014)
Browser: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Win32)
(P.S. The error report form is out of date, because Firefox no longer has an "Error console" option under "Web Developer"; it is now called "Browser Console".) jcgoble3 (talk) 21:30, 13 March 2014 (UTC)
Latest comment: 10 years ago5 comments3 people in discussion
Minor edits are a bit of a hassle to save. You have to select "minor edit", then either click save or click focus back to the edit summary and hit return (since selecting the checkbox takes focus away, at least for me.)
A button to "Save page (minor edit)" or similar would simplify things, rather than requiring multiple steps.
Can this be done with a custom button instead? I guess I could figure out how to make JavaScript set the minor-edit flag and then save, but that doesn't seem like a great way to do it. E4FZq (talk) 02:09, 12 March 2014 (UTC)
Actually, hitting Enter/Return with focus on the minor edit checkbox also submits the form (the same applies to the watch page checkbox). I use that shortcut all the time by typing in my edit summary and hitting Tab-Tab-Space-Enter (I need two tabs to get to the minor edit box, since I use User:Svick/SectionInput.js, which, when combined with wikEd, inserts its section box between the wikEd summary box and the minor edit checkbox in the tab order; you would probably only need one tab.) jcgoble3 (talk) 02:30, 13 March 2014 (UTC)
Also, Alt-Shift-i focuses and toggles that box. Maybe I could add a persistent lock feature to that checkbox (e.g. triggered by Shift-click)... Cacycle (talk) 10:36, 13 March 2014 (UTC)
Tab-space-enter does work for me. Thanks! (In fact, now I remember using that in the past. I think it stopped working at some point from a browser or OS bug, and I forgot I could do that.) Ctrl-alt-i works too. Safari doesn't focus the checkbox if I do click on it, so I still need to go back to the keyboard if I click, but it focuses it doing either of the above so I can hit return. More of a browser problem than a wikEd problem, obviously... You also need "All controls" selected in the Shortcuts tab of the Keyboard prefpane on OS X to focus things like checkboxes at all, which I already had but isn't the default.
A persistent lock would definitely be useful for doing lots of minor edits in a row or for people who mostly do minor edits. (Especially since it seems like the pref for doing that disappeared at some point, but maybe I'm wrong on that.) E4FZq (talk) 15:55, 13 March 2014 (UTC)
When previewing, screen now jumps down to edit window
Latest comment: 10 years ago3 comments2 people in discussion
Thanks for your March 7th update. However, since then I've noticed that when I click "Preview" I'm only taken to the preview (on top) for a split second before jumping to the edit box below it. In the grand scheme of things this is no biggie, but it was more convenient to read the preview first without having to scroll up every time (especially when editing a long section). Is this fixable? The "Go to editing area" link is still next to the red "This is only a preview...", but my screen jumps to the edit window automatically and I have to scroll up to read the preview (and see what I've misspelled :-)). I'm using XP and FF 27.0.1, and don't have anything in my preferences affecting the edit window. Thanks for any help and all the best, Miniapolis21:34, 13 March 2014 (UTC)
Forgot to mention that the preview behaves normally when I switch WikEd off. Thanks again and all the best, Miniapolis15:14, 14 March 2014 (UTC)
Miniapolis: I cannot reproduce this. Does it still happen? Please could you give a full error report in that case (see top of the page). Thanks, Cacycle (talk) 12:20, 6 May 2014 (UTC)
s vs del
Latest comment: 10 years ago3 comments2 people in discussion
It seems that strike is being deprecated in some circles in favor of delete. Cacycle, how do you feel about the change (which I don't like, FYI) and changing WikEd to go along with it? The tag s is 9.1 times as popular as del. (911% more popular in marketingspeak; 5,840,886 for <s> vs 641,205 for <del> using Special:Search) --Elvey (talk) 01:12, 20 March 2014 (UTC) (edited)
Elvey: It's two different things that just look the same. As it is not widely used on article pages, I guess it doesn't matter much which button wikEd has, <del> could always be added manually. So, until we have a new button image for <del> we will continue with <s>. Cacycle (talk) 12:17, 6 May 2014 (UTC)
Right. (And someone was misinterpreting the W3C; this use of <s> hadn't really been deprecated.) Thanks. --Elvey (talk) 15:47, 6 May 2014 (UTC)
Non-breaking space chars – ways of preserving?
Latest comment: 10 years ago2 comments2 people in discussion
Hi Cacycle. We've encountered a problem with wikEd's NBSP→SP replacement on skwiki recently. We don't have that "use HTML entity" policy like here on enwiki and literal character form is preferred, so it's quite serious issue – editors using wikEd (as a gadget opt-in available in user prefs) are just silently crippling articles, containing non-breaking spaces (between numbers and units, around range dashes, inside dates, between prepositions and words, and so on...).
I understand, that there are design issues with full NBSP char support, as you've stated several times here. But anyway, I can imagine a better workaround alternatives, than current "silent" replacement by plain spaces:
to replace them by entities (inside the pre-filter code before passing markup to the editor)
and optionally replace all back into literal chars in post-filter (an opt-in for environments where literal form is preferred)
to replace them by some macro markup, that will be displayed and preserved by wikEd and substed back into NBSP chars on saving
Hi Teslaton, unfortunately, there is no reasonable and foolproof way to support the actual nbsp characters in rich text editing. They are not even supported in the standard textarea (i.e. they get consistently converted to blanks in Firefox without wikEd! See Mozilla bugs 359303 and 613223). It is time for your wiki to adjust policies to reality! That said, I have changed the upcoming wikEd release 0.9.126 so that existing nbsp characters are automatically converted to their character entities. I have also added a customization option to convert all to the actual characters when switching to the textarea or saving/previewing (var wikEdConfig = {}; wikEdConfig.nbspToChar = true; see User:Cacycle/wikEd customization). I do not recommend to use this setting. Cacycle (talk) 11:40, 6 May 2014 (UTC)
Curly apostrophes vs. typewriter apostrophes
Latest comment: 10 years ago2 comments2 people in discussion
Until recently wikEd treated these as different characters. I recently upgraded Firefox to 27.0.1, and it now treats them as one character, so if you use Firefox find function, searching for "’" will also find "'", and vice versa. Also, wikEd's "Find next match" box will treat them as the same character. But if the "Search field is a regular expression" button is depressed, they are treated as separate characters by wikEd. This provides a way to find either one character or both characters, so it is not altogether a bad situation, but we might want to document this somewhere for new users, or for users who upgrade Firefox and encounter this. My guess is that the Firefox change was in late fall 2013 or thereabouts. Christhe spelleryack17:16, 29 March 2014 (UTC)
Problem description: Doesn't save/preview edited text if parameter "nosummary=1" is given, for URL above the preload without the user-filled parameters is saved or lost if clicked on preview. Multiple affected users with Monobook to Vector and Firefox, IceWeasel and IE 11 using all the url above or [3].
Steps to reproduce:
Click on a Editlink with nosummary=1 as provided above
Hmm, I cannot reproduce your problems (under 0.9.125c). Do you still have this problem under 0.9.125c? If yes, it could be caused by another gadget - what happens if you disable the other gadgets? Thanks for your help - Cacycle (talk) 22:55, 5 May 2014 (UTC)
Error console: No error messages related to wikEd.js; one error message for a Chrome Extension emoji:
Uncaught SyntaxError: Unexpected reserved word chrome-extension://fbgkphlalcbmifhkabdbodaghlhfcbbd/emoji.js:32
Consider using 'dppx' units instead of 'dpi', as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-resolution: 144dpi)
Problem description:
When using the wikEd interface, a file shows up as a redlink; however, it is a valid, existing file:
[[File:Norris WestAJ Map scale.jpg|thumb|Aerial photo showing location of [[Campus of Virginia Tech#Norris Hall|Norris]] and [[Campus of Virginia Tech#Ambler Johnston Hall|West Ambler Johnston]] Halls]]
Removing the other parameters of the link results in a bluelink; there might be something about the way the link includes information for the photo that makes wikEd think it's not a valid file:
[[File:Norris WestAJ Map scale.jpg]]
However, removing the internal links doesn't fix the problem; the following still shows as a red link:
[[File:Norris WestAJ Map scale.jpg|thumb|Aerial photo showing location of Norris and West Ambler Johnston Halls]]
I've now noticed that by copying and pasting [[File|...]] links in the article, more of them become red, when they were blue before.
It sounds like wikEd only discovers whether the file page exists at the English Wikipedia. File:Norris WestAJ Map scale.jpg is at Commons and {{#ifexist:File:Norris WestAJ Map scale.jpg|found|not found}} returns: not found. For comparison, File:Example.jpg is here and {{#ifexist:File:Example.jpg|found|not found}} returns: found. A check on Media instead of File would work in wiki code. {{#ifexist:Media:Norris WestAJ Map scale.jpg|found|not found}}: found. {{#ifexist:Media:Example.jpg|found|not found}}: found. {{#ifexist:Media:No such file.jpg|found|not found}}: not found. PrimeHunter (talk) 11:23, 5 May 2014 (UTC)
Error console: Use of getUserData() or setUserData() is deprecated. Use WeakMap or element.dataset instead.
Problem description: Whenever I click on a section link e.g. from either my watchlist or an archive search from somewhere like VPT then the page loads, takes me to the right place then 'bounces' to the top of the page. I've disabled all scripts, reset preferences and it does appear to be WikEd that is the cause as it's only when I disable it that the problem does not occurs. Nthep (talk) 20:56, 6 May 2014 (UTC)
User:Nthep: wikEd scrolls down to the edit area, without wikEd, you always stay at the top of the page. One of your many scripts seems to scroll back to the top after wikEd has scrolled down. Cacycle (talk) 14:53, 8 May 2014 (UTC)
Cacycle: With the same gadgets as you are using, I cannot reproduce this. The error console warning is not related to the problem. Strange. Cacycle (talk) 15:07, 8 May 2014 (UTC)
Thanks for the reply. I've disabled all scripts, cleared the cache and I still get the same behaviour - click on a section link in my watchlist, page loads to righ place then back to the top. I'll have to try against any prefence settings to see if that is the cause of the conflict. Nthep (talk) 15:11, 8 May 2014 (UTC)
Confirming that I had the same problem, and just disabled WikEd; the problem disappeared. (I have not checked the HotCat combination.)--S Philbrick(Talk)16:28, 8 May 2014 (UTC)
Ok, I've now tried against all gadgets set in preferences and there is one causing a conflict. I get the problem when both WikEd and HotCat are enabled. Disable one and no problem. Nthep (talk) 16:02, 8 May 2014 (UTC)
Yes, I've been getting this probably since upgrading FF to 29.0 (and same with 29.0.1). I find with WikEd disabled I get close to (but not right at) the section. With HotCat disabled I get to exactly the right place. See WP:VPT#Redirect not working right which might be related. I suspect FF 29 actually. Thincat (talk) 22:03, 9 May 2014 (UTC)
Fixed in 0.9.126b by improving the detection of view and restore deleted pages preview pages (their textareas do not have an id, name, or class). Please update with Shift-Reload. Thanks to Lupo who figured this out. Cacycle (talk) 23:03, 9 May 2014 (UTC)
Many thanks for sorting this out. The "jumping to top" and "not moving exactly to section" problems have both been solved for me even with both gadgets enabled. (It didn't happen to me before FF 29!). Thincat (talk) 23:46, 9 May 2014 (UTC)
customize selected text?
Latest comment: 10 years ago7 comments2 people in discussion
r talk:Mitch Am
When I have syntax highlighting enabled, any selected text appears in bold, which I find very difficult to read. Is it possible to add a customization so that selected text is not bold? I've looked at the customisation, and changed a couple of colours already, but I can't find one for "selected text". Thanks, Mitch Ames (talk) 13:34, 7 May 2014 (UTC)
Which browser and browser version are you using? It is a browser bug, the 'bold' is actually a text shadow that should not be visible in selected text. Cacycle (talk) 13:42, 7 May 2014 (UTC)
Ouch. Time to update I guess. Nothing I can do for you... (of course you could customize the following css: '.wikEdFrameBodySyntax': 'height: auto; min-height: 100%; width: auto; background: transparent; margin: 0; padding: 0; padding-left: 0.25em; overflow: auto; font-family: monospace; text-shadow: white -1px -1px 0, white -1px 0 0, white -1px 1px 0, white 0 -1px 0, white 0 1px 0, white 1px -1px 0, white 1px 0 0, white 1px 1px 0;' (remove the text-shadow part). Cacycle (talk) 14:13, 7 May 2014 (UTC)
Latest comment: 10 years ago4 comments2 people in discussion
If I have syntax highlighting enabled, when I paste text into the edit box (that I have copied from something with formatting information) wikEd leaves the text selected and displays the toolbar with the [W][T] buttons. Is there a customization to disable this "feature". Most of the time I just want to paste the plain text, ie close the toolbar. The problem is that normally pasting does not leave the pasted text selected, so muscle-memory has me pasting and then immediately typing what I want to be after the pasted text. With the wikEd "feature" this overwrites the (selected) text that I just pasted! Very annoying. Being able to turn off that feature would be helpful. Thanks, Mitch Ames (talk) 13:47, 7 May 2014 (UTC)
Latest comment: 10 years ago5 comments2 people in discussion
I use WikEd and the MonoBook theme. Presently within the Firefox 29.0 browser under Bodhi Linux.
Recently—soon after I noticed that a new "Expand view" button had been added to image file pages—I went to edit an article and found my WikiEd interface reproportioned (smaller editing field with more displayed below) and an active search box floating above the editing field and obscuring a portion of it.
Have there perhaps been some global changes to the wiki interface which are conflicting with WikEd?
Could you please submit a detailed error report (see top of page)? I cannot reproduce your problems - it is probably related to other gadgets, beta features, or preferences settings. Thanks, Cacycle (talk) 09:19, 8 May 2014 (UTC)
Pardon the delay, I've not been on wiki much recently.
Screenshots from editing 'full window mode' on User_talk:Cacycle, via Google Chrome Version 35.0.1916.114 running under Bodhi Linux 2.4:
Example of floaters (Wikipedia logo and search box) when first entering a pages editing mode in WikEd's full window mode ...
You're welcome. Thanks for fixing. I'm using the full window interface now as—I type—in a new (to me) LCD monitor and things look good. -
[p.s.— When I pressed "preview" from full mode it briefly flashed the the preview at normal scale and then settled back to full window editing mode, rather than dropping into normal aspect and staying so to review the preview as it had previously. Not a big problem, but I thought I'd note the change.] --Kevjonesin (talk) 21:16, 8 June 2014 (UTC)
Support for personalized buttons not working
Latest comment: 10 years ago6 comments2 people in discussion
Hi, I tried to add a personalized button following your examples in my common.js on Wikidata, but for a reason I don't understand this does not work (I made it work once, but cannot reproduce). It's supposed to replace a string like Q1 with {{Q1}}, but for a reason I don't understand this does nothing. What did I do wrong ? (the div example does not work either). Thanks in advance. TomT0m (talk) 16:12, 9 May 2014 (UTC)
TomT0m: Did you clear your cache after changing your common.js (Shift-Reload)? The DIV button works for me when I use your code. Cacycle (talk) 18:44, 9 May 2014 (UTC)
Sorry, corrected the error and switche to your new code to handle the selection, cleared the navigator cache (both shift-ctrl-R and remove the file in the cache of firefox), but still does not work. I get those errors in firebug console :
TypeError: document.getElementById(...) is null
...ntById('c-u-rfx').onmouseover = function () {showMenu('opt-user-rfx',findPos('c-...
index....7132816 (ligne 337)
TypeError: element is null
if (!element.getElementsByTagName('a').length) return false;
2
index....7132816 (ligne 188)
Semantic Forms: edit with form: form scrolls automatically to the free text field on the end
Latest comment: 10 years ago5 comments2 people in discussion
Sorry, maybe a stupid question but I don't know any help:
I use wikEd with an own Wikimedia installation together with Semantic Mediawiki and Semantic Forms. Problem: every form has an field with free text at his _end_:
{{{standard input|free text|rows=2|cols=80}}}
wikEd scrolls automatically every form to his end when it is edited with forms. The cursor is going to the free text field to the end of a long form. So it is necessary to scroll up every time going to edit form modus
'cols' are ignored
There are some problems with the layout.
How is it possible to disable the automatic scrolling to the free text field? Or is is possible to disable wikEd selective for Semantic forms?
This is a general problem of wikEd (as in Wikipedia). The focus/cursor jumps always to the input field. Thus, the page scrolls up. In normal editing this is visible too: The lemma name is hidden. When the editing field is further down - like with http://www.mediawiki.org/wiki/Extension:Semantic_Forms, it is very disturbing (free text input field at the end of a formular).
When editing without wikEd the edit box has no focus. One must first click inside it to edit. No focus/cursor inside the edit box would be the solution - perhaps optional. Thanks a lot. --Tom Jac (talk) 07:08, 6 June 2014 (UTC)
Tom Jac: Fixed in current version 0.9.128b by turning off autoscrolling and textbox focus for Semantic Forms. Thanks for bringing this up. Cacycle (talk) 18:13, 8 June 2014 (UTC)
Latest comment: 10 years ago3 comments2 people in discussion
Often when I am editing, I'm copying text from a Word file that I've created. I want to transfer the text without any formatting, so I right-click and choose "Paste as plain text". I still get the pop-up for converting text, which I then have to dismiss. Is there a way to disable the pop-up when using "Paste as plain text"? My browser is Google Chrome (latest version). Thanks!—D'Ranged 1VTalk03:04, 1 June 2014 (UTC)
Latest comment: 10 years ago5 comments2 people in discussion
Another thing - I often turn off "Find ahead as you type", select a text area that I want to apply changes to via search and replace, click "Replace all matches in whole text or selection", and then return to the find/replace box to enter the next change for the same area of text. The problem is as soon as I start typing in the find box, "Find ahead as you type" is re-activated and I lose my text selection. Cannot tell you how frustrating this is! Thanks!—D'Ranged 1VTalk03:12, 1 June 2014 (UTC)
I can't reproduce the problem; maybe I was doing something wrong. If it happens again, I'll make sure I can re-create the problem before posting. As a side note; I had this page on my Watchlist; so I caught your "notify" edit. Two things: You didn't actually notify me; you just linked to my page. (You used square brackets instead of curly braces.) Also, I'm given to understand that you can't retroactively add the {{User}} notification template to a post; it must be included before you save the post for the first time. I haven't tested that yet. Thanks!—D'Ranged 1VTalk18:06, 7 June 2014 (UTC)
And thanks to your post, I learned that linking to my user page sends a notification as well as using the notification templates. Thanks!—D'Ranged 1VTalk05:07, 9 June 2014 (UTC)
wikEd bug report: The new version add non breaking space on wikitext
Latest comment: 7 years ago16 comments6 people in discussion
Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Problem description: This version adds non breaking spaces after "«" and before "»"
Ok, I will modify the script to remove it as on French Wikipedia we don't have a policy about adding html code inside wikitext. I left you a message about the other bug. Hunsu (talk) 06:20, 5 June 2014 (UTC)
Hunsu: I am not sure what you mean by "I will modify the script to remove it". Please see above under User_talk:Cacycle/wikEd#Non-breaking_space_chars_.E2.80.93_ways_of_preserving.3F why it is technically impossible to conserve non-breaking space characters when using rich text editors like wikEd. There you can also find the wikEd settings to turn off the automatic conversion to at the cost of a high probability of losing the non-breaking property of those spaces. Cacycle (talk) 15:59, 8 June 2014 (UTC)
Hi Cacycle,
Unfortunately, the "nbspToChar" option does not help us here. The old behavior (replacing unicode non-breaking spaces by spaces while preserving existing entities) was a better compromise for frwiki. Indeed:
On one hand, normal editors not supposed to insert non-breaking spaces as unicode characters, because as you said yourself, they "are not even supported in the standard textarea (i.e. they get consistently converted to blanks in Firefox without wikEd!)". However, a bot added such non-breaking spaces in many places where they are normally inserted automatically by the MediaWiki parser (for instance after "«" and before "»"). This was supposed to be an experiment to see how quickly they would be transformed into normal spaces. But now wikEd is inserting in these places.
On the other hand, " " entities are sometimes intentionally inserted in wikicode. They should not be turned into non-breaking spaces, because they would eventually be removed by other tools...
Would it be possible to add an option to get this behavior?
Here is a possible way of implementing this, without changing the default behaviour: [4]. Could you please apply this patch? Thanks, Orlodrim (talk) 17:14, 4 July 2014 (UTC)
Orlodrim: Wouldn't that change all intentional " "s to nbsp characters (\xa0)? I do not think that it will be possible to make wikEd compatible with nbsp characters (at least not in an intuitive and transparent way). Cacycle (talk) 14:41, 7 July 2014 (UTC)
No, I just make the conversion of '\xA0' to " " optional. When the option is disabled, non-breaking spaces (not written as HTML entities) are converted to normal spaces when the page is saved, but " " entities remain unchanged (example). This is what wikEd was doing a few weeks ago. Orlodrim (talk) 18:11, 7 July 2014 (UTC)
Cacycle: Sorry to insist, but without this option, I have to maintain a patched version of your script for the French Wikipedia, and this not practical in long term. Could you please apply the change or tell me if you see something wrong about it? Thanks, Orlodrim (talk) 11:45, 1 November 2014 (UTC)
Orlodrim: I have added nbsp support to the upcoming version 0.9.145. Existing nbsp (" ") will be highlighted and conserved. The fixing buttons will convert them to unless the following config option has been set to false:
// fix buttons convert nbsp to character entitywikEdConfig={};wikEdConfig.fixNbsp=false;
Hi Cacycle, i get a lot complains about silently crippling wikilinks and unintentionally adding in de.wiki while using wikEd. Since the nbsp support was remove, it would be nice to get that Patch[5] as Orlodrim already suggested, to opt-out the conversion of \xA0 to . New10n (talk) 17:33, 29 October 2015 (UTC)
New10n: this will be my next project as soon as I find the time - promised. Will take a while though as this is actually somewhat complicated and tricky and I am really busy IRL right now... Cacycle (talk) 16:53, 2 November 2015 (UTC)
Is it possible that Wiked was adding Non breaking spaces in edits such as this? I've opted out of Wiked in case that was where the bug was. ϢereSpielChequers21:03, 29 May 2017 (UTC)
WikEd problem
Latest comment: 10 years ago2 comments2 people in discussion
Hi there. I have used wikEd by just enabling it in preferences. It worked fine until yesterday when my account was actually renamed from User:Abhishek191288 to the current one. Now next to the logout button on the right top, there is an error that displays "Incompatible script or gadget: Code editor - WikEd 0.9.127 G". I have enabled wikEd through script after this, but still in vain. Your help is appreciated. Thanks, — LeoFrank Talk05:18, 31 May 2014 (UTC)
LeoFrank: Please try deleting the following Wikipedia cookie: wikiEditor-0-codeEditor-enabled. If that doesn't work, please provide more details by posting a bug report (see top of this page). Cacycle (talk) 16:01, 2 June 2014 (UTC)
Somebody diddling with Wiked today? Please put it back like it was
Latest comment: 10 years ago11 comments3 people in discussion
Resolved
I posted the below earlier on Village Pump (technical) and see no response over there. But I can no longer edit with WikEd, as of just a few hours ago. Who is doing what to it? — Maile (talk) 22:19, 5 June 2014 (UTC)
What's going on with WikEd, the edit window and Reftoolbar 2.0?
Just started happening, and was not happening a couple of hours ago. WikEd is involved. If I try to edit as usual with WikEd installed, text in the edit window is splayed outside the borders of the edit window, as a transparancy overlay on the rest of the page. I can type in a blank edit page, but part of the bottom portion of the Reftoolbar displays briefly and then disappears entirely. It will not allow me to "Save Page" or "Preview". Right now, I have WikEd turned off in order to do this post. However, not all of the Reftoolbar is showing. What's going on all of a sudden? NoScript was disabled, so that was not the conflict. Windows 8 Firefox 32.0 — Maile (talk) 18:42, 5 June 2014 (UTC)
Maile: Firefox 32.0 is an experimental alpha version of the browser, the current version is 29.0.1. Do you experience the same problems with the regular version too? Cacycle (talk) 16:26, 7 June 2014 (UTC)
No problems on my side using 32.0a1 and refToolbar. Please could you post an error report (see top of this page)? Thanks, Cacycle (talk) 16:32, 7 June 2014 (UTC)
Perhaps you can suggest how I can get either 29.0.1 or 32.0a1 I did not download 32.0 on my system. It was downloaded by a computer support technician who insisted no other version was available. — Maile (talk) 17:38, 7 June 2014 (UTC)
Well...I uploaded 29.0.1 Firefox, and the beta version is gone. Just to make sure, I also rebooted my system. I'm still having the same issues, so I'll fill out a bug report. — Maile (talk) 18:47, 7 June 2014 (UTC)
User:Maile66: Thanks a lot. Please could you click Ctrl-Logo to get the automatic form data and post it here? That would make tracking this down much easier for me. Cacycle (talk) 09:55, 8 June 2014 (UTC)
I'm collapsing the details above, because it isn't happening in the same way. And this might be something I should just wait out for a few days. As of this morning, I'm not having the same issues with WikEd. I can check WikEd in Gadgets, and have no problems. WikEd does not seem to be activated in this edit window, even though it's checked in Gadgets. However, I have no problems in editing. And the Edit Toolbar looks a bit different, but that might not be related to WikEd. So, I think I'll just wait a few days and see what happens. — Maile (talk) 13:57, 8 June 2014 (UTC)
Helder.wiki: TemplateData Editor is a component of VisualEditor and as such it cannot be compatible with wikEd. You have to decide if you want to either use VisualEditor or wikEd. Cacycle (talk) 15:26, 7 July 2014 (UTC)
Helder.wiki: But as far as I can see, it only works together with (and makes sense for) VisualEditor. I am not sure how that could be made compatible with wikEd. Cacycle (talk) 15:41, 7 July 2014 (UTC)
Still does not work :( I would have like to know, the UI of this stuff is a little frustrating to use :). Is there a way to show the incompatibility ? TomT0m (talk) 09:20, 20 April 2015 (UTC)
wikEd bug report: wikEd does not work after renaming account
Latest comment: 10 years ago4 comments2 people in discussion
Date: 2014-06-14 03:34:34 UTC
wikEd version: 0.9.128b G (June 08, 2014)
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Win32)
Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Problem description: My account was moved to this name from Abhishek191288. In the old account name, I was able to use wiked with no problem. In the new one I am not able to. I even tried another browser (chrome), but in vain. FWIW, I just logged in using the old id and it worked perfectly fine with the old name, but not this. On the wiked icon on top of the page, I see the following error message Incompatible script or gadget: Code Editor - wikEd 0.9.128b G. I have a screenshot of the problem. If there is anyway, I can send it, please let me know.
Steps to reproduce: Just edit any page and wikEd does not work.
Line breaks not re-wrapping while editing, CharInsert not compatible, Cursor location unreliable
Latest comment: 10 years ago4 comments2 people in discussion
I was working on adding spaces before pipes in a long citation template:
{{cite web|title=Palestinian National Authority|accessdate=8 June 2014|website=World Statesmen.org|url=http://worldstatesmen.org/Palestinian_National_Authority.htm|archive-url=//web.archive.org/web/20140208062450/http://worldstatesmen.org/Palestinian_National_Authority.htm|archive-date=8 February 2014|deadurl=no|publisher=Ben Cahoon}}</ref><ref>{{cite web|title=Palestine|accessdate=8 June 2014|website=nationalanthems.info|url=http://www.nationalanthems.info/ps.htm|archive-url=//web.archive.org/web/20140331034257/http://www.nationalanthems.info/ps.htm|archive-date=31 March 2014|format=includes audio|deadurl=no}}
I noticed as I was adding spaces using the search and replace box to replace | with | that lines weren't re-wrapping; for example, the first line should automatically re-wrap after "Statesmen.org", and it doesn't. If I put the spaces in by hand, the lines re-wrap, but even after finishing the search and replace, I have to dismiss WikEd to get the lines to wrap correctly.
Another issue is that I have the Gadget CharInsert turned on, but it's incompatible with WikEd. For example, if I have WikEd active and highlight some text, then click on the <code></code> tag to wrap it, it puts <code></code> in the replace field of find and replace instead of wrapping the highlighted text.
Additionally, when I paste text, the cursor jumps to a different place in the text rather than staying at the end of the inserted text.
Here's a bug report:
Date: 2014-06-14 07:35:17 UTC
wikEd version: 0.9.128b G (June 08, 2014)
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 (Win32)
Thanks! #2 seems to be fixed now as well. (Sorry, it's still broken after I've placed focus somewhere other than the text editing area.) As for #1, my browser doesn't do this when I'm not using wikEd; there's something in the tool that's causing the browser to see spaces as non-breaking spaces, I suspect. Another possibility is that wikEd treats line end/carriage return differently, perhaps putting a soft carriage return after the line break?
One more request: could you please make the Find ahead as you type button default to deselected? It's driving me nuts! My most frequent use of the search and replace function is to do global search and replace; every time I preview my changes, I have to remember to click the button before I start the next global search and replace. I would rather imagine that most folks use this function as a global tool, not as a Find ahead tool; I could be wrong. Regardless, it either needs to be off as the default or remember the last state it was in when returning from a document preview. If it makes any difference, this happens only when I use the regular preview button, not the wikEd magnifying glass. Thanks!—D'Ranged 1VTalk17:23, 7 July 2014 (UTC)
Apparently the unified wikEdDiff button doesn't work to show the differences between pages on Special:ComparePages. This would be an invaluable tool to a Template editor like myself and I'm wondering if this support is on the todo list. Thanks. — {{U|Technical 13}}(e • t • c)20:06, 14 June 2014 (UTC)
Latest comment: 10 years ago3 comments2 people in discussion
Encouraged by your last message I'd like to share an observation on one of the strings used in translationd: in Polish wikipedia user page is 'Wikipedysta:X' ('User:X') but his talk page is 'Dyskusja_wikipedysty:X' ('User_talk:X'). As you see using simple postfix '_talk' in translation is not enough (I guess that the same goes with prefixes); of course because of leaving English-language back-end intact everything's working just fine, so this might be seen as minor to no issue at all. konrad (talk) 14:56, 21 June 2014 (UTC)
First, your bug report form seems to be a little off... Second, wikEdDiff wouldn't load on the last diff "&diff=cur&oldid=prev" for my user sand box User:Technical 13/SandBox. It shows shows the source of the page starting at the pp report instead. — {{U|Technical 13}} (e • t • c)12:02, 26 June 2014 (UTC)
Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - Cacycle (talk) 14:54, 29 June 2014 (UTC)
I get the same results as Technical 13 on his link above. Also, I get same result just doing a diff on his above post. The error shows in the window opened with the little toggle arrow below the diffs. Just started happening yesterday. Go to the article Page → History → Compare Selected Revisions. Windows 8.1, Firefox 30.0, Skin Modern. — Maile (talk) 14:55, 2 July 2014 (UTC)
If I can be of any more assistance, I know my way around the error console and would be happy to test things. I'm using the latest version of FireFox btw (since the useragent string above doesn't specify). — {{U|Technical 13}} (e • t • c)16:03, 2 July 2014 (UTC)
Technical 13: Mhm, works fine for me, even with your common.js code and gadgets, under different skins, and under FF, MS IE 11, and Chrome. Maile: could you post an error report for your browser, gadgets, and scripts? Cacycle (talk) 16:20, 2 July 2014 (UTC)
Technical 13, Maile: I have fixed this in wikEdDiff 0.9.23 by removing the '#' from the hrefs of the bold old/new version links on top of the diff table. Something on your computer (add-on, script?) is inserting this character on your system, but not on mine. Would be interesting to figure out what is responsible for this... To update, please refresh wikEdDiff.js code to version 0.9.23. Cacycle (talk) 10:00, 3 July 2014 (UTC)
Cacycle, Technical 13, On my system, it now shows the toggle arrow below the diffs. But when I click it, absolutely nothing happens - no window, no nothing. However, as of yesterday afternoon/evening, WikEd does not seem to be working for me. I've unclicked it in Gadgets, and my edit window view is the exact same without it as it is with it. — Maile (talk) 11:54, 3 July 2014 (UTC)
I'm unclear about why wikEd itself is not working for you at the moment, but it is possible (although wikEd itself is working for me). Have you made any other javascript related changes on your account such as editing your common or skin .js or changing gadgets or beta features? Either way, I do not have time to dig right now, I'm going to meet my ex for a "date" with my 3 yr old daughter for the next several hours. — {{U|Technical 13}} (e • t • c)13:00, 3 July 2014 (UTC)
I also thought it might be a .js, but this started yesterday afternoon and no .js changes happened yesterday. There was a .js add on my skin on July 1, so I reverted it today to see if it was the problem. Apparently, that's not what is causing this. No changes in gadgets, and I don't use any Beta features at all. — Maile (talk) 13:08, 3 July 2014 (UTC)
Cacycle, I think I know what you want, but it will have to wait a few hours if you want it from me per my comment above to Maile66. I'm unsure if that user will be able to get you what you are requesting or not but am guessing it will just have to wait until I am free unless you can find another techy editor with the issue to do it. It "may" be best to just revert these parts of wikEdDiff to the version it was at before adding the Special:ComparePages modification I requested until I can get that for you. If you just want to move this version to a separate subpage or what not I can disable the gadget and load that version directly in console or via vector.js (which is where I do most my testing so if I completely screw up I can just change skins and fix it). — {{U|Technical 13}} (e • t • c)13:00, 3 July 2014 (UTC)
Just as a note to both of you, I tested to see if my NoScript could be the problem. Disabling it had no effect. I still don't have WikiEd in my edit window, but if I have it enabled on Preferences, I do have the WikEd logo at the top of the page - just nothing else.— Maile (talk) 21:42, 3 July 2014 (UTC)
Ahh... Maile66, I have a guess as to what happened. When you tried to ctrl click to get the above report, you must have accidentally single clicked the icon as well, which means that icon are probably gray because you toggled wikEd off. Simply click that gray icon once and it should turn it back on. — {{U|Technical 13}} (e • t • c)23:18, 3 July 2014 (UTC)
Oh, for goodness sakes! That took care of it. We still have the Diff issue, but WikEd is back in my edit window. Thanks. — Maile (talk) 23:34, 3 July 2014 (UTC)
Technical 13: where does the [restore this version] texts/links on top of the diff table in your screenshot come from? I don't have them, even with all gadgets enabled and your common.js. Cacycle (talk) 09:52, 4 July 2014 (UTC)
[restore this version] does indeed come from Twinkle. I just got up, do you use IRC at all? ##T13connect is my channel if you want to pop in and give me your email to send that package with the HTML.
HTML of diff section with Twinkle "restore this version" etc.
<tableclass="diff diff-contentalign-left"><colgroup><colclass="diff-marker"><colclass="diff-content"><colclass="diff-marker"><colclass="diff-content"></colgroup><tbody><trstyle="vertical-align: top;"><tdcolspan="2"class="diff-otitle"><divstyle="font-weight: bold;"id="tw-revert-to-orevision"><ahref="#"><spanstyle="color: Black;">[</span><spanstyle="color: SaddleBrown;">restore this version</span><spanstyle="color: Black;">]</span></a></div><divid="mw-diff-otitle1"><strong><ahref="/w/index.php?title=User_talk:Cacycle/wikEd&oldid=615282897"title="">Revision as of 08:04, July 2, 2014</a> (<ahref="/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&oldid=615282897"title="">edit</a>)</strong></div><divid="mw-diff-otitle2"><ahref="/wiki/User:Kitchen_Knife"title=""class="mw-userlink">Kitchen Knife</a><spanclass="mw-usertoollinks">(<ahref="/wiki/User_talk:Kitchen_Knife"title="User talk:Kitchen Knife">talk</a> | <ahref="/wiki/Special:Contributions/Kitchen_Knife"title="Special:Contributions/Kitchen Knife">contribs</a>)</span></div><divid="mw-diff-otitle3"><spanclass="comment">(<ahref="#wikEd_bug_report:_.28Please_add_short_title.29">→</a><spandir="auto"><spanclass="autocomment">wikEd bug report: ____ (Please add short title)</span></span>)</span></div><divid="mw-diff-otitle5"></div><divid="mw-diff-otitle4"><ahref="/w/index.php?title=User_talk:Cacycle/wikEd&diff=prev&oldid=615282897"title=""id="differences-prevlink">← Previous edit</a></div></td><tdcolspan="2"class="diff-ntitle"><divstyle="font-weight: bold;"id="tw-revert-to-nrevision"><ahref="#"><spanstyle="color: Black;">[</span><spanstyle="color: SaddleBrown;">restore this version</span><spanstyle="color: Black;">]</span></a></div><divid="mw-diff-ntitle1"><strong><ahref="/w/index.php?title=User_talk:Cacycle/wikEd&oldid=615288095"title="User talk:Cacycle/wikEd">Revision as of 08:50, July 2, 2014</a> (<ahref="/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&oldid=615288095"title="User talk:Cacycle/wikEd">edit</a>) (<ahref="/w/index.php?title=User_talk:Cacycle/wikEd&action=edit&undoafter=615282897&undo=615288095"title=""Undo" reverts this edit and opens the edit form in preview mode. It allows adding a reason in the summary.">undo</a>)</strong></div><divid="mw-diff-ntitle2"><ahref="/wiki/User:Technical_13"title="User:Technical 13"class="mw-userlink">Technical 13</a><spanclass="mw-usertoollinks">(<ahref="/wiki/User_talk:Technical_13"title="User talk:Technical 13">talk</a> | <ahref="/wiki/Special:Contributions/Technical_13"title="Special:Contributions/Technical 13">contribs</a>)</span></div><divid="mw-diff-ntitle3"><spanclass="comment">(<ahref="#wikEdDiff_bug_report:_diffs">→</a><spandir="auto"><spanclass="autocomment">wikEdDiff bug report: diffs: </span> RE</span>)</span></div><divid="mw-diff-ntitle5"></div><divid="mw-diff-ntitle4"><ahref="/w/index.php?title=User_talk:Cacycle/wikEd&diff=next&oldid=615288095"title="User talk:Cacycle/wikEd"id="differences-nextlink">Next edit →</a></div></td></tr><tr><tdcolspan="2"class="diff-lineno">Line 961:</td><tdcolspan="2"class="diff-lineno">Line 961:</td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"><div>Message from webpage</div></td><tdclass="diff-marker"> </td><tdclass="diff-context"><div>Message from webpage</div></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"><div>---------------------------</div></td><tdclass="diff-marker"> </td><tdclass="diff-context"><div>---------------------------</div></td></tr><tr><tdclass="diff-marker">−</td><tdclass="diff-deletedline"><div>== <delclass="diffchange diffchange-inline">wikEd</del> bug report: <delclass="diffchange diffchange-inline">____ (Please add short title)</del> ==</div></td><tdclass="diff-marker">+</td><tdclass="diff-addedline"><div>== <insclass="diffchange diffchange-inline">wikEdDiff</ins> bug report: <insclass="diffchange diffchange-inline">diffs</ins> ==</div></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"></td><tdclass="diff-marker"> </td><tdclass="diff-context"></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"><div>* Date: 2014-06-26 12:01:05 UTC</div></td><tdclass="diff-marker"> </td><tdclass="diff-context"><div>* Date: 2014-06-26 12:01:05 UTC</div></td></tr><tr><tdcolspan="2"class="diff-lineno">Line 980:</td><tdcolspan="2"class="diff-lineno">Line 980:</td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"></td><tdclass="diff-marker"> </td><tdclass="diff-context"></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"><div><spanclass="before-localcomments">: Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - <ahref="//en.wikipedia.org/wiki/User:Cacycle"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="User:Cacycle">[[User:Cacycle|Cacycle]]</a> (<ahref="//en.wikipedia.org/wiki/User_talk:Cacycle"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="User talk:Cacycle">[[User talk:Cacycle|talk]]</a>) </span><spanclass="localcomments"style="font-size: 95%; white-space: nowrap;"timestamp="1404053681019"title="14:54, 29 June 2014 (UTC)">10:54 am, 29 June 2014, last Sunday (4 days ago) (UTC−4)</span><spanclass="after-localcomments"></span></div></td><tdclass="diff-marker"> </td><tdclass="diff-context"><div><spanclass="before-localcomments">: Works for me as far as I can see. Please could you provide some more details and an actual diff link where it happens? Thanks - <ahref="//en.wikipedia.org/wiki/User:Cacycle"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="User:Cacycle">[[User:Cacycle|Cacycle]]</a> (<ahref="//en.wikipedia.org/wiki/User_talk:Cacycle"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="User talk:Cacycle">[[User talk:Cacycle|talk]]</a>) </span><spanclass="localcomments"style="font-size: 95%; white-space: nowrap;"timestamp="1404053681020"title="14:54, 29 June 2014 (UTC)">10:54 am, 29 June 2014, last Sunday (4 days ago) (UTC−4)</span><spanclass="after-localcomments"></span></div></td></tr><tr><tdcolspan="2"class="diff-empty"> </td><tdclass="diff-marker">+</td><tdclass="diff-addedline"><div><spanclass="before-localcomments">:* See <ahref="//en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)%23Another_new_bug_today_-_don%27t_know_the_terminology"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="Wikipedia:Village pump (technical)/Archive 127#Another new bug today - don't know the terminology">[[Wikipedia:Village pump (technical)/Archive 127#Another new bug today - don't know the terminology]]</a> where <ahref="//en.wikipedia.org/wiki/Template:U"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="Template:U">{{U|Maile66}}</a> reports the same issue. Any diff of my sandbox actually shows the issue, but <ahref="//en.wikipedia.org/wiki/Template:Diff"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="Template:Diff">{{Diff|User:Technical 13/SandBox|prev|614509806|here's a specific one}}</a> that doesn't have a lot of changes. — <span class="nowrap">&#123;&#123;U&#124;<ahref="//en.wikipedia.org/wiki/User:Technical_13"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="">[[User:Technical 13|Technical 13]]</a>&#125;&#125; <sup>(<ahref="//en.wikipedia.org/wiki/Special:EmailUser/Technical_13"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="">[[Special:EmailUser/Technical 13|e]]</a> • <ahref="//en.wikipedia.org/wiki/User_talk:Technical_13"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="User talk:Technical 13">[[User talk:Technical 13|t]]</a> • <ahref="//en.wikipedia.org/wiki/Special:Contribs/Technical_13"style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"title="Special:Contribs/Technical 13">[[Special:Contribs/Technical 13|c]]</a>)</sup></span></span><spanclass="localcomments"style="font-size: 95%; white-space: nowrap;"timestamp="1404305441021"title="12:50, 2 July 2014 (UTC)">8:50 am, Yesterday (UTC−4)</span><spanclass="after-localcomments"></span></div></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"></td><tdclass="diff-marker"> </td><tdclass="diff-context"></td></tr><tr><tdclass="diff-marker"> </td><tdclass="diff-context"><div>== WikEd breaks valid HTML ==</div></td><tdclass="diff-marker"> </td><tdclass="diff-context"><div>== WikEd breaks valid HTML ==</div></td></tr><!-- diff cache key enwiki:diff:version:1.11a:oldid:615282897:newid:615288095 --></tbody></table>
Opened it with your link, saved it, no prroblem. Opened saved version type some garabge at foot off the page and got the problem.--Kitchen Knife (talk) 16:33, 29 June 2014 (UTC)
I opened an old version then saved it. That was the first edit. The second edit I made a chage. The difference is that I didn't make an edit first time. I suspect that making a change myself set some kind of edit flag which caused the editor act differently. I went to revert but someone got there seconds before me.--Kitchen Knife (talk) 17:43, 29 June 2014 (UTC)
If you open an old version of a page, click "edit" and save without making changes, what you're doing is reverting to that old version, hence this message when you're editing. --Redrose64 (talk) 19:12, 29 June 2014 (UTC)
Yes I know but from the point of view of the editor. It only has to write out the input buffer. If a change is made then the out put has to be created by parsing the new file. It involves a lot more software than just saving a copy of what was opened--Kitchen Knife (talk) 19:58, 29 June 2014 (UTC)
I still can't reproduce this. Kitchen Knife: Please could you post a bug report by Ctrl-clicking the wikEd logo on top of the edit page, copy the text here, and fill in the details? Thanks in advance - Cacycle (talk) 09:09, 2 July 2014 (UTC)
wikEd bug report: ____ breaking valid HTML
Date: 2014-07-02 12:00:50 UTC
wikEd version: 0.9.129 G (June 24, 2014)
Browser: Mozilla/5.0 (Windows NT 5.1; rv:30.0) Gecko/20100101 Firefox/30.0 (Win32)
Error console: ____ (Firefox: Tools → Web Developer → Browser console; push clear and reload the page. Chrome: Control button → Tools → JavaScript console. Copy and paste error messages related to wikEd.js)
Kitchen Knife: Thanks a lot! I made a sandbox for testing this issue here: User:Cacycle/sandbox. Can you also reproduce the bug when editing this sandbox page? If so, do you also see it after reverting your changes and then switching to the vector skin (in order to disable your sharebox script)? Thanks for your help - Cacycle (talk) 15:28, 2 July 2014 (UTC)
OK, I can absolutely not reproduce this. Maybe it is related to a broken browser add-on. Do you use Greasemonkey? What happens if you disable all browser add-ons? What happens if you use another browser (such as Chrome)?
Before 10 seconds saves okAfter 10 seconds save corrupt The problem seems to be an interaction between the Editor and Ginger switch either off and it is fine. If I open the file that produces the bug and save immediatly no problem but if I wait about ten secons Ginger does it's thing changes a bit of higlhlighting and a save without and added characters causes the problem. See 2 images.--Kitchen Knife (talk) 23:03, 2 July 2014 (UTC)
Kitchen Knife: I will submit a bug report to Ginger for which we need more details. Which version of Ginger are you using? Free, basic or premium? What happens if you update to the current version (3.5.89)? Even with Ginger basic installed, I cannot reproduce this, as for me, Ginger needs to be invoked manually by F2 before it suggests text changes. Also, it adds spaces, but does not shuffle the ! and < around as it does for you. Cacycle (talk) 10:36, 3 July 2014 (UTC)
Ginger's (broken) automatic highlighting might theoretically cause this problem - but I do not see any Ginger highlighting for me. Cacycle (talk) 10:56, 3 July 2014 (UTC)
Kitchen Knife: Thanks. Just to be sure: you have the current version 3.5.89 installed and the Firefox add-on is version 2.0.0.69? Mine actually is version 0.1 (!?). Do you use free, basic, or premium? What do you mean by "no support without that"? Cacycle (talk) 13:31, 3 July 2014 (UTC)
You need to go into addons, go to get addons and search for ginger. That will come up with an old version of the addon 2.0.0.50 install that and then check for updated. I'm not sure what this addon does that the other doesn't but it should start working automatically in FireFox for things like FaceBook at el. I have tried to get an explanation from Ginger but their support is very dimb and the scripts do not cover it's existance or it's function. I'm using Free and I am logged on. --Kitchen Knife (talk) 16:25, 3 July 2014 (UTC)
Ginger has a major design flaw and always breaks the undo/redo history (because of direct DOM manipulation). Also, it corrupts certain text highlighted by wikEd ("<tag><!-- -->" → "<tag<!>-- -->"). Therefore, wikEd now detects an active Ginger add-on and disables itself. Please disable this add-on if you want to use wikEd. Cacycle (talk) 21:27, 3 July 2014 (UTC)
Thanks for your effort my lack of grammatic ability means that if it a choice between wikied and Ginger then ginger will win.--Kitchen Knife (talk) 19:37, 5 July 2014 (UTC)
wikEd bug report: wikEdDiff content blank
Latest comment: 10 years ago3 comments2 people in discussion
Date: 2014-07-03 17:46:32 UTC
wikEd version: 0.9.129 G (June 24, 2014)
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 (Win32)
Problem description: On any diff page I go to, clicking the delta button results in a small gray box with a horizontal bar running thorugh it, but no content. This was working for me until recently, been a month or so since I used the functionality, so i don't know the exact break date.
Steps to reproduce: Open any diff, scroll past the standard side-by-side dif boxes, click teh delta button to open the wikEdDiff content.
Latest comment: 10 years ago7 comments2 people in discussion
Great to see more active updates being applied! Anytime an update is made to the .user.js version, Greasemonkey tells me there's a new version, and I have to click through a simple pop-up to install it, and that in and of itself is fine. The annoyance here is that once an update is made to the script, I have to click through that update popup on EVERY SINGLE FREAKING WIKI I VISIT! I mean literally, I'll get notified about the update on (this is an example) Wookieepedia, and install it. Then a few minutes later I click over to the Star Wars Fanon Wiki, and get the popup again. Then I visit here and get it again. Go to Commons, same thing. Go to Meta, same thing. Click a link to the French Wikipedia, same thing. In short, I get the update popup every time I visit literally any MediaWiki wiki anywhere on the Internet that I haven't visited since the last actual update, which means that instead of being notified about, and installing, the update once, I have to do it sometimes in excess of a dozen times per update. The actual wikis involved are irrelevant; it happens on all MediaWiki wikis everywhere.
Is this normal Greasemonkey behavior to require you to redownload the same update over and over again for every single subdomain you visit, or is something in wikEd causing this? If the latter, I would greatly appreciate it if you could fix it. — Preceding unsigned comment added by Jcgoble3 (talk • contribs) 04:01, 4 July 2014 (UTC)
Still happening. I note that the Greasemonkey popup gives the version number as 0.9.130a, but the icon in the upper right displays the version number in the tooltip as 0.9.126c GM (May 10, 2014). I wonder if the difference in version numbers could be causing this? (Also, I was slow to respond because I did not get a ping notification for your reply here. :/ I don't know what caused that; I do have both web and email notifications enabled for that.) jcgoble3 (talk) 02:32, 7 July 2014 (UTC)
Jcgoble3: If the version number in the tooltip still says "0.9.126c GM (May 10, 2014)", then you have not actually updated wikEd to the new version. What happens, if you manually update by going here? Cacycle (talk) 15:09, 7 July 2014 (UTC)
I tried the manual update. GM popup says version 0.9.131, after update the tooltip remains "0.9.126c GM (May 10, 2014)". Despite the lack of a change to the tooltip, upon visiting other wikis following the manual update, I did not receive an automatic update alert. I opened the GM "manage scripts" page, and interestingly I now have wikEd listed twice. The first one is titled simply "wikEd", and is this version of the script. The second is titled "wikEd 0.9.131" and is the current version of the script (permalink). I have disabled the older one, and we'll see what effect that has. jcgoble3 (talk) 04:23, 8 July 2014 (UTC)
Latest comment: 10 years ago1 comment1 person in discussion
I can't believe nobody suggested this, which means it's already been suggested, which means there's a reason you can't do it, which means I shouldn't request it.
But I'm going to request it anyway:
I have no idea what most of the editor buttons do. The icons, like all icons, are near-meaningless; and as with Firefox, you don't think enough people are literate to make it worth having text labels.
Now, while that is true in the United States, a few people here still know how to read and would appreciate pop-up hints when hovering over a strange picture.
ONE MORE OBSERVATION:
Every single word processor manages to do WYSIWYG table editing, but at Wikipedia, it's exceeeedingly complex and dam near impossible. Yeah, hey, well no problem. Verdana♥Bøld 20:26, 4 July 2014 (UTC) — Preceding unsigned comment added by Verdana Bold (talk • contribs)
Thanks, it has been fixed in 0.9.132a. 88.108.90.164: this cannot be the cause of wikEd not working for you. Would you mind posting an error report (see top of thispage)? Cacycle (talk) 11:36, 25 August 2014 (UTC)
insertTags
Latest comment: 10 years ago1 comment1 person in discussion
When this script is loaded, I get three copies of this warning in the console: Use of "insertTags" is deprecated. Use mw.toolbar.insertTags instead.
It seems the script should have a dependency on module 'mediawiki.action.edit', which contains the JS file where the function is defined. Helder14:19, 12 August 2014 (UTC)
Uncaught NotFoundError
Latest comment: 10 years ago3 comments2 people in discussion
Hi!
If I open an EMPTY PAGE on Google Chrome 36 and click on I get the error Uncaught NotFoundError: Failed to execute 'setStartBefore' on 'Range': The node provided is null. from the line
Latest comment: 10 years ago3 comments2 people in discussion
If I open a page whose content is the string "* {{TEST}}" and click on (or ) I get the error Uncaught TypeError: Cannot read property 'replace' of undefined from the line
Latest comment: 10 years ago3 comments2 people in discussion
Hello, Cacycle/wikEd. Please check your email; you've got mail! It may take a few minutes from the time the email is sent for it to show up in your inbox. You can remove this notice at any time by removing the {{You've got mail}} or {{ygm}} template.
Problem description: Mixed passive content problem (https://developer.mozilla.org/en-US/docs/Security/MixedContent) occurs when using short preview on given page (and possibly on other pages using flags). Always reproducible for me. I have tried to find the offending line causing the http request (using Firebug Net tab) but unsuccessfully – looking through HTTP responses, all links there to Flag_of_Tajikistan seem to use URL without specifying http or https explicitly.
Steps to reproduce:
open URL given in the report
open browser console
press "Show preview below" button
console shows mixed content and address bar icon changes from padlock to warning
Problem description: Basically, RegEx search isn't working at all. Even if I don't use any special characters. I can type 1 into the search box, and wikEd will highlight the first appearance of the character, but pressing "Find next match" won't take me to the next appearance of the character. This is the case no matter what has been put into the search box. Turning off RegEx allows me to do normal searching (and the "Find next match" button does work).
Latest comment: 10 years ago2 comments2 people in discussion
I noticed on WP:AWB/T#wikEd that wikEd does not apply any filters on the typo fixing, and simply applies the rules to all text on the page. This seems like a risky move to me, so I'd like to suggest implementing a filter anyway. I've made a short script which does exactly that, and is easy to import and use. See User:Joeytje50/RETF for the documentation. This will prevent parts of the page that most obviously shouldn't be typo-fixed from being changed. Joeytje50 (talk) 22:54, 9 September 2014 (UTC)
Latest comment: 10 years ago2 comments2 people in discussion
Version: maybe later 0.9.134 (August 25, 2014) diff
Attention line: title = title.replace(/[#<>\[\]|{}]/g, );
In the diff page, section link is not working. I am guessing that is because the # sign has been removed from the link. Thank you very much. --Frozen-mikan (talk) 01:32, 27 September 2014 (UTC)
Latest comment: 10 years ago2 comments2 people in discussion
Steps to reproduce problem
Edit a biography with a person infobox (e.g., Frank McLaury).
Manually select all text in the article (i.e., CTRL + A).
Click the wikEd button to "Fix caps in headers and lists".
Save the results.
The infobox fails to display. The problem is that the initial characters of the parameters for the infobox are converted to initial caps, as in the following example:
{{Infobox criminal
| Name = Frank McLaury
| Image_name = Fmclaury.jpg
| Image_size = 220px...
This breaks the infobox which requires lowercase parameters. If this functionality is not implemented by wikEd, I'd appreciate a redirect to the correct script. Thanks.
Supporting info
Confirming bug still appears in 0.9.142.
Running Chrome Version 37.0.2062.124 m
Windows 8.1 64bit
Wikipedia Modern skin
Bug still present after disabling all other custom scripts
Chrome error console contained the following error.
console.trace()
2XMLHttpRequest cannot load https://commons.wikimedia.org/w/api.php. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://en.wikipedia.org' is therefore not allowed access.
en.wikipedia.org/w/index.php?title=Frank_McLaury&action=edit:1
btphelps: Thanks for reporting this. The fix buttons use relatively simple rules and cannot detect the difference between a table and template parameters. This will not change in the near future. After using these buttons always check the changes for unexpected collateral damage and always use the smallest possible selection. Please see User:Cacycle/wikEd_help#Fix_buttons. Cacycle (talk) 08:12, 23 October 2014 (UTC)
Not compatible with TemplateData
Latest comment: 10 years ago3 comments3 people in discussion
Wikipedia:TemplateData is a brand new feature which is apparently not fully compatible with wikEd:
Change something in the pop-up form, e.g. the description.
Click on the "Apply" button".
Now, changes made to template data should be propagated to the edit area (<templatedata> element), but they are not. The workaround is to switch wikEd off when working with TemplateData form, or to use the edit area directly rather than the form. GregorB (talk) 20:13, 7 October 2014 (UTC)
Latest comment: 10 years ago2 comments2 people in discussion
a big problem
I appreciate your response you left on my talk page, but it didn't seem to correct the problem. This is a shot of the editing toolbar that I see when wikiEd is enabled. But even the buttons that are displayed don't even work.
Latest comment: 9 years ago2 comments2 people in discussion
Hey Cacyle. Just a heads up that wikEd is one of the scripts that will cease to function when deprecated legacy js support is removed from MediaWiki in 1.26 or 1.27. I noticed this when I saw a bunch of deprecation warnings ("Use of "skin" is deprecated. Use mw.config instead." for example) and reloaded the page in debug=true mode and saw it was wikEd causing a bunch of them. Please see MW:ResourceLoader/Legacy JavaScript for details and fixes/replacements. Thanks. — {{U|Technical 13}} (e • t • c)13:50, 11 February 2015 (UTC)
Latest comment: 9 years ago1 comment1 person in discussion
I have an absolute love for wikEd, especially its syntax highlighting and hence I'd like to be able to have the same syntax highlighting that wikEd uses for wikitext in SciTE for off-line use. This means, however, that I'll need a .properties file for wikitext, I wouldn't suppose you'd know where I could find one? Brenton (contribs · email · talk · uploads) 19:26, 26 February 2015 (UTC)
Minification
Latest comment: 9 years ago3 comments3 people in discussion
Why is this not minified? It is huge and it will make a difference.
Also it seems to not work in Wiktionary. Maybe it is because my custom userscripts. But why would it have any problems with them if I do not have anything that touches the toolbar.
Also, it would be supercool if we had some shortcuts implemented. Like, Ctrl+X for line cut, Ctrl+S for saving and most importantly multiple cursors like in notepad++. I know I know the last one is difficult but I am sure it is already written for JS. --Dixtosa (talk) 21:21, 5 April 2015 (UTC)
If someone migrates this to a gadget, and is able to make it work once ResourceLoader is enabled for such a gadget, then it will be minified for users enabling the gadget on English Wikipedia. Other wikis could import from load.php instead of index.php, and it would be also minified automatically by Resource Loader. Helder19:26, 6 April 2015 (UTC)
wikEd uses the browser-internal editor with its browser-specific default shortcuts as well as the default MediaWiki shortcuts. Therefore, multiple cursors are not possible.
wikEd is not minified because I am uploading everything by hand and minifying and distributing to more than one central place would simply be to complicated for me. A robot that automatically updates wikEd on on a list of wikis gadget pages would be a nice solution - anybody?
Latest comment: 9 years ago3 comments3 people in discussion
Hi, I have the bad habit of typing before WikEd is loaded ... Doing this I sometimes insert caracters in the beginning of the text box where the cursor was one moment ago at some different point. Is there something you can do, like not changing the cursor position on loading WikEd, or is it my setup who seem too slow ? In how many time is wiked supposed to load on a reasonable computer ? TomT0m (talk) 13:19, 17 April 2015 (UTC)
@Cacycle: I sometimes have this problem on a modern computer. It appears to be independent of where it is being used (I have seen the problem on Wikipedia and external wikis on Wikia) or how it is loaded (gadget on Wikipedia, user script on Wikia). The real cause seems to be the speed at which the edit page loads; when it takes more time than usual (e.g. very large page, slow internet connection, server slow to respond, etc.), then wikEd does not load immediately, leaving the standard edit box there for a few seconds before it is replaced with the wikEd box. Is it possible to make wikEd read the current cursor position and "copy" that over to the wikEd box on loading? (Also of note, when characters are typed in the standard edit box before wikEd loads, wikEd then fails to include those changes when asking it to show the diff below the edit box.) jcgoble3 (talk) 20:54, 14 August 2015 (UTC)
wikEd in IE
Latest comment: 9 years ago1 comment1 person in discussion
Interesting findings: WikEd loads in Internet explorer. The functions mostly don't work, or work strangely (e.g. the "find" field spells things backward), BUT — it does display the improved editing view (very handy when copyediting, so you can see around the refs), and you can check your changes with WikEdDiff. I think I might keep it around, just for those purposes. Eman235/talk18:45, 18 April 2015 (UTC)
Question about SSL encrypted Wiki sites
Latest comment: 9 years ago2 comments2 people in discussion
I enabled SSL on my wiki. Now, if I open my wiki, all browsers warn about non-encrypted content. This content is the WikEd editor (it is blocked if I choose to block non-encrypted content).
Hi rosch: Sorry for the delayed response. How do you load wikEd on your wiki? Try to replace any http://link-to-wikEd by //link-to-wikEd. Hope that helps, please report back here. Cacycle (talk) 11:38, 25 June 2015 (UTC)
search & replace NOT in markup
Latest comment: 9 years ago2 comments2 people in discussion
1. What regex magic would you use to search & replace only in the user-readable text, not in wikilinks and references and external links, please?
2. Can I leave a feature request for a button toggle implementing the above with no explicit regex? Thanks. Fgnievinski (talk) 04:20, 5 July 2015 (UTC)
Fgnievinski: try a three-step process. First replace or taint all occurrences in links with a rare character such as @ or §, then do the actual replacement, and finally reinstate the original link content. A regexp for links could be (\[\[)(searchPart1)(searchPart2)(\]\]), a replacement could be \1\2§\3\4. Cacycle (talk) 07:35, 6 July 2015 (UTC)
Load error
Latest comment: 9 years ago1 comment1 person in discussion
"Use of "skin" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgServer" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgTitle" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgArticlePath" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgScript" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgScriptPath" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgUserName" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgCurRevisionId" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgContentLanguage" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgUserLanguage" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgEnableAPI" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgPageName" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgNamespaceIds" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgFormattedNamespaces" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgVersion" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgPageContentModel" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgServer" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgArticlePath" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgScriptPath" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgCurRevisionId" is deprecated. Use mw.config instead." load.php:156:624
"Use of "wgPageName" is deprecated. Use mw.config instead." load.php:156:624
Latest comment: 9 years ago26 comments9 people in discussion
wikEd had to be disabled for the most recent Chrome version 45.0.2454.85 because of a browser bug. It was not not possible to type into empty wikEd input fields such as the edit summary or the find and replace fields. Cacycle (talk) 17:28, 4 September 2015 (UTC)
I'm also a Chrome user (with Mac, mainly works for zhwp). I find this problem very annoying, so I click on the yellow icon on the right top to close wikEd. Then another problem appears: Cannot reopen wikEd by clicking the yellow icon.--Spring Roll Conan ( Talk · Contributions ) 06:17, 5 September 2015 (UTC)
Please enable wiked for chrome 45.0, even with this error. switching to FF or other chrome version not possible. McCell (talk) 09:26, 7 September 2015 (UTC)
Two days ago I had Windows 10 installed on my computer, and when I got it back, WikEd no longer appeared at all. I have it selected under "Preferences/Gadgets", but it doesn't appear. I hope this will get fixed because it really helps me as I read and copy-edit articles. Corinne (talk) 01:44, 6 September 2015 (UTC)
Doc James I have never used Firefox. My computer had been set up with IE when I got it back from the store, and I changed it pretty soon to Chrome. Should I try using IE and Firefox to see if WikEd works on those? Corinne (talk) 02:30, 6 September 2015 (UTC)
Thank you, Cacycle, for discovering the source of the problem. I hope Google decides to consider thus this a bug rather than expecting WikEd to change itself to accomodate the new problem. I was actually trying to figure out a way to change my useragent to force WikEd back on, since I dont think I would have the edit summary problem when doing section-editing, but it seems it's more of a hassle than I expected to do so. Im probably going to just have to switch back to Firefox for the meantime since I really do need WikEd. NOTE: I can confirm that I was wrong. The edit summary field is unusable even when it is pre-filled by the software. Oddly, it still allows me to preselect previously used edit summaries, even if they are from totally unrelated pages, but it just appends this to the other edit summary. Its messy but its better than nothing. —Soap—18:39, 9 September 2015 (UTC)
What I mean is: I can't re-activate WikEd by press on the grey(yellow) icon on the right-top (using Mac 10.10.5 or Windows 7). As aforementioned, I turned off WikEd by press the yellow icon as I feel annoying on its previous flaws, but since I can't use it on PC/Macbook. Also I can't really figure out the instruction; I'm not a IT savvy, but seen something like removing "position:absolute", doubting that is it a solution. But when viewing desktop version via mobile devices while I am logging in, WikEd works well.--Spring Roll Conan ( Talk · Contributions ) 14:38, 15 September 2015 (UTC)
The Chrome bug has been fixed, after updating to the latest versions of Chrome and wikEd everything works again. Cacycle (talk) 09:45, 16 September 2015 (UTC)
I have the same problem in Opera, but works in Vivaldi. JAn Dudík (talk) 13:13, 1 October 2015 (UTC)
localStorage Error
Latest comment: 9 years ago2 comments2 people in discussion
Hi Cacycle. Just ran into an error with WikEd. You use window.localStorage.setItem() and getItem(), without wrapping them in try/catch. These commands can and do however often throw exceptions, either because of it being full, or because the user has disallowed local storage, or the storage DB has become corrupt (common problem on FF). Any usage of local storage should be able to gracefully handle a local storage exception. —TheDJ (talk • contribs) 20:06, 10 September 2015 (UTC)
Latest comment: 9 years ago6 comments3 people in discussion
I run WikEd in Greasemonkey and think it's great. There is just on major annoyance - WikEd always takes a few seconds longer to load than the rest of the page, so when I want to press one of the links at the top of the page I invariable click it just as WikEd loads and I end up logging out or going to the the wrong page.
It also makes the page slower because it keeps having to redraw it once WikEd has loaded. Neither do I ever use the button as I always have WikEd running and always Is there any simple way to disable these logos:
Icon
Name
Description
Enabled
Use this button to disable wikEd. This will disable wikEd for all browser windows and for all future browser sessions. Click the logo again to re-enable wikEd. wikEd will currently not load if the wiki database is locked or a page is protected. Pressing this button erases the undo history.
Disabled
This icon will be displayed if wikEd is disabled. Press the icon to re-enable wikEd.
Load error
If an error has occurred while loading and initializing wikEd you will see this icon instead. You can check the JavaScript console under the Tools menu of your browser for an error message and report this to the wikEd discussion page.
@CFCF: The CSS line #wikEdLogoList { display: none; } ought to remove it. To easily use this across multiple sites and easily turn it off in the event you need to check for an error or produce an error report, you can use the Stylish extension, which is to CSS what Greasemonkey is to JS. jcgoble3 (talk) 20:50, 21 September 2015 (UTC)
Thanks, I added the line to the top of my Greasemonkey script. I find Stylish bogs down my FF too much so I don't use it, but otherwise thanks for the tip. CFCF 💌📧22:01, 21 September 2015 (UTC)
@CFCF: Note that by adding it to the Greasemonkey script manually, it will probably disappear every time Cacycle pushes an update to the script. To prevent that, create a second custom script that has just that line (plus the necessary GM header stuff), and set it to execute before the wikEd script (Greasemonkey → Manage User Styles → Execution Order → right-click scripts and adjust as needed). jcgoble3 (talk) 20:25, 22 September 2015 (UTC)
Thanks, but I went ahead and installed stylish. It really didn't do much for my page-loads times, I guess I just tried some really heavy user-styles last time around. Maybe this should be documented somewhere-I can't be the only one to have had the issue. CFCF 💌📧20:30, 22 September 2015 (UTC)
I use this code to avoid logging out unintentionally: $('#pt-logout a').click(function () {return confirm('Log out?');}); That way it will ask you for a confirmation first. --V111P (talk) 10:07, 22 September 2015 (UTC)
Wikicode syntax highlighter
Latest comment: 9 years ago4 comments2 people in discussion
Hello. I'm testing WikEd in a self-hosted Wiki that I have and it's amazing! However, my needs are quite simple and specific, and I'm mainly interested in its Wikicode syntax highlighter. Is there any way to use that function only? Thanks. :)--Manuel de la Fuente (talk) 12:57, 26 October 2015 (UTC)
Oh, I see. I already tried to dissect the code and extract the highlighter, but it has +19,000 lines, so... @_@
I noticed that you mentioned the technical reasons behind the lack of a live syntax highlighter. That's precisely what I'm looking for. I know the Wikia sites include a live wikicode syntax highlighter in their "Classic editor". I'd like to know how they do it and if it would be possible to adapt it to the standard MediaWiki installations. I'm going to take a look at their GitHub and see what I can find. Anyway, thank you for the answer. :)--Manuel de la Fuente (talk) 01:52, 31 October 2015 (UTC)
Hi, it's me again. I just wanted to tell you that I finally found a live wikicode syntax highlighter without having to look at Wikia's GitHub. This is the script. I tell you in case you don't know it (though probably you do) and if it could help to the development of WikEd. Greetings.--Manuel de la Fuente (talk) 06:33, 3 November 2015 (UTC)
Advanced Regex
Latest comment: 9 years ago3 comments2 people in discussion
I often use wikEd's regex find/replace functionality to fix common issues, such as incorrect use of quotes (such as using an apostrophe instead of double quotes and using curly quotes instead of straight quotes).
Currently I use (‘|’|') to match all types of apostrophes, however this also matches apostrophes used in wiki formatting (such as '''bold''' and ''italics'').
Using negative lookbehind, such as '(?!'), finds an apostrophe which is not followed by another apostrophe, but it also finds apostrophes which are preceded by apostrophes (in other words it will find the last apostrophe in a sequence of 2 or 3 apostrophes). Likewise, using negative lookahead finds an apostrophe which is not preceded by another apostrophe, but it also finds apostrophes which are followed by apostrophe (it will find the first apostrophe in a sequence of 2 or 3 apostrophes). I have tried creating a regex using a combination of negative lookahead and negative lookbehind in order to only find single apostrophes and ignore two or three apostrophes in a row, however I can't get this to work correctly. I have written similar regexes before with combinations of lookahead/lookbehind, however this may be an area where JavaScript-specific regex syntax applies that I am not familiar with.
I think you are swapping some terms. Negative lookahead, such as '(?!'), finds an apostrophe which is not followed by another apostrophe. Negative lookbehind, such as (?<!')', should find an apostrophe which is not preceded by another apostrophe. Are you sure you can make negative lookbehind work alone? I cannot get it to work, http://www.w3schools.com/jsref/jsref_obj_regexp.asp only mentions negative lookahead, and http://www.regular-expressions.info/lookaround.html says "flavors like JavaScript and Tcl do not support lookbehind at all, even though they do support lookahead". Can you search ([^'])(‘|\’|')([^']) and replace by $1"$3 for your purpose? It captures a non-apostrophe character before and after an apostrophe, and keeps those characters while replacing the apostrophe. Or combine it with the working negative lookahead to not capture the character after the apostrophe: Search ([^'])(‘|\’|')(?!'), replace by $1". PrimeHunter (talk) 18:44, 10 November 2015 (UTC)
Not sure why JavaScript doesn't supper lookbehind; seems a bit strange.
Latest comment: 9 years ago1 comment1 person in discussion
WikEd will place diagonal red stripes on things that are wiki errors like misbalanced brackets (for example, [[abc]. Is there any way to have the editor search for that type of mistake in the article?Naraht (talk) 19:50, 16 November 2015 (UTC)
Installed wikEd Gadget, enabled <gadget-wikEd>, then nothing
Latest comment: 8 years ago1 comment1 person in discussion
Most of my installation went fine. Gadgets appeared in Preferences but I couldn't get hands on WikEd.
The Gadgets Special page says:
Gadget is not loaded. Please migrate to ResourceLoader. (Learn more)
Search and replace toolbar not displaying correctly - any fixes? REPRODUCIBLE
Latest comment: 8 years ago9 comments4 people in discussion
The search and replace toolbar is not displaying correctly (in Safari on Mac OS):
This is the case even in a newly set up test account. Can someone try to reproduce this in Safari on Mac OS? It looks normal (more or less) in Firefox.
As you can see, text in the edit window is obscured by the replacement text field...--Elvey(t•c)20:32, 8 December 2015 (UTC)
Hey Elvey. I've got two windows open, one using Firefox and another using Safari (5.1.10), both on my Mac. Firefox displays perfectly. I am seeing a slight problem on Safari, but not nearly as bad as the screenshot. Specifically, I was going to say I saw no error at all – because before I placed text in the search and replace fields, it displayed perfectly. However, once I entered some text in the two fields, they went out of alignment. Both fields but more the lower have moved down and the bottom edge of the lower field is about half a centimeter below the dropdown button next to it. Does knowing that help at all?--Fuhghettaboutit (talk) 02:04, 12 December 2015 (UTC)
Ah, interesting. I have an update. If I drag the safari browser window smaller until everything's very crowded together, I see the same error you screenshotted. But otherwise, there's just the tiny misalignment when text are placed in the fields.--Fuhghettaboutit (talk) 02:16, 12 December 2015 (UTC)
Thanks, Fuhghettaboutit! Wow, that's an ancient version of Safari! Version 8.0.8 (10600.8.9) here. Dragging my window smaller or bigger (I have a 1080p screen) doesn't make a difference, nor does zooming in/out. But I'll try with a fresh user account and see what happens. --Elvey(t•c)03:30, 12 December 2015 (UTC)
No. (Already answered - "Dragging my window smaller or bigger (I have a 1080p screen) doesn't make a difference, nor does zooming in/out.")--Elvey(t•c)02:30, 3 January 2016 (UTC)
Smaller and better userscript.
Latest comment: 8 years ago3 comments2 people in discussion
@TriMoon: "and does not run on the whole internet" Unfortunately, running on the "whole internet" is necessary because not all MediaWiki wikis are on Wikipedia or Wikia. For one, that script doesn't even cover other WMF projects (Wikibooks, etc.). There are also dozens, if not hundreds or thousands, of independent wikis out there on their own domain names. There are a few such wikis that I have contributed to using the wikEd userscript, and at least one had user JS disabled, so the userscript was the only way I could get wikEd there.
In summary, the point of the userscript is that it automatically works on all MediaWiki wikis everywhere, even those that have disabled user JS, and that simply can't be achieved with any restrictions whatsoever on where it runs. jcgoble3 (talk) 05:26, 5 January 2016 (UTC)
@Jcgoble3: "Unfortunately, running on the "whole internet" is necessary because not all MediaWiki wikis are on Wikipedia or Wikia."
However, it's not working (presumably due do a recent switch to Vector skin (currently the only skin on the site) and MediaWiki upgrade. I tried pasting the same code to the bottom of http://www.appropedia.org/MediaWiki:Vector.js but no luck.
Also, the use of the global variable wgPageName and all of its wg* siblings is deprecated and will eventually stop working. Wrap them like this: mw.config.get('wgPageName') to ensure that they continue to work in the future. jcgoble3 (talk) 21:02, 7 January 2016 (UTC)
Non-Functional on the Wikia Oasis Skin
Latest comment: 8 years ago1 comment1 person in discussion
Error: ReferenceError: wiked is not defined
Source File: javascript:%20wiked
Line: 1
Problem description: Text highlight when in text edit mode is not as highlighted as it used to be (less colors). There used to be a lot less items highlighted in gray. (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: Opened pages in text edit mode and noticed reduction in highlight variety. (Please include what happens at each step. Your problems cannot be fixed without reproducing them first!)
Latest comment: 8 years ago3 comments2 people in discussion
Hi, WikEd (tested on it.wiki) change "uad" with "", could you please create an option that can be activated to prevent this problem? (please, reply me on it.wiki)--Martinligabue (talk) 13:46, 7 March 2016 (UTC)
Hi Martinligabue, I do not see any problems, I can replace any text with ­ (soft hyphen). Please could you describe your problem in more detail? Thanks, Cacycle (talk) 14:39, 10 July 2016 (UTC)
(I changed the title for a title conflict) @Cacycle: If I use the button for fixing automatically html, unicode and spaces it does this, so it change some words, I'm not sure how to say it without an example, I have only that example... --Martinligabue (talk) 21:44, 10 July 2016 (UTC)
Bug: Strange characters inside template
Latest comment: 8 years ago1 comment1 person in discussion
When editing template with WikiEd enabled, happened twice that there were three additional characters inside tag:
Latest comment: 8 years ago2 comments2 people in discussion
This edit request to User:Cacycle/wikEd has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Here's the current section:
wikEd info and navigation box
Every wikEd project page has a navigation box on top. You can add this template to an English Wikipedia page by adding the following code on top of the page text:
{{User:Cacycle/wikEd_template}}
The following code can be used for wikEd navigation boxes and templates on non-Wikipedia sites and non-English Wikipedia pages. The box uses external html links. If you are not on Wikipedia or another Wikimedia site like Wiktionary or Wikinews, then you have to upload the logo WikEd_logo64x64.gif to your own wiki.
Please could you be more specific? I don't know what you mean by that.You haven't even linked to anything — Martin (MSGJ · talk) 09:02, 5 April 2016 (UTC)
When copying text, newlines get deleted from tables and templates
Latest comment: 8 years ago1 comment1 person in discussion
Newlines get deleted from templates and tables when copying text from the editor box. This seems to happen only when the newline is immediately followed by a pipe (although newline+pipe is safe outside of tables or templates). This happens to text loaded from the page, text that is typed into the editor box is unaffected. Seems similar to User talk:Cacycle/wikEd/Archive 011#Inserting/deleting newlines spuriously.
wikEd bug report
Date: 2016-04-27 20:55:27 UTC
wikEd version: 0.9.145c (September 16, 2015)
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0 (Linux x86_64)
Use of "wgPageName" is deprecated. Use mw.config instead. load.php:156:494
Use of "skin" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgServer" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgTitle" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgCanonicalNamespace" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgArticlePath" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgScript" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgScriptPath" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgUserName" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgCurRevisionId" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgContentLanguage" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgUserLanguage" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgEnableAPI" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgPageName" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgNamespaceIds" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgFormattedNamespaces" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgVersion" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgPageContentModel" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgServer" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgArticlePath" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgScriptPath" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgCurRevisionId" is deprecated. Use mw.config instead. load.php:156:494
Use of "wgPageName" is deprecated. Use mw.config instead.
Problem description: see above
Steps to reproduce: 1. while editing a page, add a template or a table containing at least one pipe character on a new line. 2. Hit 'Preview' (or 'Save page'). 3. copy the text from the WikEd box.
Latest comment: 8 years ago1 comment1 person in discussion
Hi, I have an issue with WikED regarding copying data from excel to Wikipedia. This is the data that I copied from Excel. After I copied to Wikipedia and clicked preview it shows that there are white-spaces between each row, like this. If I disabled WikED, the code shows correctly like here. Could anyone help with a solution? MbahGondrong (talk) 08:30, 29 April 2016 (UTC)
Find and replace/accent marks
Latest comment: 8 years ago3 comments2 people in discussion
I use wikEd in order to do find and replace operations that allow me to easily create Mexican radio articles.
However, I have an issue with the "Find" field (but not the Replace field). I cannot type accents on my Mac into the field. For instance, I get "M´exico" instead of "México". This can be circumvented by copy-pasting the offending accent mark into the field.
@Cacycle: I think it might have to do with the Mac's implementation of typing accents as this happens on Safari too (just tested latest version of WikEd on latest Chrome and Safari). For instance, I hit Option-N and get ˜, and then I type n and get ñ. That's two characters that the OS later combines. It works in Replace but not in Find; for instance, I get M´exico instead of México. Raymie (t • c) 17:44, 10 July 2016 (UTC)
Wiked incompatible with the templatedata interface
Latest comment: 8 years ago1 comment1 person in discussion
Hi, when I use the "manage templatedata" to generate a template metadata, the code is just not inserted into the page code when editing a template. TomT0m (talk) 17:07, 11 May 2016 (UTC)
Switching to the visual editor drops your changes
Latest comment: 8 years ago1 comment1 person in discussion
Latest comment: 8 years ago1 comment1 person in discussion
Hi, I think that the code for MediaWiki:Gadget-wikEd.js, when installing wikEd as a gadget in any MediaWiki 1.27 installation, has now changed to be as follows:
// install wikEd in-browser text editormw.loader.load('https://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript');
Latest comment: 8 years ago1 comment1 person in discussion
Hello. Is there a way to disable duplicated edit warnings? An example of duplicated edit warnings can be seen at Jamaica, which is indefinitely semi-protected. Also, is there a way to disable the "auto-scroll" feature that automatically scrolls to the edit window when the "Edit source" page loads? -- Gestrid (talk) 16:47, 19 July 2016 (UTC)
Source code of the page "Talouselämä_(lehti)" revid 15805468 contains Unicode 'NO-BREAK SPACE' (U+00A0) characters. (page source code loaded via API). When Wiked is started it converts 'NO-BREAK SPACE' characters to html entities ( ), example diff). Normal wikieditor doesn't change them.
Latest comment: 8 years ago1 comment1 person in discussion
Hi, I usually use Firefox with WikEd, today I used Edge... The autofix buttons didn't worked as I expected (I just used the firsts two purple buttons, because of the bug of the 4° one that changes random words in spaces), btw this extension did that (first editd part, then original part), just... why? Can you fix it? Martinligabue (talk) 21:12, 24 August 2016 (UTC)
Display issues when editing desktop version of wikipedia on mobile using wikiEd
Latest comment: 8 years ago1 comment1 person in discussion
Latest comment: 8 years ago1 comment1 person in discussion
wikEd is currently failing for me about 50% of the time. On occasions when it fails, hovering over the wikEd icon reveals the message "Incompatible script, gadget, or add-on: WikiEditor (delayed)". Nikkimaria (talk) 22:13, 12 October 2016 (UTC)
Req: Support for Foreground skin
Latest comment: 8 years ago1 comment1 person in discussion
Latest comment: 8 years ago1 comment1 person in discussion
Could you have a distinctive display of non-breaking hyphens? As explained in wp:nb-hyphen, once displayed, as produced by {{nbh}} or a numeric character entity, they can be copied and pasted into articles (as I did in Surname Law for the list of suffixes) and they work as intended but display in the edit box just like a normal hyphen. A distinctive display, like WikEd does for n-dash, m-dash, and minus sign (perhaps an n above the hyphen and a b below) would be useful. Similarly for the soft hyphen (instead of ­), and for the hair, thin, and figure spaces. (Non-breaking spaces produced by copy as normal spaces.)
Hgrosser (talk) 11:19, 29 October 2016 (UTC)
wikEd complains about |}, when {| is preprended by colon
Latest comment: 8 years ago1 comment1 person in discussion
User on dewiki has written, that wikEd makes the closing "|}" in red, when the open table syntax "{|" is preprended by a colon. Original version. Simple example:
Testcase
data
This is valid wikitext. It is also possible that there is one or more space or a html comment between the one or more colon and the {|. Der Umherirrende09:12, 31 October 2016 (UTC)
Problems in a wiki
Latest comment: 7 years ago2 comments2 people in discussion
Hi, I can't make the gadget work in my wiki, the only problem I see it's an advice it says to use ResourceLoader, but the page linked has no clue about how to fix the problem. Martinligabue (talk) 17:23, 10 November 2016 (UTC)
Latest comment: 8 years ago1 comment1 person in discussion
Can we knock this off? Its not useful like scrolling to the matching text, breaking double click to select word, right click Google search feature in Firefox/Chrome (I work on disambiguation pages), and triple-click to select lines for my screen reader. — Dispenser19:00, 10 November 2016 (UTC)
Compatibility with jQuery.textSelection
Latest comment: 7 years ago1 comment1 person in discussion
Hi!
@Alex Monk: could you improve the compatibility with the jQuery.textSelection plug-in by implementing the default interface for setting the content? This way users don't need to disable WikEd when they want to use other scripts which modify the content of the text area. This would be a follow-up to these edits and I believe it can be done by adding something like this:
Due to WikEd's popularity, it could be worth to implement the other functions too (getSelection, encapsulateSelection, getCaretPosition, setSelection and scrollToCaretPosition)...
Problem description: Text input boxes are the right size, but when I type in them, text is only visible in the central third as horizontal white lines block out the rest of the text: example of 'hello world'. It has been a slight issue for ages, but today there is far more white and it's impossible to read what I type. I noticed that the text moves vertically if I hold my mouse on it, as if scrolling but I still can't read any more. It appears specific to my OS/browser combo as I don't get this on other Firefox on Windows 7. Scrap that, as I'm also getting it on Firefox in Windows 7 now.
Firefox but not Chrome for me. Only for the past 2 days I think. I just get the top of the letters. I'm using Vector. Latest versions of both browsers. Doug Wellertalk19:33, 18 February 2017 (UTC)
I was hoping wikEd itself would be fixed, but it will have to wait, since Cacyle has apparently been away for 5 months or so now. Having a workaround is very useful. GregorB (talk) 12:56, 20 February 2017 (UTC)
Could someone explain how to fix this issue? I'm not sure what that VPT link was pointing at. I have the same issue with FF51 and Windows 10. Andyross (talk) 19:02, 1 March 2017 (UTC)
@Smartse: Thank you. Finally figured out how to create that subpage and added it. I can now see the summary as I add this. Any idea if this could have other side effects? Andyross (talk) 22:51, 1 March 2017 (UTC)
Latest comment: 7 years ago2 comments2 people in discussion
This edit request to User:Cacycle/wikEd has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Request that the table of installation methods in the Installation section be updated to include installation via user script in ALL wikis using the global.js script at Meta. The change is the same as this edit that I made to the wikEd installation page.
Hgrosser (talk) 10:26, 25 February 2017 (UTC)
Latest comment: 7 years ago2 comments2 people in discussion
The wikEd installation page gives the following code to be manually pasted into your common.js page:
// install [[Wikipedia:User:Cacycle/wikEd]] in-browser text editorimportScriptURI('//en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'+'&action=raw&ctype=text/javascript');
However, the {{wikEd}} template installs the following code:
// install [[User:Cacycle/wikEd]] in-browser text editordocument.write('<script type="text/javascript" src="'+'http://en.wikipedia.org/w/index.php?title=User:Cacycle/wikEd.js'+'&action=raw&ctype=text/javascript"></script>');
Which one is better? Even if there is no difference, it would be good to have them both the same for consistency. I just tested the template version (pasting the code manually), and it does not appear to work at all.
Hgrosser (talk) 14:56, 26 February 2017 (UTC)
Latest comment: 7 years ago5 comments3 people in discussion
input#wpSummary{/* This was added near the end of February */padding:0.625em0.546875em0.546875em;}/* Which has a higher CSS specificity than: */.wikEdSummaryText{padding:0px;box-sizing:border-box;}/* Using a different box model with different padding *//* As a result, in Firefox/Windows 7 Classic theme: I'm left with 4 pixels gap to see my edit summary. Fix this by (in [[User:Cacycle/wikEd.js]]):'input#wpSummary.wikEdSummaryText': 'padding: 0; margin: 0; ... Using a higher specificity or:'.wikEdSummaryText': 'padding: 0!important; margin: 0; ... Overriding the padding*/
Hi Cacycle, I succeed to update Wikipedia EN with WikEd 0.9.148. But for Wikipedia FR, i'm stuck with WikiEd 0.9.147a (with W10, Firefox, Vector Skin). Erànàë (talk) 23:38, 27 April 2017 (UTC)
Latest comment: 7 years ago1 comment1 person in discussion
so wiked fullscreen mode is not compatible with RTL. it is easy to see the issue, e.g., by adding "&uselang=ar" to the address line when in fullscreen. the problem is that once this condition begins (i.e., the user unwittingly clicked the fullscreen button), it is impossible to turn it off, b/c the right-hand-side menu (remember, RTL) overlaps the button and intercepts the clicks. i think "fullscreen" is broken for LTR too, but i can't really say, b/c i'm not sure what this feature should do.
in LTR, at least, it is easy to turn off - in RTL it's impossible, so it's important not to allow it. this happens to an editor on hewiki, and took some digging to figure out (took a bit of communication to realize they use wikEd, and lucky accident to figure they inadvertently activated "fullscreen").
i don't think this is worth "fixing", but it's important to disable the fullscreen button for RTL.
suggestion:
// line 3495:// grey out fullscreen buttonif((wikEd.editArticle===false)||(wikEd.useWikEd===false)){document.getElementById('wikEdFullScreen').className='wikEdButtonInactive';}// modify to:// grey out fullscreen buttonif((wikEd.editArticle===false)||(wikEd.useWikEd===false)||(wikEd.direction!=='ltr')){document.getElementById('wikEdFullScreen').className='wikEdButtonInactive';}
deeper fix is possible, but i think this minimalistic patch should do the job.
Latest comment: 7 years ago2 comments2 people in discussion
This edit request to Template:WikEd has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Need to add a <noinclude> tag above the {{documentation}} template call in order that it not be subst'd on the common.js javascript page. The correct closing tag </noinclude> already appears below.
Latest comment: 7 years ago3 comments2 people in discussion
Is there a way to change the default font size, and for that matter other style attributes, in the main edit window? I have read the customization guide and searched the archives, but I'm still hopelessly lost. Many thanks.- MrX20:47, 10 May 2017 (UTC)
Update: I was able to accomplish this by adding the following CSS to the Vecor custom CSS file:
Thanks ,I didnt see this before. I had a similar question and found a similar solution. In either case, it's independent of WikEd, since WikEd simply inherits the font size from Wikipedia's internal editor, and therefore the solution changes the font size whether WikEd is on or off at any given time.—Soap—19:32, 21 September 2017 (UTC)
Bug Report - wikEd inserts dozens of non-breaking spaces
Latest comment: 7 years ago3 comments3 people in discussion
wikEd version: 0.9.148
Operating system:MacOS, Ubuntu and Windows 10
Wikipedia skin: Vector
Web address (URL) of the page or wiki installation where you experience your problems: [11]
Error console entries: No errors.
Problem description: wikEd inserts dozens of non-breaking spaces when making an otherwise trivial edit? See this edit by WereSpielChequers, which I reverted and then attempted to reinstate the typo correction only to experience the same issue. I'm using Chrome 58.0.3029.110. Same problem using Firefox and Ubuntu. I have confirmed the issue in Chrome for MacOS and Windows 10; Firefox for Windows 10, but not Edge for Windows 10.
I found it. Not convinced that pointing to editor's userspace is the appropriate way to do this, but I have applied the change for now ... — Martin (MSGJ · talk) 20:51, 28 June 2017 (UTC)
Resolved
11:16, 6 July 2014 (UTC)
Template editor like myself and I'm wondering if this support is on the todo list. Thanks. — {{U|Technical 13}} (e • t • c) 20:06, 14 June 2014 (UTC)
on top of the edit page, copy the text here, and fill in the details? Thanks in advance - Cacycle (talk) 09:09, 2 July 2014 (UTC)
![[REF, TEMPL]](//upload.wikimedia.org/wikipedia/commons/0/0b/WikEd_ref_hide.png)
button). Please see wikEd help on WYSIWYG why WYSIWYG is actually not a good idea for wikis. Also, since all wikEd buttons have an axplanatory pup-up title, you are probably talking about the standard edit toolbar. Cacycle (talk) 10:05, 5 July 2014 (UTC)![[REF, TEMPL]](/wiki/File:WikEd_ref_hide.png){kind=small}
I get the error Uncaught NotFoundError: Failed to execute 'setStartBefore' on 'Range': The node provided is null. from the line
(or 
Eman235/talk 18:45, 18 April 2015 (UTC)
Fixed — Martin (MSGJ · talk) 11:57, 17 November 2015 (UTC)
Done — Martin (MSGJ · talk) 09:22, 3 March 2017 (UTC)
