Connor T Posted November 18, 2009 Posted November 18, 2009 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 Posted November 18, 2009 Posted November 18, 2009 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 Posted November 19, 2009 Author Posted November 19, 2009 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 Posted November 19, 2009 Posted November 19, 2009 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 Posted November 19, 2009 Posted November 19, 2009 that's all fine and dandy but doesn't work when using parent inside the hook. try it!
bfarber Posted November 19, 2009 Posted November 19, 2009 Yes, that would be correct, because your "parent" would technically be the next class up the chain.
villabus Posted December 30, 2009 Posted December 30, 2009 [quote name='bfarber' date='19 November 2009 - 05:30 PM' timestamp='1258651829' post='1880697'] 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: 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<?PHP
bfarber Posted December 30, 2009 Posted December 30, 2009 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 Then you install another hook that's When IPB goes to write the hook .php files to the hooks folder, it should actually change that second file to be Then we instantiate metooclass myhook extends public_forums_forums_topicsclass metoo extends public_forums_forums_topicsclass metoo extends myhook
villabus Posted December 30, 2009 Posted December 30, 2009 [quote name='bfarber' date='30 December 2009 - 10:56 PM' timestamp='1262213790' post='1893770'] 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 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: { { As a test This was the code to be executed. echo "<br> I am in VAct <br>"; switch ( $this->request['do'] ) { case '40': $this->showForma(); break; } parent::doExecute( $registry ); 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.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 myhookclass VAsl extends public_forums_moderate_moderateclass VAct extends public_forums_moderate_moderate
bfarber Posted January 1, 2010 Posted January 1, 2010 I would recommend submitting a bug report in that case. Something must have broke at some point.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.