In T110345#1591268, @NDKilla wrote:

@Arcane21 I'm fairly certain that cron job was removed ~10 days ago by addshore
I've manually been running the LC rebuild on extloadwiki 2-3 times a day for a week every day I'm home

I recently added a cron job to auto force a refresh of the LC caches on all MW servers, this has minimized the disruption caused by this issue, but it's merely a stopgap at best, it has done nothing to fix the underlying problem.

In T88908#1230369, @matthiasmullie wrote:

Non-Parsoid support is needed at least until Flow can reach out to Parsoid on jenkins. Nothing's going to happen until at least then.
At that point, whenever that may be, things may have changed & we should re-evaluate what we stand to gain/lose from dropping non-Parsoid config.

In T72148#1230034, @Mattflaschen wrote:

In T72148#1205755, @Arcane21 wrote:

Parsoid is extremely resource intensive, even on small setups, and while the WMF may be able to easily ignore this, many smaller non WMF setups would not be able to do so, and I have to confess I'm greatly interested in introducing Flow to the Orain wiki farm (which I serve at as a staff member), but I'd rather we not have to have to acquire much more resources than we use currently to support Flow.

To determine whether it's overly resource-intensive, you would have to compare it to other software that does the same thing: Bidirectional conversion of editable HTML to wikitext.

The reason node.js was used for Parsoid is that investigation showed it was far more performant than the same thing would be in PHP. There's no identical implementation of the current Parsoid in PHP (since no one chose to write one). However, this has almost certainly not changed.

In T72148#1211295, @FastLizard4 wrote:

With a tool like VisualEditor, it's obvious why Parsoid needs to be required, but I don't see why Flow by itself needs to have access to the powerful parsing tools Parsoid provides, especially given that Parsoid is still experimental and is rapidly changing.

Though VisualEditor is not required (either for wiki operators installing Flow or for individual Flow end users), VE is a key part of the vision for Flow (that's why we use Parsoid to begin with). That means, for example, we now use VE for previewing (so no preview without Parsoid).

In T72148#1205608, @Mattflaschen wrote:

In T72148#1179439, @Arcane21 wrote:

I strongly disagree with dropping non Parsoid support. Parsoid is incredibly costly, and while I would love to switch my LQT enabled wiki to Flow, I have no desire to install costly backend software to do so, nor would many smaller non WMF wikis with more limited resources, and if it means it performs less optimally, I would consider that an acceptable compromise to retain non Parsoid functionality.

Costly in what way, exactly?

• Requires a lot of man-hours to install?
• Difficult to maintain?
• Requires high-end services or equipment to run?

Maybe there's a way Parsoid could be easier for you to use.

The main reason we want to remove support for non-Parsoid is that it is costly (mainly in software engineer time) to maintain two versions of key parts of the code.

I strongly disagree with dropping non Parsoid support. Parsoid is incredibly costly, and while I would love to switch my LQT enabled wiki to Flow, I have no desire to install costly backend software to do so, nor would many smaller non WMF wikis with more limited resources, and if it means it performs less optimally, I would consider that an acceptable compromise to retain non Parsoid functionality.