I have been attempting to edit the following two pages with the rich text editor: - https://wiki.mozilla.org/JSFileApi (existing) - https://wiki.mozilla.org/JSScheduleAPI (new) In both cases, I cannot load the rich text editor. Basically, nothing happens, and if I reload the page, the text pane simply disappears. The web console informs me that: - stylepath is not defined @ https://wiki.mozilla.org/skins-mozilla/common/wikibits.js:586 - wgScriptPath is not defined @ https://wiki.mozilla.org/index.php?title=JSScheduleAPI&action=edit:55; - $(".bugzilla").dataTable is not a function @ https://wiki.mozilla.org/index.php?title=JSScheduleAPI&action=edit:370 - mwSetupToolbar is not defined @ https://wiki.mozilla.org/index.php?title=JSScheduleAPI&action=edit:244
Yep, our theme is broken in this version of Mediawiki (and newer versions too). The Wikimedia folks don't encourage 3rd party skin development, and don't go to extreme lengths to maintain good compatibility... the skinning is almost more for their own convenience than actual 3rd party skin development. Consequently, 3rd party skins more or less need to be completely rewritten with every new major Mediawiki version, rebased on top of the current upstream default theme. One workaround that generally does the trick is to append "&useskin=vector" to the end of your page you're trying to edit. This should get you the default Mediawiki skin, with which the rich text editor works fine. Sadly, there's nothing I (IT) can really do about this. We need more webdev resources allocated to maintaining our wiki skins. I suggest you make a plea to morgamic, if the above workaround is insufficient and/or too much hassle to use on a regular basis. We have asked more than once to have someone take up this torch, but so far no takers. :( In the meantime, I can at least drop this bug in the Websites::wiki.mozilla.org queue, so it can be easily found if or when someone can get to it.
Assignee: server-ops → nobody
Component: Server Operations: Web Operations → wiki.mozilla.org
Product: mozilla.org → Websites
QA Contact: cshields → wiki-mozilla-org
This is pretty painful. If this bug really needs webdev resources, does it actually want to live in one of their components?
That's a possibility, but I'm not sure what a better component would really be offhand. I know there's a mozilla.org::Webdev component, but I don't know how actively it's monitored. But if you know of a better place (or would like to try that one) then please do move the bug. I'd love for our wiki skins to get some TLC. :)
I'm going to put it there so that at least the WebDev folks will see it and be able to find it. If this is the wrong thing to do because of resourcing issues, perhaps Morgamic can chime in...
Component: wiki.mozilla.org → Webdev
Product: Websites → mozilla.org
QA Contact: wiki-mozilla-org → webdev
I can't even switch to the normal text editor directly from the edit page (I've to go to the preferences).
I want to chime in and +1 fixing this bug. Because the rich editor is broken, editing the Wiki - which is a integral way we communicate internally - is nearly impossible for people that do not code. A core business tool is broken. Let's fix it.
This is also becoming problematic for my team. Let's please fix it.
I can work around it - but it's not fun/easy and is a huge deterrent to keeping wiki's updated.
If this is a problem with the customized theme, I'd suggest cc'ing Milos who made it. Milos, can you take a look at this?
Hey folks, lets not add +1's to this bug anymore. That's not the right approach to getting it fixed.
(In reply to Aakash Desai [:aakashd] from comment #15) > Hey folks, lets not add +1's to this bug anymore. That's not the right > approach to getting it fixed. Here's an idea - based on the hack in Comment 1, what if we created an addon that appended "&useskin=vector" to the pages you want to edit, through a "Edit Wiki" button that you can add to your browser toolbar?
One Mozilla theme and Tabzilla for wiki.mo?
Once we're finished with our move out of SJC1, this will get some attention. Thanks to some skin contributions from a member of Wikimedia (and an offer of some ongoing help), we should be able to get things fixed up and work on also upgrading to the latest stable Mediawiki. I'll update this bug as we make progress
As a long-term option, I'd suggest moving towards the One Mozilla Theme and Tabzilla though. But that's going to require a lot of QA and Communications work. I remember a lot of wiki layouts were broken when we moved to this layout. I'd assume the same would happen with One Mozilla.
(In reply to Brandon Burton [:solarce] from comment #18) > Once we're finished with our move out of SJC1, this will get some attention. > > Thanks to some skin contributions from a member of Wikimedia (and an offer > of some ongoing help), we should be able to get things fixed up and work on > also upgrading to the latest stable Mediawiki. > > I'll update this bug as we make progress That's great to hear, Brandon, thanks for picking this up!
(In reply to Laura Forrest from comment #16) > (In reply to Aakash Desai [:aakashd] from comment #15) > > Hey folks, lets not add +1's to this bug anymore. That's not the right > > approach to getting it fixed. > > Here's an idea - based on the hack in Comment 1, what if we created an addon > that appended "&useskin=vector" to the pages you want to edit, through a > "Edit Wiki" button that you can add to your browser toolbar? This add-on will just add the parameters to the wiki edit links automagically. I've done some minimal testing, WFM https://addons.mozilla.org/en-US/firefox/addon/wikirichtextfixer/ Source is here if your're curious: https://builder.addons.mozilla.org/addon/1052080/latest/
(In reply to Jeff Griffiths from comment #21) > (In reply to Laura Forrest from comment #16) > > (In reply to Aakash Desai [:aakashd] from comment #15) > > > Hey folks, lets not add +1's to this bug anymore. That's not the right > > > approach to getting it fixed. > > > > Here's an idea - based on the hack in Comment 1, what if we created an addon > > that appended "&useskin=vector" to the pages you want to edit, through a > > "Edit Wiki" button that you can add to your browser toolbar? > > This add-on will just add the parameters to the wiki edit links > automagically. I've done some minimal testing, WFM > > https://addons.mozilla.org/en-US/firefox/addon/wikirichtextfixer/ > > Source is here if your're curious: > > https://builder.addons.mozilla.org/addon/1052080/latest/ This is fantastic! Thanks again - I encourage anyone who is having the same problem to install this add-on since it fixes the problem. Ah, the power of Add-ons. This could be a "works for me" but will leave open since root cause is still unresolved.
(In reply to Marco Castelluccio from comment #7) > I can't even switch to the normal text editor directly from the edit page > (I've to go to the preferences). Changing my preferences to disable the rich text editor worked for me. I am very used to basic wikimedia markup and I prefer it. To do this click My preferences, scroll down to Editing, select "Start with rich editor disabled" and save your changes.
Renormalizing priority levels... P4 is "normal" now.
Assignee: bburton → server-ops-webops
Component: Webdev → Server Operations: Web Operations
Depends on: 707181
Priority: -- → P4
QA Contact: cshields
Whiteboard: [review 6/25] → [triaged 20120831][waiting][dev resources]
Here, I have the same problem! I am stuck with html mode! my wikipage got converted to html and now i cannot go back ! mike
You can switch back by changing the skin to "Vector". Sebastian
This bug mangles pages, because clicking the "Rich Editor" button converts the contents of the textbox from MediaWiki markup to HTML. If the user then edits the result and clicks "Save", the page gets mangled and the edit has to be rolled back and redone. Example: https://wiki.mozilla.org/index.php?title=Community:SummerOfCode13:Brainstorming&oldid=525704 If we don't have the resources to fix this, can we please disable the Rich Editor for everyone, or at least remove the link to enable it in our custom skin? Gerv
+1. At the very least just disable the rich text link so people don't get stuck in a broken experience.
(In reply to Gervase Markham [:gerv] from comment #28) > This bug mangles pages, because clicking the "Rich Editor" button converts > the contents of the textbox from MediaWiki markup to HTML. If the user then > edits the result and clicks "Save", the page gets mangled and the edit has > to be rolled back and redone. > > Example: > https://wiki.mozilla.org/index.php?title=Community:SummerOfCode13: > Brainstorming&oldid=525704 > > If we don't have the resources to fix this, can we please disable the Rich > Editor for everyone, or at least remove the link to enable it in our custom > skin? > > Gerv Justin Crawford has been working with IT on the wiki.mo upgrade. What we have been told that the upgraded version of mediawiki will not include a rich text editor and thus this bug may become invalid. We also want to develop a light Sandstone theme for mediawiki, but only after the upgrade is complete and we have bandwidth. Justin: Can you clarify the rich text editor question with the upgrade?
(In reply to Chris More [:cmore] from comment #31) > Justin Crawford has been working with IT on the wiki.mo upgrade. What we > have been told that the upgraded version of mediawiki will not include a > rich text editor and thus this bug may become invalid. We also want to > develop a light Sandstone theme for mediawiki, but only after the upgrade is > complete and we have bandwidth. That's unfortunate, my impression is that people want a rich text editor for the wiki, this is the whole reason behind my add-on.
(In reply to Jeff Griffiths (:canuckistani) from comment #32) > That's unfortunate, my impression is that people want a rich text editor for > the wiki, this is the whole reason behind my add-on. Some people definitely do want a rich-text editor. The rich text editor currently in use on wiki.mozilla.org is FCKEditor. It was the official extension for rich text editing, but it is now abandoned upstream and no longer supported: http://www.mediawiki.org/wiki/Extension:FCKeditor_%28Official%29. There's not really anything we can do to bring it back, and we can't stay on this old version of Mediawiki any longer (it's been far too long already). And as mentioned, it has significant problems. There is an alternative, "WYSIWYG" extension: http://www.mediawiki.org/wiki/Extension:WYSIWYG. It claims to fix the HTML problem mentioned in comment 28. The problem here is it's not supported in new versions of Mediawiki... it's also a dead extension. We could switch to this, but it would be only for a week or two, and would steal time away from getting the upgrade done. Hard to justify this. The most feasible option I know of is this: http://www.mediawiki.org/wiki/Extension:WikiEditor "WikiEditor is an extendable framework with a set of feature-based modules that improve the user experience of editing. It is also the editing interface that Wikipedia currently uses." This isn't strictly rich-text, but it may get be enough of an improvement to where this is less of an issue. This is what we're setting up in the new version. The reality is there *is* no currently-supported, production-ready rich-text editor for current versions Mediawiki. There is a plan for one (http://www.mediawiki.org/wiki/Extension:VisualEditor), but as that page notes it's highly experimental at this point.
Isn't an issue with FCKEditor on the current instance of wiki.mo is that it turns the markup into HTML, which is annoying for people who prefer wiki markup? I prefer wiki markup and not HTML to edit a wiki. It appears that VisualEditor is to be released in 2013 per notes here: http://www.mediawiki.org/wiki/VisualEditor "The 2012-13 Engineering Goals document sets a timeline for VisualEditor's development and deployment up to the end of June 2013." It looks like it is currently being used on wikipedia.org in the editing preferences.
So now we've upgraded, there is no rich text editor at all. This is definitely an improvement from having a rich text editor which mangles pages, but it would be nice to have one which actually works. Is the current plan to wait for: http://www.mediawiki.org/wiki/VisualEditor to become stable? Or is there another option? Do we think we can deploy it now and be part of the testing team? Gerv
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
I wonder if this is related to the jQuery issue in bug 858844? I've temporarily resolved that on wiki-dev.allizom.org, but I'm not getting anything better for an editor. CC'ing Timo, who had found a problem on that bug. Mark is already CC'd here. Perhaps their powers combined may bear fruit here as well...
Assignee: server-ops-webops → nmaul
QA Contact: cshields → nmaul
The VisualEditor has been upgraded to "Beta" status: Use at your own risk; it's not ready for production deployment except for experts! Patches welcome. Sounds like something we can play with at least for wiki-dev.allizom.org. In particular it looks like it only works out of the box when creating new pages... to edit existing ones (and maybe to save at all?), it takes an external Node.js service. It also requires MediaWiki 1.22, while we're currently running 1.19. So this isn't something we can just quickly do right away.
I do note that if I switch my skin to "Vector" instead of the default "GMO", I can get at least a small toolbar over the text editing area, which makes it simpler to do very basic formatting. It's not rich-text, but it's better than nothing at all. I can't see this using our custom "GMO" skin. This leads me to believe there is something it does that isn't playing nice, but I haven't narrowed it down any further than that.
And just to flesh out my last comment a bit... Vector and Monobook (upstream themes) will show that toolbar, but GMO, Sandstone, and Cavendish (Mozilla themes) will not.
Web QA has a *few* Wiki tests up at https://github.com/mozilla/wiki-tests, for which we have dev, staging, and production jobs -- nothing specific to editing documents, though, I don't think.
Very happy to announce that the WikiEditor extension is working and enabled for everyone on wiki.mozilla.org! This is not true rich text editing, but it's a lot more helpful than just a text box to type in. It will help with simple formatting (bold, italics, headers, lists, even tables), some pop-ups for more complicated things (links, images, gallery-of-images, etc), and provides a side-by-side preview and changes view. It can optionally also provide a sidebar table-of-contents in the editor, allowing you to quickly jump to edit different sections of a page (marked by headers). I'll keep this bug open for playing with VisualEditor, but that's a longer-range project so don't expect anything right away. And honestly, with WikiEditor working, this is probably a bit lower priority now than it was yesterday.
:jakem: Awesome! Would it be difficult to get it on intranet.mozilla.org too? I swear, if we'd had this 3 years ago, HR would not have gone to Mana... Gerv
Eh, I cured the syntax error in Cavendish, but sadly WikiEditor still doesn't work. This doesn't have the Bugzilla extension, so it's not that again. Need a more seasoned Mediawiki hand to point out the flaw.
Looking at https://wiki.mozilla.org/index.php?title=JSFileApi&action=edit: * I no longer see a syntax error or other uncaught exception at any time during loading, editing or previewing. * The toolbar looks distorted (due to a class name clash, mozillawiki's skin has a rule with selector ".section" that is adding large amounts of padding), but is otherwise operational. I was able to select text and click "bold" or "italic" to inserts the relevant wikitext syntax. What is the exact issue we're working on?
@Timo: Sorry, my comment 43 and 44 are related to an internal site, intranet.mozilla.org. It seems to work very well on wiki.mozilla.org. You can simulate the breakage on wiki.m.o, however, if you switch your skin from the default GMO to "Cavendish". As to your point regarding a class name collision... how on earth did you figure that out? :) I ask half in jest, but also with a grain of genuine curiosity- I'd bet money this is not the only such collision we have that's causing odd formatting that we simply haven't spent time to track down and fix. I commented out this definition in the skin on wiki-dev.allizom.org, and it does indeed fix the extra padding added to WikiEditor. I have yet to find anything that now looks broken, either... I'm thinking this may well be cruft carried over from older versions of MediaWiki and not something we added for any specific reason. I don't see anywhere in our custom code (mainly this skin, plus the Bugzilla extension) that is relying on this "section" selector.
Extra padding fixed in https://github.com/mozilla/mediawiki-skins-gmo/pull/4. Merged, deployed to prod.
Whiteboard: [triaged 20120831][waiting][dev resources] → [kanban:https://kanbanize.com/ctrl_board/4/84] [triaged 20120831][waiting][dev resources]
WikiMO is an IT-managed tool at the least, so moving components. (This could also ostensibly fall onto our Websites side, depending on the solution.) Looping Christie in to get further feedback.
Component: WebOps: Other → WebOps: IT-Managed Tools
(In reply to Gordon P. Hemsley [:GPHemsley] from comment #48) > WikiMO is an IT-managed tool at the least, so moving components. (This could > also ostensibly fall onto our Websites side, depending on the solution.) Actually, I'm gonna go ahead and move this to our side so that we can triage it along with everything else. This may wind up being a dupe, WFM, or WONTFIX.
Component: WebOps: IT-Managed Tools → wiki.mozilla.org
OS: Mac OS X → All
Product: Infrastructure & Operations → Websites
QA Contact: nmaul
Hardware: x86 → All
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/84] [triaged 20120831][waiting][dev resources] → [triaged 20120831][waiting][dev resources]
WONTFIXing because the issue applies only to the now retired skins of GMO, Cavendish and Sandstone. Re-open if you're seeing it on Vector (default) or Monobook.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.