Extension talk:NewPageCSS

Issue with FCKeditor

Using NewPageCSS all pages where I use the <css> 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: bugzilla: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:

function CSS_include($content)
{
  global $wgParser;
  $css = htmlspecialchars( trim( Sanitizer::checkCss( $content ) ) );
  $wgParser->mOutput->addHeadItem( <<<EOT
<style type="text/css">
/*<![CDATA[*/      
{$css}
/*]]>*/       
</style>
EOT
  );
  return htmlspecialchars("");
}
?>

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:

<?php
if (!defined('MEDIAWIKI')) die();
/**
 * A parser hook to add per-page CSS to pages with the <css> tag
 *
 * @file
 * @ingroup Extensions
 *
 * @author Ævar Arnfjörð Bjarmason <avarab@gmail.com>
 * @copyright Copyright © 2005, Ævar Arnfjörð Bjarmason
 * @license http://www.gnu.org/copyleft/gpl.html GNU General Public License 2.0 or later
 */

$wgExtensionCredits['parserhook'][] = array(
	'path' => __FILE__,
	'name' => 'Page CSS',
	'url' => 'https://www.mediawiki.org/wiki/Extension:PageCSS',
	'description' => 'Parser hook to add per-page CSS using the <tt>&lt;css&gt;</tt> tag',
	'author' => 'Ævar Arnfjörð Bjarmason'
);

$wgHooks['ParserFirstCallInit'][] = 'CssHook::setup';

class CssHook {

	public static function setup( $parser ) {
		$parser->setHook( 'css', array( 'CssHook', 'parse' ) );
		return true;
	}
	
	public static function parse( $content, array $args, Parser $parser ) {
		$css = htmlspecialchars( trim( Sanitizer::checkCss( $content ) ) );
		$parser->mOutput->addHeadItem( <<<EOT
<style type="text/css">
/*<![CDATA[*/
{$css}
/*]]>*/
</style>
EOT
		);
		return htmlspecialchars("");
	}

}

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 files (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)

No downloads, so what do we do?

As the users before me have stated, despite there being a link to "download the files" from MediaWiki, there aren't any files to download, instead a bunch of code for copying and pasting. I'm aware that's what we'd have to do; but if that's the case, where should we save that file, and what should we save it as? --The-Psychid (talk) 03:11, 8 April 2018 (UTC)

Also, for the example provided on the main page (the one in the "Usage" section), where should we save that file, and what should it be saved as? --The-Psychid (talk) 03:15, 8 April 2018 (UTC)