D16837 should clean this up. Thanks for the thorough report!

Some discussion of current context in T10448#186240.

Oh, no, T7579 / T7580 are very slightly different. These probably do need updates at some point but I'll leave 'em for now

I'm going to merge this into T7580 since I think that's the same task?

I added "Mentions" (and "Mocks") recently in connection with T4788.

Just had this issue today on our mercurial repository. Exact same exception when executing ./bin/repository update --trace <repository>
I've managed to solve it.

@chad
I configure my Phabricator instance's MySQL with ngram fulltext parser and I can search CJK with mysql fulltext engine.

ah, seems like a restart of apache fixed it.

(Please ask general admin questions like this in Ponder).

We unfortunately do not take installation questions as bug reports. We're happy to assist with our Phacility Consulting if you need or use Support Resources.

In the phabricator directory, what does file bin/config say?

This is sort-of-maybe related to T11482 but I'm also not exactly sure what's step in the process is slow here.

I'm happy to change this if anyone comes up with good alternate wording, but I think this might be about the best we can do.

never mind I love the text area

In T11831#199501, @epriestley wrote:

Also
this text
area sure
is
small now

Yeah, the upper-right action thing is a little weird since we don't use it in other applications, but it has felt OK to me once I kind of got used to it / continued being too lazy to change it.

Why can I subscribe to events? But not accept?

Wouldn't miss it for the world!

This is probably the required test:

Which interaction exactly is taking a long time?

whew! good to hear.

Definitely there was a problem with the installation, for some reason the files got corrupted and downloading a fresh installation solved the problem.

Thanks chad. I will check if there is a problem with the installation and let you know.

Hi @kislinsk
Thanks for your answer! Sorry, I wasn't speciffic, I would like to change the default Home Page Pinned Applications for everybody. Is it possible?

Great!

Closing as Resolved since this doesn't seem actionable by the upstream without concrete reproducible steps.

/mail/ will tell you why you received any given mail.

We need to know how to reproduce bugs in order to fix them. Please take the time to give us all information needed about your environment so we can reproduce the bug. Id() missing means something is dramatically wrong with your installation, as no part of Phabricator is expected to run without access to libphutil and its functions.

For me seems to be quite good the information provided, but I try to explain myself with more details:

This report doesn't look to include reproduction information.

Yes, i manually built the pcre, enable utf8 and unicode properties.
this issue was resolved.
thanks.

Eventually building a setup check is the extent of our support here. You'll have to build/enable UTF-8 support for your system on your own.

pcretest -C

PCRE version 8.10 2010-06-25
Compiled with

No UTF-8 support
No Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

I open the debug mode, on console, i found errors:
preg_replace_callback(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0
Stack trace:
preg_replace_callback called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php:189]
PhabricatorObjectRemarkupRule::apply called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupBlockRule.php:78]
PhutilRemarkupBlockRule::applyRules called at [/lv_code/phabricator/libphutil/src/markup/engine/remarkup/blockrule/PhutilRemarkupDefaultBlockRule.php:17]
PhutilRemarkupDefaultBlockRule::markupText called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:232]
PhutilRemarkupEngine::markupBlock called at [/lv_code/phabricator/libphutil/src/markup/engine/PhutilRemarkupEngine.php:128]
PhutilRemarkupEngine::preprocessText called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:269]
PhabricatorMarkupEngine::loadPreprocessorCaches called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:133]
PhabricatorMarkupEngine::process called at [/lv_code/phabricator/phabricator/src/infrastructure/markup/PhabricatorMarkupEngine.php:73]
PhabricatorMarkupEngine::renderOneObject called at [/lv_code/phabricator/phabricator/src/applications/phriction/controller/PhrictionMarkupPreviewController.php:23]
PhrictionMarkupPreviewController::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/AphrontController.php:29]
AphrontController::handleRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:257]
AphrontApplicationConfiguration::processRequest called at [/lv_code/phabricator/phabricator/src/aphront/configuration/AphrontApplicationConfiguration.php:169]
AphrontApplicationConfiguration::runHTTPRequest called at [/lv_code/phabricator/phabricator/webroot/index.php:17]

The policies work like you expect them to. This is just like a revision saying "All Users" but not being visible to users who can't see the corresponding repository.

I think it makes more sense to have events inherit their policy from the import that created them (if they are imported events)? i.e. rather than copy policy settings on import, make the policy pull from the import similar to other systems (like how "build target" view policy is pulled from the "build" view policy).

But yeah, it is 100% not good to show this:

Okay, so I ended up having to restart my Phabricator instance to get the import to stop, then "Delete Imported Events" seemed to work right even though it took a reasonably long time to complete from the web UI (I feel like it should really be using the bulk operation infrastructure).

Oh god it's still importing even after I disabled the import and deleted events.

It's just very
important to
thoroughly explore
the applications

In my case (T9287), the dependencies are cross-repository, which I don't think we can reasonably automatically figure out.

(If we were better about figuring this out automatically -- which we may be soon -- would it be a problem at all?)

In T11833#199387, @epriestley wrote:

The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".

The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".

"Earlier" / "Later" ?

Or, of course, we could do:

I think there was no web UI for this until T4788, which added both options. Prior to that, the only way to mark dependencies was by writing "Depends On" in text (which still works). So we didn't previously have anything else, unless I'm misremembering.

(I've asked a wordsmaster for help, so maybe we'll have better ideas soonish).

I was used to the "dependency" ones we had, but I agree they're not really unconfusing enough.

Our use of "parent" and "child" are consistent with Git's use of "parent" and "child", if that helps: for example, git help log discusses the ideas of "parent commits" and "child commits" in many places, and "parent revisions" and "child revisions" have the same relationship order as commits do in Git.

What specific, totally unambiguous labels would you prefer these actions to have?

The Phabricator versions you listed above are also not current. Just a reminder we only take bug reports at HEAD.

Bug reports like this are exceedingly resource intensive on the upstream and as stated, we are unlikely to look into for many years if ever. I'd be happy to accept this bug if you can duplicate the bug in a new, clean, environment and completely list out all components needed to reproduce it. Overall as no one else is reporting this, it is likely an environmental issue - so understanding what is unique in your environment vs everywhere else Phabricator is installed is important. Things to look at:

Sounds good, thanks!

In other words is your array syntax always messagekey[gender][plural] or could it also be messagekey[plural][plural] depending on the variables?

We support unlimited gender/plural variants in any order. We have a number of strings like this: