Optimize the UI for screen size wider than 2000px by allowing content to occupy part of the unused whitespace.

File has an extra .less in its name

Content in tables is not centering with class="wikitable" style="margin:auto; text-align:center; font-size: 8pt;". It works on other skins. How do I fix this?

The Problem

I want to have the same at the footer, how to achieve this?

The Problem

can you keep old stile for navbox, with vector skin or Minerva, the title of collapsable nav bar width is 100% when collapsed,
the attached files are screenshots that describes what I mean.

link to navbox:
https://en.wikipedia.org/wiki/Template:Navbox

The Solution

A clear and concise description of what you want to happen.

The Alternatives

A clear and concise description of any alternative solutions or features you've considered.

The lazyload function and low quality image placeholders are causing issues on wikis without Citizen enabled on Miraheze. Could be some kind of caching issue or the hook is leaked. Either way the current implementation is based on the older lazyload extension and should be reworked, maybe referencing how MobileFrontend implement it.

Hello.
The previous problem has not been solved yet.

You changed my commit a bit, and maybe that didn't fix the problem.

Please check it again

There is another problem in the dark mode that when we go to the help option, its color turns black and is not visible, while in other links it is not so and they change to white.

Install skin and go to api.php.

There should not be an internal error but there is, debugging leads me to https://github.com/StarCitizenTools/mediawiki-skins-Citizen/blob/master/includes/api/ApiWebappManifest.php

Error states:

2020-05-14 20:33:53 test2 test2wiki: [29e0785fb18ded9484cde6cd] /w/api.php?action=query&format=json&origin=*&generator=search&gsrnamespace=6&iiurlheight=200&iiprop=dimensions%7Curl%7Cmediatype%7Cextmetadata%7Ctimestamp%7Cuser&prop=imageinfo&gsrsearch=test&iiurlwidth=300&gsroffset=0&gsrlimit=15   InvalidArgumentException from line 123 of /srv/mediawiki/w/includes/api/ApiModuleManager.php: $spec must define a class name
#0 /srv/mediawiki/w/includes/api/ApiModuleManager.php(79): ApiModuleManager->addModule(string, string, array)
#1 /srv/mediawiki/w/includes/api/ApiMain.php(289): ApiModuleManager->addModules(array, string)
#2 /srv/mediawiki/w/api.php(68): ApiMain->__construct(RequestContext, boolean)
#3 {main}

When the page width is less than 720 pixels, the "Create New Section" section disappears. But it can still be clicked

When the mmv lightbox closes, it scrolls back to the original place in the page, as if the lightbox were an overlay.

With html { scroll-behavior: smooth }, this scroll becomes visible and jarring.

Ideally there'd be a class to select against, e.g. html.citizen-animations-ready:not(.mw-mmv-lightbox-open) { scroll-behavior: smooth; }, but unfortunately the relevant handler in the MultimediaViewer code is:

MMVB.cleanupOverlay = function () {
	var bootstrap = this;

	$( document.body ).removeClass( 'mw-mmv-lightbox-open' );

	if ( this.$overlay ) {
		this.$overlay.remove();
	}

	if ( this.savedScrollTop !== undefined ) {
		// setTimeout because otherwise Chrome will scroll back to top after the popstate event handlers run
		setTimeout( function () {
			$( window ).scrollTop( bootstrap.savedScrollTop );
			bootstrap.savedScrollTop = undefined;
		} );
	}
};

So the selector is removed before the scroll, and it's set to body, not html.

Injecting some addClass and removeClass calls to the function in the setTimeout works, but I don't know a way to do this cleanly (i.e. without changing the MultimediaViewer code). The following somewhere seems to work, but I don't know where it'd go, and has an obviously flimsy race condition:

$(document).on('mmv-setup-overlay', function () {
	$('html').addClass('mw-mmv-lightbox-linger');
});

$(document).on('mmv-cleanup-overlay', function () {
	setTimeout(function () {
		$('html').removeClass('mw-mmv-lightbox-linger');
	}, 20)
});

Hi! Wonderful skin! Thank you very much for developing and making it available. I have been really glad since I've found it. .

I would like help changing a few things in order to use the skin for my personal wiki. I am a total novice to css, less, json etc. I thought I could understand my way through the files in the skin folder but I could not.

The following items are what I would like to achieve.

