Your code example probably does not work, because you're registering them on the $Plugins object and not $AvailablePlugins..

But anyway, an event for this is a lot better, because it would not register the plugin always, if panels_plugin gets instantiated.

However, I've rewritten the discover method, so that it respects all files below plugins/, so this does not seem to be needed..

But with files inside /panels_plugin/Panels/
they will be named _name.panel.php, not _name.plugin.php ...
Edit: As they will be inheriting from [/panels_plugin/_panel.class.php]

Also, i think having the panels_plugin adding the plugins is a better idea, as someone can not make the mistake of adding the panels into the Plugins directory instead of the Panels directory.
Plus the panels_plugin could also make it so it only registers the panels if it is installed. As there is no point installing or seeing what panel plugins i have if i do not even have the panels_plugin installed.

Edit: And what is the difference between Plugins and AvailablePlugins? - Which does work.

$AvailablePlugins displays the available plugins. $Plugins are the installed plugins.

The panels_plugin should not care, where the panel plugins are, should it?

The only reason for a custom register procedure seems to be the naminf scheme *.panel.php. I'm not sure, if this is a good idea, though.

But it would make more sense to the end user though.

As the Panels inherit from the Panel Class which inherits from the Plugin Class. And they will be dependent on panels_plugin anyway.

And having like 15 or so Panels in the Plugins Page when the user doesn't even want to use them would be anoying.

Plus if it's a _name.panel.php, they know to stick it in the Panels folder, when if its a _name.plugin.php, they might stick it in the Plugins folder which would probably cause problems...

And yeh, as in the future if other plugins adopt this idea, you will end up with a lot of different plugin types and it may end up hard to figure out what is what in the file structure when they are all _name.plugin.php....

Well i think having panel_plugin handling the registering of panels quite a good idea.

You can already declare dependencies in 1.8.

¥

Yeh, and declaring a dependency makes sure that the dependency is installed otherwise fail to install the plugin.

But if the user does not want anything to do with Panels, then why would the user still want to see 15 or so Panels in the Plugins Viewer.

And it makes more sense having the Parent control which children are loaded, as their may be special conditions when one is not loaded etc (version conflicts, other dependency conflicts, etc). Instead of the Grandparent (b2evo) deciding ;)

And we also go back to the user being able to easily identify what is what and where it goes via the [_name.type.php] naming convention.

And just to point out, this concept relates to the feature request 'Plugin Grouping' here;
http://forums.b2evolution.net//viewtopic.php?t=8281

Why would a user have 15 panels of plugins uploaded/installed if they weren't interested?

¥

That's a good point.
So let's say the user has just downloaded the Panels Plugin, it comes bundled with several Panels.

Then the plugins viewer would be quite messy....

Anyway my other arguments are valid...

lol @ arguments ;)

¥

;) What word would u use?

lol, I'd happily agree at you being argumentative :p

As an aside, the naming convention (_name.type.php) : all panel types are plugins. "the Parent control which children are loaded" : name me a parent that knew how many children (and what they'd do) they'd have.

¥

As an aside, the naming convention (_name.type.php) : all panel types are plugins.

All Panels actually inherit from the Panel Class, and that inherits from the Plugin Class.

But i will also be using this concept for 3 other things ;)

And some of them may just be one file, so if they just downloaded:
_somefile.plugin.php , and they are a 'newb'. I can see some problems arising then.

"the Parent control which children are loaded" : name me a parent that knew how many children (and what they'd do) they'd have.

The Plugins Class;

$s = sizeof($AvaliablePlugins->Plugins);
echo 'I have '.$s.' children.';
for ( $i = 0; $i < $s; $i++ ) {
$Current_Child = & $AvaliablePlugins->Plugins[$i];
echo $Current_Child->name.' does '.$Current_Child->long_desc;
}

:)

Anyway, what are we arguing about again?
As far as i can see, if the event gets added everyones happy....

All Panels actually inherit from the Panel Class, and that inherits from the Plugin Class.

So they're plugins with a dependancy then?

(and what they'd do)

Echo'ing a long_desc is not the same as hearing what it says ;)

Anyway, what are we arguing about again?

The price of beer in some parts of the world (bloody extortionate it is as well :|)

¥

:'( still not added in the v1.8-beta release, but heres the hack to do it.

[ FILE: /blogs/inc/_misc/_plugins.class.php ]

Add following into the get_supported_events' array.

'AfterPluginsDiscover' => '',

Add following to the end of the discover() function;

$GLOBALS['Plugins']->trigger_event( 'AfterPluginsDiscover' );

[ FILE: /blogs/inc/_misc/_plugin.class.php ]

Add following into the Plugin Class;

	/**
	 * Event handler: called after plugins have been discovered so plugins
	 *                can manually add any additional plugins
	 *
	 * @param array Associative array of parameters
	 */
	function AfterPluginsDiscover( & $params )
	{
	}

And a example use is here;

	function AfterPluginsDiscover( & $params ) {
		
		global $AvailablePlugins;
		$Panels = array();
		$dir = dirname(__FILE__).'\\Panels';
		
		if ($dh = opendir($dir)) {
			$dir = str_replace('\\','/',$dir).'/';
			while (($file = readdir($dh)) !== false) {
				if( is_file($dir.$file) ) {
					$name = substr($file,1,strlen($file)-11);
					$Panels[] = array( $name.'_panel', $dir.$file );
				}
			}
			closedir($dh);
		}
		
		$s = sizeof($Panels);
		for( $i = 0; $i < $s; $i++ )
		$AvailablePlugins->register( $Panels[$i][0], 0, -1, NULL, $Panels[$i][1] );
		
		$this->Panels = $AvailablePlugins->get_Plugins_in_sub_group('Panels','Panels');
		
	}