Filed as T11228

Please add the triple dash to the documentation page, I couldn't find it clicking on the main life-saver icon link.

This is probably better implemented as "content" ("content matches regexp...") than the narrower "shebang".

This reproduces for me:

I think the error is correct and the URLs are wrong. We should probably handle this with an Exception though. Also correcting our site links.

In our Use Case we set up a few flavors of "support" tags, which will only be used in the Ponder application. Requiring users to both "watch" and join these tags for the items they care about seems like a reasonable solution.

That sends them anything to do with the project though. If they only want to know about Ponder, then they can set up a Herald rule for personal notifications.

Thanks for the quick reply, much appreciated

Thanks, we'll look into it.

Every install that uses Phriction has long documents. We plan on adding additional features (like ToC improvements, builtin navigation, CMS, etc) to deal with this.

For example, look at this page, created with this tags :)

Root of problem: if you create a big documents in wiki, reading this documents can be hard.

Can you read Contributing Feature Requests and tell us the root problem you're having with Phabricator is? The tag isn't widely supported, so I can't see adding it.

8bb124c37de3dfa29fcd23d4be53a5696b705c81 seems most likely root cause. I can trace it down to ssh coming in from getProtocol which should be blank and give you an error.

I'm not sure what to do with your link. Here's what I can reproduce:

It should be erroring out that you're not putting in a valid URI.

Stock arcanist:

Bug Reports require reproduction steps.

eventually the dead ones appear to fall off the edge, but in the meantime UI doesn't give me a warning that my daemons are not actually running.

Ok, I just installed a new instance of the server in another VM.
Steps to reproduce, as far as I can tell, are:

Ah, ok, that was my fault. I actually had no saved querys, so I didn't see that option ;) Thanks for helping :)

Going to close merge this into T5307 which makes query -> panel more discoverable. Dashboard panels can run any saved query, not just built-ins.

Here's a Dashboard Panel with "Phacility" tagged Events.

Doesn't Calendar already offer this today?

... but I would be very happy to get just the repo on the card now, if we can upstream it until T418.

"Show repo on card" is T10992: Allow Object Item List be customized for display, which is T418: Integrate CustomField into more interfaces

Aye, that would allow to visually scan the cards, and to understand what repo is concerned by each change.

@chad Thank you for clearing that up, now I understand this design.

Would having the repository on the "card" solve the issue, albeit not as perfectly? My guess is for instances that 1.5k+ repositories, always knowing the repository on a diff card is likely useful, where just bucket queries are likely narrowly useful.

alrighty

I identified posts on invalid blogs with this query:

Oh, it actually should cause this issue as currently written. I'm just going to destroy the bad data until this appears in the wild in a more reachable way, I don't think there is any easy way to resolve it.

Post #667 has an invalid blog, so this is probably difficult/impossible for normal users to hit, but it shouldn't cause this issue. I'll see if I can reproduce it locally.

• PhameBlog calls delete() on posts directly, but should use the destruction engine to destroy them instead. Calling delete() directly means that edges, comments, etc., on the posts won't be cleaned up when a blog is deleted.

Oh, and we select the correct protocol for custom domains now, but don't enforce it when serving content. That is, these both work, and we always link to "https", but "http" should redirect you directly to "https" instead of serving content:

Few more things I caught:

Thanks, this reproduces for me.

In live comments, these links are bad offhand:

The goal is to sort the contributions of one person who committed to a lot of different repositories, to get an overview of where they contribute. For example, that allows me to identify what repos are on my expertise domain so I can review there / who I can contact to unblock situations for other repos.

• The stuff above should be better now, but I'm not sure if I got everything. We should run through that list again.
• The "Subscribers" and "Projects" links here do not link to the correct domain, and fixing them isn't trivial because they're event-driven extensions:

Probably go with data driven. I don't think these need to be sprited, but should probably inline CSS (base64) with celerity? I don't think these will be large enough to need to be in an image sheet.

You can also already filter by repository. Why do you need to group by repository?

This isn't an actionable bug report because it doesn't include reproduction instructions. Reports MUST include reproduction instructions; see Contributing Bug Reports and Providing Reproduction Steps.

Nevertheless, I'm still not sure how to debug this error message / my configuration.
Is there a way to test/run the Drydock Host Blueprint and get more information than the command failed?

There is significant usability/UX research into the readability and comprehension relating to the width of content on a web page. The wider the content, the more difficult it is to read and understand.

No.

Is there an attempt to change this?