From what I understand it's something Google is working on. I've been dealing with the limitations myself for a while and it sucks, but hopefully it'll be fixed on their end sooner rather than later.

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

@20after4, just a heads up:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Ah, thanks! I've asked downstream if anyone still runs into any issues, but so far I also believe this is now resolved.

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

phabricator.wikimedia.org is running a version including these changes plus D16886 on top. So far it looks like a great improvement!

I caught another case of this: here, "Phacility" should be first, but is not.

I believe this is now resolved, in the sense that I expect all specific, reproducible examples I'm aware of function in a way consistent with user expectation. In particular:

I have some possible approaches for cheating on the "more than 100 results" case, but I think we ultimately need to put the prefix paging rule on the server side, so we return all prefix matches and then all content matches. That's kind of a big mess, but all the ways we can cheat will break down at some point (e.g., when you have 100 "wikidata" projects that are alphabetically earlier than "wikidata") so I think it's not avoidable.

@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.

@epriestley: Jaime, Senior DBA at the WMF, has posted some answers for your list of questions:

Also, reindexing is required after switching to innodb.

Does InnoDB FULLTEXT respect ft_boolean_syntax? If no: is there another similar option? If no: we need to parse queries ourselves and submit the +A +B version to the backend (see also T10642).

Just my 2c, but we've seen "table needs repair" on such a regular interval over the past 2-3 years of using Phabricator that our startup script includes a call to MySQL to automatically run "REPAIR TABLE" on startup. It's actually part of the Docker image because a broken MyISAM table will prevent bin/storage upgrade from running:

PHP 7.1 RC2 is now available, and the patch for async_signals was merged into what is presently the 7.1 branch.

Is worth to mention that PHP 7.1 RC1 is available. Does it resolve our problems with comparability?

This seems to be working, I think the last step is replacing the original call in the backup workflow.

This will "help" you "become more familiar with Phabricator's codebase".

I think most of these have been converted now, and the remaining stragglers are getting fixed up alongside other changes (EditEngine, third-generation APIs, etc).

I'm just going to close this since we've converted most of the Query classes by now and are fixing the remaining ones as adjacent work happens. These changes were just minor improvements to code clarity and there's no particular urgency to fully modernizing things, nor do we get to delete a bunch of code once we're done or reduce maintenance costs in a global way or anything like that.

I believe this is resolved with modern clustered repositories. secure has been spread across two hosts for some time now without encountering any of this.

I'm running into a need for this to make automated export reliable, too, and don't really want to put a second copy of set -o pipefail in the codebase.

In T9640#189032, @michaeljs1990 wrote:

@reet- If you are using ppa:ondrej/php they tend to be of higher quality then the official php packages maintained on ubuntus ppa in most cases. You have to trust someone however and in this case it's ondrej instead of canonical.

@reet- If you are using ppa:ondrej/php they tend to be of higher quality then the official php packages maintained on ubuntus ppa in most cases. You have to trust someone however and in this case it's ondrej instead of canonical.

Indeed very annoying. Updated our instance to 16.04.1 yesterday, and my day was not so happy any more. Of course this is not Phabricators fault, but I doubt that reading the Ubuntu release notes would have helped as the problem is not that obvious.

@michaeljs1990, is was actually not possible to install PHP5 on Ubuntu 16.04 through a safe means (an apt repository or similar) for some time.

It seems likely, as well, until php 7.1 is officially supported that you probably don't want to sign-up for some potential pain points by choosing to roll the dice.

I think you are using the word "only" wrong @PascalReintjens, @CodeMouse92. What you mean is by default. You can easily install any version of PHP you want this should not be a blocker for anyone. It's a slight annoyance but so is trying to keep track of the release cycle for RHEL, Ubuntu, CentOS, Debian, OSX, ArchLinux, Gentoo, and every other distribution you can think of.

In the case of Debian 9, it looks like it won't even freeze for 6 months. If it ships with PHP 7.1, it may well run Phabricator. It is impossible for us to answer compatibility questions about hypothetical software slated for release the better part of a year from now.

@PascalReintjens, correct, in the same way that it won't run under Ubuntu 16.04 (which also comes with PHP7 only).

Debian Stretch will come with php7 only. Am I right assuming that Phabricator won't run under Debian 9?

When we make a hire we can make them do this "to become more familiar with Phabricator's codebase".

I would like to add, to anyone browsing this and trying to get a new instance of phabricator working on php7, to not do that (since it isn't supported and is now blocked by the software itself).

I recognize as a user (and a developer myself) the situation and that, as a user, I'm just complaining and not giving solutions. I also recognize you don't want to be dual-developing phabricator on multiple fronts. We're running on arch so I'm extremely biased AND recognize that saying this isn't a workable solution but because of the "bleeding edge" php levels on arch, I would prefer focus on php7 (again, super biased and I know that isn't just going to happen).

What would you like us to do differently?

I think what is most frustrating about this is, having fought through php 7 configuration (without opening tickets, just trying to follow other tickets and doc), after an update today I'm greeted with having to edit source now to get php 7 (unsupported, I know) to continue working...

That option is "comment out the check", as @khanhicetea has done in T9640#184512. Phabricator is open source, and you are free to modify it.

Why so aggressive ? There should be an option to ignore warning since some users already run Phabricator in PHP7 environment. Such as :

At HEAD you should receive a setup warning that PHP7 is not supported. We don't recommend using it for production.

In T9640#182027, @tomelssjo wrote:

So what exactly do you need to comment out for this to work on PHP7? Is is src/applications/cache/spec/PhabricatorDataCacheSpec.php and src/applications/cache/spec/PhabricatorOpcodeCacheSpec.php

T11270 describes a major issue with asynchronous signal handling in PHP 7 which I don't believe we have a reasonable workaround for.

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.

In T9640#172158, @chad wrote:

I'll fire up a VM this weekend and see if there are any issues.

So what exactly do you need to comment out for this to work on PHP7? Is is src/applications/cache/spec/PhabricatorDataCacheSpec.php and src/applications/cache/spec/PhabricatorOpcodeCacheSpec.php

We discussed this briefly out-of-band, but the draft part of this is probably only sensible as "soft" prioritization:

This spawned a healthy set of followups, but I believe the core work described here is now resolved and accounted for and all future work is covered in narrower followup tasks.

Thanks for testing, that's quite helpful.