The upload image control is only available from main conpherence (/conpherence/*, /ZXXX) so the images available to drag and drop are few and are things like the logo and your profile picture.

T1894#19092 specifically mentions a comment remarkup tag as a possible solution.

I have a basic implementation of this in D12691 and D12692. It's really hacky, but seems to work... I'd like to iterate on this after hopefully receiving some initial feedback. I'm not exactly sure how I should proceed.

So, this isn't really related to being a CMS, though having that ability might be nice (though much more complex). This task comes from a real use case. I am looking at migrating an existing wiki, and we have comments like "this list must be kept in sorted order" or "if you change this list, also modify that XML file". While I could translate these to small font italics or something, having a real comment syntax would be nice.

Best way to think about it for me is, plead a real use case, something that is bothering you on a day to day basis. Real problems from real use get our attention best. We try to separate out the 'wouldn't it be cool if...' tasks from the 'this would save me 5 real minutes a day' tasks. We also, if you haven't noticed, like to over-engineer things when possible.

In this case I tried to describe the problem as well, but let me try differently.

T1894 discusses something similar, but only for Phriction. It may or may not be what you're looking for.

What problem specifically are you having using Phabricator? Is this Phriction, Maniphest, something else? What are you trying to do? How often do you need to leave notes, who are the left for, should they be restricted in viewing.

I think (2) is the right way to go so I kicked this into T5378. I'd maybe still render them as URLs but they should definitely trigger mentions.

Presumably resolved.

Nice, I like that.

We moved away from project auto-association and I think that's sticking, so there's less of a consistency argument here now.

We were never able to reproduce this and no one else has reported it in more than a year.

to meemees is two many meemees

Not reproducing on this this install...

Hmmm... This could be handled like dot & cowsay! For starters: theres tex2im but it's not standard on many distros, there's also some forms of tex2png, also there's dvipng that You can use to convert compiled dvi file to png... there's more than one way to skin a cat... That's for starters.

Another behavioral difference which came up recently is this:

Ok make sense, thanks for clarification.

When you write  and the resource is not an image we have to handle that sensibly.

@epriestley to be honest, this kind of syntax was particular interested in the repositories on not actually in the wiki.
My git documentation is using markdown and referring local images (stored in repository).

That's blocked on T4190.

T7854 is a request to support Markdown image format

Add other protocols by configuring uri.allowed-protocols.

For this use case, I mostly think it should be a lot easier to preview Diviner documentation. You could maybe imagine a command like:

You can use this as a workaround in this case:

After T7149, drag-and-drop uploads support arbitrarily large files and resumable uploads for files larger than the chunk threshold (currently 8MB).

oic thx u :3

Yes, select a string to convert it in a clickable link, then click the "link" button.

I think it's this:

What is "click on link action in the toolbar"? Is it that they are clicking Action: Comment and selecting something from the dropdown, or is there another interaction? Does this occur on all Chrome forms, or just Phabricator?

Yeah, the main thing I looked at with the header was where the actual use was occurring. In real examples, most were in documentation or more long-form comments/descriptions. In those cases a simpler header worked very well. If you're using these more frequently in code-review or other short form comments, the display does not hold up as well.

I had similar feedback on the original diff I think -- I think this one looks a lot better, but we did lose the sense that the title is visually tied to the code block and is a label for the block content.

In T7444#99690, @chad wrote:

The problem with the old design is it has a number of display issues, bad font mixing, and the different colors were problematic. One way to keep the header connected would likely involve removing the color choices.

Interestingly the format seems inconsistent with email now too.

The problem with the old design is it has a number of display issues, bad font mixing, and the different colors were problematic. One way to keep the header connected would likely involve removing the color choices.

Im not sure if its consistent, but I liked the boxing that previously joined the header to the code block. It made it obvious that the two were related.

Do you have specific feedback? The old design was not consistent with other Remarkup blocks, so it was converted to a standard UI header. I went through a few dozen live examples before settling on this direction.

This was resolved by D11706.

Make sure that ALTERing a binary collated column which contains utf8mb4 characters into utf8 column succeeds with --unsafe.

This is relatively simple to fix, but we need to:

We should, yes. Until this was reported I wasn't aware of this issue and believed we had comparable support across versions.