cotonti.com : set metas from standalone plugin

Trustmaster

Sat, 28 Feb 2009 14:15:08 -0000

# Kilandor : Here is a idea of how the new Advanced hooking will be improved.

Hooks to be allow to be only included on specific areas.

Ex, a header hook only included on user.details, or a plugin header hook, only included on plug.php?e=myplugin

Timed Hooks, hook is only included on its page, when the time has passed, sorta like a cron.

Multi-Hooking, hooking a single php file into multiple area's.

And maybe more features.

It makes me think that we should really try callbacks instead of includes. Pre-include problem most probably has some smart logical solution. But what we need to solve in first place is the scope limitations, otherwise old plugins will become incompatible.

# Kilandor : So it comes down to, do we know any plugins, or possible reasons if we move the header. That could cause problems?

My thoughts are, it may cause problems with whoisonline.
It changes the logical flow of things (sorta).

No, whosonline is mostly done in common.php. The plugin is just used to display data from sed_online table.

Kilandor

Sat, 28 Feb 2009 12:33:28 -0000

Well I see what your doing dervan, its a interesting idea, it would save a header hook everywhere, but as i've said that will be change in the future. But it goes back to exactly what trust was saying, for some people it might cause double processing.

Maybe we should hold off till then, none of this will be included untill 0.1.0 anyways.

Here is a idea of how the new Advanced hooking will be improved.

Hooks to be allow to be only included on specific areas.
Ex, a header hook only included on user.details, or a plugin header hook, only included on plug.php?e=myplugin
Timed Hooks, hook is only included on its page, when the time has passed, sorta like a cron.
Multi-Hooking, hooking a single php file into multiple area's.

And maybe more features.

So it comes down to, do we know any plugins, or possible reasons if we move the header. That could cause problems?

My thoughts are, it may cause problems with whoisonline.
It changes the logical flow of things (sorta).

My only other thought is that, anywhere else outside of standalone, the header.main hook would have to be used anyways. So it would just keep it the same for anything needed.

dervan

Thu, 26 Feb 2009 04:56:05 -0000

# Orkan : no offence, fella

no dust, guy :)

# Orkan : Im only talking about possible programming solution, ...

bla bla bla, i see

=======

# Kilandor : The only way that moving where header is included would be if a plugin used any data generated by header, which is possible. Then it would completely break it, I truthfully don't know any off hand like this, but it may break future things like a more updated Whoisonline tracking method.

I can see the reason for moving it, but it doesn't solve all the problems. Also do remember this, we will be getting more advanced hooking methods, so that a hook is only loaded on certain pages/area's. By moving the header all it does is save that hook, and in some cases yes maybe extra processing.

well

solution:
add new hook - standapart

will change metas from standapart plugin only
standalone plugin will work as before

modified code in system/core/plug/plug.inc.php:

	if (is_array($sed_plugins))
	{
		foreach($sed_plugins as $i => $k)
		{
			if (($k['pl_hook']=='standapart' || $k['pl_hook']=='standalone') && $k['pl_code']==$e)
			{ $out['subtitle'] = $k['pl_title']; }
		}
	}

	$out['subtitle'] = (empty($L['plu_title'])) ? $out['subtitle'] : $L['plu_title'];
	$sys['sublocation'] = $out['subtitle'];

	/* ============= */

	$extp0 = array();
	$extp1 = array();

	if (is_array($sed_plugins))
	{
		foreach($sed_plugins as $i => $k)
		{
			if ($k['pl_code']==$e)
			{
				if ($k['pl_hook']=='standapart')
				{ $extp0[$i] = $k; }
				if ($k['pl_hook']=='standalone')
				{ $extp1[$i] = $k; }
			}
		}
	}

	if (count($extp0)==0 && count($extp1)==0)
	{
		header("Location: " . SED_ABSOLUTE_URL . sed_url('message', "msg=907", '', true));
		exit;
	}

	$t_plug = new XTemplate($path_skin);

	if (count($extp0)>0)
	{
		$extp1 = array(); // disallow standalone hook
		$t = $t_plug;
		foreach($extp0 as $k => $pl) { include_once($cfg['plugins_dir'].'/'.$pl['pl_code'].'/'.$pl['pl_file'].'.php'); }
		unset($t);
	}

	require_once $cfg['system_dir'] . '/header.php';

	unset($t);
	$t = $t_plug;

	if (count($extp1)>0)
	{ foreach($extp1 as $k => $pl) { include_once($cfg['plugins_dir'].'/'.$pl['pl_code'].'/'.$pl['pl_file'].'.php'); } }

	if ($autoassigntags)
	{
		$plugin_title = (empty($plugin_title)) ? $L['plu_title'] : $plugin_title;

		if($cfg['homebreadcrumb'])
		{
			$bhome = ''.sed_cc($cfg['maintitle']).' '.$cfg['separator'].' ';
		}
		else
		{
			$bhome = '';
		}

		$t-> assign(array(
			"PLUGIN_TITLE" => $bhome . ''.$plugin_title."",
			"PLUGIN_SUBTITLE" => $plugin_subtitle,
			"PLUGIN_BODY" => $plugin_body
		));
	}

	$t->parse("MAIN");
	$t->out("MAIN");
	unset($t, $t_plug);

	require_once $cfg['system_dir'] . '/footer.php';

