How does a user create their own user page?
A few things I've tried here:
After consulting with @nettrom_WMF, it seems like analytics-privatedata-users is the level we want, but, would it be possible for someone to clarify what exactly is meant by "private data" on https://wikitech.wikimedia.org/wiki/Analytics/Data_access#Access_Groups ?
Fri, Feb 15
Roan's suggestion: use a single search input field, keep it on the home panel, toggle the search results (and other elements) on home panel if search is active or not.
Thu, Feb 14
@Etonkovidova after QA, please move this back into the ready for development column so that we can implement a fix which adheres to the desired UX (focus on search input does nothing; inputting text swaps to search panel).
what should we do with the editor_interface field?
@MMiller_WMF the most obvious solution is to go back to the previous behavior, where focusing the search input on the home screen swaps to the search panel before the user begins typing. Let me know if we should do that at least as a short term fix.
OK, the issue is not the spellcheck setting, I tested that locally just now.
I can reproduce. My only hypothesis at the moment is that this might be a side-effect of setting spellcheck = true for the search input field, which isn't done in Minerva or Vector's search.
Wed, Feb 13
@daniel have a look at https://sonarcloud.io/project/issues?id=mediawiki-core
@daniel we are currently using the hosted version of SonarQube at sonarcloud.io: https://sonarcloud.io/organizations/wmftest/projects
That's what I mean. What if you want to "cancel" but you accidentally click outside it and the thanks completes. Is this something we should be worried about?
Tue, Feb 12
@Pchelolo unfortunately this is still not working. I can see from the profile trace that the first job is enqueued https://performance.wikimedia.org/xhgui/run/symbol?id=5c6344dc3f3dfab50a29b7cf&symbol=ClearUserWatchlistJob%3A%3AnewForUser but after that, I'm not sure where this is falling apart. I could try adding some logging statements to ClearUserWatchlistJob#run if you'd like.
Follow up from yesterday's comments, we also talked about a different approach of using categories to annotate which pages should appear in the help panel links section. The challenges here would be (1) this can't be restricted to admins, (2) we can't easily use custom labels, (3) we'd have to figure out how to include pages that are not on the target wiki (i.e. kowiki help panel has a link to a help page on mediawiki.org). I don't think we'd go this route but documenting the idea here anyway.
Instead, please use something already defined and widely accepted by the tech community (both wiki and non-wiki), like JSON (we already have a content model for pages containing JSON, I am pretty sure that means it's possible to get a PHP associative array directly, however, I'm not sure).
Sadly, this doesn't fix the problem. On first search, the scroll is reliably stuck. It's possible that the latest patch makes it easier to "unstick" the search scroll but I'm not totally confident about that, since I've seen lots of inconsistent behavior with this one.
Mon, Feb 11
For future reference, you can tag me, UI-Standardization or Design for those requests…
and perhaps we can obscure page_id and page_title.
@Trizek-WMF for this:
We seem to be done with this.
Fri, Feb 8
That's another "yes" from me. I opened this ticket primarily to document that this exists. Feel free to close it and prioritize other tasks. We can reopen it if this becomes an actual issue.
@EBernhardson thanks for these notes!
<i>[obfuscated page title string]</i>
Lastly, I think "help" will be the easiest module of them all, because we've already written most of that UI elsewhere. Lifting and shifting this code will take a little bit of effort, but probably less than any of the other modules.
Thu, Feb 7
can we move this toward being tested as we await approval? We want to test in Test Wiki so we can look at the events in Hadoop.
I started hacking on this at all hands as a proof of concept. If we decide to move forward with this, we can use the patch here as a starting point. It's pretty close although there are details to work out.
Wed, Feb 6
MobileFrontend generates code coverage reports, so we can use that as an example for JS.
Tue, Feb 5
Came across this task while looking over my team's board. Special:EditWatchlist/clear is still broken.
Mon, Feb 4
We might want to also limit the maximum input length for the description.
Tue, Jan 29
Hmm. So I ran this locally with:
Mon, Jan 28
Thu, Jan 24
I've created two WIP patches for this which use different approaches, see above. In short, version A (486304) adds a new $body_only parameter to Utils::convert() and friends, which defaults to false. The Flow Parsoid Utils API has a new body_only parameter added, and it's set to true in the context of rendering a Flow post in VE. If you don't do this, the wikitext conversion to HTML results in meta, head, etc being in the textarea.