This Forum has been archivedVisit the new Forums
We have two updates coming today (15th July), consisting of tweaks to the Monaco skin, and some upgrades to the new Rich Text Editor.
First, the Monaco skin changes:
- We are adding "creation links" to sidebar to surface and promote content creation. On blog pages, these change to blog creation links.
- All pages will have an article footer, with appropriate page specific links, such as WhatLinksHere.
- The toolbox link ordering has changed - it goes left/right/left/right/etc. instead of being one list split into two. Essentially, this means your toolbox links may reorganise, but they should also appear in more predictable locations.
Second, the Rich Text Editor feature updates:
- The editor now allows entering basic wikitext in WYSIWYG mode to help prevent newbie mistakes and give those used to the traditional editors a few shortcuts. Wikitext is converted into Rich Text upon clicking Preview/Save or switching back from source mode.
These types of wikitext are accepted:
- Bold, italic, underline, strikethrough
- Simple templates and magic words
- We now support HTML comments (
<!-- text -->) when they begin a line of text. A little yellow note icon will appear - hovering over this shows you the content of the comment, and clicking it allows you to edit or remove it.
- We have also improved support for pasting between different instances of the editor (e.g. from one wiki to another).
- Internationalization support has been added to make this editor accessible for all languages.
The Skin is messed up
. The skin is supposed to be Slate. As you can see, the skin has been reverted to default. Regardless of what I do to try and revet it, nothing works. This bug was most likely been caused by the new update, as it started today. However, this may just be Firefox unable to read the new code. Do you know of any way to fix this software glitch? ScatheMote 17:01, 15 July 2009 (UTC)
For some reason, the "What links here" link is no longer appearing automatically on Fallout wiki. Is that intentional? I've now added it manually to MediaWiki:Monaco-toolbox (just in case you're wondering why it's there now). However, I noticed another slight issue when doing that: If said link is added manually at a position which is not the last in the list, it will make all links after it disappear on pages where it is hidden (like Special pages). -- Porter21 (talk) 18:34, 15 July 2009 (UTC)
- The removal is intentional, as the link now exists in all page footers. Wikis are free to add it back.
- The other part: definitely a bug - will get that sorted. 19:00, 15 July 2009 (UTC)
- (edit conflict x2)
- Is that so ? Glad this isn't happening on fr.guildwars (this link is set up to show the french UI since the english toolbox is not properly set up yet).
- By the way, since my language is french, when i go on Fallout, i dont see any of the custom sidebar or toolbox because you have not set up the french version of it (i.e.: MediaWiki:Monaco-toolbox/fr and MediaWiki:Monaco-sidebar/fr).
- I wonder when will Wikia, if ever, find the time to fix that problem. — TulipVorlax 19:02, 15 July 2009 (UTC)
- That's unfortunate, but it seems not really feasible for us to fix (for all languages I mean - it would be doable for a couple). I guess it'd be better if the sidebar fell back to the default at MediaWiki:Monaco-sidebar if language-specific versions have not been set up. Not sure whether the toolbar should do the same - depends on whether you'd rather have wiki-specific additions or a translated standard toolbar I guess. -- Porter21 (talk) 15:25, 16 July 2009 (UTC)
We've just put out a fix for the location issue: if whatlinkshere is shown higher up the list than at the end, a blank space is shown on special pages (in line with the ideals of this project being that the toolbox links no longer move around). I've tested it out, and it looks pretty natural - however, my recommendation is still that whatlinkshere should go at the end of the list, or be removed entirely. 15:51, 16 July 2009 (UTC)
Chrome & IE8
In Chrome & IE8 I have a big white bar. Clicking the left side of the bar takes me to create a new article. Clicking the right side takes me to upload a new file. On the create a new article page, I noticed the categoryselect feature that is currently on blog pages. You've stated on multiple occasions that that awful thing is going to be replaced. Why is it there on a non-blog page now? -- LordTBT Talk! 19:00, 15 July 2009 (UTC)
- Special:CreatePage isn't a new page, but yes, it is also going to be updated very soon. 19:02, 15 July 2009 (UTC)
Block user/Email user/Contributions
On user pages, you now have "Block user"/"Email user"/"Contributions" links both in the masthead and in the toolbox for the Monaco skin. Seems to me one of each would be enough :) -- Porter21 (talk) 21:39, 16 July 2009 (UTC)
- Not every wiki has the masthead.--AB 17:01, 18 July 2009 (UTC)
On edit pages, if I move my mouse to display onto a navigation sidebar menu item, to have a menu appear, and I mouse over that menu, then move my mouse onto the edit box, the menu does not disappear. This only happens with the wikitext editor and not the rich text editor. Beep21 00:10, 18 July 2009 (UTC)
- This also happens with other text boxes, such as the upload form's "Destination filename" text box. Beep21 21:35, 20 July 2009 (UTC)
Hi there! Surely you've a lot of work to do, but please take a look at the whole Memory Alpha site, that is hard to navigate and working on it, 'couse the layout is messing by few hours. Thank you! --Gifh 23:19, 15 July 2009 (local time)
- That is the weirdest thing i've ever saw on Wikia File:MA-Skin problem.png
- It only occur when logedin. As annon, the site render ok. — TulipVorlax 02:19, 16 July 2009 (UTC)
- Temporary solution; go to your prefs over there or here (they are shared), deactivate the "See custom skins" option. — TulipVorlax 02:23, 16 July 2009 (UTC)
- Don't worry about this, I've had this happen for multiple reasons way before this Monaco update went live. It usually goes away for me especially if you clear your cache a lot. Probably is just a CSS incompatibility. ~Joey~ ^Talk^ 10:28, 16 July 2009 (UTC)
Login box (unfixed)
- Thank you very much.--AB 12:52, 22 July 2009 (UTC)
- This occurs again since last Wednesday.--AB 11:19, 5 August 2009 (UTC)
Asterisks, indentation. Added by new editor to bulleted lists
I don't know if I should post this in this thread, or in the help desk forum, or in the very long thread about the new editor (can we start page 2 for that thread?). But I just noticed this problem today with *asterisks* being added to lists on a couple pages.
So maybe it is the latest revisions of the new editor that is causing the problem. It also substituted an asterisk for the first curly bracket in some templates, thus breaking the template on that page. That may have been fixed already though. So the indentation weirdness is the ongoing problem.
Note that it is mainly a bulleted list of items. Each one starting with ONE asterisk (when looking at wikitext source view).
Click on the edit link at the top. Note that it immediately doubles most of the asterisks (indentation added). This is before saving the page, and before going to the source editor as I usually do. So I can't avoid this problem. I wish there were an "edit wikitext" icon/link at the top of the page, and in each section of the article, in order to go directly to the source editor. Maybe that could be an optional add-on for some wikis.
The new editor indents most of the list. The second asterisk is noted in the source code, and on saving the page. The first item in the list is a template. It is not indented. All the items after it are indented by the new editor. The new editor also adds a blank line after the 2 template items in the lists. This can be seen in source view.
So the problem has to do with templates used in bulleted lists. I have used templates in a bulleted list before. For example; the main page:
The templates have been in that list a long time. I don't remember problems before, though I am not sure.
I also noticed the added asterisks and indentation on that main page today too when I edited it. I had to put __NOWYSIWYG__ at the top of that page to sort out the many problems that started when I edited the page today. It was very difficult to sort out the problems because there are multiple templates used in the list and the table. It messed up the table code too at the end of the table.
I think it is a mistake to let the new editor make any changes in existing wikitext without permission. This is a problem with some WYSIWYG web page editors. People often complain about those editors that make changes in the source HTML without permission. The default setting for any editor in my opinion should be no changes. "Optimizing" the source code should always be optional.
"Optimizing" wikitext could be an optional icon in the editing toolbar, so that people can preview the changes first before saving them. I suggest that it only optimize what is selected. This could be a very useful optional tool.
Is there a way to turn off this default optimization? I suggest admins be able to toggle it on or off for a wiki. Then we could turn it off when it is causing problems. --Timeshifter 18:31, 19 July 2009 (UTC)
- Great. This looks like a related problem:
- Forum:New Visual Editor: Problems and Suggestions#Templates
- See also:
- Forum:New Visual Editor: Problems and Suggestions#Table wikitext changed by new editor --Timeshifter 08:27, 20 July 2009 (UTC)
- it is a mistake to let the new editor make any changes in existing wikitext without permission -- the problem is that the RTE doesn't see the wikitext, it is a HTML editor and gets fed HTML from the server, and the server re-makes the wikitext from that (and some hints). --◄mendel► 02:39, 21 July 2009 (UTC)
- Thanks. That explains a lot. It seems like a lot of problems are from how the new editor treats templates, or acts around templates. If it is recreating templates each time this could explain a lot of problems. Maybe the new editor needs a "hint" not to change template wikitext. It should be instructed anytime it sees template brackets to pull up the wikitext, and not to recreate template wikitext. See my latest comment at
- Forum:New Visual Editor: Problems and Suggestions#Templates
- The new editor also needs to be instructed not to add indentation anytime it sees a template in a bulleted list. I can't figure out why it would do that. --Timeshifter 09:36, 21 July 2009 (UTC)
Note, for further feedback on the new editor, please use Forum:New Visual Editor: Problems and Suggestions. 15:19, 7 August 2009 (UTC)