OK. If you are partially mentioning nonsenses in we.phorge.it itself, you are indeed right.

We might come from different user journeys.
Your users might be aware what the project means, and that the project (and its workboard) is archived, and they do have an initial reason to look at this archived workboard (e.g. default view is not "open tasks" but "all tasks")?
My users clicked an external link to some project tag in something called Phorge, and that project has been archived in the meantime, and that project is set to show the workboard by default, and that is now just empty columns (as the default view of workboards is "open tasks"), and that is confusing and unhelpful.

(Trying to make this task a bit more about the root problem, and less about the proposed solution)

I mean. See this archived Project (archived Milestone), that is linked from our changelogs:

For example, some people then may ask "why my default view was changed?" and they will start manually "rollbacking" this to their desired view (e.g. showing closed tasks, from the Workboard, with a filter "Show all tasks").

Premising that I like the implementation but I think it's not the desired solution.

I think GitHub allows that syntax only in comments 🤔

In T15744#18236, @20after4 wrote:

I was unaware of `#0969DA` syntax from github/gitlab.

I was unaware of #0969DA syntax from github/gitlab. I'm not sure if I like that syntax better than {} but I am generally in favor of using the same syntax as other systems in order to converge towards defacto standardization.

Thanks again @20after4 for the efforts.

In T15096#12185, @valerio.bozzolan wrote:

Another problem dramatically frequent for newcomers (at least in my office).

It's relatively too much easy to start with a similar commit message:
...

At least, please go to GitLab, instead of GitHub, so at least you use Free Software :)

Just some (probably final) thoughts on arcanist and phabricator/phorge. After quite a bit of discussion internally, we are moving on to GitHub with our repositories (which were previously stored in another Git server - not Phabricator). But that move also spells the end for our/my 10+ year long use of Phabricator, because when we move to GitHub, we'll also be ditching Phabricator for code reviews.

It seems to me that this problem can be solved with an additional setting that turns this functionality on or off.

Probably my somewhat 10 cents at a broader level;

We don't create the links to page$line in most places as hrefs, so this shouldn't be an issue.

• Don't exist in Diffusion
• Do exist in Paste
• Don't exist in Differential

If it's that easy

I'm guessing $ is used instead of # because (1) a user-agent might not send the # part to the server, and (2) the natural behavior of # ("scroll to this anchor") isn't what the intended behavior ("highlight these lines and scroll to the first one").

Ah, also adding a smalll meta "noindex" HTML tag on legacy file.php$123 pages and similar ones, would maybe help a little bit.

In T15670#15501, @avivey wrote:

Thinking more, I think we'd like to allow the robots to index latest version of the code - these days the big boys know how to handle that. Stopping them from crawling older versions is still important.

Anyway, I vote to revert the change - commit pages can have discussions in.

If it's that easy, then I'm both impressed and surprised it remained this way for so long. I'm actually not quite sure I understand the reasoning for not using # to begin with.

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

Another good simple candidate GDPR-friendly:

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

In T15728#15768, @valerio.bozzolan wrote:

I tried to understand the situation. Thanks.

In your opinion: on the repo view (with clone buttons) is it really important to link to the other similar "reduced" view (without clone buttons)?

I tried to understand the situation. Thanks.

I agree, disabled users should be hidden in the global search typeahead results.

In T15736#15681, @bekay wrote:

• Get rid of the JX namespace and the the require comments - use import and export like it is done in modern js

I'm not against replacing the mechanism - It's just that the original task description doesn't specify why that would be good (i.e., what the benefit would be).
That's clear from the discussion now, but should generally be included in the ticket description - the "describe "what", not "how"" principle.

A big benefit of using client-side variables in CSS, is that one can use the browser's prefers-color-scheme media query to select light or dark mode based on the user's browser or system setting, automatically, and that the transition from light to dark mode, or to other accent/highlight color schemes, requires no reload.

Well, I see a tremendous critism and scepticism concerning modern client side techniques here. The world of frontend tooling has changed tremendously in the last 5 years. And I understand concerns, but nobody has to write JavaScript for certain browsers anymore. Javelin for example tries to solve so many problems that Babel solves with one config entry. But that's okay and I like the architecture here and know we can't change everything at once.

Ok, I don't understand the specifics of css-vars, but if they're better, they're better.

The overwriting of variables with media queries could be configured inside the theming class. So possible breakpoints can be part of a theming API.

And my general approach is: when the client can do something (and that even better), why should the server do it?

@avivey CSS vars are a vital part of modern modularized theming. They are versatile, can be overwritten with media queries or per class/element basis. They are editable in browser dev tools. If you would ask me: this step is pretty important.

In T15736#15726, @avivey wrote:

to have a working dev server when developing js - at the moment I have to ./bin/celerity map after every change to js and css to see my changes...

Are you sure about that? I thought celerity map was only needed when adding a file (in dev mode).

also, adding this file in src/extensions/ will let you have css/js files from src/extensions/rsrc/ loaded automatically:

to have a working dev server when developing js - at the moment I have to ./bin/celerity map after every change to js and css to see my changes...

Looks to me that the existing system is better at providing Themes? It allows real code, inheritance, etc. to set variable values.
That is, I think Extension Themes are better off writing PHP Post-Processor rather then CSS vars.

I don't know if that is part of this task, but the global typeahead search should hide all disabled users, wikis and repos, shouldn't it? This is nothing you want as a fast suggestion...

Well, my idea would be:

When I was at Wikimedia I remember a lot of issues from search robots endlessly indexing dynamic pages.

In case of what?

OK. Then we can add a Task about how to easily configure robot changes without forking, in case.

Thinking more, I think we'd like to allow the robots to index latest version of the code - these days the big boys know how to handle that. Stopping them from crawling older versions is still important.

So apparently the ferret search engine doesn't really have any sort of dynamic ranking. The ranking is entirely based on how many ngrams match the query...with one singular exception - all user results are boosted above everything else.

I'll try to figure out a architecturally-appropriate way to do this. The users do get grayed out in the typeahead search, just not on the results pages.

Partially related, from the mentioned search it's easy to recognize closed Tasks, but Users are not greyed out when Disabled.

User content is also content, thus yes.

Good question. Maybe also related to L2.

Is it assumed that using the site will automatically license the user’s content under these, or should there be a line for that?

In T15322#15031, @aklapper wrote:

+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.

Values given in em units may produce unexpected results...

Yes. I think we should wait for a kind Administrator to implement the first one.

@aklapper @valerio.bozzolan See D25520.

BTW I like the proposed screenshot. So I also agree to: feel free to share the solution 👍

My fix would work with this css class

I did not realize you had a fix. Please share it. :)

In T15715#15174, @aklapper wrote:

I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...

I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...

Also for Archived Projects, and maybe some other objects.
I'm not sure if there's a generic way to do this, or if each search-engine needs to be updated manually.

+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.

Completely agree on lowering their ranking as default

Since I can, thanks to that revision, at work I've put this additional CSS rule for extra nonsense scary climax.