Jump to content

User talk:Cacycle/wikEd

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< User talk:Cacycle

This is an old revision of this page, as edited by 2401:4900:33ac:9ab3:1:0:bbac:6075 (talk) at 16:07, 10 June 2020 (→‎capitalising first word on template Citar enciclopédia: add RegExTypoFix feature request). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Shortcut

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.
wikEd
WikEd logo
Installation
wikEd diff
Program code
Project
Gadgets
Translations
WikiProject iconUserboxes
WikiProject iconUser:Cacycle/wikEd is part of WikiProject Userboxes. This means that the WikiProject has identified it as part of the userboxes system. WikiProject Userboxes itself is an attempt to improve, grow, and standardize Wikipedia's articles and templates related to the userbox system, used on many users' pages. We need all your help, so join in today!UserboxesWikipedia:WikiProject UserboxesTemplate:WikiProject UserboxesUserboxes articles

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:

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]
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)[reply]
P.S. This refers to wikEdDiff.js, the main wikEd code is OK. —Tacsipacsi (talk) 21:45, 10 October 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Stop adding &nbsp;

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)[reply]

WikEd is not adding non-breaking spaces. They are already there, and wikEd just makes them 'visible' in the code by changing them to &nbsp;. — JJMC89 (T·C) 18:22, 23 July 2017 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
Better than the adding of all the _&nbsp;_ though Doc James (talk · contribs · email) 21:55, 5 December 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 and pages that request the singning of contributions.
The automatic replacement also causes problems in the name-parameter of the Template:Coord (also in eqivalent templates in other languages wikipedias like de:Vorlage:Coordinate), because any entity placed in the value of this parameter, is put into the URL which is created by the template, in a way, that it is passed to the GeoHack as entity, and also appears als entity (e. g. ″&nbsp;″) 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 &nbsp;. 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) and 12:31, 4 May 2018 (UTC)[reply]
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)[reply]
According to the Phabricator ticket, it turns out Visual Editor was adding invisible &nbsp; and wikEd was simply making them visible. — Dispenser 13:03, 2 March 2018 (UTC)[reply]

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)[reply]

As long as wikEd isn't able to use this nbsp-replacement feature only in those contexts where it is useful, or this nbsp-replacement feature isn't removed entirely, it should be made optional (e. g. by customization of wikEd). User:Cacycle/wikEd customization#Customization describes the options to customize wikEd. Among the user configurable variables in User:Cacycle/wikEd.js is already:
// convert all &nbsp; character entities to actual characters for textarea editing and saving (not recommended)
if (wikEd.config.nbspToChar === undefined) { wikEd.config.nbspToChar = false; } .
This one will perhaps not solve this problem, but if it's possible to have replacements the one and the other way round, it should also be possible to just leave both, the character and the nbsp-entity, as they are. The above mentioned template-case shows, that in some cases it's necessary to have both within one page. --X black X (talk) 12:31, 4 May 2018 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
@Tacsipacsi: Are you saying to put it in common.css rather than common.js? Pariah24 (talk) 19:06, 22 September 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
Hi JJMC89, thanks for the help. It is now working properly. --Tenryuu (talk) 02:13, 20 September 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
@TheDJ: Thanks! --Tacsipacsi (talk) 21:48, 3 October 2017 (UTC)[reply]

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)[reply]

@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)[reply]
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)[reply]
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)[reply]

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)[reply]

That should work. Cacycle: are you okay with that? — Martin (MSGJ · talk) 12:08, 2 October 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

Here is a screenshot of the bug report with the interference. -- Bwefler (talk) 04:53, 22 January 2018 (UTC)[reply]
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)[reply]
This also happens for me. I'm on Windows 10 64-bit using Firefox 68.2.0esr (32-bit). FWIW, I've noticed this problem for several years. —danhash (talk) 16:26, 6 December 2019 (UTC)[reply]

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)[reply]

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)[reply]

Tenryuu, it is possible to create custom buttons, see User:Cacycle/wikEd_customization#Custom_buttons. This requires some JavaScript savvy, though. GregorB (talk) 12:52, 18 June 2018 (UTC)[reply]

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)[reply]

It is needed for offline version only. If you have a stable internet connection (as is the case almost always), you don’t need it. You will always load the latest version. —Tacsipacsi (talk) 11:21, 21 April 2018 (UTC)[reply]

Full codebase vs install-script in Common.js for Sitewide Install?

I found the instructions a bit confusing re sitewide install-- seemed in one place i only needed your install script, but elsewhere it seemed that i was required to place the entire codebase into common.js.

Both worked. — Preceding unsigned comment added by Johnywhy (talk • contribs) 06:06, 13 April 2018 (UTC)[reply]

Copying the entire codebase is only required if you don’t have a stable internet connection (and the wiki is not accessed through the internet, e.g. runs on the local machine or somewhere on the local network). —Tacsipacsi (talk) 11:26, 21 April 2018 (UTC)[reply]

Indonesian Translation

@Cacycle: I've translate it to Indonesian language, you can find the translation here. -- Bagas Chrisara (talk) 11:34, 18 April 2018 (UTC)[reply]

Unmatched params are undefined, not empty string

'xyz'.replace(/x(y|(no match))(z)/g, function(p, p1, p2, p3) { alert(p2==undefined); }); yields p2 as undefined on Pale Moon, Firefox, and Chrome.