1. Make the dark mode always enabled (I've read it is not possible to toggle it).
2. Make the logout button in the side panel with the same color as the rest of the menu (the red distracts me a bit when I open the panel).
3. Change the values of the colors of dark mode to be closer to the ones I already use on my editor.
4. Change the style of headings and text (font, size, color etc.).

Are there trivial ways to make such changes? If not, could you give me some guidance as to what should I do. Thank you again very much for creating this skin and thank you in advance for the help.

(Sorry if my wording is confuse at any point. Brazilian here. Also, I've posted this message in the discussion at the mediawiki.org. I apologize if it is not adequate to submit issues which are not bugs or feature requests.)

MediaWiki 1.35 is the new LTS and Citizen should target 1.35 instead of 1.31 to reduce maintenance. The commit before the move will be freezed inside the REL1_31 branch.

Hello.
When click in the search box, The magnifying glass symbol(🔎) in Persian (right to left) is not displayed correctly.

Is shown in the attached image.

I solved this problem and sent you a pull request.

Please check it.

System

• MediaWiki version [e.g. v1.35.2]
• Server OS: ubuntu 20.04
• version: latest version 1.7.1, I downloaded from Github this morning

The header JS is clunky and should be written in pure JS. I am not too familiar with performance tuning JS so feel free to chime in!

• Update dependencies
• Remove grunt
• Add SVGO
• Fix JSdoc support
• Look into Mustache linter
• Maybe Storybook?

The Problem

please have a look at this screenshot, adding this tag will reduce more than half-second of loading time.

The Solution

Consider using <link rel=preload> to prioritize fetching resources that are currently requested later in page load.

Is it possible to implement google Adsense within this skin?

Describe the Bug

The print version is broken when the navigation is shown. The navigation is placed over the content on all pages. The text behind the navigation is hard to read.

Steps to reproduce the behavior:

1. Go to a page with navigation. Example: https://starcitizen.tools/ROC
2. Print the page (navigation)

Expected Behavior

Navigation is placed on one page and not placed over any content.

System

• starcitizen.tools wiki
• Firefox 79

The Problem

Usability point of view, Every time a user wants to go to home page he/she has to open the side menu and click on home.

The Solution

Can you offer an icon that links to the home page directly, place it near to search or sidebar icon.

Currently all the images are defaulted to lazyload and it can't be turned off nor there is a noscript fallback for the images. When a noscript user visited a page, they'll only see the low quality placeholder image rather than the actual image because of the absence of JavaScript to load the source image.

If iOS Safari have default support for native lazyload, then removing the intersection observer API will likely solve this issue too.
https://caniuse.com/#feat=loading-lazy-attr

The Problem

Is it possible to implement a font-awesome library natively with the skin, instead of installing an extension?

ed1b55c re-introduced overflow rules to containers, which presents the same problem noted in #267.

If there are still rogue elements with negative margins and such causing overflows, I'm not sure re-adding this band-aid every time they pop up is the best approach, because aside from breaking sticky positioned elements, it makes it harder to track down and fix said rogue elements.

In either case, an easy solution is using the new overflow: clip rule instead, which was created to fix exactly this problem. It works in Chrome/Firefox/Edge currently, and you can useoverflow: hidden as a fallback, e.g. .selector { overflow: hidden; overflow: clip }.

In the current implementation, the footer is hacked together with CSS tricks because it was generated the same way as the Vector skin. If the footer is generated properly, the CSS tricks won't be needed.

The Problem

Lazyload images: Improve load time of your wiki and avoid unnecessary image downloads. Require JS.

What JS do you mean? and how to implement it

The Problem

table of contents not showing at all. and lazy load images not having any effect

The triangle bullet provided by Extension:CategoryTree is skewed. It was caused by using Roboto as the font, a simple font reset will fix the triangle.

The navigation to change pdf pages overlaps the rendered pdf page.

Steps to reproduce the behavior:

1. Open any pdf filepage with Extension:PdfHandler enabled

Expected Behavior

Actual Behavior

Describe the Bug

Middle clicking search suggestion should not redirect current tab.

Steps to reproduce the behavior:

1. Search something
2. Middle click the suggestion
3. See error

Expected Behavior

Current page should stay.

When creating a page using the ---- or </hr> syntax to generate a horizontal line, the line does not appear, as should be standard for Mediawiki.

Describe the Bug

VisualEditor mostly works on the Citizen theme, however there are a couple incompatibilities. Most notably:

Steps to reproduce the behavior

1. Install Citizen theme
2. Install VisualEditor (w/ Parsoid)
3. Go to a page you can edit

Expected Behavior

Full compatibility with VisualEditor.

System

Please complete the following information:

• MediaWiki version [e.g. v1.33.1]: 1.34.1
• Server OS: [e.g. Debian 10] Ubuntu Server 19.04
• Installed extensions and versions [e.g. SemanticMediaWiki 3.0, WikiSEO 2.3.1, etc.] Nuke 1.3.0, Renameuser, CodeEditor, VisualEditor 0.1.1 (74116a7), WikiEditor 0.5.2, Cite 1.0.0, OpenGraphMeta 0.5.5 (0a61e8e), ParserFunctions 1.6.0, Scribunto, Description2 0.4.1 (2fd4f08)
• PHP version [e.g. v7.2.19-0ubuntu0.18.04.2] 7.2.22-1+ubuntu19.04.1+deb.sury.org+1 (fpm-fcgi)

The Problem

can you add a purge-action link to the dropdown menu, just after, move or protect?

The Problem

edit buttons are not showing well on rtl language.

plus here on content as it renders behind the text

Mediawiki skins are moving towards using mustache to allow easier maintenance and development. We should consider the same as it will greatly benefit the skin to go forward.

The current HTML will be broken down into components like the mustache templates in other skins, which also means that the current CSS needed to be broken down correspondingly as well.

This would be required in order to get Citizen to a 1.0 release.

Describe the Bug

I just installed 1.2.2 version of the skin and I noticed that my .svg logo doesn't show up after I opened the menu, I see the site title instead and this warning message in the console:

The resource https://mysite.com/resources/assets/logo.svg was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it has an appropriate as value and it is preloaded intentionally.

MyLocalSettings.php says:

$wgLogo = "$wgResourceBasePath/resources/assets/logo.svg";
$wgLogos = [ 'svg' => "$wgLogo" ];

System

• MediaWiki version v.1.35.1
• Server OS: Ubuntu 18.04
• PHP version 7.4.13 (apache2handler)

Thanks for any help

Describe the Bug

when searching for mediawiki: your text here, if i click on the search result
This is what i get:

Steps to reproduce the behavior:

1. Change Language to Arabic

2. Create a mediawiki file named: mediawiki:تجربة البحث في الموسوعة
   OR: full name in Arabic
   (ميدياويكي:تجربة البحث في الموسوعة)

3. Search for the same

4. Click on the result link

I think that the link address has an issue: especially when (%3A) and (%2F) are added or replaced.
قالب%3Aصندوق_معلومات_كائن%2Fنواة

Expected Behavior

To open the requested page normally,

For now

setting $wgCitizenEnableSearch=false; solved the issue by pointing back to mediawiki search,

System

Please complete the following information:

• MediaWiki version [e.g. v1.34.2]
• Server OS: [e.g. Ubuntu 20.04 LTS]
• PHP version [e.g. v7.2.19-0ubuntu0.18.04.2]

lets assume that we have a long article, and we want to show related article in between article sections,

An example of this like that:

Heading title

Intro

Section 1 H2 title

paragraph

paragraph photo

paragraph

photo

end of section

{{related articles}} to be inserted automatically on parse maybe or another method

Section 2 H2 title

paragraph

paragraph photo

paragraph

photo

end of section

{{related articles}} to be inserted automatically on parse maybe or another method

Section 2 H2 title

paragraph

paragraph photo

paragraph

photo

end of section

{{related articles}} to be inserted automatically on parse maybe or another method

Note: the code might be injected here: {{{html-bodycontent}}}
Another hint: https://www.mediawiki.org/wiki/Manual:OutputPage.php

I need this feature, as it will lead to more traffic

Describe the Bug

Hello.

When the contents of the wiki page are too small (for example, less than ten lines) an additional load scroll is added to the page.

This is because of the class "page-actions-more-menu".

The same three points that open the menu of additional tools.

Does this menu work on the phone as well?

Because it seems that when the computer mouse is moved, the menu is displayed on it.

The current CI is not in sync with the test suite on Wikimedia. It will require an update to ensure that the CI is as close as Gerrit as possible.

• Separate stylesheets per color scheme (layout, light, dark)
• Implement manual switch to override prefer-color-scheme settings (for both registered users and anon)

Dark-mode-toggle is a good starting point to look into.

Describe the Bug

i noticed that drawer menu on rtl languages has an issue with the X buttun that closes the drawer.

how i solve it:

1. Go to 'mediawiki:common.css'
2. Add the following:

#mw-drawer-button:checked ~ #mw-drawer-button-icon #mw-drawer-button-icon-2 {
transform: rotate(45deg) translate(-5px,-7px);
}
#mw-drawer-button:checked ~ #mw-drawer-button-icon #mw-drawer-button-icon-3 {
transform: rotate(-45deg) translate(2px,-2px);
}

