Extension talk:Header Footer/Archive

wfMessage replaces wfMsgExt and wfEmptyMsg
On 1.27 mediawiki I couldn't get the header footer extension to work until I replaced both the wfMsgExt and wfEmptyMsg with wfMessage and it seems to work.

How do you use this extension?
How do you use this extension? What would an example look like?
 * I have now included some examples. Jean-Lou Dupont 17:03, 26 May 2007 (UTC)

Header/Footer not showing:
I've installed the extension using PEAR, along with StubManager. Everything seemed fine.

I accessed the page "www.mydomain.com/wiki/index.php/MediaWiki:Hf-nsheader-Main" and added some "test test" message in there by editing the page. However, nothing shows. Isn't this supposed to show the "test test" message in all pages in the Main namespace in my wiki? Solution: use instead "www.mydomain.com/wiki/index.php/MediaWiki:Hf-nsheader-" for the Main namespace.

A few suggestions to include in the documentation page

 * Since the extension depends on the StubManager extension, you should note in the installation instructions that StubManager must be installed and the "require_once" statement for StubManager must occur above the "require_once" statement for HeaderFooter in the LocalSettings file.
 * It appears that for pages that are subjected to both a hf-nsheader- and a hf-header-, both headers are rendered and the namespace header occurs first. You might include a description of what happens for pages that have multiple header and footer influences.

Thanks, Furboy 04:10, 7 April 2008 (UTC)

A few bugs

 * Confirm Delete Page:When deleting a page from a namespace that has a corresponding hf-nsheader- or hf-nsfooter- the header and/or footer are rendered on the delete confirm page.
 * Right-aligned table conflict:If a table with the parameter align="right" is the last wikitext on a page, the table gets covered up by the hf-nsfooter. You can work around the problem by adding enough tags to get the table to move up, or by simply adding some text after the table.
 * __NOHEADER__ and __NONSHEADER__ not working:__NOHEADER__ and __NONSHEADER__ are not working for me. The documentation page says to use the magic words on "edit protected pages", which I assume means that the headers will be disabled on pages that include the magic words and that are protected.  That's how I have it set up and it doesn't work.

Thanks, Furboy 04:10, 7 April 2008 (UTC)
 * Many thanks for the detailed bug reports. Could you use my project's issues tracking facility to document these? One has much higher chances of seeing resolutions this way. Thanks again. Jean-Lou Dupont 10:09, 7 April 2008 (UTC)

Incompatibility with PHP 5.3.2
After upgrading to PHP 5.3.2 I get the following error (on any page with a header or footer): Detected bug in an extension! Hook Stub::hOutputPageParserOutput failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:


 * 1) 0 /home/srv/mediawiki/mediawiki-trunk/includes/OutputPage.php(632): wfRunHooks('OutputPageParse...', Array)
 * 2) 1 /home/srv/mediawiki/mediawiki-trunk/includes/OutputPage.php(640): OutputPage->addParserOutputNoText(Object(ParserOutput))
 * 3) 2 /home/srv/mediawiki/mediawiki-trunk/includes/Article.php(830): OutputPage->addParserOutput(Object(ParserOutput))
 * 4) 3 /home/srv/mediawiki/mediawiki-trunk/includes/Wiki.php(493): Article->view
 * 5) 4 /home/srv/mediawiki/mediawiki-trunk/includes/Wiki.php(70): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 6) 5 /home/srv/mediawiki/mediawiki-trunk/index.php(117): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
 * 7) 6 /home/srv/mediawiki/mediawiki-trunk/index.php5(1): require('/home/srv/media...')
 * 8) 7 {main}

This fix appears to be simple. In HeaderFooter.body.php, line 14: -      public function hOutputPageParserOutput( &$op, &$parserOutput ) +      public function hOutputPageParserOutput( &$op, $parserOutput ) This is the way this hook looks in other places.

--ZbySz 14:06, 20 April 2010 (UTC)

Thanks, this helped. --Molenwiek 09:00, 15 December 2011 (UTC)

