I'm going to merge this into T10510, which discusses improving Harbormaster error behavior.

Yes, you are correct, I want to wildcard the repository names. Thanks for your alternative fixes. The low priority is not a problem.

@pingpongboss, in T11787 it looks like you actually want to wildcard the repository names, not the paths?

I'm just going to "fix" this by just preventing you from hiding/locking/defaulting these fields, since it doesn't seem useful to create a "New Event on January 3, 2013" sort of form anyway.

No easy way, but we'll keep a lookout for how common this request is and roll with it if needed.

D16752 was approximately the same thing but I think this is a little complicated -- both in general, and for recurring events. I'm also not really sure this should use the trigger system at all.

I don't suppose there is any easy way to add this to a users preference settings? I often compose complex stuff in conpherence and am continually sending incomplete messages to the chat...

@khanhicetea RC5 is out.

In my opinion, everything has risks, they will release final 7.1 if it's stable enough. So at the moment, using PHP 7.1 RC 4 is better than commenting out source code with PHP 7.0

Like others, I have been bitten by the PHP7 upgrade issue on Ubuntu 16.04.

I tried stopping aphlict notification server. Stopping it has no effect, the issue still reproduces if I have Persistent Chat enabled.

Yes we are. I can try to stop the notification server tomorrow, will see if that makes any difference.

I'm not finding anything magical that triggers the error at least against this server or my test server. Are you all running notification servers?

@chad I cannot reproduce the issue on this server.

If you do Merchants, you could add sendFromEmailAddress or whatever and maybe shortNameForEmailSubjectLines (perhaps with less-awful names) and I can hook them up at some point so this:

I think I had a similar diff floating around.

I guess the Merchant version would be businessAddress or something since Merchants aren't normally billed.

I think we could reasonably do this:

I don't mind doing this, if you know what it is you want.

An instance needs their own address (and some other information) on the invoice for tax purposes:

It looks like the underlying issue (T11469) was resolved through configuration changes, so we don't need to go any further here. We are writing this log now, but it could use more work eventually.

Another instance was reproducing this more frequently/reliably and reports that they're no longer seeing issues, and I haven't been able to reproduce it myself since the configuration changes. Presuming we're in the clear now, but let us know if you see further issues.

I think this is actually a bug between several of the 300 different pieces of scroll magic we have on the page.

@chad when persistent chat is open here the preview works fine. We also use Mac/Chrome.

Are there errors in the javascript console? I have persistent chat always on, using Mac/Chrome - and haven't ran into this here on this server. Can you reproduce here? A specific task or diff?

@chad
YES! Thank god

@rphl @samr can you confirm if your users were using "Persistent Chat" when they encountered this? I'm trying to find a repro with that but haven't quite yet. It is plausible given the magical nature of Quicksand.

I don't believe this is possible to fix without significant performance penalties for everyone else, given content is ajaxed in.

Can you reproduce that on this server? Offhand I cannot, but "Persistent Chat" is Quicksand based, so it make be dependent on a certain way you navigate. Quicksand is an ajax layer we use to build full pages.

Hah, I found out what triggered the error on our installation.

I can't reproduce this by following the steps you describe. Here's a screenshot of this working properly for me:

Well, I was going to overclock my toaster, but I got some e-mail about a recall because of DNS or whatever.

In almost all cases, it's within a second or two of the push.

Much appreciated.

I'm going to merge this into T11330, but note that you can already do this via Harbormaster, as this install does (we build via Drydock, but you can run a "Make HTTP Request..." build plan instead).