git rebase master

• Rebase

Nice

(and well done Herald²)

(And well done Herald)

Go back to previous khtml only change

Great, Phorge. So much for stacked patches... Looks like git checkout -b mozPrefixedCss cssKhtmlOpacity did not do what I had expected it to do.

Remove pre-2013 vendor-prefixed -moz- CSS properties

@valerio.bozzolan could you please add to either H28 or H29 Affected files contains none of map.php?

Marking as "probably my previous block is now nonsense - but still not reviewed sorry" asd

Uhm yes thanks

In D25912#24622, @aklapper wrote:

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

I'd prefer not to introduce non-obvious confusing behavior (sometimes it does, sometimes it doesn't?) to increase code (and testing) complexity for no good reason...

It works on my computer and it makes me feel like a happy Phorgi unicorn running in a Phorgi golden forest, whoa

Another good simple candidate GDPR-friendly:

This is one great Wikimedia patch being upstreamed. Should I make this a sub-task of T15081?

Took the opportunity to fix a typo in the summary.

In D25912#24618, @valerio.bozzolan wrote:

P.S. maybe if the task number is very small (e.g. 2) maybe we can still allow that.

(Feel free to copy-paste the downstream task in Phorge - so the lack of task is not used as blocking reason - maybe title "Allow to mitigate spammers from workboard bulk move" or something similar)

I think this makes sense - Mark All Read is about marking all search results read. (I assume; I never used it. But that's what the UI implies, it being grouped with e.g. Use Results which is definitely about doing things with the search results.) So no search results -> nothing to mark as read. The bug is in not getting any results.

I believe that this is not the correct approach, thus abandoning.

@aklapper we are talking specifically about documents that are under another document, that is, about the hierarchy of pages in the wiki.
The screenshot F3250825 just shows that the visualization of the document hierarchy is not very convenient in my opinion, and I ask if it can be moved to the side.

On Outbound Email rules, does the Do Nothing action neither send an email nor a notification?

Uh interesting - good to know for the future. So at least the button Mark All Read here in F3271029 should be visible for your case - as very minimal mitigation sub-task

The mark all read link in the notifications dropdown panel is always available. (It did clear the phantom notification.)

The current workaround is to wait for a real notification, to then finally be able to click the Mark All Read.

It happened to me but only in Wikimedia Phabricator, there I had a notification counter in the top-bar, but with no unread messages in the related list

I don't understand the problem described...

Search brings up rP70d67a3908b8: Fix the most significant "phantom notification" badness

Thaanks - please wait 7 days + 1 hour + 1 second + 42 milliseconds before landing to attract more Pòkèmòn reviewers

In T15203#21226, @valerio.bozzolan wrote:

(M is short for Mockup probably)

(M is short for Mockup probably)

I'm not familiar with MediaWiki's packages - the model I'm copying is VSCode.
My thought is that in the install manual we'll say "now run ./bin/extensions install phorge-recommended-extensions" (near the ./bin/storage) step, and phorge-recommended-extensions would be the equivalent of "extension pack" hosted on the default Extension Store, which is hosted here.
(VSCode also has "bundled extensions", which I think doesn't work for us because we use "clone the repo" as the primary distribution system).

In T16007#21223, @avivey wrote:

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

Ideally, any current Prototype can be either promoted to Core, extracted to its own extension, or removed completely. Each extension/author can have their own policy on contributing.

Already, any new app that would be considered "Prototype" today should just go in its own extension, and we decided to remove a couple.

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge. This should let us know if it should be promoted to core, separated into an extension, or removed completely if no one uses it (like Releeph and Phragments). Or even better, hold a Slowvote for each prototype application's future and possibly have Phorge's customers to vote (maybe notify as much as possible by creating a blog post about the vote to notify those who use the Atom feed).

I'm not sure that "usage" is really the best way to choose between "promote to core" and "extension"; The way I imagine it, in addition to the Core, we'll have a set of "highly recommended extensions" maintained, and a single step to install all of them when setting up a new machine. In that world, any app that can be separated out to an extension will be.
The prototypes can usually be curved out easily, without effecting the rest of the code.

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

Really!? Phacility SaaS instances do not allow enabling prototypes and self-hosted Support (from the Support application on admin.phacility.com that was oddly marked as Prototype) likely wasn't even available for prototype applications.

On this server, we changed the config to /^(Q|V|M)\d$/ because we don't have P1 tickets.
I'm also not sure what M is short for.

To me, "obsolete" manes "no longer appliable" - basically, "the information in this page doesn't apply any more".
Some (made up) examples:

• "Can Phorge run on PHP 7.0?" (The answer is no, because of a specific bug in 7.0, which was EOL a long time ago)
• "I have this problem in the Chatbot app" (We've deleted the chatbot app)

In T15203#21219, @avivey wrote:

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

I'm honestly surprised about layout=inline working for {T123} - I thought is only works for images. But it can probably be made to work for Votes (or rather, all objects) like it does for tasks.

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

I now realize that this is not about hierarchy (documents below other documents) but about the Table of Contents within a single wiki page? You may want to edit the title.

What you see is 100% normal regardless of your pixel density, display size and resolution.
With a similar approach to T15920, this can be achieved. However, I think there is one disadvantage: text may be crammed with a side hierarchy, resulting in lots of newlines for documents with long titles.
You can create a task now that you are member of Trusted Contributors.

In D25889#24581, @aklapper wrote:

Hmm, maybe should not change ->setURI("/people/tasks/{$id}/") because there might be external third-party code relying on this?