Extension talk:MetaTags
Blacklist?
editEven though there seems some protection by permissions, perhaps some things should be black-listed: http-equiv="set-cookie"
comes to mind, and http-equiv="refresh" may be problematic too - and there are probably more.
- Thanks for the excellent suggestions. I'll add them to the issue list on Issue #11.
Regarding the permissions: if an admin adds a meta tag to an unprotected page, and the page is the edited by a non-admins, the meta-tag will no longer be executed, right?
- true.
This seems a bit counter-intuitive and tricky to maintain, especially since there seems to be no way to see that problem... -- Duesentrieb ⇌ 10:39, 5 January 2008 (UTC)
- I see your point. The reason I put this sort of functionality is because on the wikis I administer I only admit editing of the talk pages and I can be bothered to protect the normal pages all the time. Jean-Lou Dupont 18:45, 5 January 2008 (UTC)
XHTML
editOnly a small thing, please add the /> at the end of the Metatag to make it fit into XHTML. 77.182.28.2 01:51, 3 February 2008 (UTC)
- XHTML kompatibel Version
class MetaTags
{
const thisType = 'other';
const thisName = 'MetaTags';
/**
* {{#meta: HTTP-EQUIV | CONTENT [| NAME] }}
*/
public function mg_meta( &$parser, $httpAtt, $contentAtt, $nameAtt='' )
{
if (!self::checkExecuteRight( $parser->mTitle ))
return 'MetaTags: '.wfMsg('badaccess');
$http = $this->process( 'http-equiv', $httpAtt );
$cont = $this->process( 'content', $contentAtt );
$name = $this->process( 'name', $nameAtt );
$parser->mOutput->addHeadItem("<meta{$http}{$cont}{$name} />\n");
}
/**
*
*/
protected function process( $att, $input )
{
$out = trim( htmlspecialchars( $input ) );
if (empty( $out ))
return '';
return " $att=\"$out\"";
}
/**
* 1- IF the page is protected for 'edit' THEN allow execution
* 2- IF the page's last contributor had the 'meta' right THEN allow execution
* 3- ELSE deny execution
*/
private static function checkExecuteRight( &$title )
{
global $wgUser;
if ($wgUser->isAllowed('meta'))
return true;
if ($title->isProtected('edit'))
return true;
// Last resort; check the last contributor.
$rev = Revision::newFromTitle( $title );
$user = User::newFromId( $rev->mUser );
$user->load();
if ($user->isAllowed( 'meta' ))
return true;
return false;
}
} // end class
//
Description
editI tried to make the description a little more user friendly:
- Allows users to add META and LINK tags to an individual page's HEAD coding. This extension still allows the mediawiki page to be parser cached.
Turning off Protections?
editIs there a way to turn off the requirement to have the pages with meta tags to have protections? This restriction makes our implementation very difficult, but we need to have embedded metadata to ensure that our search engine properly catagorizes the content. The other extensions only allow additions to descriptions and keywords, which doesn't help. Prodoom 18:39, 6 January 2011 (UTC)
- Try
$wgGroupPermissions['*']['meta'] = true;
—Emufarmers(T|C) 22:59, 6 January 2011 (UTC)
work within templates?
editDoes this work within a template? i.e. can I write a template which injects meta tags into the pages that use the template? For example, if we want to add
<meta name="robots" value="noindex,nofollow">
to prevent some pages from being indexed by a search engine?
Fix for access to protected member $rev->mUser
editMediawiki's Revision source code has been tightened and MetaTags will throw an error when displaying a page with a tag. To fix this, change this line in checkExecuteRight (MetaTags.body.php):
$user = User::newFromId( $rev->mUser );
to
$user = User::newFromId( $rev->getRawUser() );
Fix for use of User::isBot()
editThis now no longer exists. To fix this, change the line in checkExecuteRight (MetaTags.body.php):
if ($user->isAllowed('meta') || $user->isBot())
to
if ($user->isAllowed('meta') || $user->isAllowed('bot'))