It looks like wikEd.FixRedirectReplace is a victim if (linkText !== '') { (linkText is looks to be undefined. — Dispenser 21:45, 12 May 2018 (UTC)[reply]

Here what needs to be added:
// Add fallbacks in wikEd.FixRedirectReplace()
			var fragmentId = p5 || p14 || "";
			var linkText = p7 || p16 || "";
Which fixed it Dabfix. — Dispenser 23:44, 12 May 2018 (UTC)[reply]

Update redirect checking logic

wikEd.LinkInfoCall does not batch the titles it passes to the API. This results in it only checking the first 50 (500 for admins) links/images/templates/etc on the page, and triggering the "too-many-titles-for-query" warning from the API if it's attempting to check more.

To avoid this, you'll need to split the titles into batches and make an API query for each batch. You could do batches of 50 always, or you could increase the batch size to 500 if the user has the apihighlimits right.

FYI I'm planning on turning that warning into an error soon, at which point wikEd's redirect checking will break entirely on pages with too many links/images/templates/etc until this issue is fixed.

Thanks! BJorsch (WMF) (talk) 20:56, 18 May 2018 (UTC)[reply]

FYI, the changing of the warning into an error is now scheduled for 1.32.0-wmf.6, which should be deployed here on May 31. Anomie⚔ 12:52, 23 May 2018 (UTC)[reply]

Enhancement: WikEd-diff-Talk: template for proposed edit to existing article section. Enhancement: generate link to diff or wikitext from Online wikEd-diff-tool

I found Online wikEd-diff-tool and it is great!

It would be superb if made into a Talk page template that might be dropped into a contentious section, enabling pacification of edit warriors. Keeping Talk page section size (with margins and chrome) and screen size in mind, default would be one article section of existing article or x# of words max.

Alternatively, perhaps simpler, would it be possible to extend existing Online wikEd-diff-tool functionality by either::

  1. generating a URL link to a particular diff (preferred), or
  2. exporting to clipboard &/or text file of color-coded diff wikitext, for paste back onto Talk page to show effect of proposed additions, deletions, and block moves. Footer bar for color-coded legend.

(If 1, additional note on restful URL, following toolname base URL: PAGENAME#SECTION-DATETIME perhaps ideal, if navigation to &/or paste of article section name allowed; otherwise just DATETIME, if unidentified text copy pasted)

As is, it requires each interested editor to: perform two copy and pastes, switching back and forth between Talk page proposed text, online tool, article text, back to tool, and then back to Talk page to maybe say what they saw, what they liked and why, and what they didn't like and why -- each and every time they want to compare two versions. That ain't happening on the flaming pages I've visited over the years: not known (why a Talk page template would increase use and visibility far more than alternatives 1 & 2), too laborious, and not verifiable without repeating each step.

Even if it did happen, seeing is believing. This enhancement proposal, like your diff tool when used, has the potential to quench a lot of fires. Thanks for your hard work! -- Paulscrawl (talk) 16:06, 19 May 2018 (UTC)[reply]

wikiEd running paragraphs together and inserting extraneous newlines

Been having a problem over the last two weeks with wikiEd running paragraphs together and inserting extraneous newlines. Running with Vector in Firefox on Windows and MacOS Hawkeye7 (discuss) 05:16, 30 May 2018 (UTC)[reply]

I get the same with Firefox, Monobook, Windows 10. The item in the next section below is the same. Chiswick Chap (talk) 12:05, 30 May 2018 (UTC)[reply]
Same here. The annoying part is that these newlines are initially not visible, at least not until one clicks on "Preview". When copy-pasting, one is therefore forced to preview the changes first and delete the superfluous newlines before saving. No such behavior with Chrome 67.0.3396.79. GregorB (talk) 08:49, 12 June 2018 (UTC)[reply]

Hawkeye7, Chiswick Chap - things did not get better I presume? For me, it's as if it has gotten worse: paragraphs stick together and there is no way to separate them other than turning wikEd off. GregorB (talk) 09:55, 7 July 2018 (UTC)[reply]

You can use the preview function to look at them, then go back in and insert additional newlines so it looks right. There are two related problems: it also inserts newlines when you don't want them; and the cursor insertion point is frequently wrong. In the Mac I've switched to Safari, which doesn't have the problem. I hoped that Firefox 61 would fix the problem., but it doesn't. Hawkeye7 (discuss) 11:04, 7 July 2018 (UTC)[reply]
Preview doesn't work for me anymore - newlines inserted in preview now disappear when the page is saved. GregorB (talk) 11:51, 7 July 2018 (UTC)[reply]
I noticed things changing but getting more confused rather than actually better - I had the impression that several fixes had been attempted, none of which got to the root of the problem; and like other editors, I have found it a continuing source of difficulty. Chiswick Chap (talk) 08:15, 10 July 2018 (UTC)[reply]
@Chiswick Chap: FYI, no significant changes have been made to wikEd since November 2017. The primary maintainer of the code has not really been active since then. —TheDJ (talk • contribs) 07:26, 11 July 2018 (UTC)[reply]
Well, as a user all I can say is that over the past ten years, it's worked really well, and in the past few months, something really odd has happened with it. Perhaps the issue is not with wikEd but with something that it interfaces with (maybe some interfaces have been helpfully updated, and the lack of wikEd maintenance has meant it hasn't kept up), I have no way of knowing, but wikEd no longer behaves as it did, as I and others have truthfully reported. Chiswick Chap (talk) 07:34, 11 July 2018 (UTC)[reply]
I'm not disputing your claim, other than the "I had the impression that several fixes had been attempted"-part. —TheDJ (talk • contribs) 08:06, 11 July 2018 (UTC)[reply]
This is all caused by Firefox updates. IIRC, new releases of Firefox broke the c/p and newline behavior at least 3 or 4 times. I imagine this is not easy to fix at all, particularly while maintaining compatibility with Chrome. Unfortunately wikEd is borderline usable for me at the moment, I have to keep it switched off half the time. GregorB (talk) 08:22, 11 July 2018 (UTC)[reply]

I'm experiencing these issues, too, using Win10 and Firefox 61 (64-bit). The random, (but frequent) insertion of extraneous newlines is "relatively new" (I think – I've been inactive, so it could be years old), as is the (rare) "sticking together" of 'graphs (workaround seems to be to insert an HTML comment on it's own line in between the 'graphs). The insertion of a newline in front of pasted text and inconsistent failure of BS and DEL to delete it (i.e. re-join the lines), is pretty old. I really like WikEd, and don't want to have to switch to something else. Are there any plans to work on it? —[AlanM1(talk)]— 08:02, 15 August 2018 (UTC)[reply]

I'm bumping this topic - unfortunately there seems to be no progress, and it's been months now since I've disabled wikEd due to this issue (i.e. messing up newlines while doing most non-trivial edits). I really hope it gets fixed some day - no wikEd for me in the meantime, regrettably (I do turn it on temporarily, for certain edits, but that's all). GregorB (talk) 12:18, 28 November 2018 (UTC)[reply]
Is it possible that this issue relates to the Firefox config editor.use_div_for_default_newlines which defaults to true? Changing it to false as Firefox offshoots like Waterfox & Pale Moon have as the default value seems to take the problem away for me. Nthep (talk) 15:35, 24 May 2019 (UTC)[reply]
I've tried it and it seems to work for me! Thanks! GregorB (talk) 16:40, 24 May 2019 (UTC)[reply]
This issue has been reported several times; see #paragraph erros and #wikEd bug report: blank lines deleted. editor.use_div_for_default_newlines is indeed the solution. Pol098 (talk) 18:24, 24 May 2019 (UTC)[reply]

