Extension talk:NewPageCSS

Issue with FCKeditor
Using NewPageCSS all pages where I use the tag turns blank in FCKeditor. The old PageCSS Extension works with FCKeditor.

Anyone else with this problem?


 * I had a lot of problems with FCKeditor, so I quit using it. All the problems I experienced were bugs in FCKeditor. Badon 01:35, 18 September 2011 (UTC)

Thank you!
Great extension! It works very well on MediaWiki 1.17, thank you very much for making it! It solves so many issues on a per page basis that used to require site-wide edits to Common.css. Badon 01:34, 18 September 2011 (UTC)

Blank Version page
After upgrading to MediaWiki 1.17.0 and PHP 5.3.2, I found that this extension caused the Special:Version page to appear blank. The problem was caused by the accented characters in the author's name, and can be fixed by editing NewPageCSS.php to use the the HTML-encoded characters as follows:

On line 19, replace:
 * Ævar Arnfjörð Bjarmason

With:
 * &ampAElig;var Arnfj&ampouml;r&ampeth; Bjarmason

Adamcox82 20:25, 23 September 2011 (UTC)

Outputs nonsense
Reported: 34453

I've carefully followed the installation instructions but regardless of what I put in the tags (including nothing), it just puts the following text on the page:

UNIQ52ac25ad4e9cfc51-css-00000001-QINU

Does anybody know how I can fix this? - Dec 07 2011


 * The CSS works fine for me, but it outputs the UNIQ junk to the page as well. I'd also like to know what to do about this. - 74.207.163.233 03:27, 8 December 2011 (UTC)

Looks to be bad coding which is causing this to break on MediaWiki 1.18 and later. That "CSS_include" is a tag hook which is supposed to accept $content as input, do something or other to it, then return an HTML result. The way this was originally written, however, the CSS was stuffed into the page headers but then nothing was returned as the result of the "CSS_include" function.

As an alternative, I advise returning the empty string:

That way, when MediaWiki goes to replace that pesky UNIQ7e6e617d796205aa-css-00000000-QINU placeholder in the page with the output from this function, UNIQ7e6e617d796205aa-css-00000000-QINU -becomes-> "" instead of not getting replaced because the returned value was never set. See Manual:Tag_extensions for the theory behind this... but suffice to say that this thing must return a value to work properly in 1.18+ --Carlb (talk) 05:16, 16 February 2012 (UTC)

Under the current MediaWiki trunk version, PageCSS is acting in the same was as NewPageCSS (ie: both work if you add the line to return ""; at the end of the hook function). As such, this page is redundant (the restrictions on Unicode in the authors name field no longer exist) and I'm nominating this for merge back to PageCSS. Carlb (talk) 19:54, 19 February 2012 (UTC)


 * Even then, I don't get it working in 1.18. --Robinson Weijman (talk) 13:45, 24 February 2012 (UTC)

This is what I currently have as extensions/PageCSS/PageCSS.php:

This is just the PageCSS currently in subversion, but with one line inserted at the end to return the empty string "" as the tag hook must return a value for MW1.18+ compatibility. I have MediaWiki 1.20 (trunk, deployed a little under two weeks ago) so this should be compatible with the latest MediaWiki version. --Carlb (talk) 16:54, 28 February 2012 (UTC)

New NewpageCss -Version
After it did not work with error on the last line of the NewPageCss.php i found a running version on https://github.com/lashtear/mechanipus-mw-ext

No files to download.
Step 1 under Installation says "Download the files from here ", with a link to https://www.mediawiki.org/wiki/Extension:NewPageCSS/Source.

There are no files there to download that I could find. What I found was a wiki page that displayed some PHP source code. I thought of copying this source code and pasting it into a new file somewhere, but (being a newbie at wiki administration) was unwilling to take the chance because:
 * The PHP source code on the wiki page had line numbers, which I was pretty sure wasn't valid PHP syntax, and I didn't trust the wiki page rendering code to not have made other subtle breaking changes. I was expecting a text file.
 * The instructions referred twice to file s (plural), and said to "extract" them (presumably from a zip or other archive file).

Could someone please update the instructions so that they're correct? I'd really like to use this extension. Thank you!


 * Exact same situation here. Fairly new to install other extensions and such, have installed some with the downloadable .tar files, uploaded them, did the extraction, etc. and manage dot get them to work. But only having a page with PHP code and no files to download and then upload in the the extension folder to extract is not at all what other extension installs have been like. So I too am at a loss on even starting to install this extension (which is sorely needed on the wiki I am deploying). — Lestatdelc (talk) 09:59, 12 November 2013 (UTC)