Template talk:Main page image/TFA

Request update
Please copy the version in the sandbox. This is a minor change to allow unnamed parameters. --- C &amp; C ( Coffeeandcrumbs ) 23:19, 16 August 2020 (UTC)
 * Done. Jo-Jo Eumerus (talk) 08:00, 28 August 2020 (UTC)

Thumbtime
@Wehwalt and/or @Jimfbleak: Can any of you coordinator + administrator please add that  parameter? I need it for Today's featured article/requests/Draft Eisenhower movement. It was previously implemented in Template:Main page image/DYK (See Special:Diff/1052927417) – Kavyansh.Singh (talk) 20:25, 29 January 2022 (UTC)
 * Templates aren't my thing. Possibly someone more technically versed can deal with it.--Wehwalt (talk) 22:04, 29 January 2022 (UTC)


 * Nor me, I'm afraid Jimfbleak - talk to me?  11:53, 30 January 2022 (UTC)

Adding the thumbtime parameter
For Today's featured article/requests/Draft Eisenhower movement, I need to set the thumbtime for the video file. Please see WP:THUMBTIME for the use of that parameter. The same change was implemented in a few days ago, see Special:Diff/1052927417. In this template, below, please add  , and reflect the same change in the documentation as well. Thanks! – Kavyansh.Singh (talk) 13:03, 30 January 2022 (UTC)
 * I've added the parameter. Please update the documentation, thanks &mdash; Martin (MSGJ · talk) 12:59, 31 January 2022 (UTC)
 * Thanks! I have updated the documentation. – Kavyansh.Singh (talk) 13:17, 31 January 2022 (UTC)

pagename
, is there a reason why the remove file prefix template was replaced with the "PAGENAME" magic word in ? i believe this may have, in certain cases, broken the code used to resize the image. specifically, what "PAGENAME" returns does not appear to be formatted correctly for the "main page image" module when the filename of the image contains either the ampersand character ('&#x26;'), the semicolon character ('&#x3b;'), the quotation mark character ('&#x22;'), or the apostrophe character ('&#x27;'). it is possible that there are other points of failure; i admittedly have yet to test the code extensively. i am checking with you because i didn't want to revert the edit unilaterally in case i ended up breaking something else myself.note that i am not sure if simply reverting this edit would fix the situation, as has since also been  to use "PAGENAME". also, i assume that similar edits to main page image/ITN, main page image/DYK, main page image/OTD, and TFLcontent have resulted in similar issues. dying (talk) 22:59, 29 February 2024 (UTC)


 * If Template:Remove file prefix also uses the PAGENAME method then that suggests that the issue is not with PAGENAME, and reverting that change would have zero effect. Can you give an actual example of what is going wrong? &mdash; Martin (MSGJ · talk) 10:57, 1 March 2024 (UTC)
 * , used to not use "PAGENAME".   to  was made before  to .  below is a table with 28 examples of affected images in tfa blurbs from 2022 and 2023.  note that all the images are presented below with the  template, so the thumbnails are all 140 pixels wide as of this writing, but should appear with varying widths if the bug is addressed correctly.


 * notice that the edit to in question was made on 2022.05.27, and that a review of the archived versions of wikipedia's main page on web.archive.org shows that the last of the above images that ran on the main page before the edit was resized correctly at 118 px &times; 167 px, while the first after the edit was resized incorrectly at 140 px &times; 190 px.i believe, to fix the issue, one can either both revert  to  and  to, or alternatively, implement in  the code that was present in  of .  (in the first case, i assume the recent updates to the documentation of  should also be reverted.)  of course, there may be other solutions; these are just the two that seem the most clear to me.  dying (talk) 19:59, 1 March 2024 (UTC)
 * I think you are mistaken. Those changes could not have any effect on the size of the images. At first you were talking about issues with punctuation marks and now you are talking about image widths. I don't think there is any problem with this template &mdash; Martin (MSGJ · talk) 21:14, 1 March 2024 (UTC)
 * , i haven't switched topics. both of my comments above discussed how certain punctuation marks in the filename of an image currently prevent the "main page image" module from correctly determining the proper width of an image to be resized.  i believe this is because the current implementation of  uses the "PAGENAME" magic word, which does not preserve some of these punctuation marks.  perhaps the following six examples will help shed some light on the issue.  note that the code used in the second and fourth examples is based on the implementation of the  template before it was reimplemented with the "PAGENAME" magic word.


 * i am assuming that you currently believe that "PAGENAME" preserves the four aforementioned characters if they appear in an image's filename. the first of the six examples above appears to confirm this at first glance, but if you actually look at the html code for that first example, you should be able to see that "PAGENAME" did not preserve the apostrophe.  (admittedly, i am not positive that you will be able to see the issue in the html code, as this may be dependent on your browser and the namespace in which the code appears.  if you are unable to see the issue, a longer explanation is provided below.)  interestingly, the last example shows that, in addition to the four aforementioned characters, "PAGENAME" apparently also does not preserve (1) the exclamation point ('!') if it is the first character of the filename, and (2) the equals sign ('=').