in system/core/admin/admin.plug.inc.php: replace this string

		$sql3 = sed_sql_query("SELECT pl_code FROM $db_plugins WHERE pl_hook='standalone'");

with

		$sql3 = sed_sql_query("SELECT pl_code FROM $db_plugins WHERE pl_hook='standapart' OR pl_hook='standalone'");

this code is tested and works

Trustmaster

Thu, 26 Feb 2009 02:04:26 -0000

There are several practical solutions known but the drawbacks of choosing callbacks over hooks are already know quite well too:
[list=1]

Callbacks are functions. It means that they cannot use variables from global scope implicitly. Which in turn means that plugins need to be changed to use GLOBALS or import the variables they use. Or some other trick if you know it.

Callbacks must have been processed by PHP before they are called. It means that mass-loading needs to be performed before the actual request handling is started. It needs to be quite smart not to include files that the current request processing does not require.

Orkan

Thu, 26 Feb 2009 01:53:40 -0000

Awesome!
I always wonder how to replace the standard plugin->hook system, and this sounds like a million-dollar idea!
If you have more concrete suggestion then go ahead and start a new topic. Im interested!

Trustmaster

Thu, 26 Feb 2009 01:13:47 -0000

The callback concept is somewhat interesting on its own, further considering the concept of user-defined functions (like sed_parser_custom(), sed_pagination_custom(), etc.). Investigating it even further, you may come up to registering custom handlers, using callbacks instead of hooks and switching to event-driven model. How do you like it?

Orkan

Thu, 26 Feb 2009 01:12:20 -0000

dervan:
no offence, fella
Im only talking about possible programming solution, all the cons and pros and nothing more.
All ideas are welcome!

dervan

Thu, 26 Feb 2009 00:41:14 -0000

# Orkan : Well, for me programming is like a piece of art, but with dervan's solution you're painting someone's portrait a'la Picasso

well at least not Matejko :)

will be other proposals?
need to solve this problem, but not heard of other solutions

Orkan

Thu, 26 Feb 2009 00:00:26 -0000

Maybe its not the best approach, however much better than disturbing the normal code flow, IMO.
Also, the performance wont hurt that much, since preg_replace() will skip after first match.

Well, for me programming is like a piece of art, but with dervan's solution you're painting someone's portrait a'la Picasso

Trustmaster

Wed, 25 Feb 2009 22:39:09 -0000

# Orkan :

$output = preg_replace(
'/]+)>/i', 
'', 
$output, 1);

This. It's not really a good design to have post-factum overwriting callbacks with regular expressions. It should be avoided if there is a way of assigning data straight into its place.

Orkan

Wed, 25 Feb 2009 22:23:11 -0000

what do you mean by "it is fulltext parsing" ?

each callback will process only a part of "fulltext", ie. callback_header($header) will only process parsed header.tpl output

Trustmaster

Wed, 25 Feb 2009 21:25:11 -0000

What I don't like about parsing the output buffer is that it is fulltext parsing. Well, Seditio's advanced rewrite acted this way, and it added about 10% to render time. I know this one won't go so complex. But it doesn't look like strong design.

Orkan

Wed, 25 Feb 2009 20:18:59 -0000

# dervan :
no no no, not like goto :)
it's any little trick with $t object that used by header.php and plug.inc.php both

sorry, I didnt make myself clear enough. I mentioned GOTO as an example only. I understood your solution. however, you must admit that it only makes the code more difficult to read, right?

# dervan : i'm awaiting for your solution of problem on this carcass

this method is rather simple..
Basically each "main module", for example system/core/plug/plug.inc.php, should start with ob_start('name_of_callback_function') including header.php and footer.php as well.

just a note:

common.php

if ($cfg['gzip'])
	{ @ob_start('ob_gzhandler'); }
else
	{ ob_start(); }

ob_start('sed_outputfilters');

