User talk:Cacycle/wikEd

Please support wikEd

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

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

• Webkit/Chrome:
  • None.

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

Archives

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

.

wikEd Bug reports

Please Ctrl-click the wikEd logo ( on top of the page) or the wikEd button () on the page where you observe your problems. This gives you a bug report form that contains important debugging information.

In order to help you with problems, the following details and information are needed:

• wikEd version. Does the bug persist if you update to the latest version 0.9.155 (November 5, 2017) with Shift-Reload or Ctrl-Shift-R.
• Browser id
• Operating system
• Wikipedia skin
• User scripts that you have installed on your Special:Mypage/skin.js and Special:Mypage/common.js pages (if any). Optional: What happens if you disable this code.
• Gadgets that you have checked in your preferences. Optional: What happens if you disable these gadgets.
• Web address (URL) of the page or wiki installation where you experience your problems

In addition, please fill in the following fields:

• Error console entries. See reporting JavaScript errors. (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. 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 your problems. Please include what happens at each step. Your problems cannot be fixed without reproducing them first!

Please add your bug report at the bottom of this page.

Obsolete globals

This script is trying to access the deprecated globals skin, wgServer, wgTitle, wgCanonicalNamespace, wgArticlePath, wgScript, wgScriptPath, wgUserName, wgCurRevisionId, wgContentLanguage, wgUserLanguage, wgEnableAPI, wgPageName, wgNamespaceIds, wgFormattedNamespaces, wgVersion and wgPageContentModel instead of using mw.config.get('wg...') to acess them (check the multiple warnings in the console). Helder 23:30, 14 January 2015 (UTC)

Helder: Thanks, I will check into this (it may take a while as I am quite busy in real life at the moment...). Cacycle (talk) 11:31, 22 February 2015 (UTC)

@Cacycle: It’s been a while since the above message. If you don’t care about pre-RL clients, the following line should fix the problem (instead of lines 18347–18350):

globalScopeCode += 'wikEd.wikiGlobals.' + names[i] + '=mw.config.get("' + names[i] + '");';

—Tacsipacsi (talk) 16:46, 9 September 2017 (UTC)

I didn’t look at the source of wikEdDiff, but I see warnings for that as well (and this code says it’s copied there, so there shouldn’t be big differences). —Tacsipacsi (talk) 16:50, 9 September 2017 (UTC)

Still a problem, shouldn’t be archived yet. —Tacsipacsi (talk) 18:25, 10 October 2017 (UTC)

I've now fixed this. It was kind of annoying during debugging, so better get it out of the way. —TheDJ (talk • contribs) 21:04, 10 October 2017 (UTC)

Almost. In line 1371, 'if (typeof ' + names[i] + ' != \'undefined\') {' still tests the global variables even in modern environments. —Tacsipacsi (talk) 21:42, 10 October 2017 (UTC)

P.S. This refers to wikEdDiff.js, the main wikEd code is OK. —Tacsipacsi (talk) 21:45, 10 October 2017 (UTC)

Wow, this took care of about 2/3 of the remaining calls to these legacy variables. —TheDJ (talk • contribs) 12:54, 17 October 2017 (UTC)

Potential wikiEd issue in checking of links, and a suggestion

While checking log entries to see how many daily requests would be broken by fixing T41936: Limit on number of piped values in API should throw an error, I noticed a request that seems to be due to your editor. In particular, I see in wikEd.LinkInfoCall() that you're extracting links without batching them to the maximum number allowed for the titles parameter. You can check the maximum by making a call to action=paraminfo, or you would be reasonably safe in hard-coding it to 50 (500 for users with the 'apihighlimits' right, e.g. sysops).

I can reproduce the issue while logged out (in a private browsing window) by going to https://en.wikipedia.org/w/index.php?title=Paul_Warfield&action=edit and using the code at User:Cacycle/wikEd installation#Complete version to load wikiEd. Getting your bug report thing to work in that situation was something of a pain (it doesn't seem to like being used while logged out), but eventually I monkey-patched it well enough to produce output:

• Date: 2017-07-17 15:53:18 UTC
• wikEd version: 0.9.148 (March 20, 2017)
• Browser: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 (Linux x86_64)
• Skin: vector (detected: vector_new)
• MediaWiki: 1.30.0-wmf.7
• Gadgets:
• MediaWiki scripts: RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
• Scripts: User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
• URL: https://en.wikipedia.org/w/index.php?title=Paul_Warfield&action=edit
• User subpages: None, IP user
• User/skin.js: None, IP user
• User/common.js: None, IP user
• Error console: No error messages are produced. But if you open the one POST to api.php and look at the response, it includes a warning "Too many values supplied for parameter "titles". The limit is 50.". The request includes 114 titles.
• Problem description: See above
• Steps to reproduce: Just load the editor on the page. Note that bots and sysops have the 'apihighlimits' right, so you'll want to either use an unprivileged account or find a page with over 500 links.

Also, a suggestion: If you set the Api-user-agent HTTP header in your API requests to something appropriate, it will be easier for me to identify when an issue is due to wikiEd and you'll be able to use Special:ApiFeatureUsage to watch for issues yourself.

Thanks! Please ping User:Anomie if you need a reply from me, otherwise I'm not likely to see it. BJorsch (WMF) (talk) 16:03, 17 July 2017 (UTC)

Language Bug

Hello, I'm using wikEd with Chrome 49 in german Wikipedia and I'm getting english buttons "Preview" and "Changes" when this feature is activated. Also "wikEd help" link should go to the german help page.--Sinuhe20 (talk) 07:21, 19 July 2017 (UTC)

Stop adding  

Tracked in Phabricator
Task T183647

WikEd appears to add hard spaces from time to time such as [1]

Can we have it stop per [2]? Doc James (talk · contribs · email) 17:25, 23 July 2017 (UTC)

WikEd is not adding non-breaking spaces. They are already there, and wikEd just makes them 'visible' in the code by changing them to  . — JJMC89 (T·C) 18:22, 23 July 2017 (UTC)

I started a section at the help page with a convenient shortcut since this appears to be a common query elsewhere. Review WP:WIKEDNBSP. The rationale for why wikEd does this might reasonably be included there (I believe it's because we expect invisible characters always to be visible in some way). --Izno (talk) 14:53, 25 July 2017 (UTC)

User:Izno can we have wikEd convert "invisible non-breaking space" into normal spaces? WikEd can than fix some glitch that is occurring some place else. Doc James (talk · contribs · email) 16:43, 5 December 2017 (UTC)

@Doc James: I don't think the request is an unreasonable one either technically or socially, but that might look even more confusing to editors than nbsp's mushrooming. --Izno (talk) 16:48, 5 December 2017 (UTC)

Why do you think it would be confusing User talk:Izno? If people want to add real hard spaces than they will need to add them visibly. Doc James (talk · contribs · email) 17:27, 5 December 2017 (UTC)

@Doc James: Because they will see a space replaced with a space in the diff. I guarantee that will generate as many questions as nbsp does. --Izno (talk) 21:52, 5 December 2017 (UTC)

Better than the adding of all the _ _ though Doc James (talk · contribs · email) 21:55, 5 December 2017 (UTC)

I have filled out a phabricator ticket here.[3] To try to get this issue fixed. Doc James (talk · contribs · email) 01:51, 24 December 2017 (UTC)

Your request doesn't have consensus, and anyway isn't a part of MediaWiki but instead this script, so the request on Phabricator will likely close as invalid. --Izno (talk) 02:23, 24 December 2017 (UTC)

Please fix it. Some "dumb as posts" admins have already warned me, and removed comments, for editing other user talk page comments because the editor inserts the nbsp character anywhere it sees fit. It shows in diffs as a change by an editor that they didn't make and can't undo. The editor should not make any changes in a work where the edit is attributed to a user. It's a false attribution. Run a bot if the wiki needs changes, not a random fix by the editor. --DHeyward (talk) 08:31, 26 December 2017 (UTC)

It's irritating for authors when wikEd executes automatic changes (corrections) because most users of wikEd don't know that wikEd does this and thus don't expect this behaviour and are puzzeled about this changes, they didn't make. Furthermore they dont have any clue where these changes might come from or will expect an edit-conflict which of course can't be found in the history of the page, what also leaves them puzzeld.
DHeyward correctly mentioned the problem, that by this behaviour also signed contributions of other users (e. g. in talk pages and other pages requesting singning of contributions) are changed, what thwarts the idea of signig ones contributions. If this replacement function should be kept, it must be disabled for any edits in Talk namespaces and other namespaces requesting singning of contributions.
The automatic replacement also causes problems in the name-parameter of the Template:Coord (also in other langages like de:Vorlage:Coordinate), because the entity in the value of this paramter is passed by the URL to the GeoHack, as entity, and also appears als entity in the headline of the GeoHack. Thus a non-breaking space in the value of the parameter name of the Coordinate-Templates must not be changed into an entity  . If the general automatic replacement function should be kept, wikEd must learn to distinguish between the mentioned cases, and behave apropriate to the context (namespace and template-parameter). --X:: black ::X (talk) 12:15, 8 February 2018 (UTC), updated 12:23, 8 February 2018 (UTC)

I fully agree with other editors' concerns about this function. Please either 1) remove it entirely, or 2) make it optional via a user-side parameter, or 3) replace the found non-standard characters with regular blanks instead of NBSPs (whichever option is best from a technical POV). I greatly appreciate all the work you have done to provide a lot of useful functionality for editors, but this one is actually counterproductive. GermanJoe (talk) 09:38, 2 March 2018 (UTC)

According to the Phabricator ticket, it turns out Visual Editor was adding invisible   and wikEd was simply making them visible. — Dispenser 13:03, 2 March 2018 (UTC)

The WikEd feature still changes editor signatures (which is discouraged as cosmetic change of talkpage messages imo) and in article content derived from other sources (like old browsers or external editing software). Hopefully the VE flaw will be fixed, but that doesn't solve the underlying problem in this tool itself. GermanJoe (talk) 11:31, 11 March 2018 (UTC)

unable to select other languages for typing while using wiked

Hi, I am trying to use wiked in Tamil wikisource. First, when wikEd is enabled I am unable to choose other languages in input method. second the wikEd option is not enabled in header and footer section of wikisource. Thanks. Regards Balaji ^{(Let's talk)} 02:06, 15 August 2017 (UTC)

Hello

To install WikiEd on the Haitian Creole Wikipedia, do I just translate th variables and cut and paste to its own .js page? Barbara (WVS) ✐ ✉ 11:32, 26 August 2017 (UTC)

Barbara (WVS): please check User:Cacycle/wikEd_installation for details. You probably need the "complete version" on your your common.js page. Cacycle (talk) 20:45, 12 November 2017 (UTC)

Feature Suggestion - Remove Left-to-Right characters (and possibly other invisible characters)

I noticed that in some browsers there is a problem with pasting text from links - often the Left-to-right character is inserted as well. I don't know that this is particular to wikEd, but it would be nice if wikEd had a feature or button to make it easy to cleanup Left-to-right characters, and maybe other invisible characters, before posting. -Furicorn (talk) 20:31, 30 August 2017 (UTC)

Text zoom cycling

Im along time user of Wikipedia and WikEd but lately I've developed minor vision issues. I've figured out how to magnify the text of Wikipedia without magnifying images and basic layout elements (i.e. without using browser zoom), and I like it that way.

One feature that's right next to the "Text zoom cycling" button is labeled "Simple view: hide refs, templates, and table code" and whichever setting I choose for that sticks with me between edit sessions. But I seem to have to set the text zoom manually on every edit which requires a few clicks (either four or shift plus two). Also, at least in this session, zooming seems to have made it so my usual method of saving an edit (tab,tab,enter) doesn't work and I have to manually click the Save button. Is this intentional, and is there any other way I can make the magnification permanent? i.e. using CSS properties perhaps?

I'm glad to see WikEd is still being actively developed in order to keep up with changes in Wikipedia and to add new features. Thank you for your effort and time. —Soap— 16:38, 7 September 2017 (UTC)

Reply to self ... still interested, but while researching the next question I looked through the code and it seems that WikEd simply inherits its text size from the internal editor, which explains why the text is also not magnified when I turn off WikEd. —Soap— 23:00, 20 September 2017 (UTC)

Further reply ... this edit solved my problem for the mainspace and anything that uses the same CSS style (possibly nearly everything except other code pages). The coloring seems different somehow, but that's probably just an illusion caused by the text becoming less bold as it gets larger. —Soap— 23:11, 20 September 2017 (UTC)

Making the edit box bigger

I could have sworn there used to be a section in the Customization doc about increasing the height of the main box, but I can't find the right code anywhere. Does anyone know how to do it? Pariah24 (talk) 01:47, 15 September 2017 (UTC)

I guess I can just drag the box down every time; it would be nice to not have to do that though. Pariah24 (talk) 02:56, 15 September 2017 (UTC)

I may be able to help. In the JavaScript source code for WikEd there is a series of lines that says

// frame

'.wikEdFrameHtml': 'height: 100%; width: 100%; padding: 0; margin: 0; background: transparent; background-image: url({wikEdImage:resizeGrip}); background-attachment: fixed; background-position: right bottom; background-repeat: no-repeat; line-height: normal;',

'.wikEdFrameBodyPlain': 'height: auto; min-height: 100%; width: auto; background: transparent; margin: 0; padding: 0; padding-left: 0.25em; overflow: auto; font-family: monospace;',

'.wikEdFrameBodySyntax': 'height: auto; min-height: 100%; width: auto; background: transparent; margin: 0; padding: 0; padding-left: 0.25em; overflow: auto; font-family: monospace;',

'.wikEdFrameBodyNewbie': 'height: auto; min-height: 100%; width: auto; background: transparent; margin: 0; padding: 0; padding-left: 0.25em; overflow: auto; font-family: monospace;',

Have you tried changing the height: values in those lines? You probably would only need to change one, since it looks like WikEd has three modes, and I've only ever used the Syntax mode. I was able to resize the window in Chrome's toolbox by changing the height: value of .wikEdFrameBodySyntax to a random number. This might mean that making a similar change in your userspace would resize the textbox permanently. But whereas I solved a problem of my own by editing my CSS file, I think you would need to edit your custom.js file instead. —Soap— 23:19, 20 September 2017 (UTC)

You should be able to change CSS using CSS subpage (e.g. .wikEdFrame { height: 35em; }). If it doesn't work for first, try adding !important (i.e. .wikEdFrame { height: 35em !important; }). CodeEditor will complain about it, but it's OK. —Tacsipacsi (talk) 19:04, 21 September 2017 (UTC)

@Tacsipacsi: Are you saying to put it in common.css rather than common.js? Pariah24 (talk) 19:06, 22 September 2017 (UTC)

If you have pure CSS code, it should go to common.css. If you have styles in JavaScript for some reason, it should go to common.js. So the following is CSS:

.wikEdFrame {
	height: 35em;
}

while this is JS:

wikEd.config.frameCSS['.wikEdFrame'] = 'float: left; width: 100%; border: 0; height: 35em;';

(you have to add all the default styles in the latter form in order not to override them, it's automatically done when you use CSS). --Tacsipacsi (talk) 20:34, 22 September 2017 (UTC)

Incompatible script, gadget, or addon: Code Editor

Hi there, Cacycle! I love this editor of yours with the helpful syntax highlighting and improved changes comparison display. My only problem is that while I can use your editor on almost every wiki (including third-party wikis), for some reason I can't use it on Wikipedia itself (it is displaying a "Incompatible script, gadget, or addon: Code Editor - wikEd 0.9.149" error). I've enabled it in gadgets and I've also written down the complete code in my userpage. Help is greatly appreciated. Thanks! --Tenryuu (talk) 22:30, 19 September 2017 (UTC)

Hi Tenryuu. CodeMirror/Code Editor/Wikitext syntax highlighting cannot be used with wikEd. CodeMirror can be disabled in your beta preferences. — JJMC89 (T·C) 01:24, 20 September 2017 (UTC)

Hi JJMC89, thanks for the help. It is now working properly. --Tenryuu (talk) 02:13, 20 September 2017 (UTC)

Live Preview unable to render pipe tricks correctly

Hi, Cacycle! I have a minor visual problem I was hoping you could resolve. So when I try to do a pipe trick (e.g., [[Pipe (water)|]]) the live preview doesn't seem to render it properly (it'll come out as [[Pipe (water)|]]). Clicking the standard "Show Preview" button renders it properly as an internal link. Any fixes for this tiny problem? Thanks! --Tenryuu (talk) 22:28, 24 September 2017 (UTC)

It's not only about the pipe trick, but everything which is changed while saving, like template substitutions, signatures etc. It's because wikEd doesn't use the pst parameter, so

	// API request
	if ( (	wikEd.wikiGlobals.wgEnableAPI === true || wikEd.wikiGlobals.wgEnableAPI === 'true' ) && livePreview === true ) {
		var postFields = {
			'format': 'xml',
			'action': 'parse',
			'title': wikEd.pageName,
			'text': textValue
		};

should be changed to

	// API request
	if ( (	wikEd.wikiGlobals.wgEnableAPI === true || wikEd.wikiGlobals.wgEnableAPI === 'true' ) && livePreview === true ) {
		var postFields = {
			'format': 'xml',
			'action': 'parse',
			'pst': '1',
			'title': wikEd.pageName,
			'text': textValue
		};

(maybe it could use mw.Api for easier response processing and maintenance). --Tacsipacsi (talk) 12:38, 25 September 2017 (UTC)

Sorry for the late response Tacsipacsi and thanks for letting me know about this. Would I have to go into my common.js to add that line? --Tenryuu (talk) 20:29, 2 October 2017 (UTC)

No, it should be changed in the main script (i.e. User:Cacycle/wikEd.js)—I hope Cacycle knows this… (Although I recommend you to blank your common.js and load the script as a gadget as described in User:Cacycle/wikEd installation#Gadget, just to make it clear that you don’t have to maintain anything.) --Tacsipacsi (talk) 18:49, 3 October 2017 (UTC)

@Tacsipacsi: simple enough change.. I just did it. since Cacycle seems to be away a lot lately. —TheDJ (talk • contribs) 20:19, 3 October 2017 (UTC)

@TheDJ: Thanks! --Tacsipacsi (talk) 21:48, 3 October 2017 (UTC)

Please add this photo on instructions on how to enable this gadget

It is not clear how to enable this gadget.

It is frustrating that this page is locked down and cannot be edited by other users. 11:15, 2 October 2017 (UTC) — Preceding unsigned comment added by Moscowamerican (talk • contribs)

Protected edit request on 2 October 2017

Please add this screenshot to the page:

File:WikEd logo displayed on top of the pages next to the log out link.png

It is currently not clear in the instructions how to enable this gadget. Moscowamerican (talk) 11:16, 2 October 2017 (UTC)

@Moscowamerican: please be more specific. Where exactly is it going? Is a caption, or further text required alongside? And please resolve the copyright tag on the image otherwise it may get deleted. — Martin (MSGJ · talk) 12:08, 2 October 2017 (UTC)

This is why most pages are not protected by administrators, it hampers editing with unnecessary bureaucracy.

I added it to the help page here: User:Cacycle/wikEd_help#Enabling_WikEd, a similar section could be created to this protected page. Use your imagination :)

Also, if I wouldn't have come back to wikipedia, the image would have been deleted by a bot, even though it is clearly a free image of wikipedia. No one bothers to take less than a second to fix this?

Admins often seem so paralyzed, really doing nothing but keeping the status quo. Moscowamerican (talk) 04:34, 3 October 2017 (UTC)

Moscowamerican: Point 2 from Wikipedia:Edit requests says "Any edit request must be accompanied by a detailed and specific description of what changes need to be made. Clearly indicate which sections or phrases should be replaced, and what they should be replaced with." If you had made your request specific, it would probably have been done on 2 October. — Martin (MSGJ · talk) 12:25, 5 October 2017 (UTC)

Protected edit request on 2 October 2017

This page is locked for the following reason:

<!-- This page is protected from editing because of the security-sensitive code. -->

I suggest:

1. putting the security-sensitive code in a subpage,
2. protecting the subpage,

1. nesting the subpage in this page, or creating a link to the security-sensitive code subpage,

....so that normal non-administrators like me, who have over a decade of mediawiki and wikipedia experience, but happen not to be administrators, can edit this page.

In addition, if a link was created to the security-sensitive code if would make the main page easier to read.

Thank you for your consideration. Moscowamerican (talk) 11:22, 2 October 2017 (UTC)

That should work. Cacycle: are you okay with that? — Martin (MSGJ · talk) 12:08, 2 October 2017 (UTC)

Moscowamerican, MSGJ: I protected this page because of the embedded wikEd installation code. Somebody changing that code could potentially cause harm. Moving that code to a subpage and unprotecting the main page would not help at all - anybody could then replace the templates with plain text code. Cacycle (talk) 14:27, 2 October 2017 (UTC)

Excuse my ignorance, but what sort of harm could be caused by malicious editing? E.g. could it allow someone to install something different on your computer? — Martin (MSGJ · talk) 18:56, 2 October 2017 (UTC)

People can follow incorrect instructions and accidentally install malware. It's not that common, and likely this page is watched by enough people that it wouldn't last more than a few hours... Usually we don't bother with things like this, but wikEd is rather widely used, also outside of English Wikipedia, and as a greasemonkey script. —TheDJ (talk • contribs) 20:22, 3 October 2017 (UTC)

I had a look around Category:Wikipedia tools and couldn't see any other examples where the installation instructions were protected. That probably indicates that the risk is not high. I think we could consider lowering protection to semi perhaps? — Martin (MSGJ · talk) 10:49, 5 October 2017 (UTC)

I've lowered to semi protection. If that is deemed insufficient, then a compromise may be extended confirmed, but there are no other tools that protect pages like this, so I'm not convinced it is needed. — Martin (MSGJ · talk) 07:13, 6 October 2017 (UTC)

User:Cacycle is your page, so the community has little say it what would make the page better in the long run.

Do this extensions ever move by the owner to public space? Moscowamerican (talk) 04:28, 3 October 2017 (UTC)

CharInsert doesn't work with wikEd

CharInsert (mw:Extension:CharInsert) doesn't work with wikEd: if one clicks on a character in MediaWiki:Edittools (on a wiki where it's visible, unlike enwiki), nothing happens. As it's an extension, this gadget should be fixed to work with CharInsert, not vice versa. --Tacsipacsi (talk) 19:10, 11 October 2017 (UTC)

Tacsipacsi: It works fine for me. On my private wiki I had to update the gadget Edittools to the latest version (≥ May 27, 2016) for mw:MediaWiki:Edittools to work at all (unrelated to wikEd). Hope that helped... Cacycle (talk) 23:28, 11 November 2017 (UTC)

I don't know where and how this gadget works, but, as I said, the problem is with the CharInsert extension. Not a gadget, but a real extension developed by WMF employees, hosted on Git. (See link above.) So I won't update anything as I have no right to do that. (P.S. I forgot to mention a wiki where the bug does occur: e.g. huwiki.) --Tacsipacsi (talk) 12:29, 12 November 2017 (UTC)

As far as I know, this (and many similar problems) would also be solved by making WikEd compatible with jQuery.textSelection. Helder 11:24, 19 November 2017 (UTC)

WikEd blocks the keyboard shortcuts on Google Chrome and Chromium

WikEd blocks the keyboard shortcuts on Google Chrome. Is there a work around?

question also found here:

[4] (until archived)

I created a video - https://www.youtube.com/edit?video_id=11LoI-eSI1Y&video_referrer=watch

The shortcuts work on Firefox, but not on Google Chrome. Imaginelenin (talk) 19:47, 23 December 2017 (UTC)

I've verified that the same thing happens in Chromium. The Transhumanist 07:30, 29 December 2017 (UTC)

Using WikEd colors

Do you know how to use WikEd colors within Syntax highlighting?

Doc James (talk · contribs · email) 01:50, 24 December 2017 (UTC)

Unicode fixing bug

WikEd has a very nice tool for fixing Unicode characters, but there is a bug that make it practically unusable. All occurences of the sequence of characters "uad" as in "squad" is replaced to &shy; (soft hyphen) and then words like "squad" become "sq&shy;".--Luizdl ^Talk 16:14, 7 January 2018 (UTC)

suggestion

I love WikiEd and use it every day. And when I do, other editors come on by and reformat the references. The funny thing is that each of the articles I edit with WikiEd gets formatted from the WikiEd reference formatting inconsistently to a variety of other preferred formats by other editors. I stopped caring a while ago but what a waste of time. What actually means that sometimes editors come on by to format refs one way and another follows and re-formats the refs another. I personally believe it to be a waste of time to make such tidy formatting changes, but hey! It's WP and anyone can edit the encyclopedia any way they would like. I guess in my perfect version of WikiEd, editors could sail on by and select a citation style they prefer. So if there was a change that could be made it would be to give referencing options for other editors so they could be able to reformat all the references in an article into their preferred formats. Best Regards, Barbara (WVS) ✐  ✉ 14:44, 14 January 2018 (UTC)

Here is the perfect example of what I am talking about. Barbara (WVS) ✐  ✉ 15:23, 18 January 2018 (UTC)

Fullscreen mode - interference from left Wikipedia column

Using wikEd 0.9.155 (November 5, 2017) on Chrome browser: From my sandbox, when I go to fullscreen mode, the left Wikipedia column text (the column that's common to all en.wikipedia.org articles) interferes with the view of wikEd toolbar and editing window.

(I took a screenshot of the same problem when doing this bug report in full screen, but I cannot yet figure out how to insert the image - sorry.) -- Bwefler (talk) 04:16, 22 January 2018 (UTC)

Here is a screenshot of the bug report with the interference. -- Bwefler (talk) 04:53, 22 January 2018 (UTC)

Operating system: Windows 10 (version 1709, OS build 16299.192) (Hope the wikEd build is the most recent—just selected it from Gadgets and started using it yesterday.)-- Bwefler (talk) 17:12, 22 January 2018 (UTC)

Getting WikEd to work on Wikia domains?

Hi guys, I'm trying to get the WikEd extension to appear on Wikia sites, but I'm not sure if it's skin specific. I've tried disabling syntax colours and other editing stuff but nothing worked. Help is greatly appreciated! --Tenryuu (talk) 02:54, 19 March 2018 (UTC)

Macros

Can WikEd perform macros? There are some functions that I'd like to perform with one button click. --Tenryuu (talk) 00:43, 29 March 2018 (UTC)

Is wikEd_current_version Required for Site-Wide Installation on Common.js?

Wanting to get auto-updates. https://en.wikipedia.org/wiki/User:Cacycle/wikEd_installation#Site-wide_installation

thx --Johnywhy (talk) 03:09, 13 April 2018 (UTC)