No problem, thanks for the report!

I've marked D16909 as fixing this, but it just removes mysql.implementation, and uses the rule "mysqli if available, mysql otherwise".

I think this should be fixed now. Note that we still have T11165 floating around which may make it look like this is still an issue, by sending you to the wrong place when you hit "Save". That bug is dumb but fairly harmless so I haven't chased it down yet.

Oh, hrrrm, this is actually more involved since it's not just the .git clone URI that's in trouble. So I can't just ban . without fixing existing short names.

Okay, let me ban them for now and if it causes too much of an issue we can try just banning .git at the end.

Partly, just haven't gotten there yet.

(This is T6740, not T9979.)

(Is this a performance concern or do you just want like 6 fewer lines of code to maintain?)

Feel free to add it to Community Resources, you should be able to edit that page.

This is because we now recognize shortname.git in some cases, and it's ambiguous if quack.git is "the repository with shortname quack.git", or "the repository with shortname quack, addressed as a Git repository".

WMF has extensions and modifications to Phabricator so you shouldn't report anything you experience on that install to us directly. Report it locally, make sure it isn't because of an extension, then bring it upstream. The versions we could show you would not be useful anyway because they'd be hashes of local commits which do not appear in the upstream, so we would just close your report as invalid and say "test with unforked code before submitting a report" anyway.

I've marked D16905 as resolving this: we now recommend a minimum value (33554432).

See also T10246#163438 for Drydock, and the Harbormaster / Drydock documentation.

Here's the general shape of how to do this. Since we encourage synchronous pre-review lint to fill this role instead of asynchronous build-like processes, support is much rougher than support for lint.

Have you looked at the existing lint support already?

We have at least one tricky issue remaining: when applying storage upgrades, we currently apply them like this:

Although it's very possible that this is a bug, this state also has a 72-hour internal cache which wasn't written correctly in older versions of Phabricator.

See T11898 for the previous iteration on this.

Please read Contributing Feature Requests carefully before filing a feature request.

Can you show me the <VirtualHost> entry you've added for Phabricator in your Apache config? I suspect you may have omitted the B flag in the RewriteRule.

Phrequent is a prototype, and we don't accept bug reports for prototypes. See User Guide: Prototype Applications for discussion.

General state of the world here:

This should now be fixed in HEAD of master and stable.

Cool. D16901 should fix this properly. Thanks for the report!

Yeah, looks like some credential shenanigans are afoot. I instrumented the user we're actually connecting as and am getting a mixture of what I passed with -u ("trunk") and the default user ("root").

Maybe also: do you have cluster.databases configured?

If you run this from mysql directly, as root, does it work?

I'll strip restricted handles from the "Mentions" lists.

Description!

Wow, isy is quite a productive little worker!

I can't reproduce this either. Here's what I did:

Yeah, I tend to agree. I don't really see any approaches we can take here that don't make things a little worse for experienced users who already know what they're looking for, and I'm not sure there's too much of a use case left for less-experienced users.

This is sort of what I was thinking about for the "Search Description" / "Usage Hint" (descriptions / projects are random examples):

Did you follow our installation guide, or did you follow a third-party installation guide (for example, a blog post you found somewhere on the internet)?

Pup was very well behaved while running the errands.

Okay, whew. Losing the opportunity for that joke was really keeping me up last night.

(You could write some similar rules if you want to try something in that vein, although it's a pretty big pain to fork JS/CSS right now.)

Okay well @chad resigned from D16893 as soon as he saw animation in a CSS file so I don't think that one's going anywhere.

Alright, I'm going to try this:

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

I caught another case of this: here, "Phacility" should be first, but is not.

Oh, sorry, I meant: if security.alternate-file-domain was configured, that prevented this problem.

I'm reasonably sure that fixes it; let us know if you're still seeing issues after updating.

(This likely would not be reproducible on any instance which has security.alternate-file-domain configured, which is why it wouldn't reproduce here or in the Phacility cluster.)

This reproduces somewhat-reliably for me with Quicksand (Persistent Chat) on.

Too bad too because I was going to write a great joke about soldering port 22 to port 2222 on your motherboard.