I would replace ob_start('sed_outputfilters') with just ob_start() to catch some warning messages, etc.. they will be discarded anyway at the end of common.php by simple @ob_end_clean(); - or even completely remove this buffer?

I can implement it, just want to hear from Kilandor, Trustmaster what they think?

dervan

Wed, 25 Feb 2009 18:35:50 -0000

# Orkan : It should be avoided, like GOTO command in C++, it only makes the code more difficult to read.

no no no, not like goto :)
it's any little trick with $t object that used by header.php and plug.inc.php both

# Orkan : I really like the output buffering feature implemented in PHP - it seems to be perfect solution here IMO.

ol korekt :)
i'm awaiting for your solution of problem on this carcass

Orkan

Wed, 25 Feb 2009 15:58:13 -0000

# dervan : Orkan, what is wrong in the use of pointers?

Well, all Im saying - it is not a procedural approach.
It should be avoided, like GOTO command in C++, it only makes the code more difficult to read.

From the other hand, what if I wanna use footer hook to set metas? see, its not perfect anyway...

I really like the output buffering feature implemented in PHP - it seems to be perfect solution here IMO.
You can have nesting buffers for all three parts: header, body and footer.. and hook them separately.

';
}
function callback_body($body)
{	
	global $counter;
	return (++$counter).' - callback_body(), content: '.$body.'
';
}
function callback_footer($footer)
{	
	global $counter;
	return (++$counter).' - callback_footer(), content: '.$footer.'
';
}


ob_start('callback_header');
echo 'echo_1_header
';

ob_start('callback_body');
echo 'echo_2_body
';

ob_start('callback_footer');
echo 'echo_3_footer
';

while(@ob_end_flush());


?>

and this will output:

3 - callback_header(), content: echo_1_header
2 - callback_body(), content: echo_2_body
1 - callback_footer(), content: echo_3_footer

see? the callback_header() is processed by ob_end_flush() last, but it is sent to the browser as first

Also, to get rid of additional hook include()'s - which is a waste, one can define (in the core) three global arrays for preg_replace() to use in these callbacks accordingly.

Kilandor

Wed, 25 Feb 2009 11:09:11 -0000

Actually using output hook in that method would be alot worse and more difficult orkan. Since all the keywords and such can be hooked into by header.main anyways.

The only way that moving where header is included would be if a plugin used any data generated by header, which is possible. Then it would completely break it, I truthfully don't know any off hand like this, but it may break future things like a more updated Whoisonline tracking method.

I can see the reason for moving it, but it doesn't solve all the problems. Also do remember this, we will be getting more advanced hooking methods, so that a hook is only loaded on certain pages/area's. By moving the header all it does is save that hook, and in some cases yes maybe extra processing.

The handling of $t won't be hard, i've already thought of how it can be done, because yes you have to store the $t from the plugin, and hold it till header parsed, then let main use the $t from the plugin.

dervan

Wed, 25 Feb 2009 05:19:09 -0000

Trustmaster, thanks

Trustmaster

Wed, 25 Feb 2009 04:44:04 -0000

It is deprecated in PHP5, because in PHP5 objects are passed by reference by default.

dervan

Wed, 25 Feb 2009 04:29:50 -0000

Orkan, what is wrong in the use of pointers?

Orkan

Wed, 25 Feb 2009 03:42:44 -0000

anyway, it doesn't look too professional, isnt?

$t_plug = new XTemplate($path_skin);
$t =& $t_plug;

Trustmaster

Wed, 25 Feb 2009 03:20:38 -0000

What we need to find out is what exactly those specialized plugins are.

Orkan

Wed, 25 Feb 2009 03:16:29 -0000

I dunno why, but something tells me it isn't a good idea..

Some more specialized plugins may not work after this change.
And this will require at least 2 hooks, so why dont use hook:output for that?

$output = preg_replace(
'/]+)>/i', 
'', 
$output, 1);

Trustmaster

Tue, 24 Feb 2009 20:32:31 -0000

Disagreed with Kilandor. Mostly standalone plugs would like to put the results of some processing into keywords/title. If you do that with a special header plugin part, that means that you have to do the processing twice, which is a waste. So if dervan's suggestion does not have any negative consequences, I would prefer it.

Kilandor

Tue, 24 Feb 2009 20:26:41 -0000

There is no need for this, actually you can modify things in the section. Because we no longer use sed_htmlmetas() except for in pfs and thats only till its re-written.

$out['head_head'] may be used to input any needed data into it outputs to {HEADER_HEAD} and is a default tag.

Actually all of the below can easily be modified. by hooking into header.main