Wish List

 * hf-header- trumps hf-nsheader-: It appears that for pages that are subjected to both a hf-nsheader- and a hf-header-, both headers are rendered and the hf-nsheader- occurs first. For my own application, I would rather see the hf-nsheader- header get rendered in all instances where there is not a hf-header-, but that when there are both a hf-nsheader- and a hf-header-, that the hf-header- is rendered and the hf-nsheader- is not.  I suppose that I could use a __NONSHEADER__ to force the override, but I haven't been to get my __NONSHEADER__ to work.  Ideally, I would like to be able to put a __NONSHEADER__ in my hf-header- or a __NOHEADER__ in my hf-nsheader- to force the appropriate overrides.
 * Custom parameters: It would be nice to be able to pass a parameter from a page to its corresponding hf-header- page, similar to the way you can pass parameters to templates. One way might be with a hook like parameter name|parameter value that could be retrieved in the hf-nsheader- from a variable like .
 * Evaluate Cite.php: Cite.php is a citation reference extension that collects text enclosed by &lt;ref> tags and inserts the text as a footnote in a section indicated with the placeholder tag &lt;references/>. Some of the shortcomings of Cite.php include 1) the editor must actually remember to include the &lt;references/> tag, 2) placing the &lt;references/> tag is an additional task for the editor - a task that must be repeated on each page that has such references, and 3) many editors means that the location and formatting of the reference footnotes are not likely to be similar.  If there was a way for HeaderFooter.php to evaluate whether a page included &lt;ref></tt> tags, a standard footer could be developed to the &lt;references/></tt> tag conditionally.

thanks, Furboy 04:10, 7 April 2008 (UTC)
 * Could you also add these the my project's issues/features tracking facility? Thanks. Jean-Lou Dupont 10:11, 7 April 2008 (UTC)


 * hf-parentheader-: Similar to hf-header-, but shows up on subpages of the given page as well. Alternately, implement something like  and put the functionality in hf-header; this way you don't have to duplicate as much code. (will add to github issue tracker as well) --Memethief (talk) 18:09, 8 April 2014 (UTC)

Thanks
Thanks for pointing me to it, works fine for me. --Subfader 09:30, 16 May 2008 (UTC)

Automatically appending categories to pages
On my wiki I have at home, I've set up this extension (and all works great). However, I have one question: how would I write the code so that when a certain header is applied to all pages of a namespace, those pages are automatically added to a certain category? For example, I have a header that goes at the top of every page in the User namespace, and I want all those pages to be in "Category:User Pages", but when I add something to the page MediaWiki:Hf-nsheader-User along the lines of  </tt>, nothing happens (except that the header page is added to that category). The same if I use  </tt> tags or if I don't use tags around it at all. What should I do to fix this? ~Signed &Omega;mega234 &Dagger; talk to me 02:32, 17 June 2008 (UTC)
 * Hi - the header and footer text are processed outside of the scope of the current page; hence, what you are trying to do won't work. You may file a feature request on GoogleCode and maybe ... ;-) Jean-Lou Dupont 02:42, 17 June 2008 (UTC)
 * I second this request. Would be a real killer feature :-) -- Thoralf 16:44, 28 August 2008 (UTC)

__NOHEADER__ and __NONSHEADER__ not working - my solution (NOT AN ISSUE)
Hello.

__NOHEADER__ and __NONSHEADER__ only work on pages that are protected from editing. I edited this part of HeaderFooter.body.php:

if ($disable && $protect) return null; return $content;

And deleted "&& $protect".

Works fine for me.

Hey that helped me out a lot! Why on earth would the author force the page to be protected for these to work? That's extremely unintuitive. I would like to see this adjustment on the extension page itself.

Many thanks to the author! 19:03, 4 July 2008 (UTC)
 * Hi - note that the magic words are working... but not the way you wanted. Jean-Lou Dupont 01:16, 5 July 2008 (UTC)

Header & Footer position
Hi first of all thanks for your -very useful- extension. Is it possible to change the position of the elements and to move them for example outside of ?

Complex SItename
Hello, thanks for this extension, but it does not work for complex sitenames like:

Entw:/pk=2qrk2mn13ods8s5iReQu/AWF-REQ00000368/DOKU

I have tried with the Page "Test" - it works fine. The good way to link to the page headers(footers) is MediaWiki:hf-header In my case MediaWiki:hf-header-Entw:/pk=2qrk2mn13ods8s5iReQu/AWF-REQ00000368/DOKU is set correct, but the headers are not visible.

(sorry for my English) any Idea?

File ns: not footer not at end of page
Hi there. I added a footer for the File NS and the content is added right below the image desc (above the File history section). Shouldn't it be below the last section File links / Metadata? Although I see that's added below the page content which is the manually added file description. Nontheless, it looks odd. --Subfader 21:55, 1 October 2009 (UTC)

A More Efficient Implementation
If you have a lot of database inquries in your header, you might notice that using the __NONSHEADER__ command still parses the header wikitext before it inserts it into the page. So, for instance, if you have a demanding main namespace header, even though the header is disabled on Main Page, it will still incur a high server load whenever you go to the Main Page (which is clearly undesirable). I also disabled the protect-only feature which was unnecessary and confusing for most users.

