- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 14 2023
May 25 2023
Jan 11 2023
May 5 2022
Apr 10 2019
I like the idea of using two-letter codes for language projects though you obviously run into the issue of only being able to link to one project in that language that way (e.g. w.wiki/de would presumably go to de.wikipedia.org, not de.wiktionary.org, etc).
Nov 11 2018
Oct 11 2017
In T177949#3676337, @Aklapper wrote:Not sure if @DanielFriesen still maintains this codebase?
Jul 17 2017
Nov 18 2016
Oct 17 2016
I'm not sure how $wgConf works.
Not all wiki families are separated by domain; some use paths instead and this pattern will break for that.
May 7 2016
@ashley They just want to use MW to host the policy pages rather than use it like an actual wiki. So omitting things like content_actions and just switching to Vector for logged in users should be fine.
May 6 2016
@brion Also some privacy software / virus suites / intermediate proxies supposedly strip out the Referer header as well.
May 4 2016
In T40417#2265444, @Bawolff wrote:In T40417#2263011, @Krinkle wrote:We can potentially avoid session inflation by creating the session separately from creating the edit html (which would indeed allow session inflation if an attacker requests edit urls repeatedly without cookies enabled). For example, we could start the session from JavaScript on the edit page in a background request (AJAX).
I don't understand how that would help the session inflation problem. The problem (if it still is a problem) is too many users have cookies on the client side, bypassing varnish. Using too much space in redis/whatever to store sessions on the server side, is not the problem (as far as I am aware). Creating sessions with javascript should not make a difference in that context
@Krinkle Javascript! Thanks, I just noticed a factor I wasn't taking into account this whole time.
Mar 18 2016
Somewhat relevant old RFC; for which code was completed but simply halted because no-one would review it.
https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0
Jan 13 2016
In T118932#1932148, @Tgr wrote:In T118932#1932051, @MaxSem wrote:Practically speaking, there is a huge difference: Ubuntu 14.04 LTS comes with PHP 5.5 and will be supported until 2019. You can't get anything like that for PHP 5.3.
How is that a practical difference? PHP 5.5 stops getting security fixes six months from now. (link) Is Ubuntu going to write/backport security fixes themselves?
Dec 3 2015
In T118932#1846869, @Betacommand wrote:I think that 1.27 should ship with 5.3 or 5.4, and then move to 5.6 after the LTS, Given how difficult it is to get third party hosting providers to update php we shouldn't use our LTS to move to a cutting edge version. Lets use 1.28 for that.
Nov 6 2015
In T107561#1788847, @cscott wrote:Daniel Friesen mentioned browserify as a major contributor to the move of client-side libraries to npm, although he warned that there were essential conflicts between "server side" and "client side" users of npm which would lead to confusion and delay as more client-side packages migrated. He also made some ResourceLoader-specific points which I don't feel confident recapping accurately.
Oct 5 2015
In T30085#1701267, @devunt wrote:@Tgr Then keeping old email addresses as same as now and only saving new email addresses as lowercase would be ideal?
Oct 4 2015
You're right. I also tested with 500MB before, but it looks like Node.js requires 1GB of ram even for something as simple as this script:
console.log('...');
Oct 2 2015
While the intention is to try and make things easier. This change basically adds a brand new unintuitive piece of syntax that now everyone has to learn.
Oct 1 2015
In T30085#1692382, @Qgil wrote:In T30085#1691937, @Tgr wrote:where 1 has poor usability (why does my password not work?)
"We cannot log you in because this email address is being claimed by more than one Wikimedia account. You can log in using your username, and you can change your email address in your Preferences."
Sep 26 2015
Sep 25 2015
At least DigitalOcean has small $5/mo servers.
Sep 24 2015
In T113210#1672261, @Ciencia_Al_Poder wrote:Packages often do weird things with dependencies, so if you plan to install apache+php+mediawiki on one server, and mysql on other server, but the package marks a database server as required, you will end installing mysqlserver on the webserver where you don't want it, or else it won't install. This is something to consider.
Jul 30 2015
The issue doesn't appear to exist anymore. Either the donation form changed or LastPass made some improvements.
Jul 24 2015
May 27 2015
Apr 9 2015
I also brought up currently existing bugs and flaws:
The possibility we might actually want Allpages to be reasonably indexable (potentially helpful to smaller wiki).
Why was the RFC simply accepted with absolutely no discussion over the negative effects of blacklisting /wiki/*? which I brought up on wikitech-l and on the RFC's talkpage:
Mar 11 2015
Mar 3 2015
Mar 1 2015
Feb 28 2015
In T89456#1075262, @Ricordisamoa wrote:In T89456#1073608, @DanielFriesen wrote:Note that in the case of licenses our license-name may need an upgrade.
What do you mean? Both 'schemas' use SPDX codes:
Feb 27 2015
In T89456#1073289, @Ricordisamoa wrote:Of course they can't be deduplicated right now, but some of them (except for name and description, as @DanielFriesen pointed out) are actually redundant between the two .json files.
Feb 23 2015
Another note on something I noticed,
https://getcomposer.org/doc/02-libraries.md#specifying-the-version
Feb 21 2015
In T89456#1056654, @MarkAHershberger wrote:I think you did a good job of this. Thanks, especially, for identifying
why description might not work. I suggest that we talk to the SMW devs
about that one.
...
I agree with the caveat that I think there may be a way to compromise on
description.
Feb 20 2015
In T89456#1054723, @MarkAHershberger wrote:There was some discussion during the meeting about being able to refer to composer.json from extension.json if it contains the information already in order to reduce duplication.
I would suggest that we fall back to reading composer.json if it exists and an extension.json does not exist. This would allow us to gather basic author and name information for display on Special:Version.
Feb 17 2015
In T18691#1043526, @Edokter wrote:In T18691#1042886, @polybuildr wrote:From what I can see in Resources.php, loading only the (default) skinning/elements.css and not content.css or interface.css.
So, why is this CSS not in skinning/elements.css? That's where headers and links are styled for all skins.
In T89456#1043385, @mwjames wrote:I came to the conclusion that for the repositories I'm involved extension.json brings no benefit nor does maintaining information in two files (composer.json and extension.json) is time well spent. For us composer.json has functional relevance but extension.json has not therefore I can't see any motivation to actually maintain such a file.
Feb 16 2015
In T89456#1042122, @Ricordisamoa wrote:At least: name, description, homepage, author and license should not be duplicated between the two.
Jan 10 2015
@Paladox this is about allowing users to explicitly pick a skin that happens to be the default (and won't change if the default is changed) or explicitly pick the site default skin (so it will change when the default changes). So it is not done.
Jan 6 2015
Jan 2 2015
en is already en-US, there's no point confusing people by having them both in preferences.
In T33874#952505, @MrStradivarius wrote:We shouldn't be so quick to throw away "en". There is such a thing as International English, after all, so "en" doesn't necessarily have to refer to American English. Also, if we only have en-US, en-GB and en-CA, it doesn't leave any other category for other Englishes, of which there are quite a few. I imagine quite a few Australians may prefer "en" over "en-GB", for example, even though the spelling may be closer in the latter. Also, we shouldn't forget dialects like Indian English and Singlish. Perhaps English speakers of those dialects could get by with en-GB, but perhaps not; more investigation is needed, I think.