toc has some problems, comparing with your example website, it is not acting the same, in your example website, it drops from top, in this screenshot, it is sliding from the right

Prior to 8129ca, clicking on the drawer would close it.

If this was done to avoid the drawer closing when a link is clicked, checking Event.target in the click handler for anchor elements and not closing the drawer if they're found should address that without causing this regression.

The Problem

it would be great to have a (second) sidebar that is always visible on the side instead of the current overly-menu.

Solution

have one of those options or even both:

1. have a sidebar on the left and the toc on the right.
2. or allow to have a sidebar on the left side and a switch-button at the top that switches between sidebar-menu and toc. this would also replace the current menu which spans as a overly over the hole page.

I think a sidebar that is always visible on the side makes for some wikis more sense that the overly-menu, because its alway in the eye of the viewer and therefore helps navigating the wiki faster. If there is for example a navigation-tree with pages and sub-pages it would be sense to be always visible instead of always having to open it via the menu-button.
What do you think?

Gif I received from a user.

For many users, this is terribly confusing.

• They assume the button on the top-left will close it, but that instead opens another menu (the main sidebar).
• They assume that clicking the main body will close the menus.
• Since they never pressed the button to open the toc in the first place, they don't where it is to close it.
• When all of these fail, they assume the page is broken and give up.

