I vote for an "unresolved setup issue" if you have an old MySQL version

In T7287#96789, @epriestley wrote:

The simplest fix for this would be to make the pre-5.5 sorting collation utf8_general_ci. Most columns with sort collations have only ASCII text (email addresses, usernames, callsigns) but these do not:

PhrictionDocument->slug
PhabricatorProject->name
ManiphestNameIndex->indexedObjectName
PhamePost->phameTitle
PhabricatorRepository->name
PhabricatorUser (name token table)->token
ManiphestTask->title
PhrictionContent->title
CustomFieldStringIndex->indexValue

Some of these would be easy to fix/degrade but it's hard for others. But it's probably cleanest overall to restrict this set of fields to 3-byte characters until 5.5, since that seems less bad than not having these columns collate letter case properly.

If they're really separate, put a newline between them:

Can you make unnumbered lists count as "text"? And to solve the ambiguous case where you want an unnumbered list as an item in a numbered list, you could use indention as a hint?

We'll render this as a level 2 header if there is any text following it. For example (use "View Raw" to see the markup):

In T7287#96791, @mholden wrote:

Is upgrading as painless as a "sudo apt-get upgrade mysql" -- or am I asking for huge amounts of trouble with that level of naivete on my production install?

Sorry, I pretty much have no idea.

Is upgrading as painless as a "sudo apt-get upgrade mysql" -- or am I asking for huge amounts of trouble with that level of naivete on my production install?

The simplest fix for this would be to make the pre-5.5 sorting collation utf8_general_ci. Most columns with sort collations have only ASCII text (email addresses, usernames, callsigns) but these do not:

Aaah, okay. Upgrading to MySQL 5.5 or newer and running bin/storage adjust will fix this. I'll look into getting it fixed for older MySQL versions.

./bin/search index --type USER had no effect.

There is also a very small chance that running this will fix it:

Hmm, I'm not sure then. Can you show me the output of this?

And, my head commit is at 5a9d70707b9e16169b8a298135b36dd133e2ae

And, my head commit is at 5a9d70707b9e16169b8a298135b36dd133e2ae

Nope, no adjustments

I updated about to the upstream 2 hours ago, I didn't notice any adjustments when I ran my "update.sh" script.

Just a guess. I actually can't reproduce this, though, at least immediately:

:p So is that a known bug, expected behavior?

I am a master sleuth.

Actually yes, I believe they do

Do all the problematic users have uppercase letters in their names?

We currently have a consistent way of creating links where you specify a full URI for an external link and anything else is guessed to be a wiki doc, and you may optionally provide a title, else the URI is used as the title.

Screenshot from description for posterity:

In general I think the Remarkup bar is very noob-ish, that is that the features only are useful if you are new to Phabricator. It'd be nice to build some sort of 'search typeahead shortcut' into it for referencing any object (not simply Phriction) quickly without leaving the page. I frequently have to juggle multiple tabs when looks up related tasks and diffs.

It would be a lot simpler to use HTML 5 File API together with a regular <input type=file /> field. This won't help the IE8s of the world, but will help users of non-standard, but modern operating systems and browsers.

I'm unable to escape the bar | to literally put it in a Remarkup table. Used both backticks and %%%|%%%.

Thanks!

Fixed by D11382. (You can put "Fixes T6968" in your commit message to automatically close tasks when changes land.)

Note the lack of double spacing and the glorious even margins.

Just write this:

After some discussion, this feels like it got more complicated and is largely inferior to "Signature Requests", a planned feature in T5505. I'm just going to merge this into that task.

This wouldn't leak the info (if you were not allowed to know about the signature status, the document would appear un-signed), but it might cause some confusion. Maybe using "red" for not signed, "green" for signed, and grey for "you aren't allowed to know" would resolve that.

I guess it's true that only people now who can edit a doc can see others signee status, and this leaks that info. Wanted to make note in case that's important :) I can't think of why a whether a document is signed would be private, but probably if this task is desirable it should follow the same policy logic as other mentions.

@lpriestley, if this sounds like something reasonable to you, let me know and I can walk you through it in more detail.

Diff here: D11297

Managed to get this working on our install, will bring together a Diff after testing.

A while ago, we added support for the HTML5 <audio /> tag. We can take the same approach for <video />.

I would like a configuration option, but I'm fine either way. I took me some time to get used to.

This is in HEAD now. I'll keep an ear out for complaints; the behavior has mostly seemed reasonable to me so far.

+1 for mobile browsers

Similar issue: backticks don't escape the pipe in table syntax.

For posterity, T6819 discusses the Guides issue specifically.

There's a "Plain Text" option in paste that stops highlighting in Paste.

Paste should get a "no highlight option" the user can select if its not there already.

I'm not entirely sure that no highlighting by default is always reasonable. For example, the company I work at developers mainly PHP, and pretty much all code snippets we write in comments, tasks, etc. are PHP.

this means to use what the user selects when creating the paste? if so, also agreezy

• If the block is in an inline comment on a diff, default to the language implied by the file (for instance, inlines on a .py file get Python highlighting by default).
  • agreezy
• If the block is on a paste, default to the language of the paste.
  • this means to use what the user selects when creating the paste? if so, also agreezy
• If the block is on a revision/commit, default to the majority / plurality language of the revision/commit? Not so sure about this one. Major issue I can think of is that a "PHP" revision may be majority/plurality HTML or CSS, and the highlighters are very different. This is probably hard to figure out, too, and could theoretically change over the course of a revision. Maybe better to leave this rule out.
  • I think inline comments should behave the same on revisions / diffs / commits -- defaulting to the language of the filename. all other comments should have no highlight by default
• Anywhere else (no context to infer language from), don't highlight by default.
  • agreezy

Hmm, I think it auto-reassociates because it's in the description.

I am unable to un-associate Guides to this task, also. haha.

rPHU31e0327 partially fixed some of this. Specifically, > --- is no longer interpreted as a list item:

And unhappily this doesn't solve the problem for mobile browsers :/

Copy/paste should already work in Chrome.

Just a question: the copy&paste scenario is mentioned here tangentially, but as a feature is very different from a vanilla upload button. Hast it been considered? The main use case are screenshots: user takes a screenshot, it's in the clipboard, can be inserted in a textarea with a paste action. This would be equally beneficial for all users, since it's simpler than drag & drop (you don't need to open the files app to drag from).

Assuming resolved.

Ideally we would not modify the RAW text at all, rather

I have a mild opinion about rendering the full URL -- I think we're better off preserving features of the input text when we can, and overall find features which discard input text to be frustrating more often than helpful. For example, if I type:

This request has been evolving at https://phabricator.wikimedia.org/T76095 and now we think that the good solution is to actually parse "https://secure.phabricator.com/T5378" just like T5378

Closed by commit rPa8be733e5ffe.

Closed by commit rPHU549aa1bf1485.

Closed by commit rPe872f79f6147.

You can use remarkup.ignored-object-names to ignore specific object names like T1 and P2 if they're common in your organization. If you don't have a use case beyond that, we probably won't pursue this.