Use this code instead:


 * thanks. It works well with 1.16.0


 * Thanks. Jean-Lou quit coding for MW so it's good to see some people still use it / work with it. --Subfader 21:54, 15 July 2011 (UTC)

Can't get this to work...(fixed)
In the Special:Version page looks like that it's installed and looks fine.

But It doesn't work. I created the page MyWiki:Hf-nsfooter- and write "Test".

Shouldn't it work and show "Test" on every page? Am I doing something wrong?

It's resolved. I was using my wiki's name. The correct was MediaWiki:Hf-nsfooter-

Is it possible to close the header?
Just like on Wikipedia?

Main_Page

I want to put a header on my wiki, but it would be better if we could close it.

Can't get it working for the Special namespace
Can't get it working for the Special namespace. Does anybody know how to?

Why is it showing the footer on the edit page?
Hi, I'm using this extension in 2 Wiki's and in one of them it is showing the footer on the edit page while I edit. Twice on top, and once on the bottom.

Anyone can help me? I'm using MW1.18 on the Wiki with the problem.

P.S.: Sorry for my english, it's not my native language.


 * You can easily hide it via CSS. Check body class on page edit and hide the footer div. --Subfader 23:42, 29 January 2012 (UTC)

StubManager Dependency Removed
Seeing as neither this nor StubManager (which this depends upon) are being updated anymore by the original author, it seemed like a good idea to remove the dependency on StubManager. I didn't see how StubManager was that useful, anyway. Below is code I've used to replace the contents of HeaderFooter.php. It appears to be working fine on my wiki, where we heavily use MediaWiki:Hf-nsfooter- to pull in semantic data related to pages. We don't use the other headers and footers at all.

Does anyone see any issues with this? I'm pretty new to MW extension development. Please note that in HeaderFooter.body.php I've also made the changes suggested by User:ZbySz above for compatibility with PHP 5.3.2 and greater.

--Jamesmontalvo3 (talk) 18:52, 2 May 2013 (UTC)

[RESOLVED] Fatal error in MW 1.21.1
I cloned the latest git snapshot and istalled it and I get:

Warning: Missing argument 4 for HeaderFooter::conditionalInclude, called in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 35 and defined in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 49

Warning: Missing argument 4 for HeaderFooter::conditionalInclude, called in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 36 and defined in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 49

Warning: Missing argument 4 for HeaderFooter::conditionalInclude, called in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 38 and defined in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 49

Warning: Missing argument 4 for HeaderFooter::conditionalInclude, called in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 39 and defined in (path to wiki)/extensions/HeaderFooter/HeaderFooter.body.php on line 49</tt>

--Ioannis Protonotarios 14:41, 23 August 2013 (UTC)


 * I use this extensively for a collection intranet wikis, but have had to update the code to make it work on MW 1.21. The updated code can be found at: https://github.com/jamesmontalvo3/MediaWiki-HeaderFooter


 * Note that I've incorporated the code from this discussion page, namely A More Efficient Implementation. Also, the dependency on Extension:StubManager was removed.


 * --Jamesmontalvo3 (talk) 15:55, 23 August 2013 (UTC)


 * After reading your question again I realized you probably did download the code I mentioned above. I had warnings suppressed on my production server and never caught the errors you were getting. I've made the changes, which are now available on my github page.


 * --Jamesmontalvo3 (talk) 18:51, 23 August 2013 (UTC)


 * Thank you so much James for your quick response and for resolving this! Yes, I should have been more descriptive in my report. Now it works just fine!!! It's a simple extension and yet so useful. In my opinion it must be included in MediaWiki core as a standard feature. I came across it when trying to embed DISQUS comments to all my wiki's pages (which now works perfectly as well - hmm, almost perfectly, see my next report ). I also wrote a tutorial in case someone else wants to do the same thing: How to add comments to every wiki page. I took the liberty to add my wiki to Extension:Header Footer page along with this tutorial. I also put the shell commands for git too.


 * --Ioannis Protonotarios 12:37, 24 August 2013 (UTC)

[RESOLVED] Magic word not working
I put a footer with DISQUS comments to all pages of Main namespace but I wanted to exclude Main page. So I first edit protected the page and then I put magic word. But footer still exists. See a snapshot of my Main page along with it's code.

