9 replies to this topic

[Connor T]

Today I had received numerous emails that one of my modifications was no longer working (on my board)

I did some basic things and re-cached stuff, to no avail. I then checked my hooks folder, and to my surprise my actionOverloader was overloading some 3rd party hook , instead of public_forums_post_post.

I hadn't touched that file in like a month though (since I installed it), yet some other application managed to change it. That messed up my mod, however I just changed it back and re-uploaded it, and its still working as of now.


Any reason to why?

[bfarber]

If that third party hook was ALSO an action overloader that ALSO overloaded public_forums_post_post, then the hooks system tries to automatically account for this. You can't have two hooks overloading the same class (if you are familiar with php, we are extending the class, and you wouldn't have class a extend class b, and then class c extend class b, for instance).

What *should* have happened was something like your first hook extends the third party hook you installed, then that hook extends public_forums_post_post. In the end it would be like

hook_a extends hook_b

...

hook_b extends public_forums_post_post

and IPB would do new hook_a()

[Connor T]

oooo then that makes perfect sense, but I had gotten rid of that 3rd party mod that caused the change and it never reverted back to public_forums_post_post

Thanks for explaining

[bfarber]

Ah, ok then.

No problem.

If you uninstalled that hook, but the class hadn't reset properly, submit that as a bug (assuming you uninstalled it through the ACP normally, etc.).

[ll4ever]

that's all fine and dandy but doesn't work when using parent inside the hook.

try it!

[bfarber]

Yes, that would be correct, because your "parent" would technically be the next class up the chain.

[villabus]

bfarber, on 19 November 2009 - 12:30 PM, said:

Yes, that would be correct, because your "parent" would technically be the next class up the chain.

As a developer in a large group of developers, how would you detemine that a class has been already extended and by what class without looking at every IPB hooks_files record on every site to be installed?

By the way php classes can be extended more than once as in this example:

<?PHP
	class employee
   {
	   protected $empname;
	   protected $empage;
 
	   function setdata($empname,$empage)
	  {
		  $this->empname = $empname;
		  $this->empage = $empage;
	  }
 
	  function outputData(){}
   }
 
   class EmployeeData extends employee   //extending abstract class
   {
		function __construct($name,$age)
		{
		   $this->setdata($name,$age);
		}
 
	   function outputData()
	   {
		  echo $this->empname;
		  echo $this->empage;
	   }
   }
 
   class EmployeeD extends employee   //extending abstract class
   {
		function __construct($name,$age)
		{
		   $this->setdata($name,$age);
		}
 
	   function outputData()
	   {
		  echo $this->empname;
		  echo $this->empage;
	   }
   }
 
	$a = new EmployeeData("Hitesh","24");
	$a->outputData();
	$b = new EmployeeD("Jones","30");
	$b->outputData();
?>

It is not the preferred method but when developing hooks while others are developing hooks without any communication it would seem to be the only way.

I am waiting for an answer as I have already run into this problem numerous times and having to go to every site that installs it to find the other class really defeats th idea of having classes.

Thanks in advance
Villabus

[bfarber]

When a new action overloader is installed in the ACP, IPB loops through the existing hooks installed, and resets the "extends" part of the class definition appropriately.

Say you have 1 hook installed that's like

class myhook extends public_forums_forums_topics

Then you install another hook that's

class metoo extends public_forums_forums_topics

When IPB goes to write the hook .php files to the hooks folder, it should actually change that second file to be

class metoo extends myhook

Then we instantiate metoo

[villabus]

bfarber, on 30 December 2009 - 05:56 PM, said:

When a new action overloader is installed in the ACP, IPB loops through the existing hooks installed, and resets the "extends" part of the class definition appropriately.

Say you have 1 hook installed that's like

class myhook extends public_forums_forums_topics

Then you install another hook that's

class metoo extends public_forums_forums_topics

When IPB goes to write the hook .php files to the hooks folder, it should actually change that second file to be

class metoo extends myhook

Then we instantiate metoo

It doesn't work that way. That is why iBotPeaches hook stopped working.

I just did 2 for class public_forums_moderate_moderate and both ended up written exactly as coded:

Quote

class VAsl extends public_forums_moderate_moderate
{

Quote

class VAct extends public_forums_moderate_moderate
{

As a test This was the code to be executed.

Quote

            echo "<br> I am in VAct <br>";
        switch ( $this->request['do'] )
{
case '40':
$this->showForma();
break;
}
parent::doExecute( $registry );

Quote

            echo "<br> I am in VAsl <br>";
        switch ( $this->request['do'] )
{
case '41':
$this->showFormb();
break;
}
parent::doExecute( $registry );

Both work individually installed. If installed together the last one installed only works.

I have the latest ver of 3.05 installed.

[bfarber]

I would recommend submitting a bug report in that case.  Something must have broke at some point.