How does the subplugin get instantiated?

Does your main/regular instantiate it? How?

btw: what a path..! (/blogs/plugins/gallery_plugin/1_2/gallery_plugin/_gallery.plugin.php 8| )

blah

Ah.. I see..

Use symlinks instead.. :p

There's no easy solution. The best I could think of, would be to test if $classfile_path is already set (and not set it then) and then use

var $classfile_path = __FILE__;

in the real plugin.
But that's an additional isset() check (not too bad, but not really needed either), does probably not work with PHP4 and you would have to "patch" the plugin file nonetheless and could therefor also do it in PluginInit() (speaking for 1.9/HEAD).

real solution: symlinks (instead of a real file with require()). I've read somewhere, somewhen that you can simulate symlinks on Windows - heck, a normal "Link" should work probably.

you mean that isset would have to go in _plugins.class.php not my plugin. Well i think this is the best solution anyway... But why would it not work with php4?

Edit: actually, instead of scanning the php class file for events, why don't plugin developers just have a array with the events they use, like GetDefaultSettings, but GetEvents(); or something....... I don't know why this wasn't done in the first place... Seems the best thing to me.

you mean that isset would have to go in _plugins.class.php not my plugin. Well i think this is the best solution anyway...

This is a "solution" to a very specific, local problem.

__FILE__ in "var $..." does work in PHP4, just tested. But again, a local problem (you might ship your plugin with this "feature", but in general it just "clutters" the plugin class file and is not needed).

GetEvents() has not been used, because of the magic geekiness, which the current solution provides. It's a bit like testing for functionality in Javascript rather than detecting the browser by parsing the user agent string.

However, adding an optional GetEvents(), which would not trigger the "parsing of events" is a good/valid point.

It does not fix the $classfile_path problem, though.

Why do you not just use filesystem links?

blueyed wrote:

you mean that isset would have to go in _plugins.class.php not my plugin. Well i think this is the best solution anyway...

This is a "solution" to a very specific, local problem.

__FILE__ in "var $..." does work in PHP4, just tested. But again, a local problem (you might ship your plugin with this "feature", but in general it just "clutters" the plugin class file and is not needed).

GetEvents() has not been used, because of the magic geekiness, which the current solution provides. It's a bit like testing for functionality in Javascript rather than detecting the browser by parsing the user agent string.

However, adding an optional GetEvents(), which would not trigger the "parsing of events" is a good/valid point.

It does not fix the $classfile_path problem, though.

Why do you not just use filesystem links?

I use windows, and then i would need to do all crazy stuff. But this is a problem with b2evolution, not my setup.

Adding GetEvents() fixes the problem, and it is the only problem i can see with the classfile_path....

Although what was the problem with the plugin setting it's own classfile_path again?
php.net wrote:

The full path and filename of the file. If used inside an include, the name of the included file is returned. Since PHP 4.0.2, __FILE__ always contains an absolute path whereas in older versions it contained relative path under some circumstances.

Well here is a 'fix':

In $Plugins->Register change;

		else
		{
			$Plugin = new $classname;	// COPY !
		}
		
		$Plugin->classfile_path = $classfile_path;

		// Tell him his ID :)
		if( $ID == 0 )
		{
			$Plugin->ID = --$this->smallest_internal_ID;
		}

to

		else
		{
			$Plugin = new $classname;	// COPY !
		}
		
		if( !isset($Plugin->classfile_path) )
			$Plugin->classfile_path = $classfile_path;

		// Tell him his ID :)
		if( $ID == 0 )
		{
			$Plugin->ID = --$this->smallest_internal_ID;
		}

And just add;

var $classfile_path = __FILE__;

to the plugin.

Probably a better way to do this, anyway that works, and is a better fix than symlinks imho.

"better fix than symlinks"? :D

You are using a regular file, with just an include/require line in it, to serve as a symlink.. why is that better than using a symlink right away?

And, as said, you should be able to use "Links"/Shortcuts in Widows, too.

The file layout you use, is just for your testing.

I, for myself, just use symlinks which I put into my /plugins/ folder and which point to some directory in /svn/evocms-plugins/XXX/trunk/.