Here are some more details about the error:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 21 2016
I increased upload_max_filesize in the vhost to 1G. Afterwards the arc land itself worked but the commit done by phd still shows the descibed log entry.
In the buildable page that lists all the builds, I was experiencing 6 second load times until I added:
Page loads in Harbormaster for us are almost instant after adding this index.
Jan 20 2016
I didn't add to Herald as I wasn't sure whether it's specific to these forms or if there are other forms which have these components and the same problem.
This is an issue in the implementation, not a configuration issue.
It'd be good to know if this resolves your issue, since our error message is debatable on "useful".
upload_max_filesize: Maximum file size PHP will accept in a raw file upload. This is not normally used when uploading files via drag-and-drop, but affects some other kinds of file uploads. If you exceed this, Phabricator will give you a useful error. This often defaults to 2M. Set this to at least 32MB.
Thanks. I figured out that the string in php is utf-8 and the one in json must be unicode. I must convert manually myself. It is now working correctly.
Jan 19 2016
So the preview didn't show the text on multiple lines. :/
Oh, you're translating Audit. That's why it says "Accept Commit". I thought you were translating Differential, sorry. Everything else should work in Audit.
- JSON does not use "\x" escapes. See https://json.org/
- The untranslated text is "Accept Revision ✔", I'm not sure why yours says "Accept Commit ✔".
- This config value:
Great, it works like a charm !
Jan 18 2016
Ah, I just edited because I realized the difference b/w hashtag and title. I don't like punctuation in hashtags anyway, so all's well. :)
Parens?
To clarify, you can put anything you want in a project name. Only hashtags have character restrictions. ??? Whales! ??? ~(BIG WHALES)~ is a completely legitimate project name, and will be forever.
I don't mind DCing use of [] in the title, if that's what you were saying we should do...forgive me if I misunderstood. If so, I need something to use as a replacement. We have projects that are Teams, Projects, Departments, and Groups, all which need to be easily queried, and all of which need to be obvious where they belong. Right now, I'm saying "IMF [Team]", "PawLIB [Project]", and so forth. Just saying "IMF Team" or "PawLIB Project" looks entirely too messy and disorganized for our use.
Specifically, the issue was that these commits contained strings like R2/R13, which the parser was getting confused about because of an improperly grouped regular expression.
This should be fixed by D15049. Thanks for the detailed reproduction instructions, including a repository I could clone locally.
- D15045 fixes the problem with "Additional Hashtags" getting smushed.
- D15048 fixes a problem where removing old, invalid "Additional Hashtags" could fail.
- D15047 should fix old hashtags 404'ing.
I'm hitting the same problem using Chrome (Version 41.0.2272.89 (64-bit)).
However when using firefox, I do not have this problem so it seems to be browser related.
Presuming resolved by D15030.
Jan 17 2016
Also having this issue on our install on all projects with characters like (, ), and *
Jan 16 2016
T10150 is probably describing the same issue, but this report is much more detailed.
Just a heads up. I hope those duplication instructions are sufficient - this is a very weird one.
Pygments added support a couple of months ago but hasn't released a version with support yet. See:
Do you have pygments enabled?
Jan 15 2016
Oh, that probably didn't get updated for the new IconSet stuff.
See some general discussion in T9893, although this doesn't seem to be an ElasticSearch 2.0 issue.
I am using elasticsearch:1.7.4 docker image. We thought using elasticsearch has advantages over mysql fulltext, is that wrong?
(Also: why are you using ElasticSearch instead of the default search?)
What version of ElasticSearch are you using?
@epriestley, Thanks, of course, adding any file to the next commit solves the problem.
By the way, it is a not a high priority bug since it does not broke the interface.
Sure.
Thanks, those reproduction instructions are clear and I expect it will be straightforward for us to reproduce and fix this.