Change Details

MediaWiki: 1.35.0 PHP: 7.4.12 (cgi-fcgi) MySQL: 5.7.28-log ICU: 57.1 The use of %PAGE%, %TITLE%, %NAMESPACE% or any other [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#listseparators | built-in variable ]] in [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#Generating_tabular_output | surrogate/phantom ]] templates in MediaWiki 1.35 results in that exact, plain-text being displayed in the output rather than the value of the built-in variable as it should, and as it did in 1.33, and 1.34, as it says in [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#Generating_tabular_output | the documentation ]], and as it does in DPL3. So if the built-in variable %PAGE% value is "PageName" for example, in the output rather than "PageName" appearing, users see the plain-text output "%PAGE%", which breaks any functionality that relies on built-in DPL variables in surrogate/phantom templates (much of our site). In summary, built-in variables appear to be broken for surrogate templates in MediaWiki 1.35 (which oddly isn't broken in DPL3 with the same contributors listed, save for the main contributor). We started with DPL3, then went to upgrade to 1.35 and learned (in the last 2 weeks) it has been failing silently in the background with db errors due to lack of current technologies integration (actor migration). We checked the DPL3 MW page and see it flagged as incompatible, then we tried to switch back to DPL2 as we have in the past, and discovered that in 1.35 built-in DPL variables are broken for our surrogate/phantom templates. Surrogates/phantom templates allow for more complex reformatting and calculation of table cell information, surrogate template reuse (extremely useful), as well as being able to retrieve template parameter values from result sets, which is how important parts of our site are composed coupled with parser functions. Given that 1.35 now has php parsoid, restbase and VE, a lot of smaller wikis are wanting to upgrade, especially with hosts asking us to keep our software up to date. I'm really hoping one of the two extensions can be made compatible with MW 1.35.

MediaWiki: 1.35.0 PHP: 7.4.12 (cgi-fcgi) MySQL: 5.7.28-log ICU: 57.1 The use of `%PAGE%`, `%TITLE%`, ` %NAMESPACE%` or any other [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#listseparators | built-in variable ]] in [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#Generating_tabular_output | surrogate/phantom ]] templates in MediaWiki 1.35 results in that exact, plain-text being displayed in the output rather than the value of the built-in variable as it should, and as it did in 1.33, and 1.34, as it says in [[ https://followthescore.org/dpldemo/index.php?title=DPL:Manual_-_DPL_parameters:_Controlling_output_format#Generating_tabular_output | the documentation ]], and as it does in DPL3. So if the built-in variable %PAGE% value is "PageName" for example, in the output rather than "PageName" appearing, users see the plain-text output "%PAGE%", which breaks any functionality that relies on built-in DPL variables in surrogate/phantom templates (much of our site). In summary, built-in variables appear to be broken for surrogate templates in MediaWiki 1.35 (which oddly isn't broken in DPL3 with the same contributors listed, save for the main contributor). We started with DPL3, then went to upgrade to 1.35 and learned (in the last 2 weeks) it has been failing silently in the background with db errors due to lack of current technologies integration (actor migration). We checked the DPL3 MW page and see it flagged as incompatible, then we tried to switch back to DPL2 as we have in the past, and discovered that in 1.35 built-in DPL variables are broken for our surrogate/phantom templates. Surrogates/phantom templates allow for more complex reformatting and calculation of table cell information, surrogate template reuse (extremely useful), as well as being able to retrieve template parameter values from result sets, which is how important parts of our site are composed coupled with parser functions. Given that 1.35 now has php parsoid, restbase and VE, a lot of smaller wikis are wanting to upgrade, especially with hosts asking us to keep our software up to date. I'm really hoping one of the two extensions can be made compatible with MW 1.35.