Issue with editing - End of paragraph and "return"

Please see this discussion Wikipedia:Village pump (technical)#Issue with editing - End of paragraph and "return". Please ping or respond there. Regards, Cinderella157 (talk) 06:05, 30 May 2018 (UTC)[reply]

For what is worth, the linked section was archived as Archive 165. -- Rafaelff (talk) 13:11, 23 June 2019 (UTC)[reply]

Toggling off automatic conversion of HTML entities

Hi! Is there a way to stop wikEd from doing this: [5]. Upon editing the section, wikEd transforms the (what I assume is one of the Unicode white-) space character into the &nbsp ; entity. I tried disabling wikEd and I couldn't reproduce, so I assume it is part of wikEd logic. —  HELLKNOWZ   ▎TALK 10:30, 10 June 2018 (UTC)[reply]

@Hellknowz: this issue has been discussed above (see the section "Stop adding ..."), but with no solution on wikEd's side so far. Can't really help with the issue itself (I am only another user of this great tool) - just adding this note here for your information in the meantime. GermanJoe (talk) 09:34, 7 July 2018 (UTC)[reply]
Oh, whoops, I didn't see that. I quickly scanned the previous sections but must have missed it. Thanks for the pointer. —  HELLKNOWZ   ▎TALK 10:39, 7 July 2018 (UTC)[reply]

wikEd makes Special:EditWatchlist/raw unusable

Observed in Chrome 67. Best --FriedhelmW (talk) 10:16, 12 June 2018 (UTC)[reply]

Left hand column with menu (Main page, contents, languages etc) showing while in edit field stopping me from saving

This is caused by wikEd, see Wikipedia:Village pump (technical)#Left hand column with menu (Main page, contents, languages etc) showing while in edit field stopping me from saving. Doug Weller talk 14:40, 18 June 2018 (UTC)[reply]

@Doug Weller: did you accidently turn on wikEd's Fullscreen mode ? it's known to be broken. —TheDJ (talk • contribs) 10:30, 23 June 2018 (UTC)[reply]
@TheDJ: I clicked on a box that says "use wikEd instead of classical text area. That's from an edit screen that has a top menu starting with B I and ending with cite, a dropdown template box, Named references and Error check under that, and at the right and lower down a small grey box with 2 rows, the first row starting with a click box to turn on simple view. I find this setup very useful, but I miss the search and replace I used to be able to get. Thanks. Doug Weller talk 10:45, 23 June 2018 (UTC)[reply]

correction

I recently changed my username. Please change User:Aftabuzzaman/ to User:আফতাবুজ্জামান/ in the code. Thanks. --আফতাব (talk) 16:25, 25 June 2018 (UTC)[reply]

 Done — Martin (MSGJ · talk) 07:17, 26 June 2018 (UTC)[reply]

CodeMirror

