![]() |
The Technical Barnstar |
I appreciate your efforts on Xtools! Mystrixo (talk) 09:49, 31 May 2024 (UTC) |
MusikAnimal
Thank you! :)
Hi!
You get this message because you are an admin on a Wikimedia wiki.
When someone edits a Wikimedia wiki without being logged in today, we show their IP address. As you may already know, we will not be able to do this in the future. This is a decision by the Wikimedia Foundation Legal department, because norms and regulations for privacy online have changed.
Instead of the IP we will show a masked identity. You as an admin will still be able to access the IP. There will also be a new user right for those who need to see the full IPs of unregistered users to fight vandalism, harassment and spam without being admins. Patrollers will also see part of the IP even without this user right. We are also working on better tools to help.
If you have not seen it before, you can read more on Meta. If you want to make sure you don’t miss technical changes on the Wikimedia wikis, you can subscribe to the weekly technical newsletter.
We have two suggested ways this identity could work. We would appreciate your feedback on which way you think would work best for you and your wiki, now and in the future. You can let us know on the talk page. You can write in your language. The suggestions were posted in October and we will decide after 17 January.
Thank you. /Johan (WMF)
18:17, 4 January 2022 (UTC)
I've been using your DarkMode extension (thanks so much for it!) and I was curious if there was any way to exclude everything outside of #content. I know I can add the exclude class to any item to exclude it, but what about items not under our control like the site logo or header?
You can use the same fitler
property to selectively un-invert elements. So to exclude the logo, for instance:
.client-dark-mode #p-logo {
filter: invert( 1 ) hue-rotate( 180deg );
}
I'm not sure if there's a simple way to exclude everything outside of #content, unfortunately.
Hello, I made a fork of DarkMode and made it usable by logged out users, added mode preferences, added support for toggling dark mode by URL parametres, etc. If I upstreamed the commits, would you be able to review them? Thank you!
Yes of course! There's one patch already open to add a ?usedarkmode=1 URL parameter, but I'm happy to go with your implementation.
Great! Should the patches be uploaded separately or in one single patch?
Please disregard the above message. I have uploaded a patch.
Hi, I don't understand how configuration works. I've tried excluding elements or styling elements inside the skin.css, is this not how it's done? Also can the dark mode toggle be moved up to the account links area, or maybe the sidebar? It's relatively hidden at the very bottom of potentially long pages, at least on vector, idk about other skin. I would really love to use this extension on my main wiki, but I haven't been able to figure out customization or how to move the toggle yet.
@Left-Eye-125 I just pushed an update that allows you move the dark mode link. See Extension:DarkMode#Configuration for instructions. That same section should also explains what's possible as for styling elements. If you don't want something inverted, give it the .mw-no-invert
CSS class. If you find yourself needing to do this a lot in wikitext, you may wish to add a template called say, Template:No-DarkMode, that simply wraps the given content with <div class="mw-no-invert">{{{1}}}</div>
. You can also style individual elements. Say you wanted to un-invert an element with the CSS class .my-element
. Your CSS could look like .client-dark-mode .my-element { ilter: invert( 1 ) hue-rotate( 180deg ) }
which ensure .my-element
is never inverted (because it gets re-inverted). Obviously, applying the .mw-no-invert
class is easier, if you're able to do that. Hope this helps!
Hi there! Hope you're doing well. Just wanted to let you know that I posted a question for you over at Talk:XToolsabout the edit counter limit.
![]() |
The Technical Barnstar |
Thanks for implementing the on-wiki AutoEdits configuration, and working on XTools in general! |
![]() |
The Technical Barnstar |
Thanks for implementing the on-wiki AutoEdits configuration, and working on XTools in general! |
Hello. Can you fix Module:Documentation? I imported the wrong thing and I can't find a suitable version to revert to. Thank you.
Never mind fix it :) Sorry to disturb you
Still not OK. You ruined the more-or-less consistent styling of MediaWiki.org, reverted everything to English, without a single justification. I reverted it to the last consistently styled and internationalized version.
Sorry, I protected the page on Meta (from which you imported it) but I do not know much about this module beyond that. Thanks for helping out, Tacsipacsi.
Hi, I am just wondering when you will release new version of xtools and pageviews. The unreleased commits are contain many improvements in Indonesian translation, and maybe others.
Doh, sorry about that! We usually have a pretty rapid release cycle, but this time we have some major changes that are a bit risky to unleash out into the wild. I will do my best to try to get things stable and deploy sometime this week. If for whatever reason that can't happen, I'll try to deploy only the changes to the translations. Best,
Okay, noted. Thanks for the info.
Hi,
Excuse me if the question seems silly, non-programmer having my first time to work with php and wikimedia, I've read Readthedocs 5+ times, I still didn't get how to run xtools after the installation. In phabricator guide there's a phrase "Run in web server". Could you please elaborate a little?
So far I installed the full list mentioned in Installation section of Readthedocs and after the step "composer install" I've set configuration options prompted.
I haven't created the XTools database (next step) yet but I'd like to test that everything before is set up fine and actually run xtools to make sure that previous steps are correct.
If there's a need for logs, comments, etc. please let me know.
Hello and welcome! I am thrilled to hear you have interest in contributing to XTools :) The "Installation" docs are more geared toward other communities installing a production XTools instance. As a contributor, you may find the "Development" guide to be more helpful: https://xtools.readthedocs.io/en/stable/development.html. Specifically, the server can be started with ./bin/console server:start
.
Now, I should warn you -- despite what the docs say, as a brand new contributor to Wikimedia you probably won't be granted access to Toolforge, and hence access to the production replicas. That's okay though; Instead, I would install a local MediaWiki installation and have XTools connect to that. You can refer to Manual:Installation guide on how to install a local copy of MediaWiki.
There are a lot of other complexities with XTools, so you will probably run into other issues. Please don't hesitate to ping me if you need more help :)
Thank you very much for your thorought response. Indeed, I could install a local instance of mediawiki, although encountered a problem regarding cache.adapter .
Following the instructions on readthedocs, I've set cache.adapter to "file_system". However I get the same error (shown in the details below the message) every time I try to interact with XTools. Unfortunately, the Link to the doctrinebundle provided in the readthedocs is not working anymore. Although it is available in the wayback machine, the instructions don't clarify what is needed to be done next.
May I ask for your help with the problem?
The error:
C:\Apache24\htdocs\xtool>php bin/console server:run
In ContainerBuilder.php line 1011:
You have requested a non-existent service "cache.adapter.file_system".
Hmm interesting. File system should just work.. no need to install anything extra. You sure the entry in parameters.yml looks like cache.adapter: filesystem
? The error suggests you might have it set to something like cache.adapter.filesystem: 1
I should also mention XTools hasn't undergone significant testing in a Windows environment. It's possible we're doing something that is incompatible with Windows. I would be surprised if the filesystem caching were a problem, though.
Unfortunately, the parameters.yml has this line "cache.adapter: file_system" and nothing seems to be incorrect.
Thank you for clarification about Windows.
I'll run some instance of Ubuntu and I'll try again. Actually, now I start to understand why I was getting some wild errors on the previous build (3.6.11), I won't dig into it, but it seems that a better choice is just to move to linux and forget about it.