I am using the Cosmos skin and I am finding that when I use the "category:pagename" I get a line of text at the top of the screen in tiny print that repeats categories i entered.
Any ideas why?
I am using the Cosmos skin and I am finding that when I use the "category:pagename" I get a line of text at the top of the screen in tiny print that repeats categories i entered.
Any ideas why?
I use Miraheze with the Skins Per Page extension and whenever I click "edit' (either the link or the fandom-looking button) the page url adds /w/index.php?title=title_name&veaction=edit but nothing else happens.
I can still go to edit source if the page has a segment, and from there I can use visual edit, but otherwise there's no way to do it.
Is there a known way to fix this?
Is there an way to enable dark mode on Cosmos skin, for example changing the background color to a dark one?
It supports the DarkMode extension in more recent versions for a start. Also the skin is almost completely configurable, changing the background color configs to a dark color will make the text colors adapt to the dark theme.
Fixed
Given the following menu items in the MediaWiki:Sidebar. When a bullet item is empty it is still drawn. No other skins behave this way, they all simply exclude those bullet items from the menus entirely. This would be nice to get fixed for cases where logic is used within the menu to present dynamically defined menu items. For example, here under Dynamic, if the user is a sysop then they get a link to PageForSysops but if they are not then the get a link to FAQforOthers. But the next link does not have the ELSE portion, so it will be empty output for non sysop users. When this last link is rendered in the menu it appears as an empty clickable link to nothing. If there are many logic based links there can be quite a lot of empty space which other skins simply skip over entirely. Thanks for any tips before I start digging into the code myself.
* Navigation
** randompage-url|randompage
*** helppage|help-mediawiki
**
**
* Dynamic
** {{#ifsysop:PageForSysops|SysOps or FAQ|FAQforOthers|FAQ}
** {{#ifsysop:PageForSysops|SysOps or FAQ}}
Thanks for bringing it up, I will also look into this soon. Does this happen when you set the menu in MediaWiki:Cosmos-navigation or just when in MediaWiki:Sidebar, and embeded into MediaWiki:Cosmos-navigation through {{int:sidebar}}
?
Great question. I will test that out. I have thus far left MediaWiki:Cosmos-navigation as is and am using the main Sidebar because all skins (more or less) utilize that menu.
Ok, thank you for verifying that, I will look into this tomorrow also and hopefully deploy a fix. Thanks again!
Hello, I'd like to apologise for the delay in fixing this. Some personal things came up. I will try and get it done as soon as possible.
No worries, whenever you get to it. If I had more time myself I might take a stab at a fix myself.
Saw in "Planned features" update to new FandomDesktop skin - can this be done separately, as another skin, or is there possibility to still use older version?
I'm asking because I've been managing wikis on WIkia/FANDOM for ages and don't know much about "raw" wiki management/experience. There is an obvious backlash on FANDOM against this new skin, I'm among those doesn't support this change, and I was pleasantly surprised that a replica of Oasis exists on MediaWiki.
When enabling the Extension:DynamicSidebar and using the Cosmos skin. The menu simply renders a menu named USER-SIDEBAR which is a link to the article of that name. This menu has no contents and is of a slightly different style than the other menus.
The above is added to the MediaWiki:Sidebar to enable the users own personal menu, if that article User:Username/Sidebar exists and nothing is rendered if that page does not exist, when using other skins.
Hello, I once again apologise for the delay here. I will try and look into this as soon as possible. One of the goals I had with Cosmos was to have support with at least most extensions. However this goal is something I've struggled with lately, as it seems to also have issues with the NoTitle, and JSBreadCrumbs extensions as well, do to the naming convention Cosmos uses for html elements. However I do plan to work on adding support for those as well, so I will add this to the list of extensions to verify support with. Once again, thank you for bringing this up. It is greatly appreciated.
No response, and this can be done with either configuration or Cosmos.css.
Hello, can you please elaborate on what you mean by "navigation color"? Thank you!
Nothing I can do to help in this unfortunately.
Sorry to be a pain and mention so many bugs or quarks that I have encountered. I do very much like the nesting menus feature that the Cosmos skin has. I am curious if you are aware of any way to add this feature to other skins that my users may also like to have. Would be great if they would all behave similarly. Thanks for such a great skin none the less.
Hello, and no problem, the bug reports are most welcome and greatly appreciated. Unfortunately I'm unaware of a sane way to do this for additional skins, I apologise.
The MediaWiki:Sidebar element for the tools is not rendered?
In the main set of navigation menus the special TOOLBOX element does not get drawn? Is there some way to get this to work without resorting to adding the special links which appear in that part when using other skins?
* TOOLBOX
Hello, I'd like to apologise for the delay in fixing this. Some personal things came up. I will try and get it done as soon as possible.
Has been long resolved.
We are using Mediawiki 1.35.2. The Cosmos skin looks a little off . There's a message in black text that says:
Deprecated: Array and string offset access syntax with curly braces is deprecated in /var/www/html/w/skins/Cosmos/includes/CosmosToolbar.php on line 242
.
Here is an image:
Disable E_DEPRECATED errors from PHP in production. See https://stackoverflow.com/questions/24559842/turning-off-deprecation-warnings-in-php-ini-file-wamp
The problem should be long fixed on the REL1_35 branch (like 8 months ago I fixed it), and the CosmosToolbar class doesn't even exist anymore.
Thanks again.
So this is interesting...
We use Cosmos from GitHub at https://github.com/wikimedia/mediawiki-skins-Cosmos. We also checkout REL1_35 because we are running MW 1.35.2.
skins# cd Cosmos/ skins/Cosmos# git branch * REL1_35 skins/Cosmos# find . -name '*Toolbar*' ./includes/CosmosToolbar.php
It appears CosmosToolbar.php is still present.
We use GitHub sources because it is easiest (on us) to keep things updated. We have a script at https://github.com/weidai11/website/blob/master/mediawiki/update-wiki.sh, and it updates to the latest sources for us:
wiki_dir=/var/www/html/w wiki_rel=REL1_35 ... # This finds directories check'd out from Git and updates them. # It works surprisingly well. There have only been a couple of minor problems. IFS= find "${wiki_dir}/skins" -type d -name '.git' -print | while read -r dir do cd "$dir/.." || continue echo "Updating ${dir::-4}" git reset --hard HEAD && git pull && \ git checkout -f "${wiki_rel}" && git pull done IFS= find "${wiki_dir}/extensions" -type d -name '.git' -print | while read -r dir do cd "$dir/.." || continue echo "Updating ${dir::-4}" git reset --hard HEAD && git pull && \ git checkout -f "${wiki_rel}" && git pull done
That's interesting because as you can see https://github.com/wikimedia/mediawiki-skins-Cosmos/blob/REL1_35/includes/CosmosToolbar.php returns 404, indicating it doesn't exist any longer.
Thanks.
Something looks odd. It looks like something is breaking a pull and checkout.
Updating /var/www/html/w/skins/Cosmos/ HEAD is now at 73faf13 only 1 readme for all branches Already up to date. warning: refname 'REL1_35' is ambiguous. Already on 'REL1_35' Your branch is up to date with 'origin/REL1_35'. Already up to date.
Are you guys rewriting history?
I've asked the tag be removed awhile ago, I don't have access to do that. It was created by me before moving to wikimedia gerrit and now it transferred over and now I can't remove it. Apologies for issues created.