WikEd interferes with the syntax highlighting provided by mw:Extension:CodeMirror. Whenever both the gadget and the extension are enabled, users write in the wrong text box without any clue of what is happening and why they're not saving anything. Could someone please prevent that by updating the script to check whether the wikitext editor contains a div with class "CodeMirror"? A solution could be like a popup explaining that CodeMirror must be disabled to make WikEd work.--Sakretsu (talk) 23:06, 13 September 2018 (UTC)[reply]

Improvement

Moving problem issue

The little pencil on a piece of paper in the right upper hand corner loads slower than the rest of the page. When it loads it shifts everything over resulting in misclicks. Wondering if you can hold a space for the icon so that shifting does not occur? Discussion was here for a similar issue that occured with another button. Fix was by User:MusikAnimal Doc James (talk · contribs · email) 01:15, 27 September 2018 (UTC)[reply]

Wondering if anyone has had a chance to look at this? User:ערן or User:Ladsgroup? Doc James (talk · contribs · email) 16:46, 21 October 2018 (UTC)[reply]
User:ערן, User:Ladsgroup, User:MusikAnimal another year and a bit has passed. I am happy to ask User:Fz-29 to take a look at seeing if he can fix this but I think MusikAnimal fixed the last ones.
Either hold a space for the wikEd icon or move it to the left of the user name. Doc James (talk · contribs · email) 14:17, 27 February 2019 (UTC)[reply]
Okay have asked User:Fz-29 if he can figure out how to fix this. Doc James (talk · contribs · email) 10:41, 2 March 2019 (UTC)[reply]

Skin text blending with WikEd

On some wikis that use darker skins (and contrasting bright text), the editor appears to use its own skin and causes the text to become near unreadable such as here (The Cancel text, "This is a minor change", and "Watch this page" are legible only when highlighted). Is there a solution to this? — Preceding unsigned comment added by Tenryuu (talk • contribs) 16:09, 5 October 2018 (UTC)[reply]

Inescapable full-screen mode

I've tried to follow instructions reporting this. I do the control-click and I get a message box with useful information. I cannot figure out how copy the contents of this box to paste here. I am using Chrome on Windows 10. Let me know what I can try here to get this information to you.

I have accidentally activated full screen mode. As reported above this creates a messy situation and so obviously you don't want to use this feature. The problem is I am unable to get out of full screen mode. I can disable WikEd using the button I control-clicked on above. When I re enable, it is not in full screen mode but the full screen mode button is pressed and I can't unpress it. WikiEd is now coming up in this unusable full screen mode by default.

The documentation says there is a cookie associated with this mode and I have searched my cookies but there are a lot of cookies on my computer and I can't find what I'm looking for. ~Kvng (talk) 16:32, 10 November 2018 (UTC)[reply]

Clearing my browser cookies has resolved this. Full screen mode is to be avoided. ~Kvng (talk) 16:31, 29 December 2018 (UTC)[reply]

paragraph errors

It seems the last version is not working correct any more!
When i enter empty lines to get an paragraph, they are disappearing when saving.
This is happening random in different lines.
For me this Editor is not usable any more. — Preceding unsigned comment added by 89.0.185.231 (talk) 09:29, 28 November 2018 (UTC)[reply]

See #wikiEd running paragraphs together and inserting extraneous newlines above. GregorB (talk) 12:19, 28 November 2018 (UTC)[reply]
O.K. Where can i find the last version before that was working without this problem?
Then i would try to make an local installation of wikEd of this version.
My guess is that the problem was actually caused by a new version of Firefox (I'm assuming here you use Firefox). If that is true, the solution is rather to:
  1. Use Chrome (no problems in Chrome, as far as I can tell), or
  2. Downgrade Firefox to a sufficiently old version (I'm guessing 59) that does not cause this behavior.
Unfortunately, none of the above is really an option for me. GregorB (talk) 20:09, 17 December 2018 (UTC)[reply]
Thank you for your answer and your work at wikEd!
Indeed i am using Firefox under Debian 8 and it has get an security update to Firefox 60.4.0.esr.
There are additional other problems with Firefox, like etherpad is not working any more.
It seems really that Firefox is not usable any more :-(
But Chrome Spyware can't be really the alternative.

This has been reported in other sections; the solution has just been posted in a previous section:

This issue relates to the Firefox config editor.use_div_for_default_newlines which defaults to true. Changing it to false ... takes the problem away for me. Nthep (talk) 15:35, 24 May 2019 (UTC)

Pol098 (talk) 18:24, 24 May 2019 (UTC)[reply]

wikEd bug report: blank lines deleted

[Added April 2019: this seems to be the same issue as reported in the previous section, "paragraph errors"]

Issue which may be due to WikEd: with 32-bit Firefox (FF) under Windows10/64 (both up-to-date as of 23Ja19), since a few months ago (with several updates to FF and Windows), blank lines are squeezed out when saving edited Wikipedia pages. This was reported by another user on 23 Jan 19. In my experience the problem manifests under FF but not Google Chrome (I haven't tested other browsers, but expect they're OK) if WikEd is enabled, but not if WikEd is turned off. Syntax highlighting is enabled.

Issue: when editing a Wikipedia page, if carriage return is pressed twice at the end of a paragraph and more text typed, it should appear below with one intervening blank line. What actually happens is that the edited text appears in the editor as normal, but on saving (or previewing) the new text follows immediately after the existing text, with no blank line. This happens when entering new text or editing existing text. If I paste text with line breaks from a text editor, it seems to be OK. Existing text which I haven't edited does not have this problem.

With FF32, Win10/64, WikEd enabled, edit section Halogen lamp#Phase-out. Position the cursor at the end of text. Press CR twice, and type a line of text. Press CR twice and type another line. Press CR 3 times (2 blank lines), and enter a last line. Click preview. What shows on the screen, correctly, before the preview:
vvvvvvvvvv
[blah blah] August 2018}}</ref>

This is the first test line, preceded and followed by 2 CRs

This is another line, followed by 3 CRs (2 blank lines)


This is the last line.
^^^^^^^^^^

After the preview, in edit mode (I've typed in breaks to show the editor page):
vvvvvvvvvv
[blah blah] August 2018}}</ref>
This is the first test line, preceded and followed by 2 CRs
This is a another line, followed by 3 CRs (2 blank lines)

