@snaik phabricator doesn't currently support this. You can write your own however using PHPExcel. I can't see upstream supporting this as I can't imagine it would take significantly more time to just pull up muliple tabs unless the tickets are of very poor quality.

you just can't win :(.

It's fairly straight forward to add your own linter extensions as well, the only thing that becomes difficult if how you distribute them. Upstream doesn't help with this at all but you should be able to figure it out from the wiki if you have a need for them.

You are going to have to post more information. I am able to correctly see the error you posted following these steps.

Can you post your arclint file

Push to staging

Although this diff may be completely useless I did stumble upon something else. Since I was being extra lazy today I created this diff with git diff and made it through the UI. The harbormaster plan requires it to be pushed to the staging repository however that was not done so it's throwing an error as seen here https://secure.phabricator.com/drydock/lease/5342/.

I put up a diff that fixes this however I'm not sure if it's the correct solution.

this is absolutely not a bug in libphutil it is with lighttpd. I will post a small example above showing you why.

do you happen to be using a dns name that you populated using your /etc/hosts file?

That looks pretty normal to me.

@jonah214 I vote for see stuff that goes by. You can use the paste application https://secure.phabricator.com/paste/ so it's easier for us to look at.

do you have any more information from the logs? This also seems like more a question than a bug report since daemons not working right is rather hard to debug.

Sorry for this mostly stream of conscious while I was debugging the issue. The main way to resolve this that I found was find the DREV that is being processed in the workers table and kill it. I think some underlying issue exists in how this is being processed but until I have more time to look into it I am happy with just running ./bin/worker kill --id 123

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

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.

@Danny_B I am curious about your actual root problem as well. I have heard this from some end users but have yet to get a clear use case. Can you give an example of how you are using your workboards that this is a problem for you. I understand "too much email make it stop" however that is not something that is actionable and very short sighted.

This looks closer to a server configuration issue to me and is actually a pretty strange behavior (mostly because i'm not sure how the redirect after it looks like a request is served works). If I go to http://secure.phabricator.com/api/user.whoami in the browser i get the following

{
result: null,
error_code: "ERR-CONDUIT-CORE",
error_info: "You are trying to save some data to Phabricator, but the request your browser made included an incorrect token. Reload the page and try again. You may need to clear your cookies. This was a Web request. This request had no CSRF token."
}

as expected or maybe not? However if i run curl http://secure.phabricator.com/api/user.whoami i get

{"result":null,"error_code":"ERR-INVALID-SESSION","error_info":"Session key is not present."}

I have had users request this as well and we actually have a custom application that makes use of this. When you do this you run into other problems such as harbormaster doesn't clean up after tasks. That becomes the job of Drydock and you will have to write your own drydock blueprint to do this in any kind of sane way.

No this is just a general bug report since it's a fairly confusing error message for end users.

Can you update this ticket after reading this wiki please. It will save time for both you and the upstream.

Since it was super late and I should go to bed i decided i should try and figure out what it means.

I have not heard any issues from uses since we deployed this fix so I would assume it is resolved as well. Thank you!

Not sure if this should be another bug report but the / that is added at the end causes issue when using anchor tags i.e if [[ ../2016.19#gotolocation ]] was the markup the link would also be broken by adding a / at the end.

It looks like this problem is gone on php7 and hhvm based on this output https://3v4l.org/dP8LY#v5619

keep in mind that that was successfully compiled by removing lots of code https://github.com/RustJason/xhprof/commit/6c473e39fa93fb7f0acc3fae73f626e5c66dff1a and i'm not completely sure of the implications of the changes.