Thanks!

Did this ever actually work? it looks like we're still embedding links:

Unicode has a page of heiroglyphs but they don't seem to be supported yet on OSX.

Thanks for the quick reply. It seems to be an issue with an internal script here, not Phabricator itself, so you can disregard.

I've heard you are exceptional with pets.

This is probably 5 minutes of work, I am just incredibly unreliable.

Oh, we do this in column now. I guess it's not 4 hours of work for me :)

Actually, I don't think we can really style the numbers of a numbered list independently of the rest of the list. They aren't directly addressable with CSS and the approaches I've found for doing it rely on using counter(...), which I think is unreasonably complex for this use case:

I can't reproduce this. Here's a diff with a new file:

151 seems to be the common default.

We have seen exactly the same error on our instance today, since updating to master. MySQL max_connections was set to the default of 151.

max connections was set to 250 (default?). We bumped it up to 1000, which seems to have fixed the issue for now.

Ah! Thanks, we'll get this fixed.

See Contributing Bug Reports if this is intended to be a bug report.

@rrfeng: You already brought this up in T11680 - please see and follow the reply you received there. No need to add comments in numerous places to decentralize any conversations about the (currently unclear) underlying issue you're perceiving. Please stick to T11680 - thanks!

Does raising max_connections in /etc/my.cnf (or similar) and restarting MySQL resolve this?

I can confirm that this bug also happen on a local install with a few users (around 15)

GitHub also does this:

We made one change recently (T11672) but that should cause us to use fewer connections.

I think the "graph trace" UI is not suitable for task graph.
The most scene which has problem is 1 task has too many sub tasks. And then the graph-status takes too much spaces of the page(It is so wide).

When rebooting the sql server, we get an error on:

The Web UI, in the Config > Core > phabricator.base-uri section it has the following:

搭建 emulator 的 code review

Please see Contributing Feature Requests for help filing feature requests. Thanks!

This should now just work without any changes at HEAD of master. Let us know if you're still seeing issues after updating.

I think this should work better at HEAD of master now -- let us know if you're still seeing issues after updating. Thanks for the report!

Presuming resolved by D16584. Thanks!

Submitted {D16584}

I've banged on this a reasonable amount locally without issues and the originating instance reports that this seems to have calmed things down in production with these patches, so it seems like this pretty much just worked.

There's a bunch of other Herald stuff we already do for this field so I'm just undoing the change from D14766, at least until someone complains that this field type isn't using the search logic they expect.

Yeah, go ahead and submit a patch. Thanks!

Minimum viable patch sounds good to me, but @epriestley handles all contribs. Not sure what he prefers here. Feel free to patch locally first and verify.

Pretty sure it was copy pasted from something else at the time; I don't believe I would have actually picked a glyph.

So I've figured out the underlying cause. Outlook is sending attachments without a Content-Disposition header. The current version of mimemailparser included with Phabricator completely ignores attachments without that header.

I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.

I was writing a lot of "Custom Actions", so I built this wrapper around the form handling pattern that was replicated around a lot.

I'm observing same issue in current ChromeOS 55.0.2858.0 dev branch.
At the same time image paste works in Telegram web client (seems that they use contentEditable div instead of textarea)
Do you know whether it's a chrome os bug or google deprecated DataTransfer.items in new chrome's?

This is still logged as an EXCEPTION. Is DELETE FROM phabricator_repository.edge WHERE type = 39 a reasonable step to take, to prevent administrators unfamiliar with the non-fatal-ness of this from being worried?

I think "Waiting" doesn't actually count as "Running", because it's "Waiting to run again" after an exception made the daemon die.

To fix:

We don't normally accept bug reports on prototype applications (see Prototype) but this is a one-line fix.

I have installed Phabricator from official documentation and get the same problem. I didn't create a bug report as I don't know the production steps. The problem occurred when I have upgraded Phabricator in July.

Makes sense, these are old versions of software. I will test with more recent versions of both Windows and Outlook to see if the issue persists.

To fix this:

Or I should say, the amount of time that would be needed to get to Windows 7 issues, would negate the need to support it. We're two developers and any bug is competing with thousands of others.

We have no plans to support Windows 7. Do you have issues with more modern versions of Outlook?

Having the same issue. Seems to only occur on certain panels. Adding the panel in question to a column now creates a duplicate in the opposite column. Removing the panel from one column removes it from both.

With the .eml files, you could change the From: and To: headers and pipe directly into sendmail or similar MTA.
If that doesn't work, I would be happy to provide a VM instance to assist in reproduction.

We don't provide support for other installation guides. Please contact that maintainer or install Phabricator from our official documentation,