--Ioannis Protonotarios 12:37, 24 August 2013 (UTC) MW 1.21.1


 * You said you created a footer for the main namespace, so I think you want  instead of  . --Jamesmontalvo3 (talk) 15:16, 24 August 2013 (UTC)
 * Silly me! I got it wrong in the first place. Yes,  does the job! Thanks again my friend! Now everything works like a charm!


 * --Ioannis Protonotarios 20:45, 24 August 2013 (UTC)

Minor issue with magic word
Magic word   (and probably others too) does not render when put inside nowiki and code tags. As a workaround I break the magic word in 2 pieces (as you can see above - In my wiki doesn't look so bad due to simpler styling of the code tag).

Similar issue might help: Extension_talk:MagicNoCache

--Ioannis Protonotarios 12:37, 24 August 2013 (UTC) MW 1.21.1


 * If I just use "code" tags, not code tags wrapped around "nowiki" tags, it works for me:  --Jamesmontalvo3 (talk) 15:14, 24 August 2013 (UTC)
 * See and then edit this page to view the code: Magic test


 * --Ioannis Protonotarios 20:58, 24 August 2013 (UTC)

Conflict with Extension:Translate
When one translates a page with Extension:Translate a subpage is created named after the language code of the new language. For example, if one translates page "test" to russian, the translated page will be "test/ru". This is how Extension:Translate works.

A. In my wiki I have enabled a namespace footer for all pages of the main namespace. The footer shows fine in page "test". But in page "test/ru" there 2 instances of the footer, one below the page and one above (as if it was a header).

B. If I use magic word to suppress footer in original page "test" (and retranslate it), then the new "test/ru" has only one footer, but on top!

A + B conclude that:


 * 1) the bottom footer is the "test"'s footer that Translate copied it somehow (where it shouln't have because it's not part of the page's content wikitext), and
 * 2) the top footer is the legitimate namespace footer automatically created for every page but it is in the wrong place!

Indeed, If I completely remove Extension:Translate from LocalSettings.php, then the footer appears where it should be, i.e. at the bottom.

Issue reported to Extension:Translate as well

--Ioannis Protonotarios 18:48, 5 September 2013 (UTC)


 * Is there a fix for this yet? Double header output of headers on all pages of a namespace when switched to a translated page. Thanks! Hutchy68 (talk) 15:10, 9 February 2014 (UTC)
 * Here is a work around for now. In the translated page (pagename/ ), you must invoke __NONSHEADER__ or __NONSFOOTER__ so the translated page is ignored. It doesn't really solve the footer at the top. Translate is parsing the header div, it's custom div then the footer div. Next it appends the pagename/ to the page which of course has the header and footer in the content again. We use this (an old variation) extension and will be upgrading to this extension with the addition of Translate. It would be great if they could play nicely together! Perhaps even an update to Header and Footer to look at / of page and offer localised headers and footers. Hutchy68 (talk) 16:14, 9 February 2014 (UTC)

Not Working
So I have the latest MediaWiki and the latest version of this file, I've included it in my local settings and uploaded the files. I went to MediaWiki:Hf-nsheader- and editited the page with some "jarble" and went back to reload my main page and nothing was showing up. I thought that this plugin would show the header across the entire wiki without my having to add any special code to the page. Any idea what's going wrong?

http://bukkit.mckennastudios.org

EDIT: NEVERMIND IT appears I have fixed my own problem.

--Gabessdsp (talk) 05:00, 20 October 2013 (UTC)

Option to add Footer after Categories for page
Tested and worked in 1.21.1. No way to make the Footer appear after the page's categories? A footer is generic and should not appear before categories which are page-specific. --Choshi (talk) 02:40, 12 December 2013 (UTC)

[RESOLVED] Headers not showing up
I added the most recent HeaderFooter extension via a git checkout as can be seen on my Version page, then created a header page for the Conditions namespace, but that header isn't showing up on pages in that namespace. Why not? Bjp716 (talk) 21:00, 31 March 2014 (UTC)
 * Fixed. The problem was that I hadn't explicitly created a namespace, so my pages were named Namespace:PageTitle, but were still in the Main namespace.  I fixed the problem by creating a custom namespace, and then using the namespaceDupes.php maintenance script to move all existing pages with a title suggesting that namespace into the actual namespace.  The headers now appear. Bjp716 (talk) 16:36, 1 April 2014 (UTC)

Bug in version 2.1.0 causes headers and footers to not show up
I have been seeing headers and footers simply not showing up after having upgraded to 2.1.0. The bug is in HeaderFooter.class.php.

