Free Software Directory:Backlog archive

Archived bugs

Free Software Directory:Backlog/gobutton

This page is reserved for backlog administrators, who independently provide for the storage of obsolete bugs.
You can find the old bugs you reported here.

The bugs are archived after at least one week from their resolution or if the bug cannot be identified due to lack of information.
If you find a regression (a bug on this page that comes back with your browser or your system), report it to the page of the active bugs and we'll take care of it as soon as possible. Thank you!

Table Of Contents

---

General

• JavaScript enhancement (TOP PRIORITY): Display a JavaScript countdown (precision: second; time: real; graphics: fancy; standalone: true; license: free) when the meeting is imminent. --LorenzoAncora (talk) 13:04, 3 April 2020 (EDT)

COMPLETED --LorenzoAncora (talk) 12:25, 19 April 2020 (EDT)

Added custom wiki-wide RT timer extension to show a real-time clock in any page of our choice, with the official time-zone of the FSF.
Use .currentEDT as CSS hook to embed the timer. --LorenzoAncora (talk) 12:25, 19 April 2020 (EDT)

• White space issue: I removed the white space in "( ": https://directory.fsf.org/wiki?title=Template:IRC_text&diff=79361&oldid=79331, but I could not figure out how to remove the white space " (" in https://directory.fsf.org/wiki/Template:IRC_text. Can someone else please have a look? --David Hedlund (talk) 23:42, 22 February 2020 (EST)

COMPLETED --LorenzoAncora (talk) 18:27, 23 February 2020 (EST)

Prevented trailing/leading blanks caused by a bug in the transclusion engine. --LorenzoAncora (talk) 11:27, 23 February 2020 (EST)

• A non-JS countdown timer for https://directory.fsf.org/wiki/Template:IRC_text would be very nice. --David Hedlund (talk) 14:42, 7 February 2020 (EST)

COMPLETED --LorenzoAncora (talk) 21:05, 14 February 2020 (EST)

Added a static countdown timer using wikicode. --LorenzoAncora (talk) 14:05, 14 February 2020 (EST)

• "Preview" button does not work for Template:Entry. It shows the unedited version, but I don' think there is a way around this from our end, as the displayed values are based on a query of the saved page.

COMPLETED --LorenzoAncora (talk) 14:37, 15 November 2019 (EST)

Created a specialized script (fixEntryPrevBug() @ Common.js) to hide the Preview button when appropriate.

• Fix search results, so that template data doesn't get dumped into the description below the page links. In other words, just put in the beginning of the description.

COMPLETED --LorenzoAncora (talk) 14:17, 8 November 2019 (EST)

Created a specialized script (fixSrTmplBug() @ Common.js) to hide all bogus search descriptions, leaving all meaningful ones intact.

• Update the queries on GNU/Export to make sure the second column is the GNU package name property

OBSOLETE --LorenzoAncora (talk) 14:25, 14 June 2019 (EDT)

Was already resolved by Joshua (2011). The export feature produces the correct output for CSV and other formats.

