DoorkeeperTagView is also used for DifferentialAsanaRepresentationField, which is probably easier to set up (?).

The value is rendered here: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/differential/customfield/DifferentialJIRAIssuesField.php;70463e8a16d4cbe0c83b23b9328c4a359072c506$53

I'd need to see it to fix it. These are tags?

git blame suggests that this hasn't ever matched on word boundaries (it didn't in August 2012, when it was first written -- see rPHU45f7bd6a).

oh

It's intentional that we don't support these because they appear frequently in expressions source code, for example:

I believe this is now resolved and accounted for. See the remarkup documentation for some details.

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

Current state of the world after D16108 is:

In T11126#179873, @eadler wrote:

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

See also T11134

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

Looks like there's a JSON API: https://xkcd.com/json.html

I implemented this, sort of. However, it doesn't work cleanly because transactions are "adjusted" (have old values populated) after they are "expanded" (which generates the @user mention transactions). So when the code runs, it doesn't have access to the old text and can't easily figure out which mentions are new.

I think that's fixed in HEAD now. I pushed it here, let me know if you catch any cases which still misbehave.

Yes. [[ x#y ]] or [ x#y | some text ] results in a link to /x/#y/ which doesn't actually link to the anchor.

Specifically, the issue you're hitting is that [[ x#y ]] and variants thereof generate garbage output?

(broken wiki links everywhere)

+1 we just discovered this issue and ended up here

In T6916#179233, @epriestley wrote:

I have no idea if this is MP4 or not:

IMG_0370.MOV0 BDownload

I think this one works:

I have no idea if this is MP4 or not:

and this is what the feed entry for the previous comment looks like:

test page
1Zhttps://secure.phabricator.com/w/test_page/#derp-code/

This appears to have had a regression at some point

D16006 is the main fix; CORGI is resolved in secret at https://meta.phacility.com/D84.

• We'll bring something similar to D11297 upstream.
• T6674 discusses an issue where some mime types (notably, OGG) may ambiguously be audio or video. At a minimum, we'll provide {Fxxx, layout=video} or similar to force ambiguous types to render as a specific type. This may not really be much of a problem, but if we don't have an easy, reliable way to automatically detect whether a given .ogg file has video we aren't planning to put a tremendous amount of effort into detecting it correctly at this time.

I made some headway on this but I'm feeling really icky about it and I think I may want to try making PHUIRemarkupView more powerful and moving away from PhabricatorMarkupInterface first.

This is in master and live on this install. Let me know if you hit issues with it, especially on mobile. Seems fine on my iPhone 4 but I don't have a ton of devices on hand for testing.

quick note: even on systems with 'normal' windowing systems many users
dislike or can't use drag-and-drop workflows. I'm mostly mentioning this so
that the non-D&D workflow isn't entirely treated as a second class citizen.

D15953 played out more or less as described above. I'm not going to land it before cutting stable this week since it touches Workflow in a couple of ways that might have unforseen consequences, but I expect it to be available in master some time later tonight or tomorrow.

After D12066, we have an upload workflow which gracefully accommodates very large files (progress bars, resumable uploads, no server host needs to handle more than 4MB of data on disk or in memory at once). This flow is activated when you drag-and-drop, and we've successfully used it to transfer reasonably-sized cluster import/export files (1-2GB) for the better part of a year now.

Tagging Wikimedia - This task would resolve a regression we experienced after having moved from Gerrit/Gitblit to Phabricator Diffusion as primary repo browser. Gitblit, similar to GitHub, rendered .md files as Markdown by default. (Remarkup would be fine, too.)

In T5187#175015, @epriestley wrote:

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

See Paid Prioritization and L34 Phacility Prioritization Service Agreement for specifics, if you haven't run across them yet.

You're behind T10917 and T10939 in the queue (see the Prioritized workboard) and some other things which are wrapping up, so it will probably be about a week before we can pursue this. If that sounds reasonable, we can get this into the queue now and confirm with you before starting work.

Sure. I'd estimate this is 1-2 hours of work if we develop a patch ourselves and 2-3 hours of work if we work with @matmarex to make his patch suitable for inclusion and maintenance in the upstream. Which would you prefer?

@epriestley I'm happy to try to pay you to review the patch if that'll help.

(If that answer isn't particularly satisfying, maybe see discussion starting here: T7820#172877.)

We haven't seen much interest in this from outside WMF, so there are probably several hundred tasks ahead of it on our natural roadmap.

This is still a big problem for Wikimedia's Phabricator installation, making it unnecessarily difficult to file or amend bug reports about mobile issues.

I think I fixed this in D15847:

That seems to be doing something fairly reasonable in my client, yell if it looks funky somewhere else:

I think this isn't really too bad. The major issue is that we can't use stylesheets in email because Gmail doesn't support them, so we need to emit markup with inline style attributes.

In T10163#154382, @epriestley wrote:

• D15039: Two effects:
  • If you finish typing a word (e.g., type a space) and there are no results, deactivate since nothing else you could type could possibly cause matches and you're probably not fishing around since you just hit space.

Throwing a vote in that this feature would definitely be of great use to us as well.

When we make progress, we update tasks. We don't have a secret hidden version of Phabricator full of progress updates that we're hiding from the world.

Two years later, any progress on this? I have the same intention as several of the comments, which is to simply embed code blocks in a numbered list of things to do.

• If /w/x/ exists and is titled "History of X", it would be nice if [[ x ]] generated a link with the text "History of X" instead of a link with the text "x". Today, you must do [[ x | History of X ]] to get the proper link text.