In addition, once the user has the toccollapse cookie set, the collapse is done by JavaScript, so every page load starts with the table of contents flashed open for a moment, which looks ugly.

Steps to reproduce:

1. Go to this page with small width viewport on fresh browser
2. Table of contents is opened by default
3. Close table of contents, reload
4. Table of contents is temporarily visible, then closed by a pageload script

Expected Behaviour:

1. Table of contents is closed by default
2. Table of contents not temporarily visible on pageload when being closed by default

This is the behaviour on https://starcitizen.tools, so it's possible this is caused by a difference between MediaWiki 1.31 and 1.35 or between Citizen 0.9.4 and 1.1.0. I see this commit between those versions of Citizen which suggests to me this is the case.

Related but more of a feature request, other expected behaviour is:

1. Table of contents (and sidebar menu) closes if user clicks on the body

System

• MediaWiki version v1.35
• Server OS: Arch Linux
• PHP version: 7.4.12 (fpm-fcgi)
• No relevant extensions

Look into better integration with OOUI
https://www.mediawiki.org/wiki/OOUI/Themes

Could potentially be a lot of maintenance since the library is updated a lot and used by core and many extensions.
Though it should help with the dirty skinstyles with OOUI, and also easier to style if done that way.

The Problem

Hidden categories are not being treated, and will remain visible

Example

A clear and concise description of what you want to happen.
Category:Pages with syntax highlighting errors
this is a hidden category and it should not be visible for visitors.

Describe the Bug

Edit action and view history next to article title are visible only when the chosen language is non rtl language.

Steps to reproduce the behavior:

1. Go to 'language option'
2. Click on 'العربية'
3. See how the edit and view history disappear.

Expected Behavior

Edit action and view history should change position to the right.

Behavior on ltr languages is normal:

Behavior on rtl languages were edit and view history disappears:

The ResourceLoader modules can be further optimized to improve performance for the skin. Modules should only loaded when they are necessary. And non-critical modules should be moved out of the Critical Rendering Path.

The Problem

when you hoover some pictures, especially those loaded from commons, you get this hover effect on some of them, which makes it ugly, try to keep this effect on text links only (it a brilliant idea for those hover effects on text links).

Note: this should be done to avoid editing all articles that contain images like those, and there is a lot of them.

one more enhancement, if you could contain gallery images within the same article or body width, and avoid starching it too wide.

Something to look into to aid development