On line 62 of HeaderFooter.class.php there is a test for an empty message with an error that reverses the outcome. Here is the fix: 62c62 <              if (wfMessage( $msgId, $msgText )) ---  >               if (wfMessage( $msgId )->inContentLanguage->isBlank) While I'm at it, there is another change recommended by Manual:Messages_API: 56c56 <              $msgText = wfMessage( $msgId, array( 'parseinline' ) ); ---  >               $msgText = wfMessage( $msgId )->parse;

Regards, --Memethief (talk) 20:26, 30 October 2014 (UTC)

Hi ! Thank you for your help ! "if (wfMessage( $msgId )->inContentLanguage->isBlank)" was my problem. It's working fine now. 18/11/14

Some Magic Words does not show up
Hi! Some of the Magic Words does not show up. If I write in the MediaWiki:Hf-nsheader- the following

Rev.id: latest change  by  Only

works on the header on my pages. They are visible in the MediaWiki:Hf-nsheader-. I am using MW 1.23.6 and HeaderFooter 2.1.0 (modified according to the post above).

Any idea?

Regards --Clanli (talk) 07:03, 6 November 2014 (UTC)

Per namespace CSS?
Hi.

Is it possible to specify CSS per namespace with this extension?

I've tried using Extension:CSS markup within the MediaWiki:Hf-nsheader- page, but that doesn't work.

Thanks. --Mitchelln (talk) 11:10, 30 December 2014 (UTC)

Per category headers and footers
I have quickly thrown together an addition to this extension making it a replacement for the |HeadersFooters extension. That one I have used on MW 1.19 but after upgrading to MW 1.23 it seized to work.

My addition strictly follows the given lines by using ...
 * the pages Mediawiki:hf-catheader/-footer
 * the token __NOCATHEADER/FOOTER__
 * a div class hf-catheader/-footer

Unfortunately I do not know how to use GIT so the best I can do is put the code here. In fact, it is quite simple. Everything happens in the function hOutputPageParserOutput.

1. Determine the set of categories in addition to $ns, $name and $text.

2. After adding the namespace header but before adding the namespace footer, insert the following for adding the category footers (there may be several and they are treated in alphabetical order).

$NS14 is hard-coded to the localized name of "Category" (cf. ToDo below).

ToDo
Localize the canonical name of "Category" properly. It is the localized name of that very namespace. That value is contained as value of "nstab_category" in 'languages/i18n/...' but I have not found any way of properly getting a hold on it.

Cheers!

--Sm8ps (talk) 23:53, 30 July 2015 (UTC)

Problems when used with Comments extension
Hey guys, I'm seeking a little help implementing this extension on my wiki, lostmediawiki.com. If I manually put the tag in an article's code, it works fine, but if I use the Header Footer extension to have it put said code on every page, the code for the post's time displays like this: ' NaN 13 hourss NaN 14 minutess ' instead of '13 hours 14 minutes'. The site's name also doesn't display properly when an anonymous visit browses the page, instead showing ' welcomes all comments. If you do not want to be anonymous, register or log in. It is free.' Do any of you guys know what might be causing this?

One other issue I've been running into is that, while using the current setup as described above, if an article is edited after a comment has been posted on it, it gives the error message 'Fatal error: Call to a member function getMaxIncludeSize on a non-object in /home/wiki/public_html/includes/parser/Parser.php on line 3139'. The only method of remedying this that I have come across is adding '$wgEnableParserCache = false;' to LocalSettings.php, but this, as I've been told, can slow the site down.

I'm still very much a novice when it comes to MediaWiki and I'd be really grateful to anyone who could point me in the right direction; cheers.

Dycaite (talk) 10:48, 19 February 2016 (UTC)

+1 Having the same problem. Thanks! Tiki Tom 10 (talk) 3:34, 99 June 2017 (UTC)

Issue with redirected pages
If I have a custom namespaces: and I have defined pages: and I create a page: THEN when I visit 'Foo:Page1' and get automatically redirected to 'Bar:Page1' .. the page 'Bar:Page1' renders with the header 'Mediawiki:hf-nsheader-Foo'. Can someone confirm this? My System -Rich
 * 'Foo' and
 * 'Bar'
 * 'Mediawiki:hf-nsheader-Foo' and
 * 'Mediawiki:hf-nsheader-Bar'
 * 'Foo:Page1' and then move it to 'Bar:Page1' leaving a redirect,
 * MW: 1-30
 * HeaderFooter: 2.1.1
 * Reported, fix available until it is merged. ☠ MarkAHershberger ☢ (talk) ☣ 22:00, 19 July 2018 (UTC)

Header/Footer for Entire Wiki?
Is there a way to make a header/footer for all page without making a same header/footer for every name space? Clearway000 (talk) 20:13, 8 October 2018 (UTC)