Probably a good idea, but not worth keeping a task around for.

I think in D19196 the engine always generated uppercase text, but that got changed in D19200, perhaps?

how did this ever escape us

I wasn't able to reproduce the black background issue, exactly, but here's what I changed:

very good memes

hmmm

Actually, HTML mail has an issue now.

This is technically fixed now but the meme stuff is real old and rough so I'm going to maybe make some kind of effort to get through more of T5258, etc.

This is conceptually easy but no trigger character really makes a ton of sense. I'm going to decline this until it's more clear what the desired behavior actually is.

See PHI357.

Well, it half-works in email, so that's something!

You can do this

Ahhh, so you can't have multiple adjacent macros on the same line; that was my problem. I guess that could be special-cased, which would be linear with the number of "tokens that are macros coming before a non-macro" appearing on a line, but I'm probably the only one clamoring for multiple horizontally aligned parrots.

They need to be on their own line. I think this rule got added in 2011, shortly after I left FB.

I'm just going to merge this into T5258. There are two separate issues here:

This bug does exist on this server, but unclear why. Maybe related to size of image, but probably best solution is some command-line tool to regenerate all file transforms? I don't think making PHIDs easy to find inside the app is very user friendly.

In T12950#230520, @chad wrote:

Why did they need regenerating in the first place?

Why did they need regenerating in the first place?

@jeffprouty Shoot us an email at support@phacility.com with details about your instance and the issue you're hitting if you're a paying customer; see also https://admin.phacility.com/book/phacility/article/support/.

Just confirming this is broken for phacility hosted instances (it is for us at least) and that there is no work around to date? Should this be it's own issue? Or should we reopen this issue?

If nothing's been typed in the text field for more than 5 seconds the user probably wants memes

How about "i" for "image"?

⇧ + ↓

I am also keeping an eye on https://www.reddit.com/r/bonehurtingjuice/. It's still a small meme but if it takes off we're all going to be drinking bone hurting juice this time next month.

just need to assign a trigger for the typeahead.....hmmmmmmmmm....

Also our meme format is very outdated, the new meme format is:

@epriestley, I tested out the scenario with the change applied.

Ah! That fixed it, thanks @epriestley. I'll let you know once I test out that configuration.

Remarkup is cached, so you'll need to run bin/cache purge --purge-remarkup (or make an edit, or create a new post) to purge the cache.

@epriestley, I wouldn't mind testing that scenario out this weekend (I'll have to change a couple of domain name settings to create the scenario, but that's easily undone).

Happy to accept a patch for this (deleting that one line of code) if someone wants to claim that they tested the scenario above and it worked correctly.

That is, the problem would be:

I guess we actually have to test this use case:

I can fix if it's one line, I just assumed it was something super hard with external urls or something.

I blame the fun police.

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

Macros are disabled in Phame posts, via markup engine. This originated in D2202.

We have a hosted instance and seem to be running into the same issue. How do we get this going in this case? (Warning: we are new to phab!)

We don't appear to be affected directly and I've discussed this in the changelog now, so I'm going to close this out as I think there's no action remaining on our side. Let us know if anyone has questions, etc.

This isn't a valid bug report. Please see Contributing Bug Reports and Providing Reproduction Steps.

Oh, sorry, yeah -- for macros, you'd currently have to pick the file off your desktop with the file picker thing. I'm thinking more about a general "select some existing file" feature for other cases like cover images, where you can drag-and-drop.

ah, I misunderstood @epriestley's comments above.

We don't offer drag and drop upload on the Macro page. :(

From the create-a-macro page. Uploading from the home page just creates a file (which would be helpful if this task were complete :-p)

also, on Firefox, on our instance, I can't seem to upload a file by drag&dropping it.

also, on Firefox, on our instance, I can't seem to upload a file by drag&dropping it. I can't test on this instance due to policy.

Ah, interesting. I have F1 bound to "Expose: All Windows" so the flow for me is "Click > F1 > Drop Anywhere" to save, then "F1 > Drag > F1 > Drop" to load. I'm pretty sure I can get through that faster than I could copy-paste/type-select a file by Fxxx or from a browser UI.

In general I find drag and drop workflows to be slow and annoying (with rare exceptions, such as workboards). In addition my browser is full screen so the actual workflow involves opening Downloads, finding the file among the hundreds of files, and reuploading it.

In T10374#161140, @epriestley wrote:

For anyone else with other use cases in this vein (roughly "select an existing file from Phabricator" as an alternative to "select a file from the filesystem"), can you run through the scenarios in which you'd want to use this, and why it's preferable to just downloading the file first?

T10349 has a similar use case, where a user would like to select an existing file for use as a cover image.

Presuming resolved, but yell if I missed anything.

Caches should be purged, let me know if you're still seeing issues? D15311 will fix the underlying problem, and should promote and deploy in the next 24 hours.