Mon, Jun 17
You can see an example of not knowing in MediaWiki by blocking a test user from a namespace (say MediaWiki) and then attempting to create a new page in that namespace.
This appears to work now!
There is a problem with the protocol in the redirect, here is a PR to fix the problem: https://github.com/ms609/citation-bot/pull/1794
The bot should work as soon as this consumer is approved:
I think this has to do with the confirmation email that is sent when you change your email. I suppose someone could use the conformation email to harass you, though if the other person already has your email address, there's nothing stoping them from using a bazillion other systems to send you an email.
Sat, Jun 15
It looks like the callback url is wrong:
The changes were merged and deployed by the maintainers: https://tools.wmflabs.org/citations/
ok, I've made the small UX change. After you fill out the form (or use the gadget) it will ask you to authenticate, then it will redirect you back to your original request.
Fri, Jun 14
I created a new PR ontop of the existing one:
@EvanProdromou ran into this one again today. :)
Thu, Jun 13
Wed, Jun 12
> So I guess we use BlockManager to get the blocks of a user?
Tue, Jun 11
I suppose now that we have MCR this could be rephrased as: "Adding structured data to global user pages" much like StructuredDataOnCommons adds structured data to global files.
So are we going to implement PSR-7 properly? If so, can the task description be updated? If not, could it be explained why we wont be?
Mon, Jun 10
Thu, Jun 6
I don't have a preference. :)
Wed, Jun 5
Tue, Jun 4
@tstarling have all of your concerns with PSR-7 been resolved? If so, can we move forward with a proper implementation?
Mon, Jun 3
To put this another way, you have to do this operation at least 18,867 times in order to see a difference of 1 millisecond.
So we're talking about a difference of (0.83 / 1e7) - (0.30 / 1e7) = ~0.000000053 seconds (if my math is correct). Seems like a micro-optimization at best.
It appears (from what I can tell) that PHP (as of version 7?) implements a copy-on-write strategy for cloning objects. If this is the case, then the performance concerns with implementing PSR-7 do not appear to be justified.
Fri, May 31
So there are three potential behaviors with the API:
- The preference is saved locally
- The preference is saved locally OR globally depending on the user's preference for that preference
- The preference is saved locally OR globally depending on the user's preference for that preference IF the preference is in the config (which is different for each wiki and is not exposed with the API) OTHERWISE it is saved locally.
Thu, May 30
I'm not sure how this resolves the problem(s) I mentioned above. You're allowing an extension to change the behavior of a preference regardless of where it is saved.
This might be naive, but why are immutable Responses so bad? Couldn't we provide a mechanism to replace the response rather than mutating it?
That's true, the model is different for this page and Special:Preferences. This page is changing the mute preferences of a single user where Special:Preferences is changing the muting preferences for multiple users.
This exception can be reproduced by removing this node (and it's children) from the DOM:
<select tabindex="0" aria-disabled="false" name="wpReason" class="oo-ui-inputWidget-input oo-ui-indicator-down"></select>
and then saving the form.
Wed, May 29
If we do unify the lists, the messaging (and the clarity of the action(s) being performed) can remain, which is what I would do. This can be done at a later date, but I would prefer to unify the lists over adding the checkboxes.
Fri, May 24
To clarify, we can only go with that display if we are committing to combine the two lists soon after.
There will be a new entry point file, rest.php, which invokes the static method MediaWiki\Rest\EntryPoint::main().
Errr... well, I guess we could always fake it and use the same logic again, so if we know it's an empty partial block, then we can remove that from being displayed.
Oh, nevermind, I remember why we did this, it's because there is no database flag for if it is editing or not. A non-editing block is an empty sitewide block (for now). If you would like to create a task for that, I can write what would be needed (a new field in the database to distinguish editing blocks for non-editing blocks).