A similar "attack" is to send a link to two destinations based on the viewer:

We haven't seen other interest in this and the use case feels a little unusual (I suspect 15-20% empty documents is very unusual) so I don't plan to implement it at this time.

Phriction already has modular transactions, but does not have an EditEngine. That likely needs to happen first.

This never got fleshed out into an actionable plan, see T13077 for the next planned phase here.

I'm going to roll this into T13077, which will provide full access to Phriction via the API. In combination with Webhooks, you could mirror everything into some external read-only backup system or just pipe every edit to lp and stick it in a binder or something.

Mooted by the switch to prose diffing.

Rolling this forward into T13077.

This is either T4675 or T6004. I don't know which will happen first, but I'm just going to close it in favor of those.

In T8552#233072, @mejaz wrote:

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

As for the templates-as-starting-points case: couldn't this be solved by implementing edit engine support for Phriction?

D18069 appears to fix this, but I want to understand where it blames to and possibly pursue a more graceful fix since D18069 feels a little flimsy.

Jira's Confluence provides inline comments; same model could be used by Phriction. But that's not as important. Should at least have support for end-of-doc (footer) style commenting.

No this is good, master gets promoted weekly, so this is a bug in master that will be promoted unless we fix it.

And by doing that, I realize that I have been keeping up with master instead of stable like an (oh, there's no donkey emoji, too bad...).
So it's fixed... Sorry!

Sorry, it completely slipped my mind!

How could we make it more clear that we require version information for bug reports? Here's how we currently communicate this, but it seems like it didn't work well in this case. Is there a way we could improve this or make it more clear?

I have been updating the DB manually to set status back to 0 as a workaround for now. But you could probably see how this affects our workflow!

I would use the crap out of this feature

Just kicking this out of Search since it's really Phriction specific.

Here are a few of the use cases for templates (as in {{math 2 + 2}} results in 4) that I can remember from the past.

No. You should list the (actual, real, day-to-day, not theoretical) things you want to be able to do that you currently can not, or which you do at significant time or complexity cost through cumbersome workarounds. Optionally, you might also say "in other cases, we currently use Wikimedia templates to solve these". Suggesting a solution is the least important part of a feature request.

I gave a trivial example as that is better than a complicated one.

I gave a trivial example as that is better than a complicated one. In a huge wiki, like Wikipedia templates are used for all kinds of things besides making links simpler.

See T12511#218328.

There is basically zero chance we're going to implement parameterized templates which can call one another (easily dozens of hours of work) if the only real use case is making RFC5555 autolink (works today with InlineRule, takes a few minutes to make work).

T12511 is about a very different problem and use case. This request is about adding a feature that "will allow users to quickly create a wiki page with some specific base content.". T12511 is about adding a feature that lets users create a bit or markup that acts as a macro/function/template that generates a few lines of markup within a page.

I do not think this is a duplicate. T3963 is about creating template Wiki pages that start off ready populated with some basic data. This request is about creating a Macro like tag (which is part of the Templates feature in WikiMedia markup) not about creating pre-canned pages.

T12511 discusses some possible use cases, but they are all in the form of {{name|123}} expanding to [[ something.com/123 | 123 ]] (external bug trackers, RFCs, etc).