Thanks for the recommendation, Andre! I conferred with @valerio.bozzolan and he agrees, too. I have updated the patch.

• Use phutil_implode_html() instead of implode()

(Per my last comment)

I can reproduce but the title is so generic that makes this not actionable.

I guess that would imply editing 15-20 *ConduitAPIMethod.php files which currently

$limit = $request->getValue('limit');
if (!$limit) {
  $limit = $this->getDefaultLimit();
}

and add something like

if (!is_int($limit) && !ctype_digit($limit)) {
  throw new Exception(pht('Field "limit" must be an integer value.'));
}

? Hmm.

That's because we applied D25415

Cannot reproduce anymore / fixed?

Lol. I don't know what we should do here. Feel free to wontfix. Probably this is the solution to an unclear issue.

In D25619#17360, @speck wrote:

Ah, yes thank you for the video. I should have clarified but was asking for screenies of the result after this change. The changes look reasonable but I’m not a regular css user

Ah, yes thank you for the video. I should have clarified but was asking for screenies of the result after this change. The changes look reasonable but I’m not a regular css user

@speck here you can see the described overflowing:

Test for feed: https://we.phorge.it/source/phorge/browse/master/src/view/layout/AphrontSideNavFilterView.php

All described here with screenshot (and now video): T15809

screenies?

Should the conduit handler also check this and throw an exception? Doing so will send back a more informative error to the caller. I did some of this in https://secure.phabricator.com/D21872

Haven't tested yet, I was just trying to document the patch behavior.

Just a question. Does it work for you? Since locally, {#FA8072} still does not work for me.

Thanks!

Add return value (though it seems to make no difference)

Root problem is the https://we.phorge.it/source/phorge/browse/master/src/view/layout/AphrontSideNavFilterView.php with its styles: https://we.phorge.it/source/phorge/browse/master/webroot/rsrc/css/phui/phui-basic-nav-view.css

Yeah, I believe the most important adaptation is the //File a Bug Report// section saying that until you are confirmed as a "trusted contributor", you need to report bugs in the form of a Ponder question.

To implement this, you may want to start from this 🌈

(Oh sorry avivey, I have not noticed your priority action - I agree)

I do not (yet?) understand the use case of this task.

Indeed reported from a Wikimedia user about Wikimedia Phabricator.

I have a nice working version here, which renders the diagram with the drawio viewer javascript component:

• Fixes regression from missing html element

Anyway, even with this fix, for some reasons I can't still use this feature with a comment like {#0000ff} in my local installation 🤔 I'm confused since the unit test works.

This single-casing of a specific class is not ideal, but given the complexity of other proposals here I'd like to get the current four lines in. Any other opinions? :)

@valerio.bozzolan yes, just now. I have only realized that there is a fix already after opening the ticket raised as a concern. Hadn't checked this in the past few days, so here I am, finally with my account approved and the issue is fixed. Thank you. :)

@zajdee have you already tried to update to latest master? After 6ab2b56a1a4a6 I mean. Thanks for this confirmation

EDIT: This was already reported and resolved in T15802: Regression: HTML entities rendered as plain text in config option descriptions, I'm keeping the comment just to track this.

Thank you for testing. I think this looks good. In the one case that the old var is used it’s rendered as a string in pht so string assumption seems okay here.

One by one

thank you!

yarp

The underlying issue is way more contained now that rP7868ab3754fa is merged. I'm abandoning this revision to clean up my backlog.

Break long line into two

If we find 10 minutes, let's test this on every provider, as last time it gave us a little surprise on one of them