You still need the wikimedia extension at least for now. The screenshots just show how to change the subtype of a task and then shows the due date icon. I just changed the permissions on the attachments, maybe they work now?

@littleggghost: Yes after applying the patch to phorge master branch I can see the icon.

confirmed, that warning makes no sense.

Hahah I guess I could have tested it first.

This looks correct to me:

I agree, badges seems like the right way to go. They are an underutilized feature really, IMO.

@littleggghost So it turns out that in order to enable this feature, there was a patch to Phabricator core. That patch isn't part of the wikimedia extension, and hasn't been merged into phorge.

@littleggghost one thing you might want to try is updating the celerity map. You may be missing the custom css rules to style the deadline appropriately. I’m not familiar enough with the phorge docker image to be able to tell you exactly how that is accomplished. With non-containerized phorge instances you would just run bin/celerity map from within the phorge root directory.

In T15743#15855, @valerio.bozzolan wrote:

• https://github.com/xemlock/php-latex (PHP server side)

Interestingly, I just discovered Wikimedia has a pretty cool project to render math on the server side, by transpiling some js into php:

I went down a rabbit hole while trying to add unit tests for this. Our core remarkup unit tests are pretty thorough but they only seem to cover the "core" remarkup engine and syntax. When I added a new test case for this it would pass but always caused a different test case to fail in weird ways. I haven't yet figured out what part of the unit test or engine is stateful such that my unit test alters the state in a way that breaks a later test. If I change the order that tests run in, it just causes another different test case to fail.

Fix lint again

fix lint.

Added contrasting color calculation

There is also MathJax, a subset of LaTex that only covers the mathematical notation without the page layout functionality.

This is not yet tested.

fix lint error.

This would be useful for discussions about design, specifically I wished for this feature while reviewing D25491: Improve contrast of Links in Dark Mode

In T15719#15304, @Tgr wrote:

Given how it's displayed on the Gmail UI, IMO unsubscribing from all emails or at least all emails of the given type (e.g. all Maniphest emails if it's a Maniphest notification) is the only thing that makes sense. If I mark an email as spam, and then use the unsubscribe option instead, I would not expect to continue getting identical email from all the other tasks.
No idea how (or if) other email clients handle the header, though.

In D25491#15482, @Iniquity wrote:

Hello! Are you sure changing the links color is a good idea? Perhaps we should just make the background darker?

The only progress I've made is to think through the implementation but I haven't actually started coding on it. It is sort of high on my wish list so I may get to it soon.

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

In T15673#15587, @valerio.bozzolan wrote:

TRUST ME - YOU DON'T WANT TO LISTEN MY ENGLISH :D :D

Btw now the video is here :D :D AGAIN SORRY PHORGE FOR MY MISTAKES <3 <3

Nice, you touched on most of the advantages of Phorge. It really does have some strong competitive advantages.

From my perspective, on Linux, Phorge already supports configurable fonts - that is, none of the specific typefaces mentioned in the phorge css actually work, so it falls back to whatever I set as the default document font in Gnome.

In T15630#15574, @sirocyl wrote:

CSS is rather flexible now; a larger font scale can be specified for displays above a certain horizontal resolution or display width/effective character width, nowadays.
Atkinson looks poor at the font size specified, you're right about that @bekay.
I feel like it might need to break out into another task item, but perhaps CSS modernization is imo a good step towards making Phorge more compatible and capable, on screens both small and large.

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

Interesting that gnome is considering Inter. Recursive looks really good too. I like that it has both monospace and proportional all in one.

In D25501#15033, @valerio.bozzolan wrote:

Maybe we can simplify things introducing a commodity "if viewer exists" method like:

This seems reasonable.

Noto seems like a reasonable choice. I personally really like DejaVu Sans a lot.

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.

can confirm, https://we.phorge.it/D25342?id=1111 does show an error for me in an incognito window.

I'm inclined to merge this. Any objections?

One concern that I have is that there isn't really a one-size fits all deployment. A single tiny VM image with the database and web server pre-installed would probably be ideal for evaluating and even for a tiny team's use. Once usage increases beyond a very basic level then users will fairly quickly outgrow a tiny VM and need at least a larger memory, more storage, possibly a separate database node, etc. Migrating from the tiny setup to a more robust setup might not be a fun process and I don't know how much we should encourage people to start out with a setup that won't scale very well for them.

I think there's an app-store style thing for hosted VMs in the big cloud providers

Glad you got it working and happy to help!

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.

In T15566#14934, @valerio.bozzolan wrote:

I've just found again this

https://github.com/cooperspencer/phorge/

In T15673#14931, @valerio.bozzolan wrote:

OH MY GOD FOR SOME REASONS THEY RE-OPENED OUR PROPOSAL \o/ IT'S HAPPENING!

https://pretalx.fosdem.org/fosdem-2024/talk/review/EXZNAUXQKMJ7HRYYRD7MKFXTTV8JFQDJ

Is this needed simply because PhabricatorApplicationSearchController doesn't actually have a try { } block to catch this particular case? Maybe we could improve the exception handling instead of return null?

In D25501#14443, @aklapper wrote:

This also needs rework because I still get a Query overheated when not being logged in and going to http://phorge.localhost/feed/transactions/query/all/

I think it might be applicable here and in several other places that follow the general pattern of “look up all subclasses of a given feature and then loop over all of them to run extension hooks “

The only trouble with maintaining a separate arcanist package is keeping the version in sync with phorge. Phabricator never followed anything like semantic versioning and there was never really any stable api version to depend on. Perhaps we could think about versioning and release cycles that follow a more predictable major version release cycle with API compatibility guarantees. It is certainly more convenient (for the upstream) to avoid all of that but it offloads quite a bit of burden on anyone trying to use the software.

TLDR; I think @aklapper is on the right track: I did some more digging and it looks like something similar to P24 is probably the only reasonably easy solution.

@aklapper you are now a member of Blessed Committers.

Since this was vetted by epriestley and previously by myself as well. I think that it exceeded the minimum standard for code review before it landed here.

Here's another one that I think deserves to be upstreamed: https://phabricator.wikimedia.org/T230787 adds context and search term highlights to fulltext search results. Currently Phorge and upstream Phabricator only show matching document titles with highlights on keywords in the title but not the body.
The efficiency of my solution is questionable, however, it's working well enough for Wikimedia's use of the feature.