Jump to content

User talk:Cacycle/wikEd/Archive 006

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


Porting to PHP

Has anyone worked on this? I'm going to start but don't want to redo someone else's work. Ericmock 16:37, 30 August 2007 (UTC)

Sorry, I have missed your post (they are usually added at the bottom). It does not sound as if somebody is working on it, but I have no idea what you mean. wikEd is user-side browser-executed JavaScript, PHP is a server-side scripting language. Cacycle 14:09, 19 September 2007 (UTC)

Numbered lists from Microsoft word

Hi Cacycle, you've got a really cool tool here. I am trying to paste a numbered list from Microsoft Word 2002 and the "Wikify pasted content" button does not work for numbered lists. Instead, it converts it to a plain text numbered list with an extra line between every item. Is that enough information? It'd be great if you could fix that... thanks! ~MDD4696 18:50, 13 February 2007 (UTC)

It only seems to occur when I have different settings for the numbered list indents (accessible via the Customize button on the Bullets and Numbering selector). If I set it to the default (Aligned at: .25", Tab space after: 0.5", Indent At: 0.5") then it converts to wiki code just fine. ~MDD4696 13:36, 15 February 2007 (UTC)
I will try to fix that if possible as soon as I find the time. Thanks, Cacycle 04:16, 19 February 2007 (UTC)
Fixed in 0.9.38 Cacycle 01:20, 19 July 2007 (UTC)

wikEdTypoFix 2

Can wikEdTypoFix replace things like:

  • {{desambig}} by {{desambiguação}}
  • == Links == and ==Links== by =={{Ligações externas}}==
  • [[Category: by [[Categoria:

Can wikEdTypoFix delete things like [[Imagem:Exemplo.jpg]] too?

That is language specific and has to be added as a custom function using the custo buttons as explained in the wikEd customization section. Cacycle 03:31, 17 April 2007 (UTC)

wikEdTypoFix can't do that? AutoWikiBrowser Typos (portuguese) have: 

<Typo word="{{desambiguação}}" find="\{\{desambig\}\}" replace="{{desambiguação}}" />

for replacing {{desambig}} by {{desambiguação}}

I tried this in wikEdTypoFix: 

//{{desambiguação}}
   obj.str = obj.str.replace(/\{\{desambig\}\}, "{{desambiguação}}");

and I get an error in JavaScript console. Mosca2 07:34, 17 April 2007 (UTC)

cannot edit a new page using wikEd, firefox, mac osx

Great tool! One bug: when I edit a page that does not exist, I cannot type into the iframe. I can work around this if I click on 'use full screen editing', and then click back to the regular edit view - then I am able to type into the iframe. I suspect this is a mac and firefox issue, but I consider it a major one - if users can't easily create new pages, that's a problem. Any ideas? I am using the latest wikEd, firefox, and OS X. It may also be an issue with the skin I am using. You can check it out here: http://www.wikicheatsheets.com/w/index.php?title=Test2&action=edit Thanks! Nick

--81.159.111.166 20:39, 1 May 2007 (UTC)

Yes, users have reported similar problems before. It is a FireFox for Mac bug. Would you like to participate in fixing this? That may take a while, but it would be cool to track this down. Simply change your wikEd.js call to wikEd_dev.js in your monobook.js (or whatever skin you use). It is currently identical to the main version. I would make changes and you would have to report back what it does :-) Cacycle 23:32, 1 May 2007 (UTC)
OK, I may take a look at this, but I would copy the js file to a place where I could edit it in order to make changes and see effects myself. I will probably live with the problem for now, but may take a stab at it soon. Thanks! --81.159.111.166 00:01, 2 May 2007 (UTC)

We are a school district that uses MediaWiki (and Wikipedia) extensively, and have many teachers working on collaborative curriculum development. All staff and students are Mac OS X users. Those who also use the latest Firefox and Flock versions are having the WONDERFUL WikEd toolbar fail to allow text entry on NEW pages unless they use the "full screen" workaround. We would be more than happy to help identify and fix this problem. WikEd really is a useful tool, Cacycle, and we really appreciate your efforts in developing it. Our wiki has about 5800 pages of K-12 curriculum and resources, and is growing rapidly. http://wiki.bssd.org Johncn

Cool, let's find a workaround! I am a bit busy right now and this is a tricky bug, so it might take a while. Please could you start by describing your problem and all possible workarounds in every possible detail so that I (without a OS X system) can get an idea of what happens (e.g. when does it happen, what exactly happens, what is broken, what does work, exact steps to reproduce everything and what happens at each step, are there JavaScript error messages or warnings.). Thanks, Cacycle 05:22, 28 May 2007 (UTC)

Sorry...summer vacation. We're back at work now, and I'm doing training on Wiked in a couple days.

We are using OS X 10.4.7, and Firefox 'above 1.5.0.1 (which does actually work) on all our machines. When we load the edit page in more recent Firefox versions, the Wiked HTML Editor appears, but you can't type in the entry box.

If you hit the "Full Screen" button, you can enter text in that mode, or just return to regular mode and all is normal again. The problem is that we have to teach students to click that before making changes, and many are just using the old style editor instead since it is easier and quicker than using the workaround. Thanks! Johncn --BSSD UNK 17:31, 4 August 2007 (UTC)

2 Suggestions

2 suggestions:

  • give the option of fewer buttons
  • hide the existing toolbar when showing yours

A simple interface is the best, people who are scared away by wiki markup are also scared away by 98 buttons! Keep up the good work. Miken32 23:20, 8 May 2007 (UTC)

I'd second this. The reason that keeps me from using wikiEd is it looks and feels bloated. JoeSmack Talk 12:51, 21 May 2007 (UTC)
What screen resolution do you use (i.e. does it feel bloated because you have the buttons in multiple rows). Which functionality, buttons, or button bars would you minimize or remove. The standard toolbar can be hidden with one click, these wikEd settings are now preserved between browser sessions. Cacycle 13:34, 21 May 2007 (UTC)
I have now removed several buttons to streamline the interface. Cacycle 03:01, 1 June 2007 (UTC)

Problem

I did every thing that the one guide told me to do yet it still doesn't show anything at all (offline/Intranet Wiki). Is there a way to fix this? Frostyfrog 02:57, 18 May 2007 (UTC)

Maybe, if you give more details. See the top of the page for how to report errors. Make sure to follow the guide on the wikEd homepage. Cacycle 12:58, 18 May 2007 (UTC)
Has $wgAllowUserJs = true; been set in LocalSettings.php of your wiki installation by a server admin? Cacycle 13:01, 18 May 2007 (UTC)
yes it has been set ($wgAllowUserJs = true; is at the bottom)) Frostyfrog 22:15, 21 May 2007 (UTC)
Could you please check the top of this page for the information that I need to help you. Thanks, Cacycle 23:03, 21 May 2007 (UTC)

Removing wikEd

Hey there, I'm a new Wikipedian and was hoping that wikEd would be able to help me get my feet underneath me as a new editor. However, it is giving me some problems and I'd like to get a little more experience under my belt before I use it. Is there any way to uninstall/remove it? I have "disabled" it by clicking the box in the upper right corner of the screen, but would like to just get a fresh start and come back to it later. Thanks for your help, and for making such a great product! bwowen T/C 00:08, 19 May 2007 (UTC)

Just remove the installation code from your monobook.js and click Shift-Reload to clear your browser cache. But clicking the "main switch" on top of the page should work too. Which problems did you have, maybe it can be fixed. Cacycle 00:41, 19 May 2007 (UTC)
I couldn't edit some pages - I didn't look at the specific error, sorry. I'd edit a page, hit preview, and nothing would happen. Any advice? bwowen T/C 02:05, 19 May 2007 (UTC)
That sounds like the bug from above and has been fixed. It was related to the newest feature of making all links in the edit text clickable. Cacycle 04:39, 19 May 2007 (UTC)
So I just put it back in my monobook.js to reinstall it then?bwowen T/C 22:45, 20 May 2007 (UTC)
Good idea :-) See the wikEd homepage for details. Cacycle 23:19, 20 May 2007 (UTC)

Syntax error

I just install MediaWiki for my local host, and trying to install WikEd for it. But after I have followed everything guided in Installation step by step (If I do properly), it still doesn't work. Follow the troubleshooting to the last step, I open the Error Console in Firefox, I get the following error alert:

Error: syntax error Source File: http://localhost/Wiki/index.php?title=-&action=raw&smaxage=0&gen=js Line: 19, Column: 1 Source Code:

</nowiki>

I'm using:

  • WikEd 0.9.33
  • WindowXP SP2
  • Firefox 2.0.0.3 for browser : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 *Firefox/2.0.0.3
    • And currently, I use All-in-one sidebar
      • Bookmark Duplicate Dectector
      • Document Map
      • DOM Inspector
      • Full Cal
      • Mozile
      • Reminderfox
      • Scrapbook
      • Tab Mix plus
      • Torrent Search Toolbar
      • Nandu
  • WAMP5 1.7.1 for WAMP soft
  • MediaWiki 1.9.3
  • user scripts to common.js:

/* Any JavaScript here will be loaded for all users on every page load. */ /* define image path*/

var wikEdImagePath = 'http://localhost/Wiki/images';

/* disable auto update*/

var wikEdAutoUpdate = false;

/* install the wikEd translation (omit if no translation needed) */ document.write('<script type="text/javascript" src="' + 'http://localhost/Wiki/index.php?title=wikEd_translation.js' + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');

</nowiki>

/* install [1] in-browser text editor*/ document.write('<script type="text/javascript" src="' + 'http://localhost/Wiki/index.php?title=wiked.js' + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');

wikEd does not work with that ancient MediaWiki installation. Please install a recent version (also for security reasons) or ask for it. Cacycle 12:50, 24 May 2007 (UTC)
Sorry, Mines is 1.9.3, not 1.10 <_- is it the latest version.
The problem might be related to the helper scripts. Does it work if you put this before the installation code:
 // disable external diff script
 var wikEdLoadDiffScript = false;
 
 // disable external wikEdDiff script
 var wikEdLoadDiff = false;
 
 // enable external InstaView script
 var wikEdLoadInstaView = false;
 
 // enable external RegExTypoFix script
 var wikEdLoadRegExTypoFix = false;
 
 // disable RegExTypoFix (http://en.wiki.x.io/wiki/User:Mboverload/RegExTypoFix), needs User:Cacycle/wikEdTypoFix.js or translation
 var wikEdRegExTypoFix = false;

If enabled, these scripts should also be copied to your wiki. I will update the instructions later today. Cacycle 14:15, 24 May 2007 (UTC)

Sorry to say nothing change, thanks for prompt support
Are there other error messages. Or does it help to replace "</script>" with "</' + 'script>". Cacycle 15:31, 24 May 2007 (UTC)
This seems the most probable cause of the problems. I have already updated the wikEd homepage. Cacycle 16:04, 24 May 2007 (UTC)
You should also use the current version (0.9.36j) and then update later today or tomorrow to get a find/replace bugfix. Cacycle 15:39, 24 May 2007 (UTC)
Are you sure it is an uppercased W in wiki in your path? Cacycle 16:02, 24 May 2007 (UTC)
Yep, I copy it from the link, so it should be okie. It still have the same error. I'm not sure what you mean by replace....</scritp>. I think, for the next time, you should export code in txt file, so it wont be mistaken. For example, when copy code from your WikEd and paste to mines, it does not look exactly the same.....
Simply replace every occurrence of "</script>" with "</' + 'script>" on common.js. Cacycle 17:12, 24 May 2007 (UTC)
Already change, but no effect. The same error for the < /nowiki > < /pre > (I use space to neutralize the code).

Sorry, it took me while. You have to remove the "</nowiki>" parts. I have it already fixed on the homepage. Cacycle 16:41, 26 May 2007 (UTC)

Nothing happen again :(. But I not that, you forget to say about wikEdDiff.js??

After removing the "</nowiki>" parts, please could you post your common.js and all related error medssages. Thanks, Cacycle 17:42, 27 May 2007 (UTC)

Issue in "Fix basic, html, and unicode"

As you see here, using "Fix basic, html, and unicode" causes errors in cite tags. Rather than correcting every cite tag manualy, can you make it so that it dosnt change – to –? ffm ✎talk 14:59, 30 May 2007 (UTC)

This button is explicitly made to convert &ndash; into –, what is wrong with that. I will try to fix the <br /> substitution. These buttons should not be used on the whole text but rather on selected text because intentional and sometimes very tricky formatting might get lost, even during "normal" operation. The problem with the ref tags is that they miss the quotation marks for the name attribute, it must be <ref name="abc">, not <ref name=abc>. Cacycle 02:52, 1 June 2007 (UTC)
HTML tag parameters are now accepted without quotation marks in 0.9.38a. I will not fix the <br /> substitution as this is the expected functionality of the "fix html" and the "fix all" buttons, please use them only on selected text. Cacycle 02:54, 19 July 2007 (UTC)

Keyboard shortcuts

Hey, I just started using wiked and (oh, that's cute, I just got the name) it's pretty sweet, but I'm just wondering about keyboard shortcuts. Before I installed this, I had my own javascript (oh, this is on my own wiki, not the pedia) that caught keydown events from the edit box and did things like markup and submit the form and stuff. Since installing yours, these no longer work. The function isn't even getting called, even though I include the javascript and the onkeydown attribute statically in the edit page. Is your script capturing them out from underneath me or something? I'm on Firefox 2.0.0.4 on WinXP Pro SP2 (doubt that's relevant). MediaWiki is pretty old, v 1.6.5, but the script works fine, it just seems to be trumping mine.

If you need to, you should be able to test it out and view the source here: http://bmearns.net/wwk/edit/WorldWideWiki:Sandbox
Ctrl-b is supposed to bold, Ctrl-i is itallicts, and there's some others. They delegate to the media wiki standard insertTags JS function. More importantly, they return false to prevent the keyevent from going any further.

So any help would be appreciated. I'll let you know if I find anything. Thanks. B.Mearns*, KSC 18:23, 1 June 2007 (UTC)

The page is empty for me. But if you give me a list of shortcuts I can add them to wikEd. Cacycle 19:32, 1 June 2007 (UTC)

Installation issues into MW 1.10.0

Hello,

I have recently installed a MediaWiki Server for use at a colabrative information source at the office. I was hoping to add WikiEd to the server, or perhaps on an initial user basis so that it would assist with the learning curve of wiki markup and in hopes that it encouraged more users to contribute.

I have created this account and installed it and it seems to work here on Wikipedia(at least mostly), however the same on my server results in no wikied icon in the upper right.

I have reviewed the documentation provided and have ensured that I followed the sections. My browser is JS enabled, and I get no errors. I have set the requested LocalSetting varriable to enable JS for my users and bounced apache. I reviewed the section for troubleshooting the install and believe I have done as expected, however I still have no WikiEd icon in the upper right.

  1. Does WikiEd work in MW 1.10.0?
  2. Do you have a simple sample JS that would be able to test this functionality in my Wiki outside of WikiEd
  3. mostly: Do you have any suggestions on how to make this work?

Thanks in advanced for any assistance you can provide.

J

It should work well with all newer Mediawiki versions. What happens if you install it into your username/monobook.js. Is $wgUseSiteJs set to true. Did you click Shift-Reload to update. In order to help you I need more infos, including the contents of MediaWiki:Common.js. Is $wgUseSiteJs set to true. Cacycle 02:11, 3 June 2007 (UTC)


Hi. I found the problem with J's MediaWiki. I had the exact same problem. Cacycle, your Common.js code refers to wiked.js. However, in your installation instructions, you specify to create wikEd.js. Since MediaWiki is case sensitive, this breaks the installation!
Another thing in your Common.js code - you refer to wikEdDiff.js. However, nowhere in the installation have you provided the code that goes into this file. Is this a mistake? --Pratsx 05:56, 21 September 2007 (UTC)

The newest versions of wikEd seems to collide with link-changing scripts (this one, to be specific) on diff pages. (The script should insert a "bot=1" parameter into rollback links, but the link gets totally messed up, and mostly turned into plaintext. I'm not sure when exactly this started, but used wikEd for quite a while so I think I would have noiced it earlier if it didn't happen recently. I suspected the new linkification feature, but wikEdFollowLinks = false didn't help. (Turning off wikEd with the cookie doesnt help either.) A tried this both with my script loaded before and after wikEd, doesn't change anything.

I use the newest wikEd (0.9.37b) and Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4) under Windows XP. I only get the error on diff pages, not on other pages with a rollback link (e.g. history pages). I don't get any javascript errors.

This is the original HTML source of the rollback link (for the article "Farkas" last edited by "Don golgi" in huwiki): 

[<a href="/w/index.php?title=Farkas&action=rollback&from=Don+golgi&token=436a4903602fb8798bbd686325e13e6c%5C" title="Farkas">visszaállítás</a>]

This is how it should look (and how it looks when wikEd is turned off): 

[<a href="/w/index.php?title=Farkas&action=rollback&bot=1&from=Don+golgi&token=436a4903602fb8798bbd686325e13e6c%5C" title="Farkas">visszaállítás</a>]

This is how it looks with wikEd: 

[<a href="%3Ca%20href%20=%20" http:="" hu.wiki.x.io="" w="" index.php?title="Farkas&action=rollback&amp;bot=1&from=Don+golgi&token=436a4903602fb8798bbd686325e13e6c%255C%22"" style="text-decoration: none; color: inherit;" title="http://hu.wiki.x.io/w/index.php?title=Farkas&action=rollback&amp;bot=1&from=Don+golgi&token=436a4903602fb8798bbd686325e13e6c%5C"">http://hu.wiki.x.io/w/index.php?title=Farkas&action=rollback&amp;bot=1&from=Don+golgi&token=436a4903602fb8798bbd686325e13e6c%5C"</a> title="Farkas">visszaállítás]

Do you have any idea what might cause this? Thanks, --Tgr 00:42, 9 June 2007 (UTC)

Quick fix: var wikEdLoadDiffScript = false; to disable the wikEdDiff feature. I'll check for the exact cause and a real fix later. Cacycle 02:26, 9 June 2007 (UTC)
It should work now, please could you test it and report back. It is now linkifying only in non-title cells of the diff table. Thanks, Cacycle 03:49, 9 June 2007 (UTC)

Thanks, it works fine now. --Tgr 18:21, 9 June 2007 (UTC)

FF Spellcheck dosn't work in frame

For some reason, firefox does not spellcheck text entered into wikEd like it does for text entered into the standard edit box. ffm ✎talk 11:42, 12 June 2007 (UTC)

It works fine for me in Firefox 2.0.0.4 and 3.0a6pre and the current SeaMonkey. What happens if you update to 2.0.0.4. Or maybe it is a preference setting. Cacycle 14:03, 12 June 2007 (UTC)

Adding only highlighting

Hi im working on a company intranet homepage and want to make things easier for people to use. I wonder if its possible to only have highlighting and nothing else? --192.100.124.219 09:27, 19 June 2007 (UTC)

There is no easy way to do this. I would also not be user friendly because one needs at least the [T] button to use wikEd. But I am open to suggestions to simplifu things. Why don't you use it for a while and give me some feedback. Cacycle 12:40, 19 June 2007 (UTC)

wikEd not playing nice with Twinkle

Line: 1201

Any help on this odd, near isolated issue would be helpful! --treelo talk 01:46, 24 June 2007 (UTC)

I also have this issue. --Flex (talk/contribs) 02:05, 24 June 2007 (UTC)
Looks like it was twinkle, but the error is gone. FYI, the error noted happens with or without twinkle enabled. --Andrew Hampe Talk 03:39, 24 June 2007 (UTC)
I have temporarily fixed it. The error is actually caused by some strange programming in Twinkle and I have contacted AzaToth. Cacycle 04:56, 24 June 2007 (UTC)

templates and url

I think I finally found what caused the red-bold of some templates that annoyed me for so long: URLs used as parameters. Can that be fixed? Circeus 04:10, 8 July 2007 (UTC)

Please could you give me an example. Thanks, Cacycle 13:19, 8 July 2007 (UTC)
http://en.wiki.x.io/w/index.php?title=Ailanthus_altissima&action=edit&section=9 Although the {{cquote}} is also bolded. When working with this article, I noted that replacing a url (which are ALSO bade into red bold) with a DOI would cause the template to become normal again. Note that removing the HTML comment in the Cquote will also return it to normal. Not all templates with URL become bold, but the vast majority will. Circeus 04:53, 9 July 2007 (UTC)

Preview/change problem

When I edit a page, click the main "Preview" button, then make another change and press the green Δ change button, only the last set of changes (i.e., those that have been made in the current page session or whatever the term is) is displayed. (I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 and wikEd 0.9.37c.) --zenohockey 04:34, 9 July 2007 (UTC)

This is normal behaivor. It is designed to work this way, it is not possible (or would be difficult) to retrive the original page data. Also, it would cause issues if someone changed the page while you were editing it. ffm ✎talk 18:53, 10 July 2007 (UTC)
That's right, thanks Firefoxman. I might add the requested function in the future, similar to the preview that uses first a local view and then retrieves a server preview using AJAX techiques. Cacycle 02:36, 11 July 2007 (UTC)

HTML comment preceding bullet point

It seems that, when there's a bullet point preceding by an HTML comment, the bulleted text is not "grayed."

For example, click "Edit" and look at this:

  • This text is not grayed.
  • This text is grayed.

--zenohockey 05:18, 9 July 2007 (UTC)

Thanks for noticing, I am not yet sure if this can be fixed easily, we might have to live with it in order to keep the program fast and short. Cacycle 02:38, 11 July 2007 (UTC)
Fixed in 0.9.37e. Cacycle 03:17, 15 July 2007 (UTC)

Ref button

Do you think you could add a button to the toolbar that wraps selected text in ref tags? ffm ✎talk 18:42, 10 July 2007 (UTC)

You mean like the Ref button? Cacycle 02:39, 11 July 2007 (UTC)
Doesn't that just hide the refs? (I cannot verify as I am on IE right now) ffm ✎talk 15:00, 11 July 2007 (UTC)
Not the blue one on the left button bar :-) Cacycle 18:24, 11 July 2007 (UTC)
Ah, I see. Thank you.[1] ffm ✎talk 14:06, 15 July 2007 (UTC)

Links of the formet [[singular word]]s do not convert properly, they always end up like [[singular words]]swhen pasted text is wikified by wiked.

Fixed in 0.9.37d. Cacycle 02:13, 15 July 2007 (UTC)

Also, characters like the underscore and tilde are converted into percent-encoded element for the purpose of ctrl+click, which often breaks the link. Not to mention links themselves containing percent encoded characters...Circeus 12:33, 14 July 2007 (UTC)

Please give me examples so that I can fix it. Thanks, Cacycle 02:13, 15 July 2007 (UTC)
Édifice Price, "History" section: the "lachappelle" (name of ref) ref link breaks because it has an underscore. It also highlights improperly, as does the "benoit" ref. Circeus 02:23, 15 July 2007 (UTC)
Thanks, I have fixed it in 0.9.37f. Cacycle 04:08, 15 July 2007 (UTC)

Compressing JS Code

How about compressing the wikEd code? It can make a huge difference, both in file size and performance. On TiddlyWiki (or rather, TinyTiddly), this is done with the following tools:

  1. ShrinkSafe
  2. JsMin
  3. Packer

Lint might be helpful too...

-- FND, 09:16, 17 July 2007 (UTC)

Thanks for the suggestion and the interesting links. I am a bit reluctant - it would certainly speed up the script download, but I do not think it would affect the execution speed. JavaScript is load only once and then kept in the browser cache, so that during normal operation there would not be any difference. However, it would be quite some work to compress every version and to keep a readable as well as a compressed version on separate pages. Cacycle 04:30, 18 July 2007 (UTC)
You might be right about the execution speed (it might be a different issue with TiddlyWiki's huge load of JS code). As for the effort it would take, that could probably be automated with a script - if you're interested, I could ask the TinyTiddly guy whether his (Ruby) script could be adapted to your needs. -- FND 06:50, 19 July 2007 (UTC)

Greasemonkey

I would like a greasemonkey version, (and it would nice nice if the whole script was packed together as a single file) so I can use it on all the wiki sites I use, and possibly on intranet systems. I tried to modify it myself but it kept loading a blank page for me. I do not understand why. So you do it. Thank you very much. --ALok 21:27, 18 July 2007 (UTC)

Thanks, I am working on it Cacycle 18:18, 22 July 2007 (UTC)
The next wikEd version will also work as a Greasemonkey script! It already works fine under Firefox, but I still have to adapt an automatic update system and probably have to bundle the scripts together. See wikEd_dev.js for a working preview and click here to install it (the content of these links will be removed/changed in a few days). Cacycle 13:56, 19 September 2007 (UTC)
Thanks for the suggestion! wikEd 0.9.44 is now Greasemonkey compatible and the whole bundle can be installed by clicking here. Cacycle 05:05, 24 September 2007 (UTC)

Cut and delete not working

Firefox 2.0.0.5 Intel Mac OS X 10.4.10 wiked 0.9.38a More details available if needed - the cut function in firefox edit drawdown menu does not show or work - and the two delete buttons dont work SatuSuro 12:31, 22 July 2007 (UTC)

This looks like a FireFox for Mac OsX bug, everything works fine with SeaMonkey and FireFox under Windows and your monobook.js also works for me. I am sorry, but I cannot try to find a workaround because I do not have access to a Mac Os X box. You could check the error console for JavaScript errors and/or file a Mozilla bug report. You could also try to disable other, potentially incompatible, browser addons. Cacycle 18:18, 22 July 2007 (UTC)
Dont apologise - I appreciate the response - what I might do when i have the time is disable all the firefox addons - they are a nuisance anyways - and see what happens - anyways for some type of editing - for the moment disabling between cut/delete editing and other is no big deal - will get back when i have aclearer idea - cheers SatuSuro 01:42, 23 July 2007 (UTC)
I assumed this was intentional. But for me not being able to right-click, menu, cut is something I am already missing since I started using this editor yesterday. I've not got a Mac. qp10qp 22:16, 22 July 2007 (UTC)
Qp10qp: You are not using Mac OS X and don't have the cut entry in right click menus? That is really strange as it is there for me. What about the delete and backspace keys. Cacycle 14:03, 23 July 2007 (UTC)
This is not intentional. What version of FF are you running? ffm 14:45, 23 July 2007 (UTC)
I think I am on the last but one update of Firefox. It's possible that there is a clash with a dropdown from my tab extension. But the minute I disable this editor, my right click drop down menu is a standard undo, cut, copy, paste, select all list, and I haven't had the problem before. With it enabled, I get select all, but the rest is a drop down related to my tab extension, I think. It does have "back".qp10qp 17:10, 23 July 2007 (UTC)

Dashes

I've been trying this editor out. Many thanks for all your work: it's very interesting.

I thought I'd try the dash fix thing on the article I am working on, William Shakespeare (I thought it might save me some time converting hyphens to en dashes in date and page ranges); but unless the preview misled me, it appears that the fix intends to put spaces round em dashes. Spaced em dashes are not really very common in print, however, and our MoS now deprecates them ("Em dashes are normally unspaced on Wikipedia"). Spaced en dashes may be used instead of em dashes, but I suspect that the majority of editors would not wish to do that.qp10qp 22:12, 22 July 2007 (UTC)

Should I make it en-dashes only or unspaced em-dashes. Personally, I don't like em-dashes... For consistency it could also convert all ems to ens... Cacycle 14:02, 23 July 2007 (UTC)
I think this is a real minefield, because there are many schools of thought and different publishing houses use different styles. At the moment, the MoS, rightly I think, advises either unspaced em dashes or spaced en dashes, but I don't think the fix should force one of these two styles (dash nerds like myself would go bonkers). A conversion of spaced ems to unspaced would be in keeping with the MoS, except there would need to be an exception where people have wrongly used ems for date ranges. But ens are difficult because they might be spaced in prose but unspaced in page or date ranges. The most useful thing to me would be changing hyphens to en dashes on page or date ranges, though I think a bot comes round every so often to sort this out; also a quick way of adding dashes to text with key strokes (at the moment, if I type two hyphens, your editor gives me a spaced em dash, and so I have to delete the spaces; the alternative of dropping down to the menu below the edit box is also dreary).qp10qp 16:56, 23 July 2007 (UTC)
It is fixed in wikEd 0.9.41. It now removes spaces around em dashes, adds spaces around en-dashes, and converts html character entities into dash characters, -- to en dashes, dashes before numbers into a minus sign, and dashes to en dashes in dates. Cacycle 02:21, 7 September 2007 (UTC)

Typo?

"Toggles the automatically addition of "…using wikEd" to summaries on submitting the page. This setting affects all new pages and is kept for future sessions."

Just a minor thing for your info: odd English (I didn't correct it because I wasn't sure what it should be).qp10qp 22:39, 22 July 2007 (UTC)

Sounds like valid English to me :-) The button toggles a setting that adds some text to the summary after you have pushed the submit button. Cacycle 13:56, 23 July 2007 (UTC)
Do you mean "toggles the automatic addition of..."? qp10qp 16:41, 23 July 2007 (UTC)
Oops... yeah Cacycle 18:53, 23 July 2007 (UTC)

What happend to "...using wiked"

dosnt appear in the toolbar anymore. ffm 16:00, 23 July 2007 (UTC)

Add var wikEdShowUsingButton = true; to your monobook.js before calling wikEd. Cacycle 04:40, 2 September 2007 (UTC)

Starting 23 July 2007 WikEd isn't loading.

Firefox 2.0.0.5 is complaining of: 

Error: invalid XML tag syntax
Source File: http://nc1lxbuild01.nc.tekelec.com/tekpedia/index.php?title=User:Jhildebr/monobook.js&action=raw&ctype=text/javascript&dontcountme=s
Line: 6, Column: 40
Source Code:
+ '&action=raw&ctype=text/javascript"></' + 'script>');
-----------------------------------------^

Which is a part of my installation line in my monobook.js file. 

// install [[User:Cacycle/wikEd]] in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></' + 'script>');

Any ideas?

Can you paste the hole monobook.js, as I cannot access your site, it seems to be down. (By the way, sign your comments with ~~~~) ffm 13:25, 24 July 2007 (UTC)
It's a private site, so I'm not surprised that you can't access it. The only thing in my monobook.js file is the code shown above. I've been playing around with it and it seems that it's reading http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js as http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js' <--- note the "'" at the end of the line. if I cange it to
// install [[User:Cacycle/wikEd]] in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"><script>');

it loads in preview, but not normally.... go figure. --Hildebrandj 13:33, 24 July 2007 (UTC)

Remove just the "' + '"part, leave the "/", resulting in:
// install [[User:Cacycle/wikEd]] in-browser text editor
document.write('<script type="text/javascript" src="'
+ 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></script>');

Hope that helps, Cacycle 13:45, 24 July 2007 (UTC)

I've isolated it out. It turns out that there's an incompatibility issue with the LinkedImages Extension. Once I took that out, it loaded. Go figure. Thanks for your help. --Hildebrandj 14:21, 24 July 2007 (UTC)

js highlighting

Think it could be incoperated into wikEd? ffm 13:27, 24 July 2007 (UTC)

Thanks for the suggestion. I will probably not write this as it would bloat the code and slow down the already slow syntax highlighting, even if it would come handy for the handful people that edit JavaScript in the input field :-) Cacycle 00:01, 26 July 2007 (UTC)

Feature request: support lang tags

Would it be possible to support the use of language tags for the regextypo fixer? AWB supports them so that English spelling corrections are not applied to text tagged as foreign language e.g. {{lang|fr|some text}}. Thanks Rjwilmsi 19:35, 25 July 2007 (UTC)

wikEd 0.9.40 now supports the {{lang|}} template to exclude text from typo fixing. Please note that the lang template must not contain other nested templates - the excluded text ends currently with the first occurrence of }}. Please notify me if nested templates really need to be supported (it would make the code much more complicated as far as I can see). Cacycle 03:15, 5 September 2007 (UTC)

Safari support

Has wikEd been tested for compatibility with Apple's Safari 3 Beta? This version appears to be based at least partly on Mozilla. I have it running on XP and would be happy to help in any testing. —Travistalk 14:58, 28 July 2007 (UTC)

I am currently on vacation. Your help in testing it under Safary would be appreciated, please check User:Cacycle/wikEd_development for the preferences setting to bypass the wikEd browser test. Unfortunately, I cannot help much until I am back. Cacycle 17:23, 1 August 2007 (UTC)
I just today returned from vacation myself, so I'll be starting this next week. —Travistalk 04:09, 5 August 2007 (UTC)

WikEd doesn't work in Offline Environement

Hello,

the problem is that the wiked.js file isn't loaded properly. I suppose it is cutted after 256 Kilobytes, when I display any site of my wiki. I used the url "http://localhost/wiki/index.php?title=wiked.js&action=raw&ctype=text/javascript" and I just get a part of this file. If I write a plaintext file on the webserver with the content I can download it and the content in OK. So I suppose there must be a Problem in my PHP, MySQL or MediaWiki Configuration. I can edit this page and there everything is fine.

  • Your wikEd version: 0.9.38a
  • Your MediaWiki Version: 1.9.3
  • Your 'browser: id19 Firefox/2.0.0.5'
  • Error console errors: Parsing errors because last Part of file is missing
  • Which browser add-ons have you installed: just Prefbar
  • Which user scripts have you installed on your monobook.js page: no other script
  • Which operating system do you use: Server SLES 10, Client Windows 2000
It might also be a webserver setting. Cacycle 22:37, 14 August 2007 (UTC)
But what should be the problem? I've checked the configuration of Apache, PHP and MySQL and raised all buffers, caches and execution times I could find. But the problem is still the same. --Michael Mann 05:00, 15 August 2007 (UTC)+
Please provide more details :-) Cacycle 23:22, 20 August 2007 (UTC)
What a funny guy ;o), I will supply my php.ini, Media Wiki Configuration, apache config as soon as possible. Which files/informations do you also need? Thanks --Michael Mann 12:44, 21 August 2007 (UTC)
I was thinking more about: at which position does it break, always at the same position, or is it really 256 kB. Cacycle 13:28, 21 August 2007 (UTC)
It breaks everytime at a Point where 256 KB was reached and if I delete some lines it's just an other line. But now it works curiously, I restarted the machine because of maintainance issues and after that it works, when I connect via VPN. I will test the problem when I am at work in september and I hope I can tell you what the problem was. Thanks for your help. --Michael Mann 10:30, 26 August 2007 (UTC)

