Last modified: 2011-02-10 03:07:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8680 - Allow additional icons in the footer
Allow additional icons in the footer
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-18 01:19 UTC by Zach Dennison
Modified: 2011-02-10 03:07 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
The changes necessary to implement a hosted-by icon at the footer (826 bytes, patch)
2007-01-18 02:55 UTC, Zach Dennison
Details
Modification to my earlier changes, this one allowing multiple icons to be added to the footer (1.23 KB, text/plain)
2007-07-10 01:49 UTC, Zach Dennison
Details

Description Zach Dennison 2007-01-18 01:19:55 UTC
While not too important, it would be nice if MediaWiki one day had built-in
support for adding icons to the footer, without modifying the skin. This could
by used by many things, most notably to display a small icon advertising your
webhost (like what Wikia does). A new function, getHostedBy(), could be added to
the Skin class, and the options $wgHostedPage, $wgHostedUrl, $wgHostedIcon, and
$wgHostedText added to LocalSettings.php. Then, the skins distributed with
MediaWiki could display it the same way it does the Rights and Powered-by icons.
There could also be support for displaying multiple additional icons when, say
$wgAdditionalIcons, is given a multi-dimensional array (each array inside
defining the 4 values needed for each icon).
Comment 1 Zach Dennison 2007-01-18 02:55:05 UTC
Created attachment 3085 [details]
The changes necessary to implement a hosted-by icon at the footer

I wrote the functions needed to implement this. Just fill the variables
$wgHostedIcon, $wgHostedText, and $wgHostedUrl, and this works fine. The id of
the div it outputs is "f-hostedbyico". I am currently using this on my wiki,
and it seems to work just fine. If this doesn't break anything, maybe it could
be committed to svn.
Comment 2 Robert Leverington 2007-07-07 16:16:18 UTC
Is this not what $wgCopyrightIcon was originally intended for - I don't see the sense in adding more configuration settings and global variables when this can already be achived.
Comment 3 Zach Dennison 2007-07-09 17:41:25 UTC
No, what I'm talking about is adding an additional icon, or additional icons at the bottom. What if you want to have an icon to display the license, powered by mediawiki, and say, a link to an affiliate. To the best of my knowledge, this currently requires modification to the skin. If you use any of the provided skins, and only modify it for the icon or icons, then the changes have to be reapplied every time you update MediaWiki. I thought it would be a good addition, and not to hard to apply, if the skin template was modified to allow adding additional icons to the footer. I created an attachment that gave instructions to one icon to the monobook skin, to show how easy that would be. Of course, that was to the current revision of the time, which was 6 months ago. I'd imagine that the only difference to apply the changes to the current revision would be the line numbers at which to add the lines of code.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-09 19:36:01 UTC
If this is done it should probably be through some kind of hook, not a hardcoded ability to add a single extra icon.
Comment 5 Zach Dennison 2007-07-10 01:49:49 UTC
Created attachment 3883 [details]
Modification to my earlier changes, this one allowing multiple icons to be added to the footer

I uploaded an attachment which gives directions to modify Skin.php, SkinTemplate.php, and MonoBook.php to allow the addition of icons in the footer. To add icons, create an array variable $wgAdditionalFooterIcons in LocalSettings.php. Here is an example of the syntax:

$wgAdditionalFooterIcons = array(
  'icon1' => array(
    'url' => 'http://example.com',
    'img' => 'http://example.com/example.png',
    'text' => 'Hover text',
  ),
  'icon2' => array(
    'url' => 'http://example.com',
    'img' => 'http://example.com/example.png',
    'text' => 'Hover text',
  ),
);

The id of the <div> for these icons will be "f-icon1" and "f-icon2" respectively.

If using the modified files, $wgAdditionalFooterIcons needs to be initialized as an array. Even if not adding icons to the footer, the variable needs to be an empty array to prevent php warnings.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-10 01:56:38 UTC
It's preferable for patches to be in Unix diff format to the latest version of the software in our [[Subversion]] repository at http://svn.wikimedia.org/svnroot/mediawiki/phase3/, generated with the command "svn diff" from a terminal.  That way we can apply them with ten seconds' typing or clicking instead of having to manually follow instructions.

As for the content of the patch: people might not want to add just icons to the footer.  If this is done, as I said, it should probably be through a hook, not just a global variable, so any content that might be desired can be added.  (Also, in your implementation, you should use standard attributes like href, src, title instead of url, img, text, plus you should allow attributes like alt - which by the way you break XHTML validity by not using.)
Comment 7 Zach Dennison 2007-07-10 02:12:16 UTC
The code transforms url to href, img to src, and title to alt. I don't know if you just didn't see that, or if I still lack something that breaks XHTML validity. If this does break XHTML validity, I would like to know, even if this code won't be used, so that in the future I don't use invalid code. Thanks
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-10 03:58:40 UTC
(In reply to comment #7)
> The code transforms url to href, img to src, and title to alt. I don't know if
> you just didn't see that, or if I still lack something that breaks XHTML
> validity. If this does break XHTML validity, I would like to know, even if this
> code won't be used, so that in the future I don't use invalid code. Thanks

I realize the code transforms the attributes.  I was just suggesting that you use the actual HTML attributes rather than possibly more ambiguous values.

As for the XHTML validity, it does seem to be valid, since you set alt="$text".  I missed that because I had assumed you were using title for hover text, which you should.  alt is what's supposed to appear in place of the image if the image is unavailable (e.g. not loaded yet) or unsupported, title is to be used for hover text.

Anyway, as I said, the proposed patch is too narrow to be good enough to put in core, in my opinion.
Comment 9 Zach Dennison 2007-07-10 06:37:19 UTC
Well thank you for your input. I didn't actually think that the code would be put into core when I uploaded it, but I thought it might help a developer implement the change. However, if it is to be done with a hook (if at all), as you suggest, then my code probably won't be of any use to anyone else. Oh, and for using alt and not title, I actually based the code off the Skin::getPoweredBy() function, which does it the same way. I just figured that I'd model that code after some existing code. Thanks again for your reply, I really appreciate it.
Comment 10 Dan Jacobson 2010-12-29 01:02:59 UTC
I note there is now [[Manual:$wgFooterIcons]].

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links