Bug 749449

(I can't login on enstage.o.o, so all I can do is judging based on Special:Version)

It seems to be the "WYSIWYG" extension. I'm following http://www.mediawiki.org/wiki/Extension_talk:WYSIWYG since years, and used a similar extension (FCKeditor) in a productive wiki - until various problems came up and I had to disable it... (Fun fact: No user complained after FCKeditor was disabled - and they are gardeners, not computer experts...)

WYSIWYG might be better than FCKeditor, but it still has various bugs and problems (the one you mentioned is a known issue IIRC) - in other words: I don't recommend it. On the positive side, it is at least maintained.

What I can recommend is the WikiEditor extension (from the usability initiative, also shipped with MediaWiki >= 1.18 and used by Wikipedia) - it works with plain wikitext, but is much more helpful for users than the "old" toolbar we have now.

Anyways: We should discuss this on the mailinglist, not in bugzilla ;-) 
(but I'll also add that I'll just say "good idea, go for it" when it comes to installing the WikiEditor extension)

related upstream bugzilla:
http://bugs.smwplus.com/show_bug.cgi?id=15945

Assigning to Scott.

WikiEditor Extension has been installed on the Stage Site.  Please test and verify that its use is desired. 

Thanks

(In reply to comment #4)
> WikiEditor Extension has been installed on the Stage Site.  Please test and

That brings us back to an old problem - external (non-SUSE/Novell) users can't create an account on stage (and therefore can't login). It would be nice if you can create an account for me and send me the login details...

> verify that its use is desired. 

I can't speak for all wiki editors ;-)
What I can say is that last time I proposed WikiEditor I only got positive responses - not too surprising because it is a big improvement over the "old"/current edit page. IMHO you should "just do it"[tm].

In order to avoid any unforeseen side effects from the WikiEditor Extension, it would be appreciated if testing were done for the remainder of the week.  

If no bugs or side-effects are found, then I will plan on rolling WikiEditor up to Production on Monday (4/2/12).

Thanks

Unfortunately, right now the Wiki is not set up to handle test accounts (due to it being SSO).  With the recent upgrade to Access Manager, we are working on making the Stage Site Public.  However, until this is completed we are still restricted.  I apologize.  Juergen, we will go ahead and wait for you to get back so that you may do some testing.

Thanks and I apologize for the inconvenience.



(In reply to comment #5)
> (In reply to comment #4)
> > WikiEditor Extension has been installed on the Stage Site.  Please test and
> 
> That brings us back to an old problem - external (non-SUSE/Novell) users can't
> create an account on stage (and therefore can't login). It would be nice if you
> can create an account for me and send me the login details...
> 
> > verify that its use is desired. 
> 
> I can't speak for all wiki editors ;-)
> What I can say is that last time I proposed WikiEditor I only got positive
> responses - not too surprising because it is a big improvement over the
> "old"/current edit page. IMHO you should "just do it"[tm].

Testing has been delayed until 4/2/12.  This will then push back deployment to Production.  Also due to the Blackout, deployment to Production cannot occur until 4/13/12.  This will allow for extensive testing.

Now that we are out of the "Blackout" period, we may roll the WYSIWYG up to Production.  How has the testing gone and are there any concerns with the WikiEditor Extension?

I did a quick test, and it worked.

The editor behaves well. 
The embedded javascript is very helpful. 
Also, I can switch between wikitext, preview and diff view without save/load roundtrips now.

Does this editor also feature WYSIWYG editing?

Minor note: The left margin is different for  different types of text.
Normal text has some margin (which looks good), A table has no margin, and numbered lists have their numbers too far left, beyond the margin.

(In reply to comment #12)
> numbered lists have their numbers too far left, beyond the margin.

That's a bug in the Bento theme and has nothing to do with the WikiEditor.
en.o.o/MediaWiki:Common.css contains a rule that fixes it, but the real fix should be done on static.o.o to get it fixed everywhere - with the risk of side effects :-/

I'll add those bento fixes once the wiki is updated. 
Will you commit the wikieditor extensions to the wiki git when deploying?

The WikiEditor has been installed in Production.  I will commit the WikiEditor
to the git repository later today.

Thanks for you patience.

Bug has been set to Resolved.  Will be closed on Friday if no problems occur.

I'm afraid you broke something :-(  (but I doubt it's related to WikiEditor):

The sidebar no longer shows what we want (see http://en.opensuse.org/mediawiki:sidebar ) - instead it shows the mediawiki default sidebar boxes "Navigation" (includes some mediawiki default links), "SEARCH", "TOOLBOX" and "LANGUAGES" (all empty).

This at least affects en.o.o. On de.o.o, I also see it sometimes, but force-reloading the page fixes it. (In other words: if we are lucky, it's "just" a caching issue and will fix itsself. If there is any server-side cache, please clear it.)


Besides that, the editor looks quite good, but needs two CSS fixes:

a) the "help" area always has a horicontal scrollbar (looks like Bento CSS causes funny side effects...) - proposed fix:
    #wikiEditor-ui-toolbar .section-help .page-format table { margin-left:0; }

b) the textarea uses a fixed width (80 chars wide) instead of using 100% of the width, which doesn't look too good with WikiEditor.
IIRC this is (was? I can't find it right now) a config option in the user preferences, but it probably makes sense to hardcode it to 100%. Proposed fix:
    .wikiEditor-ui .wikiEditor-ui-text > textarea { width: 100%; }

.

It seems the sidebar issue is solved. 

I pushed the requested css changes to git, please deploy again. Thanks

CSS changes have been deployed in stage and production.  Let me know if there is anything else that needs to be done.

Thanks

The WikiEditor extension seems to be gone again :-(

Your git commit added lots of extensions/WikiEditor/ files, but I don't see any changes for LocalSettings.php. I'd guess you forgot to commit the additional lines that enable WikiEditor ;-)

BTW: Your commit is listed with username "root" - it would be nice to have a realname there ;-)

I have added the necessary code to LocalSettings and the WikiEditor has now been re-enabled.

It was our understanding that the LocalSettings.php file was not included in the repository.  If it is, and we feel that it needs to be, perhaps we could change the name so that it does not overwrite the current LocalSettings.php file each time a pull is done.

(In reply to comment #21)
> I have added the necessary code to LocalSettings and the WikiEditor has now
> been re-enabled.

Verified, thanks!

I had to do a small CSS fix (the selector for the help area was too strict and didn't match). I pushed it to git already - please deploy once more.

> It was our understanding that the LocalSettings.php file was not included in
> the repository.  If it is, and we feel that it needs to be, perhaps we could
> change the name so that it does not overwrite the current LocalSettings.php
> file each time a pull is done.

It's in git intentionally ;-) and I wouldn't change that (or its name). Having *everything* in git (ok, except the database password ;-) makes tracking changes and reverting a broken change easy.

The solution is easy: if you want to change something in LocalSettings.php, commit to git and deploy it ;-)
Doing changes behind the back of git is evil, just "don't do it"[tm]

Christian is right, we should also deploy Localsettings from git like we've done before. 
The database password is read from /srv/settings/wiki_settings.php which gets included in Localsettings. We also need to make changes to Localsettings occasionally to enable or configure stuff.

Closing as all issues have been resolved.