We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

In T9360#183602, @chad wrote:

Is [HTTPS] simple? Not sure where to start? Nothing is jumping out at me here.

Suggestion from one chat I had:

I mean even having just a "Revert" button for each change would be easier
Even if you had 50 to click, it's better than manually undoing :)

FWIW we'd be perfectly fine with the following:

• allow editing phriction documents via Conduit
• create a panel which shows the contents of a specific phriction page

In T9360#182482, @epriestley wrote:

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:

• http://blog.phacility.com/
• https://blog.phacility.com/

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

This could still be improved, but the immediate confusion we encountered appears fixed.

We can fix the highly-tractable web UI part, at least.

(Just bookkeeping; there's no external priority on this.)

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

Mooted from a prioritization standpoint by D16139.

but yeah, a spacer could help too

That sounds good to me, should give us more clarity around the dashboard stuff.

Maybe I should just design out my dock idea, the dock then goes with Dashboards (admins can set the apps, etc).

When you're editing a homepage dashboard, just having a spacer bar there for the applications menu might help make it more clear that 66/33 is better in a lot of cases than 50/50 -- currently, you can't see what stuff will really look like until you're already done and installed.

I think some sort of logged out / open source public template would head off like the majority of these. I think I had a plan in another thread.

wow pretty sure I even picked numbers that add up to 100%

I definitely think we should skip the 3-column versions for now, I don't think we've seen any kind of need for them in practice. We could look at it again after Facts since I think some of these weirder things could make more sense on standalone dashboards, the app just isn't powerful enough yet for that to be paritcularly useful.

this guy is clueless: T5531#66370

T6444#81725

The other solution is just to make it so these are more hidden / advanced options. That the defaults we provide are good enough that users just modify those templates instead of making one from scratch.

Do you think 50/50 and 33/66 are always bad even for standalone (not-on-homepage) dashboards? e.g., if we had a "Phacility Metrics" dashboard in the future after Facts, a 50/50 of a "Users" column and "Revenue" column or whatever could never be a useful way to present the information?

My rough thinking for new homepage is roughly consisting of three things:

Haha, that's probably T10612.

Babel seems to have the same panel in both columns, too.

The problem with 50/50 layouts is they don't guide the user anywhere as to what is important. It basically says, everything is important and conversely, is difficult to follow the page since panels just appear everywhere.

Why do you think installs (offhand: Babel, WMF) are picking 1/2 + 1/2 if they're strictly worse than 2/3 + 1/3?

You're the only user we're currently aware of who wants to use the software like this, so I don't plan to address this use case at this time.

In T11260#183515, @epriestley wrote:

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

What would you like Phabricator to do when you look at events in its Calendar application?

But when I am looking at my calendar app, I want to see local times, for whatever timezone I am in.

Got it. Thank you! I just started the reindexing operations recommended in this release so I may leave things be 'til that finishes.

they won't not exist

"Ignored" in the sense of: no publishing, no herald rules, no audit triggers. Not, like, "they won't not exist".

Only that any legitimate commits pushed until things catch up will also be ignored. The repository will automatically leave the mode once everything finishes.

Ok; will let it do its thing then.

There was a relatively recent change to make Phabricator discover commits which are only reachable from tags and refs. As it discovers these commits, it will treat them like new commits and publish feed stories about them. This is a one-time event, but a few installs have a lot of tag-reachable commits for whatever reason. You can find a bit more discussion in T11188, and details about the change in T9028 and T6878.

This doesn't appear to even to be possible in Firefox. Here's a simple example:

Ah, I found the problem in our upgrade script. We run our upgrade in the following order:

Thanks for quick response; hadn't seen this before so couldn't tell how serious the errors were.

Oh, or Apache.

Just rebooted apache once more and things are looking better.

Also likely fixed by restarting PHP-FPM, that method is defined here:

Did you restart everything after upgrading? See Restarting Phabricator.

Getting the following when I visit differential/:

From the Firefox bug and this linked one:

This appears to be stable, and is now accounted for.

This seem quiet and is now accounted for.

This appears functional and is now accounted for.

Haven't seen issues; now accounted for.

The upstream part of this is working in production, and this is now accounted for.

We haven't seen issues with this and it's now accounted for (I believe it's also in production).

A substantial number of users have linked Google accounts in production and we haven't heard about any issues, so I think that aspect of things is in good shape.

This is accounted for and we haven't run into any issues upstream with it in production after using it for about two weeks, but let us know if anyone runs into issues deploying it.

For reference, @Danny_B filed a copy of this on HackerOne here so I could award a bounty for it:

Also worth noting is that Content Security Policy (T4340) would have prevented this. CSP is obviously worth implementing, but I believe the last attack it would have prevented was D4534 in January 2013, so it's hard to prioritize if it only defuses one attack every 3-4 years.

Instances currently have two capabilities:

The Phacility cluster has been patched.

In the future, please report security issues via HackerOne:

This is impossible.

Current task graph is great for visual representation... but can we get somewhere very simple list of blocks/blocked by?