i noticed that the output of "PAGENAME" can generally be accurately observed when the code is in either the main, user, file, or template namespace, but may not be so if the code is in any of their associated talk namespaces, or in either the wikipedia or wikipedia talk namespace. as a result, previewing the above table of examples on a page in user space may work for you.alternatively, using the "string" module to determine every character in the output appears to avoid this dependency, though there may be an issue with displaying the character in question when it is either an octothorpe ('#'), a semicolon (';'), an asterisk ('*'), or a colon (':'). (i assume this is because those characters are often used to mark up lists.)the table of examples below attempts to more clearly show the contents of the output of "PAGENAME" in the earlier examples, but may have issues displaying those four aforementioned characters associated with marking up lists, as illustrated in the first six examples below. to make the table more easy to understand, i have also included a column showing what the actual character in each example is, in case the entry in the "output" column is not displaying properly.


 * to see how fares with images that have either an exclamation point or an equals sign in their filenames, i found three additional images to test, as seen in the table below.  as before, all the images in this table are presented with the  template.


 * as expected, the image with a filename that begins with an exclamation point is currently not properly resized by, and the width of its thumbnail was set to the default value of 140 pixels, even though it should have been set to 171 pixels. the thumbnail of the image with exclamation points in the middle of its filename was correctly resized, as was also expected, since "PAGENAME" preserves exclamation points in a filename that are not the first character of the filename.


 * surprisingly, although i was expecting the thumbnail for the image with an equals sign in its filename to end up with a width of 140 pixels, the template won't even return a thumbnail for the image.  to be clear, the file "Just For The Record =.png" does exist and can be displayed correctly on wikipedia, as seen at right.  however, there appears to be a bug in the  template (possibly unrelated to the "PAGENAME" issue) that prevents an image from displaying correctly when using the template if the image has an equals sign in its filename.  in any case, the string " |140px " that is being displayed in place of the thumbnail shows that the thumbnail would likely have also had a width of 140 pixels had the code been able to generate one.does the above explanation make things more clear?  if not, please let me know which parts do not make sense, and i will try to elucidate.  of course, it is also possible that i am mistaken, but in that case, there is still clearly a bug with the code for the main page, which i have so far been unable to find.  would you be able to help me find it?by the way,, regarding , i now realize that the reason why the original problematic image in this tfa blurb was so tall (as seen captured here and archived here) was because it was not being resized properly.  instead of being resized to a more reasonable 102 px &times; 193 px, the code defaulted to a width of 140 pixels because there was an apostrophe in the image's filename, as explained above, making the image 140 px &times; 265 px.  i should have figured it out back then, but it hadn't occurred to me at the time that there may have been a bug in the code for the main page.


 * courtesy pinging and, who both  the last change to the "main page image" module and presumably have a better understanding of the module than i do.  theleekycauldron, note that the image in dyk's queue 1[], which is scheduled to run the day after tomorrow, is currently affected by this bug because its filename, "Joseph Karl Stieler's Beethoven mit dem Manuskript der Missa solemnis.jpg", contains an apostrophe.  if we are unable to find and fix this bug by the end of tomorrow, i would recommend manually setting the width of that image to 125 pixels.  dying (talk) 21:59, 2 March 2024 (UTC)