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?

I would say, definitively. 'xxxxx' looks more like a placeholder for me, but that might be a personal preference.

This is fine technically, but I'm hesitant about introducing it because it makes the issues in T6522 worse in some sense. That is, this field really means something like:

If we masked with ***** instead of xxxxx, do you think that would have been more intuitive?

I am also affected. Is there any known workaround?

So, the information is just masked but really present in the real command call? The ssh man-page states what the options before the xxxxxs mean, I'm just not sure if the call is right when the information is masked. E.g. the clone call...does phabricator call with git@phabricator... or with the username provided for the ssh connection. anyway. Is there a log where the real command is written? Why is it even masked here?

the -l xxxxx is your configured SSH user, the -i xxxxx is the path to your configured SSH private key (it's written out to a temporary file).

Like, is "Students" a repository and not a project? Can you put "Students" into a project and filter open results that way? Where do repositories come into play?

How does grouping by repository solve that problem?

That data doesn't exist unfortunately, so it wasn't able to be migrated. You shouldn't see that on current badge awards.

I've got this on most of my Badges on the profile page (not here, 2 local Phabricator installations):

oh man that UI is old.

On CentOS 6 here using Webtatic PHP 7.0 with apcu. No apcu-bc available. I get errors with apc_sma_info() not found when trying to access the phabricator webpage.