unregistered tag notice

ax · 2013-10-05 02:28:07

I the debugging mode I am getting unregistered tag notices with 4.6-dev that refer to plugins. I guess that it is safe to ignore this, but is there a way to avoid these unregistered tag notices, especially if they are very many? Thanks.

Ciges · 2014-07-13 13:17:28

The plugins work, the message is a warning :-)

To not showing this annoying message the following hack can be done

Edit the “textpattern/lib/txplib_publish.php” file. At line 482 you can see the following code

// Deprecated in 4.6.0.
else if (maybe_tag($tag )) {
    $out = $tag(splat($atts), $thing);
    trigger_error(gTxt('unregistered_tag'), E_USER_NOTICE);
}

It says clearly it’s deprecated in 4.6.0, so I commented the user notification (the trigger_error call) without fear

// Deprecated in 4.6.0.
else if (maybe_tag($tag)) {
    $out = $tag(splat($atts), $thing);
    //trigger_error(gTxt('unregistered_tag'), E_USER_NOTICE);
}

Dirty, but working :-)

Bloke · 2014-07-13 20:05:51

ax wrote #275737:

is there a way to avoid these unregistered tag notices

Not really. From 4.6.0 onwards as an added security measure, all plugin tags will require registering. In some undetermined far-off future version of Textpattern, support for unregistered tags will be dropped and at that point those plugins will stop working unless the one-line change is added to register their tags. The warning is just to tell plugin authors (and site admins who are debugging sites that use those plugins) about the upcoming change so action can be taken. Without the warning, nobody would know.

So, while the hack that Ciges posted will work, it’s not advised. Try to use Testing mode instead, which will alert you to any important problems without swamping you with unnecessary messages. Reserve Debugging mode for those times when you’re truly debugging, and just use it for short periods of time so it doesn’t annoy you :-)

For reference the current mechanism for registering tags is:

Txp::get('\Textpattern\Tag\Registry')
	->register('abc_tag_does_this')
	->register('abc_tag_does_that')
	...;

So if it really bothers you, add that line to any plugins in order to register them. You can always try the following, so if it’s used in an old version of Txp it just fails silently and continues to work.

EDIT: code redacted as it didn’t work. See this post for working code instead.

Hope that helps.

[Ruud: edited to make it work without using underscores in the class name]

Last edited by ruud (2015-11-07 11:22:14)

gomedia · 2014-07-13 23:03:56

Bloke wrote #282102:

From 4.6.0 onwards as an added security measure, all plugin tags will require registering.

Are Admin-side only plugins affected at all?

Bloke · 2014-07-14 08:03:35

gomedia wrote #282104:

Are Admin-side only plugins affected at all?

Nope. Public tags only. You can continue to put admin side functions in prefixed classes or functions as usual.

gomedia · 2014-07-14 08:14:40

Thanks, I assumed not.

Are we moving towards a walled garden?

Bloke · 2014-07-14 12:37:34

gomedia wrote #282117:

Are we moving towards a walled garden?

I’m not sure that’s entirely the plan, it’s more for security/stability than anything else (though I reserve the right to be wrong).

In prior versions of Txp you could use any PHP function as a tag. At the moment, you can use any Txp function as a tag, which is a bit lax to say the least. This will close that loophole, as core will register (whitelist) its own public tags and plugin authors will have to register theirs to gain access to the system.

So, not so much a walled garden in which we control the ecosystem, more like a castle in which we grant anyone keys to the drawbridge instead of leaving ladders lying around the perimeter :-)

gomedia · 2014-07-15 01:57:03

Using the Txp::get('\Textpattern\Tag\Registry') code I can get rid of the “unregistered tag” messages in 4.6.

However, in pre-4.6 the try...catch block is trying but not catching. I get a “Fatal error: Class ‘Txp’ not found” message.

Here’s my code:

try {
	Txp::get('\Textpattern\Tag\Registry')
	->register('adi_menu')
	->register('adi_menu_breadcrumb')
	;
}
catch (Exception $e) {
	// pre-TXP 4.6
}

Have I missed something?

Bloke · 2014-07-15 08:01:38

gomedia wrote #282131:

in pre-4.6 the try...catch block is trying but not catching

Rats. Must admit I never actually tried it. Suppose it makes sense because we’re still actually executing the code which doesn’t exist. Perhaps the try catch advice was cobblers and we should be using this instead:

if (class_exists('\Textpattern\Tag\Registry')) {
	Txp::get('Textpattern\Tag\Registry')
		->register('abc_tag_does_this')
		->register('abc_tag_does_that')
		...
	;
}

??

gomedia · 2014-07-15 08:41:09

Yep, that works thanks.

Gocom · 2014-07-23 20:56:15

gomedia wrote #282117:

Are we moving towards a walled garden?

It’s mainly about fixing security vulnerability vector. As you can call any userland function from templates, you can also potentially craft tags that can execute malicious code. Not to mention the lack of registry creates collisions with PHP’s namespace.

Currently you can merely mistype a tag, and it may execute some random userland function that isn’t intended to be used as a tag. E.g. <txp:abc_deleted/> vs. <txp:abc_delete/> where the latter is a function responsible for uninstalling the plugin data.

jakob · 2016-01-07 20:09:29

Just a note: I think the above should read:

if (class_exists('\Textpattern\Tag\Registry')) {
	Txp::get('\Textpattern\Tag\Registry')
		->register('abc_tag_does_this')
		->register('abc_tag_does_that')
		...
	;
}

with backslashes instead of underscores on both the first two lines.

Adi, it wasn’t like that in your adi_gps plugin I downloaded yesterday.

If I’m wrong (or the leading slashes are not required), please put me right.

Textpattern CMS

Textpattern CMS support forum

#1 2013-10-05 02:28:07