Error

I don't know what's wrong. The Console doesn't show an error for my code, yet I don't see the icon. What's wrong? LaleenaTalk to me Contributions to Wikipedia 21:05, 12 August 2007 (UTC)

Dunno, please give more infos, see the top of the page for essential information that I need to help you. Cacycle 20:43, 18 August 2007 (UTC)

Hi. First off, thanks for making this script, it is REALLY a time saver! I am converting a wiki from UseMod to MediaWiki and wikiEd has REALLY come in handy for all those HTML-rich pages. Now, for my concern. I am using wikiEd 0.9.38a on FF 2.0.0.6 on OS X (have you figured out the editing error for OS X yet? :-P) and I had been using it without too many problems for my HTML conversion using the [< >]. For some reason, as of this week or the one before, converting the following link is giving me double square brackets instead of one:

Raw HTML (incorrect) wikiEd output Reason it is incorrect
<a href="http://www.blah.com">blah</a> [[http://www.blah.com|blah]] This is not an internal link, it should convert it to [http://blah.com blah]

It was working before (pretty sure it was after July 18, so it doesn't seem like an issue with the newest version, although it WAS working fine a few weeks ago...) but for some reason now it thinks those are internal links.

Also, if it is possible, could you make the change so the HTML does not have to be case sensitive? <A HREF="http://www.blah.com">blah</A> converts simply to "blah". Also, not sure if this matters, but I am using MW 1.6.10 (trust me, if I could be using 1.10.x, I would be...). Thanks again! --Eljaco 16:54, 22 August 2007 (UTC)

I will make these changes as soon as I find the time. Cacycle 13:07, 30 August 2007 (UTC)
Please can you give me a link to your wiki so that I can test it - here a Wikipedia it seems to work fine. Thanks, Cacycle 04:22, 2 September 2007 (UTC)

RTL text

Hello. wikEd automatically aligns text to the left (LTR). How can I add a button (or maybe add it to the next version) that will change text direction RTL<->LTR..? Thanks, Mintz l 13:49, 26 August 2007 (UTC)

Check User:Cacycle/wikEd#Custom_buttons and change the "div" example to "rtl" (if that is the html tag for it). Cacycle 13:02, 30 August 2007 (UTC)
  • Excuse me, but, it's not clear for me, the beginner, to see how to enable it, right to left? I mean, i installed all, but is there a way to change the all direction to Right? —Preceding unsigned comment added by 213.42.21.154 (talk) 21:28, 5 October 2007 (UTC)
I probably do not exactly understand what you want, please explain your problem in much more detail. Cacycle 21:30, 6 October 2007 (UTC)
  • Hi, i mean, when writing the Arabic wiki, it moves the direction of the writing, To left to Right, i want it to skip this step, and leave the default direction, From Right to Left.

PS. Try an essay, in the arabic wiki , to understand more, about this Issue. Regards. --Stayfi 00:37, 11 October 2007 (UTC)

I have added RTL-support in wikEd 0.9.46. Сасусlе 02:06, 14 October 2007 (UTC)
  • Well done, Man. I planned to change ur code, but u did it. Thanks.
Regards --Stayfi 19:57, 21 October 2007 (UTC)

Help with disambig fixing via popups: Conflicting with WikEd?

Hi, I'm having problems with your WikEd script when working with Lupins fixing disambigs popup. I think it's to do with wikEd is incompatible with other scripts and extensions that rely on or change the text edit box (see the next section). I've already had help from User:After Midnight, and after finding out it was WikEd that was causing the problem, he suggested I speak to you. All the information on the error is here in greater detail, also the conversation we had. Upon removing WikEd from my monobook.js the disambig popup script work. I have the latest version of the script, and I am using FireFox, and WikEd works perfectly normally. Any help would be appreciated, your script is very useful and I would like to keep it, while having disambig fixing popups. Thanks in advance -- Halo2 Talk 15:50, 26 August 2007 (UTC)

After a quick look I think the problem is related to this: User:Cacycle/wikEd#Making scripts compatible with wikEd and had to be fixed in the popups script. Cacycle 12:56, 30 August 2007 (UTC)

Thanks for looking at it. I'm a bit lost, I'm not sure whether I fix it when importing the script, ie including the above text into my monobook, or do I contact the author of the Popup script (User:Lupin). -- Halo2 Talk 18:46, 30 August 2007 (UTC)

JS Error

Hello. I tried to install wikEd on MediaWiki 1.10.1, and i got error report by js-console: "JavaScript - http://mtb.tj/mwiki/index.php/Участник:WikiSysop/monobook.js Inline script compilation Syntax error while loading: line 4787 of linked script at http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js&action=raw&ctype=text/javascript : obj.plain = obj.plain.replace(/([\wÀ-ÖØ-öø-\u0220\u0222-\u0 " —Preceding unsigned comment added by 85.141.89.108 (talk) 07:59, August 28, 2007 (UTC)

No idea... Could be a problem with character encoding, if you set it to UTF-8 in MediaWiki, web server, and browser it might work. Cacycle 13:06, 30 August 2007 (UTC)
I've done the problem - this is some kind of Opera's bug - on Firefox everything is OK. Thank you and sorry for idle diturbing. —Preceding unsigned comment added by 85.141.88.147 (talk) 13:03, 19 September 2007 (UTC)

Offline installation : template does not work, subst does

Hello there,

First of all, thanks for the awesome job ! wikEd is indeed wicked :)

Now, I've been meaning to install it on an offline MediaWiki installation. I followed the offline instructions thoroughly but there's a catch. If, in my monobook.js special page, I use {{wikEd}}, wikEd does not show up at all. However, if I type {{subst:wikEd}}, then all is well.

I have not yet investigated the full details of javascript + template inclusion, so I do not know exactly what is going on there. Any insight would be greatly appreciated :)

Cheers !

143.196.159.101 09:17, 30 August 2007 (UTC) (sorry, can't remember whether I had an account here)

You cannot use templates like {{wikEd}} in your monobook, you have to paste the actual text for it to work. Cacycle 13:09, 30 August 2007 (UTC)
Thanks. Then may I suggest that the "offline" instructions be changed to reflect that ? Especially the line "users can then install wikEd simply by adding {{wikEd}} to their User:USERNAME/monobook.js page." In fact, hey, I'm going to correct this myself :) Another question though : is it normal that the instant preview does not make use of the templates, ie. it does not render them at all, but displays {{templatename}} instead ? Cheers, Romain 143.196.159.101 08:13, 31 August 2007 (UTC)
Thanks for fixing the instructions. The preview first renders the article offline so that templates are not substituted and then fetches a complete preview from the server. Cacycle 12:56, 31 August 2007 (UTC)
Gotcha. In short, use the default preview when you need templates rendered, and wikEd's preview otherwise. Cheers ! Romain 143.196.159.101 14:44, 31 August 2007 (UTC)
No, it gets the complete preview in the background and displays the response from the server. If it does not work then something is wrong. Is there an error message. Cacycle 17:05, 31 August 2007 (UTC)
Hm nope, I don't think I noticed an error message. I'm using the latest wikEd (downloaded 3 days ago), MediaWiki 1.10.0, on IIS 5 with PHP5. What else could interfere here ? I'll have to check back at work on Monday. Cheers, LeCoyote 19:11, 31 August 2007 (UTC)
I do confirm : no error message whatsoever. I get the preview window, but templates are not rendered. Also in the preview, link addresses are incorrect : instead of linking to, for example 
http://intranet/pathto/wiki/index.php?title=Context:Page
it will point to 
http://intranet/pathto/wiki/index.php?title=Context:PageContext:Page
i.e. the full title of the article appears twice. LeCoyote 07:48, 3 September 2007 (UTC)
Please send me a link to your wiki or thefull html text of an edit page (you can use use the E-mail this user function on the left). Thanks, Cacycle 03:23, 4 September 2007 (UTC)
Done. Did you get it ? Can you make any sense out of it ? Thanks a LOT for your time :-) LeCoyote 11:52, 6 September 2007 (UTC)
Thanks, got it. I will check it during the next days. Thanks, Cacycle 00:06, 7 September 2007 (UTC)
I have fixed the bug, it was in the User:Pilaf/include/instaview.js script. Now you have to figure out why the Ajax preview does not work... Cacycle 22:36, 8 September 2007 (UTC)

AJAX Preview not working as expected

Hey there ! Thanks for the fix in Instaview. About AJAX however, I am confused. The AJAX diff works perfectly ; AJAX preview works but does neither parse templates nor wiki tables, and it does not render images. There is no error message whatsoever. I am about to dig into the code, although I am not exactly sure where to start. LeCoyote 10:57, 11 September 2007 (UTC)
What you see (without template expansion) is the local InstaView preview which is normally replaced by the AJAX server preview that gives exactly the same view as a regular Mediawiki preview. The preview code starts at line 2706 (wikEd 0.9.42) with "// display local preview box". It just fetches a regular preview from the form POST address with an added "&live" to suppress the non-preview part of the served preview page. The diff view is NOT Ajax or server based, it is local. So there is probably a general Ajax problem. Cacycle 02:47, 12 September 2007 (UTC)

"Cacycle 02:47, 12 September 2007 (UTC)

Ok, I'm having a go at debugging the whole thing. First finding : at line 2731, typeof(sajax_init_object) is "undefined", hence the clause is false and the ajax preview is never rendered. Since this is my first dig into Ajax code, I do not know where this sajax_init_object is defined. Does that help you figuring out what is going on ? Thanks again for your time. LeCoyote 10:39, 14 September 2007 (UTC)
Interesting. sajax_init_object is from the Wikipedia http://en.wiki.x.io/skins-1.5/common/ajax.js, but right now I do not see why this check is needed as wikEd brings its own Ajax interface (?). You might be able to remove this check, I will dig into this later. Cacycle 13:18, 14 September 2007 (UTC)
That definitely was the blocking check. It now works as expected. Many thanks ! PS : Added a subtitle for this second issue, to make it more readable. LeCoyote 14:21, 14 September 2007 (UTC)

XHTML 1.1 uncompatible ?

With default meta Content-Type - text/html everything works fine, when i set it to application/xhtml+xml (XHTML standard) wikiEd doesnt show up.

  • wikiEd complete non-offline version, global installation (common.js)
  • MediaWiki 1.10.1
  • Firefox 2.0.0.6
  • Linux 2.6.22.5 (x86_64)

193.93.72.1 23:20, 1 September 2007 (UTC)

What's the point of using content type "application/xhtml+xml"? Cacycle 23:53, 1 September 2007 (UTC)
"XHTML 1.0 became a W3C Recommendation January 26, 2000."
When you are using valid XHTML code with "text/html" content type, browser is parsing it just like normal html page, to use "standards compilance mode" you must use "application/xhtml+xml"
193.93.72.1 10:44, 2 September 2007 (UTC)
I have no idea why it does not work (any error messages?) and I do not see a reason to serve as application/xhtml+xml (which cannot be read by at least half of all browsers) when text/html works fine. Cacycle 14:39, 2 September 2007 (UTC)


Internet Explorer compatibility

Is anyone working on making this application compatible with Internet Explorer? – 01011000 20:02, 3 September 2007 (UTC)

I am not aware of anybody currently working on it. Would you like to? Check wikEd dev and wikEd dev talk. Cacycle 21:56, 3 September 2007 (UTC)
I would if I had the technical expertise but, unfortunately, I do not. – 01011000 23:58, 3 September 2007 (UTC)

Cross-Site Scripting Worries

I really want a better editor for my company's wiki, but turning on JavaScript for all users has me worried. Why do users need to have this ability. If they can run any java script then I am opening my wiki up to all moderatly talented java scripters to do whatever they want (note that I am not a java scripter, so I have only hearsay to go on for what nefarious things can be done with javascript).

Anyway, I was just wondering if there are any plans to make this a bit more secure and not require User or Site wide gifting of Javascript Access.

--Vaccano 22:48, 4 September 2007 (UTC)

If you use a site-wide installation then you have the code under your control and do not have to allow individual monobook.js code via $wgAllowUserJs = true;. I have updated and clarified the respective sections on the wikEd homepage. Cacycle 02:09, 5 September 2007 (UTC)

RegExTypoFix on french wikipedia

Hi, I'm interesting to use RegExTypoFix from Wikipedia:AutoWikiBrowser/Typos on :fr but when I put var wikEdRegExTypoFix = true; in my monobook the button disappear. How can I do to activate RegExTypoFix with fr AutoWikiBrowser/Typos? (Is it possible?) Thanks for this great tool. Leag 18:30, 5 September 2007 (UTC)

How can it disappear, do you see the button without var wikEdRegExTypoFix = true;. Does it work with the English list. Cacycle 13:09, 6 September 2007 (UTC)
Change "Wikip%C3%A9dia" to "Wikipedia". Cacycle 13:17, 6 September 2007 (UTC)

I don't see the button with or without var wikEdRegExTypoFix = true;. Strange !!! I try to desactivate other script in my monobook, there's no way to see the button The probleme doesn't come from the french translation, I try without. I try with the old var wikEdLoadRegExTypoFix = true; but nothing. Maybe a probleme with {{lang|}} template?

Using AutoWikiBrowser/Typos is a tool I need for a long time, I'm "frustrate" Leag 18:09, 6 September 2007 (UTC)

Please check for any JavaScript error messages. It works for me using your monobook.js after removing the "obtenir();" calls and adding "fr:" to the script names. Cacycle 01:25, 7 September 2007 (UTC)

I'm sorry, with only wikEd script in my monobook.js and nothing in monobook.css it didn't work. I can't see the button. Maybe a probleme in common.js on :fr? Leag 11:01, 7 September 2007 (UTC)

Oh, I see it on the French Wikipedia. I'll try to fix it later. Cacycle 13:05, 7 September 2007 (UTC)
Thanks a lot Leag 20:55, 7 September 2007 (UTC)
The rules page address must have the exact same domain name as the used wiki. On the French Wikipedia you have to use the following:
var wikEdRegExTypoFix = true;
var wikEdRegExTypoFixURL = 'http://fr.wiki.x.io/wiki/en:Wikipédia:AutoWikiBrowser/Typos?action=raw';
I have updated the example on the wikEd homepage. Cacycle

I'm sorry again, with only wikEd script in my monobook.js and nothing in monobook.css it didn't work. Leag 11:24, 9 September 2007 (UTC)

No, don't change anything, it's working without :en : 

var wikEdRegExTypoFix = true;
var wikEdRegExTypoFixURL = 'http://fr.wiki.x.io/wiki/Wikipédia:AutoWikiBrowser/Typos?action=raw';

Thanks a lot Leag 11:35, 9 September 2007 (UTC)

Deactivating advanced copy-pasting as an option

Is that something that can reasonably be done? It's extremely frustrating to have to deal with the extra whitespace (ca. 5 linebreaks) generated by any copy-pasted preformatted template code, or the headers, or text from a webpage... Circeus 19:24, 13 September 2007 (UTC)

Sorry, that's not possible without disabling wikEd - but you can use the Fix basic button to remove not necessary empty lines and white space. Cacycle 20:39, 13 September 2007 (UTC)
No thank you. Always end up adding allsort of whitespace in unexpected places. Circeus 14:26, 23 September 2007 (UTC)
When do you see those empty lines after copy-pasting - immediately or after using the Wikify button. Also, please let me know if the button adds spaces in the wrong places. Thanks, Cacycle 02:38, 24 September 2007 (UTC)

Getting strange hint on using the preview-button after updating to mediawiki 1.11.0

Hi, I'm using the WikEd Version 0.9.42. I installed it on my previous installed mediawiki which was 1.9.x. Today I upgradet to mediwiki 1.11.0 and now I receive a message saying "Deine Bearbeitung konnte nicht gespeichert werden, da deine Sitzungsdaten verloren gegangen sind.

Da in diesem Wiki reines HTML aktiviert ist, wurde die Vorschau ausgeblendet um JavaScript Attacken vorzubeugen. Bitte versuche es erneut. Sollte das Problem bestehen bleiben, melden dich ab und wieder an." when I want to use the preview-button of WikEd. What does this mean?

I'm using Firefox 2.0.0.6. and I don't have any errors on my Error-Console.

The extension is setup as serverwide setup, so I did change the Common.js. The mediawiki is runnin on SUSE 10.

Thanks, Dieter —Preceding unsigned comment added by 212.202.50.73 (talk) 18:42, 14 September 2007 (UTC)

It is the German text of the session_fail_preview message, it might be caused by waiting too long before submitting an article text. There might also be a Mediawiki setting that could be adjusted for longer timeouts. Cacycle 01:49, 15 September 2007 (UTC)

Bugs in MSWord doc handling

Hi Cacycle,

I've been using WikEd to convert doc files to wikicode lately. (Current WikEd (0.9.43), Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6, WinXP, MS Office Word 2003.)

While the wikifying function is a huge help, there are a few glitches:

  • when there are line breaks in a bold or italic text, it won't close and reopen the wikitags, and will end up with something like this:
'''boldboldbold

boldbold'''plainplainplain

which will result in

boldboldbold
boldboldplainplainplain

thus often turning large paragraphs to bold/italic instead of the first sentence.

  • ordered lists are sometimes misidentified as unordered (I'll create a test case when I have the time)
  • it would be more practical to prefix image names (currently Image:Clip image###)with the document title so that images in different documents get different names
    It now shows the original image name (but the file type seems to be always .png) in wikEd 0.9.46. Сасусlе 02:06, 14 October 2007 (UTC)
  • it doesn't recognize footnotes. This regexp finds the first reference and the matching footnote in the rich text html:
var reFootnote = new RegExp('<a[^>]* href="#_ftn(\\d+)"[^>]*>\\s*<span class="MsoFootnoteReference">[\\s\\S]*?</span>\\s*</a>([\\s\\S]*?)<div[^>]* id="ftn\\1"[^>]*>\\s*<p class="MsoFootnoteText">\\s*<a[\\s\\S]*?</a>([\\s\\S]*?)</p>\\s*</div>', "");
  • Footnote import added to wikEd 0.9.46. Сасусlе 02:06, 14 October 2007 (UTC)
  • (this one is unrelated to wikifying) when in syntax highlight mode, deleting '' or ''' (italic/bold)from the end of a line will reposition the cursor to the end of the text.

--Tgr 02:04, 22 September 2007 (UTC)

  • sometimes empty pairs of italic tags (like <i></i>) often left in the HTML by Word are not cleaned up and result in code like '''' (which in turn gets interpreted by the parser as an apostrophe plus a bold tag).
  • table wikicode doesn't alway start at the beginning of the line (specifically when the table is centered in Word, the table in wikicode will be surrounded by a div with align=center, and there is no linebreak between the div and the {|

--Tgr 14:07, 23 September 2007 (UTC)

  • when using the regular edit toolbar buttons, WikEdInsertTags doesn't highlight the sample text like the standard insertTags does. The highlighting can very convenient as "click button-paste text" is much faster than "click button-highight sample text between tags-paste text" or "paste text-find and highlight it-click button".

--Tgr 13:56, 24 September 2007 (UTC)

Thanks for these detailed reports, I will try to fix it as soon as I find the time :-) Cacycle 04:32, 25 September 2007 (UTC)
Footnote import and correct image namesadded to wikEd 0.9.46. Сасусlе 02:06, 14 October 2007 (UTC)

Document customizable parameters?

The section on "Customization" does a great job of teaching how to set variables to customize the behavior of wikEd. I'd like to suggest that someone add or point to a comprehensive list of the variables that can currently be set.

Here's the specific question I was looking to answer: how can I customize the conversion of a rich-text table to wikitext? Currently the first line of the converted wiki text is: 

{| cellspacing="0" cellpadding="0" border="1"

and I want it to be: 

{| class="myclass"

Thanks a million, Cacycle, for this great contribution.
Tom.ngo 13:26, 22 September 2007 (UTC)

That's not yet possible, but I will add it for you in the upcoming release. You can already add this to your monobook.js:
var wikEdWikifyTableParameters = 'class="myclass"';
Cacycle 18:35, 22 September 2007 (UTC)
Has been implemented in 0.9.44. Cacycle 04:33, 25 September 2007 (UTC)

WikEd version 0.9.44 prevents Mediawiki from loading in IE7 (moved from top)

I see a new version of WikEd was released on September 23rd. As of September 23rd, none of our workstations with IE7 and Windows XP can load mediawiki at all (before, we could load mediawiki in IE7 but just couldn't use WikEd).

I have WikEd installed via site installation in MediaWiki:Common.js.

When I try to load my main page with IE, I get error "Internet Explorer cannot open the Internet site http://blah.blah/index.php/Main_Page. Operation aborted." Then I get an IE error page. When I load the page in Firefox it works fine.

In IE there is also a Javascript error icon. If I click it, it says "Line 1179, Character 3, Object doesn't support this property or method, code 0". This error is referring to the javascript that had WikEd in it.

If I take WikEd out of the mediawiki:common.js, the problem does not happen.

--Jesses55 18:11, 24 September 2007 (UTC)

I'd like to confirm that we see this issue as well. Had to remove the WikEd code from my monobook.js page to load anything in IE6.
--Cedarrapidsboy 18:18, 24 September 2007 (UTC)
Perhaps someone else can confirm this code prevents IE from loading WikEd
// install [[User:Cacycle/wikEd]] in-browser text editor
// convert all characters to lowercase to simplify testing
var agt=navigator.userAgent.toLowerCase();
// *** BROWSER VERSION ***
// Note: On IE5, these return 4, so use is_ie5up to detect IE5.
var is_major = parseInt(navigator.appVersion);
var is_minor = parseFloat(navigator.appVersion);
var is_ie     = ((agt.indexOf("msie") != -1) && (agt.indexOf("opera") == -1));

if (!is_ie) {
document.write('<script type="text/javascript" src="'
+ 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js'
+ '&action=raw&ctype=text/javascript"></' + 'script>');
}
Seems to work for me after clearing my cookies, history, etc and doing a Shift-F5. Above code stolen from here
--Cedarrapidsboy 18:30, 24 September 2007 (UTC)

I am sorry for this, I will fix this today. I have already removed the javascript bugs, Shift-Reload to update to 0.9.44a. Cacycle 18:37, 24 September 2007 (UTC)

Thanks for your work. This situation brings up an interesting issue. Your tool, WikEd, has become popular and has actually infiltrated large corporations. More [people] than just the wiki enthusiasts are using your code to edit wiki articles in all kinds if wiki sites, personal to corporate sensitive. How would you suggest "customers" that are adverse to WikEd changes utilize your work? Is there an option other than the no-internet-connection installation option?
--Cedarrapidsboy 18:48, 24 September 2007 (UTC)
It's fixed in 0.9.44b, please update (IE: Ctrl-F5/Ctrl-Reload). Cacycle 18:52, 24 September 2007 (UTC)
Cedarrapidsboy: wikEd can now be installed locally as a Greasemonkey script, check the wikEd homepage for details. Cacycle 19:16, 24 September 2007 (UTC)

--Jesses55 22:43, 26 September 2007 (UTC) : I've reloaded my browser, now getting version 0.9.44f. I can verify that the problem is fixed, I can load mediawiki with IE7 and there are no errors. Thanks for the quick fix!

JS script loop when editing a page with incorrect image link

  • version : .9.44f
  • browser id : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
  • Error console errors : nothing
  • Which browser add-ons have you installed DOM Inspector
  • Optional: What happens if you disable your add-ons and restart the browser : same error
  • Which user scripts have you installed on your monobook.js page : Only wikEd
  • Which operating system : Win XP sp2
  • Describe the problem : Script loop when trying to edit a page that contain an image not properly embedded and with the Highlight syntax turned on
  • Steps to reproduce :
  • Save a page with an embedded image with parameter without closing brackets ex.: "[[image:torch|30px"
  • Try to edit the page with wikEd enabled while the syntax highlighting is turned on
  • What exactly happens if you follow these steps :
The script will loop trying to generate a color for the image but it stay stuck. When you get the message from Firefox chose stop script. Then you can go to a different page, disable the wikiEd (or syntax highlighting) and edit the faulty page to correct the image link. Alternatively; you can check the history for that page and restore the last version that had no image link without the closing brackets

Chris 14:40, 27 September 2007 (UTC)

Thanks, I'll try to fix this later today. Cacycle 19:24, 27 September 2007 (UTC)

Hi Cacycle, I forgot to add that it only does that when there are parameters with he image like # of pixels or center.
Also, I really enjoy working with your editor. Before that I used to create macro in WORD that convert tables and links but having it done witin the wiki is way better. —Preceding unsigned comment added by 206.47.249.251 (talk) 20:32, 27 September 2007 (UTC)

This is actually a tricky one.... I need more time... Cacycle 12:18, 2 October 2007 (UTC)

Text written after turning wiked off gets lost

0.9.44f, Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Steps to reproduce:

  • enable wikEd
  • edit a page
  • disable wikEd by clicking on the icon in the upper right corner
  • add a new paragraph to the text
  • save page

The text you've just added will not appear (it disappears from the textbox the moment you click on save). --Tgr 09:38, 3 October 2007 (UTC)

Fixed in 0.9.45b. Thanks, Cacycle 03:44, 8 October 2007 (UTC)

Bug/Enhancement - Know when to write # instead of *

If I do these steps:

  1. Write a list in Word with a numbered style
  2. Copy and paste into wikEd
  3. Convert pasted content to wiki code

I expect the result to be 

# Blah
# Blah
# Blah

not 

* Blah
* Blah
* Blah

Does the clipboard contain enough information to distinguish between the two? If not, what is the intended mechanism to cause the result to be numbered with # marks?

Tom.ngo 20:34, 3 October 2007 (UTC)

It seems to be a Word issue. When I start a new document and directly format a paragraph as a numbered list it produces the expected '#'-list (i.e. Word uses the <ol> tag) but sometimes it does not. Cacycle 21:35, 6 October 2007 (UTC)

Cosmetic issue when disabling

I've just found a minor issue that appears when disabling wikEd in Firefox 2.0.0.7 on Windows XP. It appears that if you're on an edit page and you disable wikEd, it leaves div#wikEdButtonsWrapper in the document, creating a rather unsightly gap between the toolbar and the edit box. Just a minor thing.

Disabling wikEd does not undo the DOM changes it made to the page. But I will try to make the gap smaller as soon as I find the time. Cacycle 12:14, 9 October 2007 (UTC)
No rush on this, just thought it looked odd. Maybe styling that div to display:none when disabling wikEd would work, and showing it on re-enable. I think it can be done with about two lines of code, but I don't know the underlying structure of the enable/disable mechanism, so I can't say for sure. Tuvok[T@lk/Improve me] 04:52, 10 October 2007 (UTC)

I did, though, find problems with my settings in the latest version of wikEd. For some reason, they were causing all kinds of errors; commenting them out in my monobook.js made wikEd work, albeit without my preset changes. I'll be debugging and adding prefs back one at a time, and I'll post back if and when I find one that I was using that causes a problem. Thanks for the great tool! Tuvok[T@lk/Improve me] 06:21, 7 October 2007 (UTC)

Issue has been fixed with version 0.9.45 Сасусlе 16:53, 27 October 2007 (UTC)

Aha! Found a couple problem options

I just found that setting var wikEdHighlightSyntaxPreset causes a loading error. The error console shows: 

Error: wikEdFindAheadSelected is not defined
Source file: http://en.wiki.x.io/w/index.php?title=User%3ACacycle%2FwikEd.js&action=raw&ctype=text/javascript
Line: 1771

I don't know why a variable is suddenly undefined, though.

I have fixed this in the upcoming release. Cacycle 16:24, 7 October 2007 (UTC)

I think setting wikEdUseWikEdPreset to false also messes things up; the only buttons that appear are the leftmost box with the toggles for the options with that option set to false.

Also fixed in the upcoming release. Cacycle 16:24, 7 October 2007 (UTC)

Lastly, what happened to the improved diff view on diff pages? I can't seem to get the button. Tuvok[T@lk/Improve me] 06:46, 7 October 2007 (UTC)

Everything fixed in the current version 0.9.45 (for the diff you might have to open and shift-reload this). Thanks for notifying me! Cacycle 03:06, 8 October 2007 (UTC)
Thanks for the quick attention. At first test, though, after a thorough Shift+Reload session, the above bug with wikEdUseWikEdPreset is still present. On the plus side, setting the syntax highlighting preset seems to work, and the improved diff view works again. Using wikEd 0.9.45c. Tuvok[T@lk/Improve me] 06:14, 8 October 2007 (UTC)
For me, adding " var wikEdUseWikEdPreset = false;" and "var wikEdUseWikEdPreset = true;" to my monobook.js works fine. It sets the Use wikEd button so that you start either with the wikEd or the classic text field (and the other editing button bars disabled). Cacycle 04:09, 9 October 2007 (UTC)
Must be me misinterpreting the setting's purpose. Is there a config variable that can set wikEd usage off by default on computers I haven't used before, so I can enable it only if I'm confident the machine is fast enough to handle it well? Tuvok[T@lk/Improve me] 05:37, 9 October 2007 (UTC)
Not yet. Cacycle 11:59, 9 October 2007 (UTC)

Why do the cleanup buttons (fix spacing, etc.) add a paragraph break after section headers?

In other words, if an article contains 

==Section A==
Body text body text

wikEd will edit it to 

==Section A==

Body text body text

The great majority of articles are formatted the first way. (I could lodge the same complaint regarding wikEd's adding a space between a bullet point and its text, but usage seems to be more evenly split there.) --zenohockey 05:22, 8 October 2007 (UTC)

wikEd follows the Wikipedia:Styleguide and Wikipedia:Help examples. Whitespaces and empty lines massively increase the readability and make navigation through the text easier, especially in long articles. That the software does not necessarily require these optical aids should not be an excuse for a sloppy editing style. Cacycle 13:13, 8 October 2007 (UTC)
But we should only do stuff like fix spacing as part of a larger edit in order to avoid cluttering up the history, right? Pyrospirit (talk · contribs) 20:52, 8 October 2007 (UTC)
Yep, that's the guideline. Cacycle 12:00, 9 October 2007 (UTC)
8300+ edits and 38 months later...I learn this. To be fair, Today's Featured Article has no spaces, so perhaps you see my original point. But if it's recommended, then I have no complaints. --zenohockey 04:56, 11 October 2007 (UTC)

HTML break tags wrongly removed from infobox

Before clicking the "Fix basic, html, capitalization, and Unicode" button: 

<!--{{Infobox Film
 | image =Wristcutter poster.jpg
 | name           = Wristcutters: A Love Story
 | director       = [[Goran Dukic]]
 | producer       = Tatiana Kelly<br>Mikal P.Lazarev<br>Chris Coen<br>Adam Sherman
 | writer         = Goran Dukic<br>[[Etgar Keret]]
 | starring       = [[Patrick Fugit]]<br>[[Shannyn Sossamon]]<br>[[Tom Waits]]<br>Shea Whigham<br>[[Will Arnett]]
 | music          = [[Bobby Johnston]]
 | cinematography = Vanja Cernjul
 | editing        = Jonathan Alberts
 | distributor    = Autonomous Films
 | released       = Octover 19, 2007
 | runtime        = 91 min
 | country        = [[Image:Flag of the United States.svg|22px|USA]]USA
 | language       = English
 | website        = http://www.wristcutters.com|www.wristcutters.com
 | imdb_id        = 0477139
 }} -->

Rendered:

After: 

<!-- {{Infobox Film
 | image =Wristcutter poster.jpg
 | name = Wristcutters: A Love Story
 | director = [[Goran Dukic]]
 | producer = Tatiana Kelly
 Mikal P.Lazarev
 Chris Coen
 Adam Sherman
 | writer = Goran Dukic
 [[Etgar Keret]]
 | starring = [[Patrick Fugit]]
 [[Shannyn Sossamon]]
 [[Tom Waits]]
 Shea Whigham
 [[Will Arnett]]
 | music = [[Bobby Johnston]]
 | cinematography = Vanja Cernjul
 | editing = Jonathan Alberts
 | distributor = Autonomous Films
 | released = Octover 19, 2007
 | runtime = 91 min
 | country = [[Image:Flag of the United States.svg|22px|USA]]USA
 | language = English
 | website = http://www.wristcutters.com|www.wristcutters.com
| imdb_id = 0477139
 }} -->

Rendered: }}

See the problem? --zenohockey 23:21, 12 October 2007 (UTC)

Simply do not use it on arbitrary text without checking the results - that is also what the wikEd manual says. Cacycle 01:08, 13 October 2007 (UTC)

Opt-in

Is there a way to make a site-wide installation opt-in instead of opt-out so that when no cookie is found it sets wikEdDisabled to true? --Tgr 13:34, 14 October 2007 (UTC)

I have added it to wikEd 0.9.46b, please use var wikEdDisabledPreset = true; for this. Сасусlе 04:23, 15 October 2007 (UTC)

Bug: Cursor location after paste

Steps:

  1. Paste content into an existing wikEd page in such a way that the end of the pasted content is not visible in the edit box.
  2. Press Up arrow (or Down) arrow.
  3. Cursor goes all the way to top (or bottom) of edit box.

Tom.ngo 19:42, 26 October 2007 (UTC)

This is an annoying Mozilla bug - sorry, I cannot do anything about it. Сасусlе 16:49, 27 October 2007 (UTC)

wikEdDiff not working

When I attempt to view the improved diff on comparison pages, it loads the box with "..." in it and just never does anything. This happens when automatic improved diff view is both on and off. I have cleared my browser cache, and force-reloaded the wikEdDiff.js script, to no avail. Is this a bug? Tuvok[T@lk/Improve me] 05:07, 28 October 2007 (UTC)

Oops, I have currently no idea what causes this. As a quick fix until I figure this out you can add this to your monobook.js:
// install [[User:Cacycle/diff]]
document.write('<script type="text/javascript" src="'
+ 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/diff.js'
+ '&action=raw&ctype=text/javascript&dontcountme=s"></script>');
Сасусlе 05:53, 28 October 2007 (UTC)
It is an interference with a very recent MediaWiki workaround [2], a bug report has been filed [3]. Сасусlе 15:59, 28 October 2007 (UTC)
Hmm, it's now working? (I never actually got around to installing the fix...) Odd behavior given your description of the problem... I'll keep an eye on it both here and on Bugzilla. Thanks for investigating! Tuvok[T@lk/Improve me] 02:57, 29 October 2007 (UTC)
I have actually added a small workaround :-) This does not render the bug request obsolete as this might become a problem on non-Wikipedia wikis, especially those on intranets. Сасусlе 04:19, 29 October 2007 (UTC)
Hmm, non-Wikipedia... Like the one I have now on my computer for testing? :-) That's good to hear; we'll see how far bug 11797 gets, and what is changed in upcoming software revisions. I can't test too easily right now; running SVN updates isn't something I particularly want to do. I already know the Live Preview feature (experimental, unfortunately) has a fix coming up in 1.12, as I reported in bug 11438. Another Gecko-only problem, I believe. I'm looking forward to trying out 1.12 on my own install... Hopefully, this bug will be a smudge on the windshield by then. Tuvok[T@lk/Improve me] 06:10, 29 October 2007 (UTC)

Site Wide Usage

I note that you have a long list of satisfied individual users, but I'm wondering if you have or can post a similar list of sites with site wide implementation of WikEd and, more to my point of interest, if so, what has been their experience? Are they getting more newbies to post than before? Etc. Natcolley 20:16, 29 October 2007 (UTC)

I would be very interested in hearing about the experience users and site admins have with wikEd. I would also like to have an idea on how many non-Wikipedia and non-Internet sites it is used. During wikEd development I actually have more the experienced users in mind, not the beginners. Feel free tostart a survey-section or article :-) Сасусlе 04:26, 5 November 2007 (UTC)

Very small wikEdDiff problem

This is just a little problem with the wikEdDiff script. Currently, it leaves the "..." displayed while calculating the diff in the diff itself at the end of the first line. wikEd 0.9.48c Tuvok[T@lk/Improve me] 20:11, 1 November 2007 (UTC)

It seems to be gone after an unrelated change to wikEdDiff.js. Please notify me if you still see it after cache flushing. Сасусlе 06:11, 4 November 2007 (UTC)
Appears to be gone in wikEdDiff.js version 0.9.4f. Great! Tuvok[T@lk/Improve me] 07:42, 4 November 2007 (UTC)

Formating and other feedback

I'm using Firefox in Linux, and for me:

  • formating from pasted text is lost on save or preview. Obviously I'm not running Word, but I've copied from Firefox, and OpenOffice 2.2, with no formating saved/converted at all.
That's because you have to press the Wikifyikify button to convert, otherwise it intentionally removes all formatting, please see the quick tutorial for a short overview.
  • pastes are messy. Paste stuff in and it adds line breaks,
Only if you paste headings. It is a logical (though sometimes inconvenient) result from pasting formatted text.
  • cursor doesn't act as expected in keyboard navigation, sometimes with mouse to. (e.g. click mouse below end of doc, cursor stays at beginning).
That is caused by Firefox bugs which have been reported a long time ago. Sorry, it's nothing I can change.
  • keyboard shortcuts:
    • if switching tabs in firefox, and come back to the edit page, you must use mouse to click in edit box. even if the edit box was in focus when you left the tab.
That might be a new Firefox for Linux bug that should be reported (http://bugzilla.mozilla.org). It works fine under Windows.
    • can't back-tab from comment box to edit box.
Will check that.

Sorry I can't be more positive. I do like the concept, and the color coded text, and some of the buttons are useful. --Chriswaterguy talk 18:38, 3 November 2007 (UTC)

Thanks for your comments. wikEd relies on the browser-internal rich-text editors. This causes some of the observed inconveniences, please check the Known general issues on the wikEd homepage for more details. Сасусlе 00:14, 4 November 2007 (UTC)
Sorry for not responding till now - I appreciate the explanations, and now I see how the the Wikifyikify button works, this will be an extremly useful tool for some of the work I want to do in Appropedia, importing large amounts of material (with permission fo course) from non-wiki content. --60.242.31.42 (talk) 12:34, 20 December 2007 (UTC)

Fix html to wikicode - upper case does not work

I tried to convert the table in this article to wikicode using the "Fix html to wikicode" button but I couldn't. When I converted the HTML elements to lower case, like this, it worked.

It appears that this (<B>this</B>) is not converted properly (wikEd just strips the tags), while this (<b>this</b>) works fine (wikEd applies ''', as expected). A bug?

Great tool, by the way. I do minor edits mostly and I feel I'm 100% more productive with it. GregorB 01:54, 4 November 2007 (UTC)

Added uppercase-html support to 0.9.49. Сасусlе 06:10, 4 November 2007 (UTC)

Possible to hide MW diffs?

I'm back with more suggestions for the wikEdDiff script. :D I find it mildly annoying to have to scroll past the MediaWiki-generated diff to get wikEd's improved view. Is it possible to make the script hide the MW diff, perhaps only if certain options are set (like automatic improved diff)? The diff table doesn't have an ID (perhaps that should be entered as a bug), but it is identified as table.diff for CSS. AFAIK, there's no easy way to select an element by class name, so the best option is probably to request it get its own ID at Bugzilla so it can be hidden. That is, if you want to work on this; it's purely convenience for Improved Diff View users. Tuvok[T@lk/Improve me] 07:48, 4 November 2007 (UTC)

The wikEdDiff diff algorithm has a few bugs (e.g. changes at the beginning of a text) and shortcomings (mostly related to moved blocks), so it is a good idea to have the standard table as a fall back. It is not really a big problem to get the table node by using JavaScript (get all tables, check them for class='diff'). Сасусlе 04:02, 5 November 2007 (UTC)

Annoyance after clicking wikEd Preview or Show Diff buttons

When clicking the Preview or Show Diff buttons wikEd generates, the browser (for me FF 2.0.0.9, WinXP Pro Tablet Ed.) display pops back up to the wikEd toolbar. Would it not be better for it to emulate the action of "Scroll to preview field"? Tiny idea... Tuvok[T@lk/Improve me] 07:51, 4 November 2007 (UTC)

Fixed in 0.9.54 with an intelligent scrolling mechanism. Сасусlе 05:02, 23 November 2007 (UTC)

Symbol insertion?

I'm sorry if this has been addressed before, but I couldn't find it.

Since I started using wikEd a few days ago, I can't use any of the special symbols under the edit box (the dashes, math symbols, Wiki markup, letters with accents, etc.) If I click on any of them, the browser focus shifts from the edit box to the top of the page (and the symbol isn't inserted).

I'm running v. 0.9.49 GM on Firefox 2.0.0.9. I've disabled all my other Greasemonkey scripts. Any thoughts? — Malik Shabazz (Talk | contribs) 09:15, 4 November 2007 (UTC)

Thanks for reporting this. It is caused by the security model of Greasemonkey and there is no easy way to fix this. I will try to find a workaround when I find the time. Сасусlе 03:41, 16 November 2007 (UTC)
Thanks. Since WP is the only Wiki I edit on a regular basis, I've disabled the Greasemonkey script and installed wikEd through my monobook.js page. — Malik Shabazz (talk · contribs) 07:32, 16 November 2007 (UTC)

WikEd makes Firefox freeze on a specific article

Problem
When attempting to edit Wiglaf of Mercia, Firefox 2.0.0.9 (effects on other versions unknown) systematically freezes, requiring the program to be forcefully shut down. The freeze occurs, as far as I can tell (I never have the time to scroll), as soon as the full page is loaded. No other article, similar or not (I tested Penda of Mercia and , seem to cause this behavior. I had never edited this article before. Deactivating Wiked via the on-screen icon before clicking "edit" did not trigger the bug.
I have "preview on first edit" enabled, but haven't tested whether that affected the outcome. I had also previously blocked the MediaWiki banner completely via Adblock and my monobook.css.
My (although I am rather incompetent) hypothesis is that some of the more off-the-wall spelling in the article interacts in some fashion with the script.
WikEd version
0.9.49
Browser id
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
console error
"redeclaration of const kSaveAsType_Complete"
No idea what that means, but I think it has to do with my recent toying with the program sued to open .zip files
add-ons
While I doubt it is relevant (given only this article is affected):
  • AdBlock
  • dictionaries for spellcheck
  • ColorZilla
  • Document Map
  • Fast Video Download
  • FireFTP
  • PDF download
  • ReminderFox
  • Session Manager
  • Tabbrowser Preferences
  • Talkback
  • Web Develloper
  • Zotero
Extension disabling
Disabling the extensions did not prevent the bug.
User Script
I tested and the error occurs even if WikEd is the only script active.
Operating System
Windows XP —Preceding unsigned comment added by Circeus (talk • contribs) 22:57, 4 November 2007 (UTC)
I can confirm this to be an issue: for me, Firefox freezes for a while, and then I get the "a script on this page may be busy" message. I noticed it before on some articles; not sure what triggers it. GregorB 23:51, 4 November 2007 (UTC)
Do you remember the articles? Maybe we can spot a pattern. Circeus 23:52, 4 November 2007 (UTC)
No, but I've just found out this: it gets stuck on the image in the "First reign and defeat by Wessex" section. Interesting. GregorB 00:05, 5 November 2007 (UTC)
Do you mean the HTML or the wikicode? I can more or less see [[Anglo-Saxon Chronicle#Surviving manuscripts|[C] manuscript]]causing problems... Circeus 00:39, 5 November 2007 (UTC)
In fact, this "[C]" appears to be the culprit. Once square brackets around "C" are removed, it works. And wrapping it in <nowiki></nowiki> doesn't help. GregorB 01:21, 5 November 2007 (UTC)
This is probably the same problem as User_talk:Cacycle/wikEd#JS_script_loop_when_editing_a_page_with_incorrect_image_link. This is a really tricky problem and I still do not have a good solution for it. It is caused by multiple nested layers of links in image tags and it is nearly impossible to solve this by using regular expressions. Сасусlе 04:11, 5 November 2007 (UTC)
Okay,In the meantime, I'll replace that with character entities. Circeus 12:50, 5 November 2007 (UTC)
I've taken a look at the code, and it is indeed a very hairy problem. I'm not sure that even Perl-grade regular expressions would cut it, and actually parsing the link would probably be an overkill. GregorB 22:11, 8 November 2007 (UTC)
Fixed in 0.9.53. Image tags with nested links are not always highlighted correctly, but this is definitely better than freezing. Сасусlе 02:05, 18 November 2007 (UTC)

Fix html to wikicode - a minor issue

"Fix html to wikicode" strips <syntaxhighlight lang=""> and <poem> elements, but I guess it shouldn't - these are legitimate wiki tags, not "legacy HTML". GregorB 23:44, 4 November 2007 (UTC)

Fixed in next release (0.9.50). Сасусlе 04:18, 5 November 2007 (UTC)

Untouchable number

WikEd inserts some extra text before the last interwiki link (sl:). It appears that wikEd attempts to make the link control-clickable, but fails because of the HTML character entity. GregorB 22:09, 8 November 2007 (UTC)

This edit was obviously triggered by the same issue (see the "248" section), although character entities were not involved... GregorB 14:33, 9 November 2007 (UTC)
Thanks, I am already working on it, it is somehow caused by the #. Сасусlе 17:10, 9 November 2007 (UTC)
Fixed in 0.9.52, it was related to Unicode hexadecimal character entity highlighting. Сасусlе 05:49, 17 November 2007 (UTC)

Support for other skins

I'm using the GuMax skin on our internal company Wiki, and unfortunately the wikED script doesn't detect the buttons and the elements, I know it's installed correctly because when I use the Monobook skin, it shows up as it should, but I can't seem to get it to do so... any assistance you might be able to lend would be most appreciated! --Kyrin\talk 22:52, 9 November 2007 (UTC)

I will add GuMax support fto the next release. Сасусlе 13:47, 12 November 2007 (UTC)
Thanks much, I was thrilled to find wikED, as a tool to make editing easier for my office users will help encourage them to contribute, which of course is my ultimate goal. --Kyrin\talk 22:30, 12 November 2007 (UTC)
Added to current version 0.9.51. Сасусlе 03:37, 16 November 2007 (UTC)
Works like a charm, thanks again! --Kyrin\talk 00:38, 17 November 2007 (UTC)

Support for Iceweasl on Debian

Debian was forced to call its firefox as Iceweasl, but it is still firefox. Could the browser checking part include Iceweasel?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.6+2.0.0.8-0etch1) --Yichun (talk) 07:51, 17 November 2007 (UTC)

Fixed in 0.9.53, I have also added the future name IceCat. Сасусlе
Thanks very much! Yichun (talk) 04:18, 19 November 2007 (UTC)

Site-wide installation extension

I tried to install the "Site-wide installation extension" and used the following code---

"// install User:Cacycle/wikEd in-browser text editor document.write('<script type="text/javascript" src="' + 'http://en.wiki.x.io/w/index.php?title=User:Cacycle/wikEd.js' + '&action=raw&ctype=text/javascript"></' + 'script>');"

This doesn't seem to work with my mediwiki personalised skin.... can you please help me? —Preceding unsigned comment added by Gbozz (talk • contribs) 11:12, 19 November 2007 (UTC)

Which skin do you use. Does it work for regular, not side wide, installation or if you switch the skin. Сасусlе 13:37, 19 November 2007 (UTC)
wikEd requires certain div elements (i.e. it will not work without them). wikEd also detects MediaWiki pages using fingerprints of common skins. Can I please have a link to your wiki so that I can check its page source to decide what's going on. Thanks, Сасусlе 21:42, 19 November 2007 (UTC)


In our present mediawiki site, we have removed the old monobook.php file which is the default file you have when installing mediawiki and have uploaded a new monobook.php file with table format instead of div.Our wiki link is-http://wiki.galbijim.com/ —Preceding unsigned comment added by Gbozz (talk • contribs) 09:42, 20 November 2007 (UTC)

Sorry, your skin is incompatible with wikEd, it misses all important div's that wikEd needs to install itself. Сасусlе 03:07, 22 November 2007 (UTC)

Suggestion

Hi ! First, thank you for this tools. I'm french and I wonder if it could be possible to allow some settings about the icon which remove space before punctuation, which is contrary to the rules of French typography (should also be able to insert it in the contrary).Manu 82.241.241.212 (talk) 18:28, 21 November 2007 (UTC)

I have added it to the upcoming version, simply add wikEdFixPunctSpace = ' '; to your monobook.js and/or to the French translation. Сасусlе 03:17, 22 November 2007 (UTC)
Added to current version 0.9.54, please could you test it. Thanks, Сасусlе 05:03, 23 November 2007 (UTC)

Hi, is it possible to make wikEd not adding empty line between the categories on fr? Thanks Leag (talk) 14:28, 23 November 2007 (UTC)

Please could you give me an example, I cannot reproduce the insertion of empty lines between categories using the Fix all or the Fix punctuation button.
On fr, we don't insert empty lines between the categories :

[[category:game]]
[[category:card]]

I'd like to know if it's possible wikEd doesn't insert empty lines like that on fr :

[[category:game]]

[[category:card]]

Thanks Leag (talk) 10:08, 24 November 2007 (UTC)

For me it doe not insert empty lines, it actually removes them. Please could you give me detailed instructons to replicate your problem. Thanks, Сасусlе 18:12, 24 November 2007 (UTC)

WikEd break "new section" editing

When using the "+" (new section) tab, WikEd gives the following errors:

Operator: Required property dtstart not specified -- wikEd (line 2210)
Operator: Required property dtstart not specified -- wikEd (line 2311)

and the editbox is readonly.

(WikEd 0.9.55 run from monobook.js, FF 2.0.0.9/WinXP)

--Tgr (talk) 00:39, 26 November 2007 (UTC)

I cannot reproduce this, please could you give me more details, e.g. the monobook.js page you are using and your browser extensions (hCalendar?). wikEd does not use anything like dtstart nor is there anything suspicious at the given line numbers. Thanks, Сасусlе 02:08, 26 November 2007 (UTC)
I cannot reproduce it on hu with your monobook.js. Сасусlе 02:14, 26 November 2007 (UTC)
OK, I noticed that you cannot edit the field, give me some time to check into this :-) Сасусlе 13:52, 26 November 2007 (UTC)
I have the same problem... Regards. JSDX from Wiki FR. —Preceding unsigned comment added by 83.203.226.63 (talk) 14:31, 26 November 2007 (UTC)
Same here. Circeus (talk) 19:30, 26 November 2007 (UTC)

I use the operator extension, which recignizes hCalendars, but several people reported this bug on huwiki, and I'm pretty sure they don't use it. (I don't know the exact error message they got, though.) Also, AFAIK there shouldn't be any hCalendar on the new section page. --Tgr (talk) 22:28, 26 November 2007 (UTC)

Fixed in 0.9.55a. Сасусlе 01:43, 27 November 2007 (UTC)

wikiEd uses cookie to store editing summary field values, to show then later when saving articles (in dropdown). Problem is when you type your summaries in russian. Every character is encoded as hex code and 3 symbols are used to store 1 character. When maximal cookie length is reached, then any attempt to access wiki (when cookies are sent by browser) fails with blank screen. Problem happens in Firefox, maybe in IE too. I've noticed that, when my MediaWiki:Common.css file stopped working on index page :(.

I do not think that you can reach the maximal single cookie length with wikEd and if cookie space is low then the browser kicks out old and unused ones as far as I know. Maybe your problems are caused by something else. Сасусlе 13:51, 26 November 2007 (UTC)
Any ideas how to fix this?

For now I've cleaned my cookies, and all seems to work again.

--Aik099 (talk) 12:20, 26 November 2007 (UTC)

No, but please report back if it happens again, especially if you can give me instructions on how to reproduce your problem. Сасусlе 23:55, 28 November 2007 (UTC)

Browser not supported? But it's the main supported browser!

I am using WikEd version 0.9.55a and my browser info is: 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.10) Gecko/20071115 Firefox/2.0.0.10

In other words, Firefox 2.0.0.10. When I load the page, the following errors come up in the error console: 

1. CSS Properties Dropped - 'column-count' , '-webkit-column-count' , 'word-wrap' , 'white-space'
2. wot_search.onload: matched wikipedia

Does not seem like much. Here are the add-ons installed on Firefox: 

Greasemonkey 0.7.20070607.0, KeyScrambler 1.3.2, Message Level Authentication 0.7.7, PhishTank SiteChecker 4.2,
RealPlayer Browser Record Plugin 1.0, ReloadEvery 2.0, SafeDownload 1.0, Skype extension for Firefox 2.2.0.70, Talkback 2.0.0.10,
Toodledo 1.43, Total Validator 4.4, TrendProtect 1.0, Update Notifier 0.1.5.3, VeriSign EV Green Bar Extension 1.0.1.2898,
WebDeveloper 1.1.4, Wizz RSS News Reader 2.1.9.7, Work Offline 1.3, WOT 20070501, and Zipedia 0.3

When I disable all of the add-ons except for GreaseMonkey (because that is where WikEd is insalled), it still does not work. The list of scripts in my monobook.js file are as follows (I do use Monobook): 

Twinkle, WikEd, Lupin's anti-vandal tools, Lupin's pop-ups, User:AndyZ/peerreviewer.js, Watchlist sorter,
Edit link on Intro, Adding Purge Button Next to Edit button on top of page, and Interiot's javascript edit counter.

As a final piece of system info, here is everything you might possibly need to know about my computer: 

OS Name:                   Microsoft Windows XP Professional
OS Version:                5.1.2600 Service Pack 2 Build 2600
OS Build Type:             Uniprocessor Free
System Manufacturer:       Compaq
System Model:              DSDT
System type:               X86-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: x86 Family 15 Model 1 Stepping 2 GenuineIntel ~ 1794 Mhz
BIOS Version:              COMPAQ - 20030528
Windows Directory:         C:\WINDOWS
System Directory:          C:\WINDOWS\system32
Boot Device:               \Device\HarddiskVolume1
System Locale:             en-us;English (United States)
Input Locale:              en-us;English (United States)
Time Zone:                 (GMT-05:00) Eastern Time (US & Canada)
Total Physical Memory:     2,047 MB
Virtual Memory: Max Size:  2,048 MB
Page File Location(s):     C:\pagefile.sys
                           G:\pagefile.sys

Now here is the problem. Whenever I load any Wikipedia page, WikEd is disabled. When I click on it, it does not enable. When I hover over the icon, it says the version number and "Browser not supported". However, I have Firefox, which is clearly a supported browser as WikEd has worked before. Here is how it started. Originally, all of my monobook.js file scripts were not working. When somebody pointed out the problem at the Help desk, all of the scripts were fixed, but WikEd was disabled. I believe is has something to do with the scripts. A confirmation to that theory is that when I log out WikEd works again (since I have it installed in Greasemokey). One possibility is that since WikEd is installed in GreaseMonkey AND in my monobook.js that it is not working, but that is just my theory. Please help me out, WikEd is completely non-functional yet the icon is still in the top-right corner, teasing me. Parent5446(Murder me for my actions) 03:11, 30 November 2007 (UTC)

You are installing wikEd twice, simply remove one call from your monobook.js page. Сасусlе 04:41, 30 November 2007 (UTC)

Custom monobook skin

A wiki I frequent, hellgatewiki is using a custom version of the monobook skin. This (I think) breaks wikiED. I'm using the greasemonkey version and it's working fine on other mediawikis (using it to edit this very comment). I've tried looking into this myself by studying the source but my javascript knowledge is limited at best. A suggestion on how to get wikiED to work with this wiki would be much appreciated. --Pixelz 17:13, 30 November 2007 (UTC)

Fixed in 0.9.55b. Сасусlе 01:37, 1 December 2007 (UTC)

IE7

I want to use wikEd in the Internet Explorer 7. 200.164.53.19 (Rodrigo.dst) 21:19, 30 November 2007 (UTC)

Are you able to support the new Quartz skins at Wikia?

From what I have seen, I either have to choose between the abilities of the new Quartz skins and their Sidebar widgets or WikEd. Can you help? Will (Talk - contribs) 22:55, 12 December 2007 (UTC)

Of course! I have added Quartz skin support to wikEd 0.9.56. Сасусlе 04:49, 13 December 2007 (UTC)

So what do I do? I currently am constantly switching skins. I am unable to install GreaseMonkey on this machine. Will (Talk - contribs) 03:07, 15 December 2007 (UTC)

Install wikEd on http://www.wikia.com/index.php?title=User:Will_Pittenger/quarz.js as described on the wikEd installation page under "Complete_version". Сасусlе 03:30, 15 December 2007 (UTC)

It's working, but I think you had a typo. You appear to have misspelled "Quartz". BTW: You might want to add Wikia specific instructions to your page. Will (Talk - contribs) 02:55, 16 December 2007 (UTC)

Greasemonkey d/l script security issues

Is it not dangerous to link directly to the greasemonkey script on a wiki? It seems as though anyone could change the file to something malicious. Granted, it'd probably get changed back quickly, but shouldn't this be locked or moved off to a nonwiki site to prevent attacks? I'm brand new to greasemonkey so forgive me if my fears are unfounded. -Verdatum (talk) 15:44, 13 December 2007 (UTC)

Only administrators can edit scripts on this wiki. But you are right, the installation link could be changed to soemehing else. I will think about protecting the wikEd homepage. Сасусlе 20:29, 13 December 2007 (UTC)
I have protected the wikEd homepage and created an unprotected testimonials page that is transcluded on that page. This should minimize problems with changing the link. Сасусlе 04:24, 14 December 2007 (UTC)


  1. ^ You rock~
Retrieved from "http://en.wiki.x.io/w/index.php?title=User_talk:Cacycle/wikEd/Archive_006&oldid=1142454523"