$t->assign(array (
	"HEADER_TITLE" => $plug_title.$out['fulltitle'],
	"HEADER_DOCTYPE" => $cfg['doctype'],
	"HEADER_CSS" => $cfg['css'],
	"HEADER_COMPOPUP" => $out['compopup'],
	"HEADER_LOGSTATUS" => $out['logstatus'],
	"HEADER_WHOSONLINE" => $out['whosonline'],
	"HEADER_TOPLINE" => $cfg['topline'],
	"HEADER_BANNER" => $cfg['banner'],
	"HEADER_GMTTIME" => $usr['gmttime'],
	"HEADER_USERLIST" => $out['userlist'],
	"HEADER_NOTICES" => $out['notices'],
	"HEADER_BASEHREF" => $out['basehref'],
	"HEADER_META_CONTENTTYPE" => $out['meta_contenttype'],
	"HEADER_META_CHARSET" => $out['meta_charset'],
	"HEADER_META_DESCRIPTION" => $out['meta_desc'],
	"HEADER_META_KEYWORDS" => $out['meta_keywords'],
	"HEADER_META_LASTMODIFIED" => $out['meta_lastmod'],
	"HEADER_HEAD" => $out['head_head'],
));

dervan

Tue, 24 Feb 2009 20:18:08 -0000

known problem:
impossible to set metas from standalone plugin

the cause of problem:
header is included and parsed before launching of standalone plugin

possible solution:
header may be included (with pointers technique) after launching of standalone plugin

this solution works without problems in Seditio 121
link (in russian)

code from current system/core/plug/plug.inc.php in trac:

	/* ============= */

	require_once $cfg['system_dir'] . '/header.php';

	$t = new XTemplate($path_skin);

	$extp = array();

	if (is_array($sed_plugins))
	{
		foreach($sed_plugins as $i => $k)
		{
			if ($k['pl_hook']=='standalone' && $k['pl_code']==$e)
			{ $extp[$i] = $k; }
		}
	}

	if (count($extp)==0)
	{
		header("Location: " . SED_ABSOLUTE_URL . sed_url('message', "msg=907", '', true));
		exit;
	}

	if (is_array($extp))
	{ foreach($extp as $k => $pl) { include_once($cfg['plugins_dir'].'/'.$pl['pl_code'].'/'.$pl['pl_file'].'.php'); } }

	if ($autoassigntags)
	{
		$plugin_title = (empty($plugin_title)) ? $L['plu_title'] : $plugin_title;

		if($cfg['homebreadcrumb'])
		{
			$bhome = ''.sed_cc($cfg['maintitle']).' '.$cfg['separator'].' ';
		}
		else
		{
			$bhome = '';
		}

		$t-> assign(array(
			"PLUGIN_TITLE" => $bhome . ''.$plugin_title."",
			"PLUGIN_SUBTITLE" => $plugin_subtitle,
			"PLUGIN_BODY" => $plugin_body
		));
	}

	$t->parse("MAIN");
	$t->out("MAIN");

	require_once $cfg['system_dir'] . '/footer.php';

modified code with this solution:

	/* ============= */

	$t_plug = new XTemplate($path_skin);
	$t =& $t_plug;

	$extp = array();

	if (is_array($sed_plugins))
	{
		foreach($sed_plugins as $i => $k)
		{
			if ($k['pl_hook']=='standalone' && $k['pl_code']==$e)
			{ $extp[$i] = $k; }
		}
	}

	if (count($extp)==0)
	{
		header("Location: " . SED_ABSOLUTE_URL . sed_url('message', "msg=907", '', true));
		exit;
	}

	if (is_array($extp))
	{ foreach($extp as $k => $pl) { include_once($cfg['plugins_dir'].'/'.$pl['pl_code'].'/'.$pl['pl_file'].'.php'); } }

	unset($t);
	require_once $cfg['system_dir'] . '/header.php';
	unset($t);
	$t =& $t_plug;

	if ($autoassigntags)
	{
		$plugin_title = (empty($plugin_title)) ? $L['plu_title'] : $plugin_title;

		if($cfg['homebreadcrumb'])
		{
			$bhome = ''.sed_cc($cfg['maintitle']).' '.$cfg['separator'].' ';
		}
		else
		{
			$bhome = '';
		}

		$t-> assign(array(
			"PLUGIN_TITLE" => $bhome . ''.$plugin_title."",
			"PLUGIN_SUBTITLE" => $plugin_subtitle,
			"PLUGIN_BODY" => $plugin_body
		));
	}

	$t->parse("MAIN");
	$t->out("MAIN");
	unset($t, $t_plug);

	require_once $cfg['system_dir'] . '/footer.php';