Happy you fixed!

Thanks for the deeper investigation! I can confirm that with the last version and following my original steps to reproduce, no stuck daemon task about the mock looping due to an exception on http://phorge.localhost/daemon/ anymore, so I'm going to land this.

One of my favourite updates in my workplace was to store counts of feature usage per month in a table. Move forward 3 years, and whenever we need to update some code in a feature, we check for it in the table, and if it's not been used in 3 years we just scrap the feature.

Skip lint (javelinsymbols)

Great suggestions

• Implemented celerity_generate_unique_node_id()
• Implemented .collapsible-content > ul.remarkup-list CSS

Loved the comment, as otherwise I wouldn't have understood what was going on in the CSS. I've reworded it - hope that's OK.

JavaScript: ✅ I damn like your proposal and I think it is very OK, non-plus-ultra

I am quite happy with this now. Spent way too long on it, so I hope you like it too!

• Refactored the PHP code to build the collapsible button & div into buildCollapsibleIndex()
• Define the javelin call config first, then refer to it - saves defining the variables independently!
• Create an icon field in the button, allowing for open and close icons to be set
• Make both the icon and the text optional in the collapsible javascript - if you just want an icon, fine. Just text, also fine. Neither - sure!

So this is the only blocking Test that is failing:

We have just a minor issue but with a potentially working fix, and it's ready to land

I don't know. Let's see :)

The problem there is that by requiring collapsiblejx to have knowledge of the 'collapsible-toggler-label', we introduce tight coupling to it's caller. (see how adding 'jx' on to the end of collapsiblejx has made it uniquely identifiable?)
A better solution would be to have the collapsiblejx config contain 'btn_open_icon' and 'btn_close_icon' icons. I'll have a go...

avoid micro-optimizations that make this unreadable

• move duplicated button text into a variable
• improve formatting

• Renamed button/div IDs to remove spaces
• Renamed diffusion-collapsible-container to collapsiblejx
• Added margin-top: 10px; in the collapsible content - this overrides the higher up margin-top: 0px
• Moved webroot/rsrc/js/application/diffusion/collapsible-container.js to webroot/rsrc/js/core/behavior-collapsiblejx.js
• Renamed the JX from diffusion-collapsible-container to collapsiblejx - the single word collapsible was a bit too common if you 'git grep' for it.

As already noted we were affected by this margin-top: 0; that was making the TOC a bit too much attached to the button:

• sorry if I introduced an ID for just the label: now replace with a non-unique Javelin Sigil
• tried to fix the margin-top thing

I can also propose another small change to adopt a sigil for the button label, so we don't need an ID.

We need more help on this. Never approved anything similar, I don't have enough experience.

Tried to add a lovely icon but still keeping the label toggling and the whole button selectable

Renamed butt to btn as per PR. Much more common abbrieviation!

Minor, just suggestion

Happy to take your suggestions with a couple of changes

• Remove index from the config labels - we've made collapsible-container.js generic, and not just for an index.
• The reason for the if/else block was to enable long variable/attribute names so as to have self-documenting code. I've done away with it, but we do need a comment instead so as to show why we associate the 'push this to close' text with the open state and vice-versa.

I'm a bit confused (!) I thought there were no PHP changes on Rev 1414 and I approved it, but instead I now see that we have again PHP changes. It's unclear to me whenever the Diff I approved was "updated to reflect changes", or maybe I'm just totally crazy because of real life. Please share your opinion.

• Use dynamically generated platform path where possible

Hoping to be useful we can self-document this joining this group:

(This was already approved but I wait for another "Yeah land" since I changed a thing)

To fix this error:

Btw, there are some similar commands in src/applications/config/check/PhabricatorManualActivitySetupCheck.php. Should I change them as well? How can I "break Phorge" to see this page rendered?

I think there’s still a chunk to do here, including additional documentation during setup

• Actually the path is not needed here.

• Fix missing arguments to hsprintf; re-add csprintf to string using the %R conversion

• Improve prompts: use hsprintf instead of cprintf, add missing <tt> markers, simplify syntax

For future reference, I went digging for the difference between csprintf() and hsprintf(), and found the following:

This might be a duplicate of T15636

As an aside, what do you think of https://github.com/campbsb/example-phorge-php-project - should we put a selection of example projects on https://we.phorge.it, either as individual repos, or one repo containing a bunch of examples, or somewhere in the arcanist repo ?

(I will immediately hard-approve this lovely change as soon as we share whatever ACK like "Yeah let's log the planet" or "Yeah let's just show a user message")

OK the situation is a bit more clear now.

More complete test case added to D25472 which demonstrates the following error:

Interesting. I think this specific crash was not caused by a specific document, but it was probably caused by a specific nonsense request with a nonsense encoding.

Good points. This patch puts also the exception message into phlog.

In T15667#14211, @Sten wrote:

how many people use Phabricator/Phorge :-(

I guess the documentation needs an update on page https://we.phorge.it/book/phorge/article/arcanist_lint_unit/ and/or https://we.phorge.it/book/phorge/article/arcanist_new_project/

I basically completely trust speck if they say this works with TLS, and I verified this works without TLS. Tried with / without this configuration.

6 year old in-your-face unreported bugs like these make me wonder how many people use Phabricator/Phorge :-(

(I share the same question from Sten)

I'm 5% scared by this since in 8 months we may discover that $author could be an object and so an user may report our well-known exception in some cases. But, the method name is getAuthorString() so I'm quite sure that Evan Priestley already choosen that name for a reason, and so, probably the getAuthor() is always a string or null and nothing else, so it's nice to report alien things with an exception, as proposed here.

In D25428#12247, @avivey wrote:

• We don't use document.querySelector - we use JX.DOM.find, you can see an example in line 43

I love your change. Simple and effective and without impact on other parts.