This is the last line.
^^^^^^^^^^

The saved/previewed text runs on without paragraph breaks, of course.

Phase-out (this is the short section I use as a reproducible example)

In 2009, the EU began its phase-out of inefficient bulbs. The production and importation of directional mains-voltage halogen bulbs was banned on 1 September 2016 and non-directional halogen bulbs followed on 1 September 2018.[1] Australia will ban halogen light bulbs from September 2020.[2]

  1. ^ "The light bulb phase out schedule / Lighting Advice - Lyco". www.lyco.co.uk. Archived from the original on 27 October 2017. Retrieved 30 April 2018. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)
  2. ^ "Halogen Bulbs to be Banned in the EU Market from September - LEDinside". www.ledinside.com. Retrieved 26 August 2018.

Pol098 (talk) 16:22, 26 January 2019 (UTC)[reply]

===(New comment on bug)===
I was just going through the preliminaries to reporting this myself, and am glad to see that Pol098 has already done so - but thought that I may as well add the only differences in my environment compared to theirs (that I know of) - else all the same:
I must also add the link to my BugZilla report, which I made before before the suggestion from Pol098 that it was related to WikEd. They're asking for further info there now but I might just point them at this entry. Laterthanyouthink (talk) 06:02, 28 January 2019 (UTC)[reply]
Additional issue: sometimes an unwanted blank line is inserted. In particular, when adding text with several points preceded by "*" there should be no blank lines between the items. I was careful not to type in unnecessary CRs (and the edit page did not show any before saving), but found that blank lines had been inserted between several (but not all!) pairs of items. Pol098 (talk) 20:26, 29 January 2019 (UTC)[reply]
I suggested a few workarounds on the WP:Help page cited; here they are:
1: after a paragraph I press Enter twice or more, then <br>, then Enter once or twice more, followed by more text. I preview the result, and find that most line breaks have been removed, but typically there is <br> on a line by itself, followed by one or more blank lines (sometimes there is a blank line before the <br>). I put the cursor on the last blank line, and backspace to delete all except the first blank line. When I save that it is usually OK.
2: I open the page in Google Chrome, which does not have this problem, if necessary copying the page in edit mode with my edits from Firefox.
3: I think that copying the edit page into a text editor (Notepad++), getting the blank lines right, and copying back, works. I don't remember as I rarely do this.
Note: the obvious trick of adding a line containing one space—CR, space, CR, instead of CR, CR— adds two blank lines instead of one, though one can then be deleted. Pol098 (talk) 16:04, 3 April 2019 (UTC)[reply]
10 May 19 update: I have the impression that the problem has got slightly worse with the release of Firefox 66.0.5 (32-bit in my case). Inserting blank lines and <br>s, previewing, and deleting redundant blanks and breaks sometimes doesn't work unless more blank lines than previously needed are added. Whether this whole issue is due purely to FF, or WikEd has a part, I can't say. Pol098 (talk) 14:53, 10 May 2019 (UTC)[reply]

SOLVED I hadn't spotted it, but this is the same issue already reported. The solution has just been posted in that section:

This issue relates to the Firefox config editor.use_div_for_default_newlines which defaults to true. Changing it to false [in about:config]... takes the problem away for me. Nthep (talk) 15:35, 24 May 2019 (UTC)

This has worked for me too (on a quick test, but no reason to doubt it). Pol098 (talk) 18:13, 24 May 2019 (UTC)[reply]

@Randykitty:, this will interest you, i think. Headbomb {t · c · p · b} 19:42, 24 May 2019 (UTC)[reply]
Thanks, trying this out now! --Randykitty (talk) 18:11, 26 May 2019 (UTC)[reply]
Changing editor.use_div_for_default_newlines from true to false in Firefox is the fix, but if anyone wants to know the detail: this is entirely down to Firefox, nothing at all to do with WikEd. A few revisions ago Firefox decided to change the default way its rich text editor rendered a paragraph break. The change is described here. 'If you type “Firefox” and hit Enter between “Fire” and “fox”, the result HTML would be <div>Fire</div><div>fox</div> instead of Fire<br>fox.'

I suppose wikEd could be tweaked to handle this, which would help people who haven't seen this page. From here: 'Pages or embedders that want to keep the old behavior can run the following command: document.execCommand("defaultParagraphSeparator", false, "br")'
Pol098 (talk) 21:33, 24 May 2019 (UTC)[reply]
@DannyS712: this might be something for the Script++ newsletter / Signpost tech news. Headbomb {t · c · p · b} 23:13, 24 May 2019 (UTC)[reply]