• Add {{#info:}}to https://directory.fsf.org/wiki/Form:Entry

'''License and version:'''{{#info:Press any key to quickly select entries that start with that character}}

COMPLETED --LorenzoAncora (talk) 12:42, 14 June 2019 (EDT)

• Make the license texts in License namespace preserve their initial space. Revisions 49613 and 49636 for the {{License}} template already implement a workaround for this issue, but this requires a mass replace in all calls to {{License}}, so as to replace |Full text= with |.

OBSOLETE --LorenzoAncora (talk) 14:46, 24 May 2019 (EDT)

• Create HTML tooltips for the different fields in Form:Entry, or create a tutorial for Form:Entry that describes what each field is for.

COMPLETED --LorenzoAncora (talk) 14:52, 26 April 2019 (EDT)

Now all form fields have help popups and, before saving, the user is notified that all changes are permanent. Security policies are now stated explicitly and SPAM redirects are strictly forbidden.

• The license list should only be a drop down menu
  Currently the license list found under "Licenses" in https://directory.fsf.org/wiki/Form:Entry is a hybrid of a dropdown but you can also add text by hand there too.
  "input type=combobox" should not be changed to "input type=dropdown" in https://directory.fsf.org/wiki/Form:Entry because the edit form will not remember the licenses previously used, so saving a form without manually re-entering license may delete the license names from the entry by default.

COMPLETED --LorenzoAncora (talk) --LorenzoAncora (talk) 14:41, 5 April 2019 (EDT)

Now users won't be able to insert arbitrary values in the License field. This discourages the insertion of non-free software and prevents the accidental pollution of the namespaces. I've also added new and more explicative help texts, based on the current structure of GNU packages.

Resolved by inheritance:

• The "License" (friendly name: "License and version") input field is too liberal, it accepts any value and if the value is a non-existing page it will appear as a red link who will eventually be created by anyone who see it. Only licenses listed in https://www.gnu.org/licenses/license-list.html#SoftwareLicenses should be on our "License and version:" drop-down menu.
  • Possible solutions:
    1. Change type from combobox to dropdown. Attempted, but reverted due to issues.
       • This would make the form edit misbehave, as it would not find the already existing values in old entries that are set before the change. Thus, in the form edit, if an already existing entry/page has MPLv2.0 set as License parameter for {{Project license}}, then it won't find it since it expects License:MPLv2.0. Making {{Project license}} set this doesn't work (it was already tried), the only fix for the already existing entries seems to be a mass-replace, so that every call for {{Project license}} that is like this {{Project license |License=MPLv2.0 }} becomes like this {{Project license |License=License:MPLv2.0 }}. The bug described in this item doesn't affect the show/read tabs of each entry.
         • Before attempting to fix this, see if fixing the item below would also fix this one.
       • Must make sure that the allowed values for Property:License or for that license-related input only point to pages at the :::License namespace. For example, currently Property:License describes Boost as one of the allowed values, however it seems to refer to Boost, not License:Boost.

• Autopopulate License verified date field if it is empty.

COMPLETED --LorenzoAncora (talk) 14:57, 22 March 2019 (EDT)

The default value of the field is now the most recent date the server is able to produce, 0-padded for compatibility (MediaWiki >1.6).

• There should be a space dedicated for scripts that can be downloaded by FSD volunteer. I suggest a link to a page in the side-bar that lists the scripts.

COMPLETED --LorenzoAncora (talk) 13:44, 28 December 2018 (EST)

• Proof read: I have emailed already emailed https://directory.fsf.org/wiki/Free_Software_Directory:Backlog#FSF_staff_tasks to Donald and asked him to suggest the sysadmins to have a look on this. However, we must proof-read the FSF staff tasks section so the FSF sysadmins clearly understand the text so they can start working on this.

OBSOLETE --LorenzoAncora (talk) 13:44, 28 December 2018 (EST)

• Remove exposure of database strip marks from pages under License namespace. Currently some (if not most) licenses in License namespace have a "pre"/"nowiki" element in their call text to their associated template. This is problematic because the template itself already wraps the text in "pre", so the result is a exposure of the database strip marks. When in the "Read" tab, pages in License namespace that are affected by this issue have a yellow triangle next to the start of the license text, for example see https://directory.fsf.org/wiki?title=License:BitTorrentOSL1.1&oldid=72843

Most of the licenses no longer present this problem, but are plagued by the presence of blank pages, malformed pages or non-SPDX redirects. Manual entry-by-entry analysis is required. --LorenzoAncora (talk) 15:15, 4 January 2019 (EST)

Reviewed today: from ACDL to Apache. Many blank lines, bad parameters etc. but no PRE tags found/fixed. --LorenzoAncora (talk) 15:38, 11 January 2019 (EST)

Reviewed today: from Arphic-PL to Boost-1.0. Same edits as before but also created a couple of redirects from empty licenses to the correct licenses, added missing license links and removed useless padding. --LorenzoAncora (talk) 15:38, 11 January 2019 (EST)

After repeated analysis, it does not appear that the problem reported in the Active Backlog Task could compromise the functionality of MediaWiki. --LorenzoAncora (talk) 12:35, 8 February 2019 (EST)

COMPLETED/OBSOLETE --LorenzoAncora (talk) --LorenzoAncora (talk) 12:40, 8 February 2019 (EST)

Show changes

When you click edit this page, and click on the Show changes button, you'll see the markup changes but not the visual changes of the page ("Remember that this is only a preview. Your changes have not yet been saved!"). --David Hedlund (talk) 07:06, 5 April 2020 (EDT)

According to Reedy in Freenode #mediawiki channel, we can perhaps look at MediaWiki:Common.js (specially the fixEntryPrevBug() and hidePreviewButton() functions. --Adfeno (talk) 15:50, 24 April 2020 (EDT)

Felipe, I've added those functions to fix existing bugs. All function in common.js won't block this functionality. --LorenzoAncora (talk) 15:55, 24 April 2020 (EDT)

LorenzoAncora: To clarify: the comment I made was not to blame anyone or any change made, but instead as a suggested place to look at (whether to improve, to study, or simply leave as is). --Adfeno (talk) 16:07, 24 April 2020 (EDT)

Hi Felipe!
I know, I wanted to ensure nobody wastes his/her energy seeking the issue in existing JavaScript, as the issue depends from the page itself (probably it hits a processing limit).
We can still use the [edit] link near each section to preview each change. --LorenzoAncora (talk) 07:32, 27 April 2020 (EDT)

I've just extended the existing JavaScript code to gain even better performance and also had occasion to fix the issue with the button directly client-side so only the pages which can effectively hit the processing limits have the functionality disabled. This Active Backlog task should be now obsolete. --LorenzoAncora (talk) 08:56, 27 April 2020 (EDT)

search links

• Fix search links: Fix links (multimedia, etc) at top of search results.

date command

Add: date --date='TZ="America/New_York" 12:00 this Fri'

• https://directory.fsf.org/wiki/Template:IRC_text
• The entries in https://www.fsf.org/blogs/directory/ -- updated by Ted

Copyright current year

Add the current year in /var/www/w/skins/Vector/VectorTemplate.php "Copyright © 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Free Software Foundation, Inc."

Favicon

"I think I would just use the fsf.org (https://static.fsf.org/fsforg/img/favicon.ico) one for any fsf.org subdomain." - quidam

Special:Ask

Special:AdminLinks "Semantic search" is blank.

Comment: To fix all of the above MediaWiki debugging needs to be enabled. It is also good to see the PHP error log.  « Saper // @talk »  13:17, 27 January 2018 (EST)

It seems to work some how now asking for License:MPL  « Saper // @talk »  15:59, 8 August 2018 (EDT)

What links here?

We want the "What links here?" enabled in the sidebar, it's the standard procedure to maintain MediaWiki instances. It's not stored in https://directory.fsf.org/wiki?title=MediaWiki:Sidebar&action=edit. I got this response from #mediawiki "It's enabled by default on normal pages. I'd say there may be an extension installed on that wiki that's hiding it. Moonbook, https://directory.fsf.org/wiki/IceCat?useskin=monobook, has "What links here?". It's strange because it's not present in the original source code. it's not hidden with CSS or JavaScript"

IRC link text

The IRC resource was displayed twice like this on IceCat for example.

IRC general channel
    [irc:chat.freenode.net/icecat irc:chat.freenode.net/icecat] 

• I attempted to fix this but it seems that something is interfering with the formatting. Strangely enough, if I make a simple page without the form, and use the IRC template, it works as expected. I don't know if this is the case, but I think there is some template interfering.--Adfeno (talk) 23:23, 26 January 2018 (EST)
• As requested in #fsf IRC channel, here is the comment I made there, describing my studies so far:
  • It basically involves three templates (it might involve more, but I only researched three so far) {{Print entry}} {{Entry}} and {{Show}}. There is a fourth one ({{IRC}}) but I think we might be able to replace it ({{Print entry}} calls it, so instead of calling {{IRC}}: we can take the code from it and insert in the caller template).
    • I think that #replace will just mask the underlying issue. --David Hedlund (talk) 10:49, 27 January 2018 (EST)
  • I think there is so far the following possibilities:
    1. an issue between the templates used;
    2. an issue with the #ask: queries and the template result format;
    3. we have reached a setting limit that makes the formatting not work (perhaps a limit on the template result format, although I have tried to remove the call to {{IRC}} but it didn't work, we might have to make tests by simplifying the template result calls even further to see if this is indeed the problematic setting);
    4. an issue with the "IRC [level name]" properties when setting (#set:) or their query and display.

  I think we can make use of #nowiki or #- display parameters when querying for the "IRC [level" properties of an entry (this is queried for in {{Show}}) in order to take the property value in raw (example: irc:chat.freenode.net/fsf) but then we will need to change either {{Print entry}} or {{IRC}} (the first one is the problematic, so I recommend to test with it first) so that it removes irc: but also allows any other : (because the URL scheme allows port numbers).

  --Adfeno (talk) 08:47, 27 January 2018 (EST)

• While MediaWiki understands IRC URLs very well, Our copy Semantic MediaWiki gets confused if a property of type URL has a protocol different from HTTP, this problem also happens if the property definition/setting is invisible (using #set:), but in all cases it works as expected if the protocol is HTTP. I don't know if this is a bug in Semantic MediaWiki (or MediaWiki) but this affects at least our copy of it. An example of the issue with IRC property can be seen in: https://directory.fsf.org/wiki?title=Free_Software_Directory:Sandbox&oldid=48884 --Adfeno (talk) 11:32, 27 January 2018 (EST)
• As of SMW 2.5.1, http https and ftp URL schemes will be printed with double slashes, all other without: https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/568d058ea68859d134654a959001ba0739c781e3/includes/dataitems/SMW_DI_URI.php#L68-L70  « Saper // @talk »  12:49, 27 January 2018 (EST)
• Fixed in [1]. --Adfeno (talk) 14:43, 2 November 2018 (EDT)

Log

• Adding #- didn't seem to help.  « Saper // @talk »  08:54, 27 January 2018 (EST)
  • We unfortunately need a function to remove irc: in order to use #nowiki or #-.--Adfeno (talk) 09:35, 27 January 2018 (EST)
• Removed dependency on {{IRC}}: https://directory.fsf.org/wiki?title=Template:Print_entry&oldid=48860
• Use #replace in IRC URL properties to get the address correctly: https://directory.fsf.org/wiki?title=Template:Print_entry&oldid=48889 --Adfeno (talk) 11:59, 27 January 2018 (EST)
• Use #nowiki in the query for IRC URL properties to pass the property value to {{Print entry}}: https://directory.fsf.org/wiki?title=Template:Show&oldid=48890 --Adfeno (talk) 11:59, 27 January 2018 (EST)
• Replace the numeric reference to the colon in "irc:" with the actual character when inside the "replace" ParserFunction that prepares the IRC URLs to be displayed. [2]. --Adfeno (talk) 14:43, 2 November 2018 (EDT)