Heh, just ran into this today

No problem, thanks for the report!

Awesome, thanks @epriestley!

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.

(From our own install's perspective) I don't think the would make anyone at all sad. It seemed to be a pretty random decision by one of our newer users while he was playing around with things.

Partly, just haven't gotten there yet.

(This is T6740, not T9979.)

Performance concern. At least one use case requires us to scour *all diffs and all diff ids*. Also a desire to avoid having deprecated calls in our codebase.

(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.

Looking through the code, looks like Maniphest doesn't use ngrams yet? Any reason?

I think this might be T9979 though.

Spin up a test instance on Phacility, build a reproduction case and update the ticket. We don't have any insights into how the server you mentioned is configured of administered. We can with Phacility instances if you can't install something locally.

@chad, thanks but isn't this an upstream bug? The example I gave downstream were of convenience. Do you need me to find an example upstream?

Please contact your administrator if you want to file a bug against Phabricator. I believe there is an area where you can file bugs for us to look into in the downstream.

Basically anything that would be accepted as a Bug would require you to have admin access to some install before you have enough information to submit it, so this is more-or-less a moot point.

I'd say 75% or more bug reports we get require administrative access to resolve. You can spin up a Phacility instance for free.

Confirmed this on my local. It seems to be due to D16851, specifically this line: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/diffusion/application/PhabricatorDiffusionApplication.php$104.

The Croatian letter "č" is also missing, but it's the only Croatian diacritic that's not present in the distributed version of Aleo, resulting in this:

Why? We set up email integration before, but each task needs to have specific projects so that didn't work and now I'm stuck doing the entry by hand.
This is in the realm of reasonable, and likely easy to solve with custom inbound addresses and Herald rules, or with a small extension to Herald. We might try to improve the documentation to make the feature easier to discover or understand.

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

Thank you so much for the tips! I'll check the resources and try them out.

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.

In T11900#201218, @epriestley wrote:

Have you looked at the existing lint support already?

The major advantage of lint over a bot is that it happens before code goes for review, so that patches generated by beautifiers like clang-tidy are incorporated locally. Reviewers never need to see unbeautified code or deal with inlines about formatting/style issues.

(Sorry I clicked submit too early)

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.

Ok, whatever you say.

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.

I tried the openssl connection you suggested and it still bombed.

General state of the world here:

Thanks to point out @chad I will take a look closer to it.

What about Node.js v0.10 and v0.12?

If you're still currently using Node.js v0.10 or v0.12, it is time to begin the transition to v4 or v6. Both v0.10 and v0.12 are considered to be in Maintenance mode currently and will fall off our support plan completely later this year.