Enabling wikEd breaks Wikipedia:Citation expander

If I have both wikEd and Wikipedia:Citation expander enabled, the Citation expander gadget doesn't work. Disabling wikEd solves this, but then I lose wikEd. Headbomb {t · c · p · b} 05:34, 28 February 2019 (UTC)[reply]

Headbomb, citation expand doesn't support jQuery.textSelection (the abstraction layer which allows multiple tools to edit wikitext content at the same time). wikEd only supports it partly. Citation expander also doesn't work with WE2017 for this reason. —TheDJ (talk • contribs) 08:12, 4 April 2019 (UTC)[reply]

Extension of WikEd to 2017 wikitext editor

Love this tool! Any plans to extend WikEd to the source editor of the new editor? -Furicorn (talk) 08:25, 24 March 2019 (UTC)[reply]

Furicorn, which features of wikEd do you miss in WE2017 ? Have you considered filing bugreuports to have those officially supported by WE2017 ? —TheDJ (talk • contribs) 08:13, 4 April 2019 (UTC)[reply]
TheDJ I immediately missed the functionality of using ctrl-click to follow a link in the edit window (it's especially useful for trying to fix templates). I submitted some feedback here, but I would be happy to submit a further bugreport if I knew how to or where. -Furicorn (talk) 11:54, 4 April 2019 (UTC)[reply]

WIkia change to Fandom Domain and Remove MonoBook skin

Wikia recently change their domain from Wikia to Fandom

https://community.fandom.com/wiki/Help:Fandom_domain_migration

And they remove their own Monobook skin long time ago

https://community.fandom.com/wiki/Thread:1456214

I can't find a way to make your code run in my wiki anymore. Can you take a look at their site and make a fix? Thank you 117.4.253.117 (talk) 03:33, 14 June 2019 (UTC)[reply]

Wrong conditional

Please have a look at this line: 

if ( ( wikEd.wikiGlobals.wgEnableAPI === true ) || ( wikEd.wikiGlobals.wgEnableAPI === 'true' ) && ( livePreview === true ) ) {

Because of the boolean priority, and because wgEnableAPI is always true (but this will change soon, see Tech News 2019-25), the conditional is always true and the according branch is executed, whether livePreview is true or false.

So there are two things to review and eventually fix:

  • the conditional / code branching (until now, the first branch was always executed, and the other branch was never executed… but no one complained?)
  • wgEnableAPI shouldn't be tested against, as it will be removed soon (thus it won't equal true anymore).

Od1n (talk) 07:35, 19 June 2019 (UTC)[reply]

Edit conflict

When I enable the "wikEd: alternative full-featured integrated text editor for Firefox, Safari, and Google Chrome (documentation)" gadget, I receive an edit conflict with about 75% (approximately) of my edits, even though the edit goes through. It might be interacting with another gadget I have enabled, or a script perhaps. I have tried in Chrome and Edge, on different computers in different locations. I had someone else try and they said they did not encounter the issue. Kees08 (Talk) 22:31, 10 August 2019 (UTC)[reply]

Hm, I hadn't thought of that as the reason for my edit conflicts that aren't really edit conflicts. I've had the problem for weeks. Doug Weller talk 13:37, 11 August 2019 (UTC)[reply]

I have exactly the same problem running wikEd in Google Chrome browser under Windows 10 Pro (all always up to date). The problem began around mid-2019. I used the same setup for several years before mid-2019 with no false edit conflict notices. Do you have any idea what might have changed in wikEd, or in Chrome, to cause false edit conflict notices? Does the problem occur in other browsers?—Finell 05:58, 29 December 2019 (UTC)[reply]

Not working in Foxtrot

Fine in Chrome. Just disappeared from Foxtrot. ¬¬¬¬ — Preceding unsigned comment added by Doug Weller (talk • contribs) 16:32, 11 August 2019 (UTC)[reply]

Semi-protected edit request on 11 October 2019

Please add {{distinguish|Wikipedia:Wiki Ed}} at the top of the page. 83.31.194.166 (talk) 19:10, 11 October 2019 (UTC)[reply]

 Done Sceptre (talk) 00:44, 12 October 2019 (UTC)[reply]

wikEd doesn't work in any other namespace other than Main

I'm on the latest Chrome version (78.0.3904.70) on Manjaro Linux.

Uncaught Error: Another textSelection API was already registered 

   at jQuery.fn.init.$.fn.textSelection (<anonymous>:39:865)
   at Object.wikEd.TurnOn (index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:3842)
   at Object.wikEd.Setup (index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:2396)
   at Object.wikEd.Startup (index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:2080)
   at index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript:19215
wikEd works for me, in Google Chrome browser under Windows 10 Pro, in Talk, Help, WP, and User namespaces (at least) in English Wikipedia and also in Meta-Wiki (meta.wikimedia.org). According to wikEd documentation, wikEd should work at any website that runs MediaWiki software.—Finell 06:11, 29 December 2019 (UTC)[reply]

WikEd can add or remove Wikilinks, which is very useful. To add a link, select a portion of text and mouse-click the Wiki link icon in the bar above WikEd (the first icon in the second row, for me at least). To remove a link, highlight a section of text with several links, then click the Wiki link icon, and all Wikilinks will be removed.

Accurate selection is required. It would be useful to add a little flexibility:

  • If already linked text is clicked without the delimiting square bracket pairs, at present WikEd adds an extra "[[...]]". It would be useful to check if the text is already linked and, if so, delete the link as if the whole link, with delimiters, had been selected. E.g., if selecting [[some text]], it would be useful for the Wiki link button to change this to "some text" (without brackets) rather than the present "[[[[some text]]]]". This would be particularly useful for single-word links: double-click to highlight the word to unlink without surrounding brackets, then click Wiki link button.
  • Possibly if selection for unlinking is slightly inaccurate, with only one of the two square brackets selected, check for this possibility: treat "[[linked text]]" as "[[linked text]]"

Perhaps wait and see if others agree or disagree with this suggestion, then consider implementing it if reasonably straightforward?

Best wishes, Pol098 (talk) 14:06, 30 October 2019 (UTC)[reply]

Capitalization of headers and lists

I would like to see the feature "Capitalization of headers and lists" removed because it is capitalising things inappropriately like infobox parameters and headings that shouldn't be capitalised. This feature is also not helpful in any way and there are far too many false positives. This capitalisation of "mRNA" is inappropriate and I had to revert it in the next edit. The feature to convert HTML to wikicode is extremely helpful but the capitalisation feature is not at all helpful and should be removed. Pkbwcgs (talk) 09:29, 1 January 2020 (UTC)[reply]

@Pkbwcgs: As described under User:Cacycle/wikEd_help#Fix, these buttons are to be used on selected text and not for unsupervised fixing of whole articles. Cacycle (talk) 07:36, 30 March 2020 (UTC)[reply]

How to get WikEd to appear on Fandom sites?

I'm not sure if the Fandom domain has some sort of Javascript or other code that prevents the editor from appearing, but even after following the instructions for complete installation in my user page's common.js, I still can't get the WikEd toolbars to appear on any Fandom sites. Am I doing something wrong? --Tenryuu (🐲 • 💬 • 🌟) 07:50, 17 February 2020 (UTC)[reply]

@Tenryuu: I see a warning “visit your preferences to switch to the old MediaWiki editor” on Fandom with JavaScript disabled. I don’t have a Fandom account, so I can’t use Special:Preferences; have you tried that? For me wikEd seems to load cleanly, but nothing appears, probably because there’s nowhere to add the wikEd UI to. —Tacsipacsi (talk) 17:09, 18 February 2020 (UTC)[reply]
@Tacsipacsi: Are you saying that you can't get the toolbars to appear? I don't see anything that allows me to switch to the old MediaWiki editor in my preferences. --Tenryuu (🐲 • 💬 • 🌟) 23:36, 18 February 2020 (UTC)[reply]

Protected edit request on 21 February 2020

Please add the closing </pre> as shown in the sandbox. This should prevent the documentation from being formatted with the pre tag, and it removes a Linter error. Thanks. – Jonesey95 (talk) 19:02, 21 February 2020 (UTC)[reply]

The suggested change would have included a stray </pre> which would have caused lint errors on the pages on which the template is substed. I've removed them entirely. --Izno (talk) 20:35, 21 February 2020 (UTC)[reply]

wiked not working on fennec aka firefox for android 68.6.0

@Cacycle: hello, i have copied and pasted code given at https://en.m.wikipedia.org/wiki/User:Cacycle/wikEd_installation on https://meta.m.wikimedia.org/wiki/User:Leela52452/global.js. unfortunately, wiked is not working. Leela52452 (talk) 02:46, 30 March 2020 (UTC)[reply]

@Leela52452: Is it working when using another browser (e.g. the default Android browser) or when using a different device or a PC? Then it is probably related to the cache not being cleared. Cacycle (talk) 07:14, 30 March 2020 (UTC)[reply]
@Cacycle: i always clear private data on quit if i add or remove anything in js or css files. browser 5.1 [ preinstalled browser on device ] has same issue. Leela52452 (talk) 08:35, 30 March 2020 (UTC)[reply]
@Cacycle: it is not working on browser 5.1. i had cleared all data using clear private data when quit before reporting. excuse for late reply, Leela52452 (talk) 00:49, 1 April 2020 (UTC)[reply]
@Leela52452: Maybe because you use the mobile interface? The mobile editor is so different from the desktop one that the wikEd user interface would need to be almost rewritten from scratch to support it. There’s a “Desktop” link at the bottom of each page that lets you switch to the desktop view. wikEd should work there. (If you’d like to stick to the mobile view by default and switch to desktop view just sometimes, instead of the “Desktop” link, you can check the Request desktop site checkbox in Firefox’s three-dot menu, and then remove the “m.” from the domain in the URL bar, e.g. change https://en.m.wikipedia.org/wiki/User:Cacycle/wikEd to https://en.wikipedia.org/wiki/User:Cacycle/wikEd.) —Tacsipacsi (talk) 19:53, 1 April 2020 (UTC)[reply]
@Tacsipacsi: activated as gadget. your suggestion using "desktop hyperlink" is working flawlessly. thank you. Leela52452 (talk) 06:06, 2 April 2020 (UTC)[reply]

A Special:Tag for wikEd

Cacycle, have you ever looked into setting up Special:Tags for edits made in wikEd? AWB did it a while ago at phab:T111663. It could be an "advertising tool" for wikEd. I'm sure you remember the nbsp thing a couple of years ago, and I think we would have figured out what was going on sooner if we'd been able to see the editing tools that people were using. Ping me if you need help (or maybe talk to Reedy, who of course knows a lot more about how to do it than I do). I'd love to see tags on wikEd edits. Whatamidoing (WMF) (talk) 19:23, 31 March 2020 (UTC)[reply]

wikEd bug report: Editor overlaps with sidebar

  • Date: 2020-04-01 10:04:44 UTC
  • wikEd version: 0.9.155 (November 5, 2017)
  • Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 (Win32)
  • Skin: vector (detected: vector_new)
  • MediaWiki: 1.35.0-wmf.25
  • Gadgets:
  • MediaWiki scripts: RefToolbar.js, RefToolbarMessages-en.js, RefToolbarConfig.js
  • Scripts: User:Enterprisey/reply-link.js, User:Enterprisey/script-installer.js, User:Enterprisey/short-tab-titles.js, Wikipedia:AutoEd/complete.js, User:Evad37/MoveToDraft.js, User:Writ_Keeper/Scripts/teahouseUtility.js, User:Danski454/stubsearch.js, User:Pythoncoder/userHighlighter.js, User:Pythoncoder/Scripts/voteSymbols.js, User:David_Condrey/bookmarknav.js, User:Lourdes/AfDstarted.js, User:ZLEA/Dashboard.js, User:Omni_Flames/PendingChangesLink.js, User:The_Evil_IP_address/hdedit.js, User:Theopolisme/Scripts/autocompleter.js, User:Evad37/rater.js, User:Cacycle/wikEd.js, User:Cacycle/diff.js, User:Cacycle/wikEdDiff.js
  • URL: https://en.wikipedia.org/w/index.php?title=Wikipedia:Clinic_for_Wikipediholics&action=edit
  • User subpages: https://en.wikipedia.org/wiki/Special:PrefixIndex/User:Berrely/
  • User/skin.js: https://en.wikipedia.org/wiki/User:Berrely/vector.js
  • User/common.js: https://en.wikipedia.org/wiki/User:Berrely/common.js
  • Error console: None related to WikEd.js
  • Problem description: The first time I turned on WikEd, I noticed that the editor overlaps the sidebar, making it hard to read what it says. The white bit disappears, but the text still combines with the text in the editor.
  • Steps to reproduce: I can't really explain how to reproduce, I just clicked the WikEd button!
Berrely: Thanks for reporting this, even when using your script settings. But I am also not sure sure, how the problem should look like. Do you still have this problem? Which sidebar are you talking about? Maybe you could post a screenshot? Thanks, Cacycle (talk) 11:57, 2 May 2020 (UTC)[reply]
Cacycle, sorry! For some reason, it fixed itself after a few days, but now another problem has arisen, for some reason, all edit notices are duplicated and there is a text saying "WikEd: Duplicated edit warning". — Yours, Berrely • Talk∕Contribs 13:10, 2 May 2020 (UTC)[reply]

Guessing Fandom is incompatible with this editor.

Hi, yet another post asking about the compatibility between this and Fandom. I recently installed Tampermonkey with the WikEd script. I went on some other wiki sites where I did not install the script as Javascript and confirmed that it works. It even works on Gamepedia, which is a property of Fandom. However it doesn't seem to work on anything that has "fandom" in its URL (e.g., [6]). Anyone know why that is? Is the software somewhat different? --Tenryuu 🐲 ( 💬 • 📝) 22:29, 3 April 2020 (UTC)[reply]

Compatibility with Wikipedia skins

Hi everyone. I recently switched skins and was wondering if WikEd supports the Timeless skin. The gadget is still active but the toolbars don't come up. —Tenryuu 🐲 ( 💬 • 📝 ) 19:33, 10 May 2020 (UTC)[reply]

Edit conflicts generated by wikEd in Google Chrome on Wikipedia and another wiki

  • wikEd version: latest one
  • Browser id: Google Chrome 81.0.4044.138
  • Operating system: Windows 10
  • Wikipedia skin: Vector or Monobook, doesn't seem to matter
  • User scripts that you have installed on your Special:Mypage/skin.js and Special:Mypage/common.js pages (if any): On Wikipedia I have loads of scripts installed, on this new wiki I have none. Issue happens on both.
  • Gadgets that you have checked in your preferences. Optional: What happens if you disable these gadgets: Wikipedia: loads, new wiki none
  • Web address (URL) of the page or wiki installation where you experience your problems: Wikipedia and https://wiki.endmyopia.org

The following doesn't happen in Firefox. I go to my sandbox page and try to save an edit, this generates an edit conflict 25-50% of the time. This happens on all articles across the wiki. It doesn't happen if wikEd is disabled. Not sure if anyone else is also having this issue. -NottNott 11:57, 23 May 2020 (UTC)[reply]

capitalising first word on template Citar enciclopédia

due to capitalisation, the references will be unusable. i have tested with greasemonkey version ( firefox for android 68.9.0) on wiki page 2401:4900:33AC:9AB3:1:0:BBAC:6075 (talk) 15:28, 10 June 2020 (UTC)[reply]

[feature request] enable RegExTypoFix on greasemonkey user script

if wiked is using awb RegExTypoFixto fix typos, if possible, can u please enable it on greasemonkey user script 2401:4900:33AC:9AB3:1:0:BBAC:6075 (talk) 16:07, 10 June 2020 (UTC)[reply]

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