Change Details

The purpose of RefreshLinksJob is to re-render pages that are affected by a change to another page (e.g. because they use that other page as a template). At the moment (early 2023, MW 1.40-alpha), RefreshLinksJob will re-render the affected page, and will update the links table entries for this page, but it will not store the new rendering in parser cache, as it used to until a couple of years ago. The intent is to avoid wasting ParserCache capacity on pages that are rarely visited. However, this means the page will have to be rendered on the fly when it is next viewed, which may be slow. This is going to be even more problematic for parsoid output needed for visual editor - opening the editor may take up to a minute, depending on page size. RefreshLinksJob should return to saving the ParserOutput to ParserCache. This could be made feasible by increasing parser cache capacity, or by only caching pages that are likely to benefit: This may be pages that are slow to parse, or have recently been edited, have a lot of page views, many revisions, many incoming links, etc.

The purpose of RefreshLinksJob is to re-render pages that are affected by a change to another page (e.g. because they use that other page as a template). At the moment (early 2023, MW 1.40-alpha), RefreshLinksJob will re-render the affected page, and will update the links table entries for this page, but it will not store the new rendering in parser cache, as it used to until a couple of years ago. The intent is to avoid wasting ParserCache capacity on pages that are rarely visited. However, this means the page will have to be rendered on the fly when it is next viewed, which may be slow. This is going to be even more problematic for parsoid output needed for visual editor - opening the editor may take up to a minute, depending on page size. RefreshLinksJob should return to saving the ParserOutput to ParserCache. This could be made feasible by increasing parser cache capacity, or by only caching pages that are likely to benefit: This may be pages that are slow to parse, or have recently been edited, have a lot of page views, many revisions, many incoming links, etc. For reference, parser cache writes were removed in https://gerrit.wikimedia.org/g/mediawiki/core/+/f588586e16c9c8043d6db1a262a00db4c12dc9a1.

The purpose of RefreshLinksJob is to re-render pages that are affected by a change to another page (e.g. because they use that other page as a template). At the moment (early 2023, MW 1.40-alpha), RefreshLinksJob will re-render the affected page, and will update the links table entries for this page, but it will not store the new rendering in parser cache, as it used to until a couple of years ago. The intent is to avoid wasting ParserCache capacity on pages that are rarely visited. However, this means the page will have to be rendered on the fly when it is next viewed, which may be slow. This is going to be even more problematic for parsoid output needed for visual editor - opening the editor may take up to a minute, depending on page size. RefreshLinksJob should return to saving the ParserOutput to ParserCache. This could be made feasible by increasing parser cache capacity, or by only caching pages that are likely to benefit: This may be pages that are slow to parse, or have recently been edited, have a lot of page views, many revisions, many incoming links, etc. For reference, parser cache writes were removed in https://gerrit.wikimedia.org/g/mediawiki/core/+/f588586e16c9c8043d6db1a262a00db4c12dc9a1.