robchur wrote:

Edit the skin files to customise the site's look and feel.

lcarsdata wrote:

But that gets changed on upgrade and is not very user friendly

robchur wrote:

Then create a new skin that encompasses the desired look and feel. You can base
it off the existing skin. User friendliness isn't an issue at this level, if one
is customising the footer to provide a consistent interface. Allowing
administrators to hide or remove, e.g. licence messages and suchlike is not at
all desirable for most wikis.

ayg wrote:

It would make sense to make the message use the same format as
[[MediaWiki:Sidebar]]. It's not vertical, true, but that's still more readable
and more familiar.

(In reply to comment #3)

Allowing
administrators to hide or remove, e.g. licence messages and suchlike is not at
all desirable for most wikis.

They already can at [[MediaWiki:Copyright]].

robchur wrote:

I still maintain it's a job for skin customisation, not the MediaWiki namespace.
The sidebar content is dictated as such, sure, but the layout is still largely
up to the skin.

ayg wrote:

Now that you mention it, most of the current footer things aren't in footers for
non-Monobook skins. It would be rather inappropriate to put them in a footer
message, certainly. Whether a second "sidebar" positioned elsewhere on the
screen than the side, but possibly skin-dependent, would be a good idea is a
separate question.

lcarsdata wrote:

It could be named MediaWiki:footer-content which suggests it is just the content
for the footer and isn't specific to different skins. Anyways, I will see if I
can produce some patch which uses already submitted code. That way even if the
patch isn't accepted for SVN it can still be provided as a extensions (albeit
complicated to add).

lcarsdata wrote:

Basic attempt at fixing for MonoBook skin *WILL NOT WORK*

This is a basic hack that may or may not produce the desired effects. I have no
means of testing it ATM and I am not a php programmer. Use at your own risk.

attachment footer-content.diff ignored as obsolete

robchur wrote:

Comment on attachment 2738
Basic attempt at fixing for MonoBook skin *WILL NOT WORK*

It's not usually a good idea to post untested patches on BugZilla except in
special circumstances.

lcarsdata wrote:

Patch

this patch has been tested with the SVN phase3 version of MediaWiki and works.
It does not change any non monobook-based skins as these don't use the footer
in the same way. It retains the current code for backwards compatibility and
simply adds some li's after it. It can be modified in the same way as the
sidebar, except it uses MediaWiki:Footer. As no extra links will be added by
default MediaWiki:Footer does not need to be added in any of the language
defaults etc.

attachment footer.txt ignored as obsolete

lcarsdata wrote:

Adds to all skins

This patch modifies buildSidebar() to be an alias of $this=>buildBar('sidebar')
(for backwards compatibility) this allowing buildBar() (formerly buildSidebar()

• just with some modifications) to easily be configured to work with both the

sidebar and the footer. This adds a footer to all skins, except Simple
(MonoBook with custom CSS) which does not show the default items anyway. A few
changes were made to use the new function calling replacing buildSidebar() and
some occurrences of ' - ' (in the footer) where replaced with $sep for easier
modification.

Attached:

lcarsdata wrote:

By the way it has been fully tested on revision 21733.

robert wrote:

I am going to do a lot of work on the skin system that will involve integration of a customizable footer.

The footerlinks and footericons are customizable via hook and a configuration var (footericons) in 1.17.

Removing keyword patch, since the patch only deals with footerlinks, and those have been patched according to Daniel Friesen

the patch keyword stays since there is a patch attached.

Adding reviewed since it appears its been reviewed.

footerlinks and footericons are done, nothing else is mentioned

Still not quite finished, footerlinks is still mostly a hack job, it's just an array of tpl keys, it needs further rewriting to be up to expectations.