Jump to content

CodingJungle

Clients
  • Posts

    3,066
  • Joined

  • Days Won

    31

Reputation Activity

  1. Thanks
    CodingJungle got a reaction from The Old Man in Check if we're on the main board page   
    plus \IPS\Dispatcher already loads these values:
    $app = null; $module = null; if(\IPS\Dispatcher::hasInstance()){ $dispatcher = \IPS\Dispatcher::i(); $app = $dispatcher->application; $module = $dispatcher->module; } if($app !== null && $app->default && $module->default){ //if we are here, we on the default app/module, lets do our thing }  
  2. Agree
    CodingJungle reacted to Ocean West in v5 news coming soon...   
    Can you speak yet of any database changes?

    I know some settings are stored in a bitwise fashion (forum features) and enabling features in mass across all forums is impossible.
    What changes do you anticipate for the ACP, or is the first push focusing on public-facing changes?
  3. Like
    CodingJungle got a reaction from Manuel Monroy in v5 news coming soon...   
    constant adoption of new php features and faster bumps in the min. required PHP. PHP is releasing newer versions faster than ever before and killing off the older versions just as fast. the biggest problem i had with IPS 4.x, was that it never really evolved. sure it changed, but it never really embraced features even found in php 5.4, let alone features added thru out 7's life.  Adoption of PSR for your code standards. gonna be honest here, i find your "coding standard" (the formatting of your code) to be the visual equivalent of an angry monkey biting down on a vibrator.  it is a serious amount of unpleasantness to view your code. i think the adoption of PSR, would be more welcoming to third party who has worked out in the wild on other things that use the PSR standard (which most frameworks/libs do now days and by nature a lot of apps have just adopted it from them).  this is a minor one, the embracing of imports+aliases when needed over FQN. FQN can make code look ugly,messy and add a fair amount of bulk. using imports, i can just look at the top of the file and see instantly what it is using. full adoption of semantic versioning. a lot of the problems that you have with 3rd party is cause you guys never stuck with a standard. you would throw in backward breaking changes in patch versions. it is pretty insane that a professional level software company wouldn't use a standard like semantic at the very least. Events Manager. i like the hook system just as much as the next guy, but i think polling of all the apps in the market place to see what is being hooked and how often, and then prioritize event triggers for those, you could probably ease a lot of your woes.  a better form class. i've said it plenty of times over the last several years, i really dislike the form building in 4. i think it was a step in the right direction, but i honestly think it could've been done better. i think it produces an extremely ugly code that could've easily been abstracted better. better use of traits/interfaces/abstract.  there are a lot of times where traits/interfaces/abstract classes should be used in 4.x, and they are simply not. a good example of this is extensions. there have been times where you have updated an extension, where you have removed methods or added in new ones and i had no idea. this is a good place where each extension gets an abstract class, where you can add/remove these methods, so if we don't implement them, they wont blow up.  search. have the search actually use the objects. you currently have things like "titleFromIndexData" and "urlFromIndexData", amongst other methods that attempt (and poorly i might add) to usurp the object class you have given us to do these very things. there are a few of my apps, who do not use the cookie cutter nature you've assigned here, so these methods require addition work from me and at times, impossible to do anything with the provided data, so i have to load the object anyway.  clubs. clubs are sort of a nightmare to implement. cause they are implemented on the item class, but god forbid you use a container/sub container class. then it becomes a huge annoyance to properly implement. clubs should be seriously revisited and much better implemented. i'm sure i have more, but i get the feeling as it is, its already too late in the development of 5.x to serious take into consideration anything i would like to see changed. too bad you guys didn't ask this at more of the start of the development, we might've been able to create something wonderful together :). 
  4. Like
    CodingJungle got a reaction from Chris Anderson in v5 news coming soon...   
    constant adoption of new php features and faster bumps in the min. required PHP. PHP is releasing newer versions faster than ever before and killing off the older versions just as fast. the biggest problem i had with IPS 4.x, was that it never really evolved. sure it changed, but it never really embraced features even found in php 5.4, let alone features added thru out 7's life.  Adoption of PSR for your code standards. gonna be honest here, i find your "coding standard" (the formatting of your code) to be the visual equivalent of an angry monkey biting down on a vibrator.  it is a serious amount of unpleasantness to view your code. i think the adoption of PSR, would be more welcoming to third party who has worked out in the wild on other things that use the PSR standard (which most frameworks/libs do now days and by nature a lot of apps have just adopted it from them).  this is a minor one, the embracing of imports+aliases when needed over FQN. FQN can make code look ugly,messy and add a fair amount of bulk. using imports, i can just look at the top of the file and see instantly what it is using. full adoption of semantic versioning. a lot of the problems that you have with 3rd party is cause you guys never stuck with a standard. you would throw in backward breaking changes in patch versions. it is pretty insane that a professional level software company wouldn't use a standard like semantic at the very least. Events Manager. i like the hook system just as much as the next guy, but i think polling of all the apps in the market place to see what is being hooked and how often, and then prioritize event triggers for those, you could probably ease a lot of your woes.  a better form class. i've said it plenty of times over the last several years, i really dislike the form building in 4. i think it was a step in the right direction, but i honestly think it could've been done better. i think it produces an extremely ugly code that could've easily been abstracted better. better use of traits/interfaces/abstract.  there are a lot of times where traits/interfaces/abstract classes should be used in 4.x, and they are simply not. a good example of this is extensions. there have been times where you have updated an extension, where you have removed methods or added in new ones and i had no idea. this is a good place where each extension gets an abstract class, where you can add/remove these methods, so if we don't implement them, they wont blow up.  search. have the search actually use the objects. you currently have things like "titleFromIndexData" and "urlFromIndexData", amongst other methods that attempt (and poorly i might add) to usurp the object class you have given us to do these very things. there are a few of my apps, who do not use the cookie cutter nature you've assigned here, so these methods require addition work from me and at times, impossible to do anything with the provided data, so i have to load the object anyway.  clubs. clubs are sort of a nightmare to implement. cause they are implemented on the item class, but god forbid you use a container/sub container class. then it becomes a huge annoyance to properly implement. clubs should be seriously revisited and much better implemented. i'm sure i have more, but i get the feeling as it is, its already too late in the development of 5.x to serious take into consideration anything i would like to see changed. too bad you guys didn't ask this at more of the start of the development, we might've been able to create something wonderful together :). 
  5. Like
    CodingJungle got a reaction from SeNioR- in v5 news coming soon...   
    constant adoption of new php features and faster bumps in the min. required PHP. PHP is releasing newer versions faster than ever before and killing off the older versions just as fast. the biggest problem i had with IPS 4.x, was that it never really evolved. sure it changed, but it never really embraced features even found in php 5.4, let alone features added thru out 7's life.  Adoption of PSR for your code standards. gonna be honest here, i find your "coding standard" (the formatting of your code) to be the visual equivalent of an angry monkey biting down on a vibrator.  it is a serious amount of unpleasantness to view your code. i think the adoption of PSR, would be more welcoming to third party who has worked out in the wild on other things that use the PSR standard (which most frameworks/libs do now days and by nature a lot of apps have just adopted it from them).  this is a minor one, the embracing of imports+aliases when needed over FQN. FQN can make code look ugly,messy and add a fair amount of bulk. using imports, i can just look at the top of the file and see instantly what it is using. full adoption of semantic versioning. a lot of the problems that you have with 3rd party is cause you guys never stuck with a standard. you would throw in backward breaking changes in patch versions. it is pretty insane that a professional level software company wouldn't use a standard like semantic at the very least. Events Manager. i like the hook system just as much as the next guy, but i think polling of all the apps in the market place to see what is being hooked and how often, and then prioritize event triggers for those, you could probably ease a lot of your woes.  a better form class. i've said it plenty of times over the last several years, i really dislike the form building in 4. i think it was a step in the right direction, but i honestly think it could've been done better. i think it produces an extremely ugly code that could've easily been abstracted better. better use of traits/interfaces/abstract.  there are a lot of times where traits/interfaces/abstract classes should be used in 4.x, and they are simply not. a good example of this is extensions. there have been times where you have updated an extension, where you have removed methods or added in new ones and i had no idea. this is a good place where each extension gets an abstract class, where you can add/remove these methods, so if we don't implement them, they wont blow up.  search. have the search actually use the objects. you currently have things like "titleFromIndexData" and "urlFromIndexData", amongst other methods that attempt (and poorly i might add) to usurp the object class you have given us to do these very things. there are a few of my apps, who do not use the cookie cutter nature you've assigned here, so these methods require addition work from me and at times, impossible to do anything with the provided data, so i have to load the object anyway.  clubs. clubs are sort of a nightmare to implement. cause they are implemented on the item class, but god forbid you use a container/sub container class. then it becomes a huge annoyance to properly implement. clubs should be seriously revisited and much better implemented. i'm sure i have more, but i get the feeling as it is, its already too late in the development of 5.x to serious take into consideration anything i would like to see changed. too bad you guys didn't ask this at more of the start of the development, we might've been able to create something wonderful together :). 
  6. Like
    CodingJungle got a reaction from TDBF in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  7. Like
    CodingJungle got a reaction from TDBF in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    this is one i would disagree on. the documentation states this:
    so this tells me that my hook is being extended by the compiled theme class, which looks like this:

    any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
    this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
    sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
    any way, i'm not even suppose to be here today!

     
  8. Like
    CodingJungle got a reaction from DSystem in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    this is one i would disagree on. the documentation states this:
    so this tells me that my hook is being extended by the compiled theme class, which looks like this:

    any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
    this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
    sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
    any way, i'm not even suppose to be here today!

     
  9. Like
    CodingJungle reacted to Afrodude in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    I pointed this out just recently mate. 
  10. Like
    CodingJungle got a reaction from Chris Anderson in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    this is one i would disagree on. the documentation states this:
    so this tells me that my hook is being extended by the compiled theme class, which looks like this:

    any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
    this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
    sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
    any way, i'm not even suppose to be here today!

     
  11. Like
    CodingJungle got a reaction from Afrodude in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    this is one i would disagree on. the documentation states this:
    so this tells me that my hook is being extended by the compiled theme class, which looks like this:

    any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
    this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
    sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
    any way, i'm not even suppose to be here today!

     
  12. Like
    CodingJungle got a reaction from SeNioR- in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    this is one i would disagree on. the documentation states this:
    so this tells me that my hook is being extended by the compiled theme class, which looks like this:

    any developer worth their weight in salt, would come to the same conclusion that calling a parent in an overloaded method, should not be a problem. its a basic feature of OOP in php. so i would still argue that the problem is an engineering one inside the framework. 
    this is why i get extremely frustrated with IPS. its a substantial investment on my part to be apart of the third party community (renewal fees + time), then to be told that a lot of the support issues IPS faces if from third party and frankly a lot of that is on IPS hands. you give us almost no tools, no real sdk (like example or boilerplate code), IDE plugins, cli generators, etc, that a lot of free frameworks will have available.  like most of the "incompatibilities" created by third party i've ever run into in IPS could be eradicated with with included developer tools like a  proxy class generator or a way for hooks to be understood by IDE's. 
    sure i understand IPS isn't a multibillion company and doesn't have the resources to develop like a IDE plugin for its framework, but most of the other things i mentioned, i was able to create without any of that and i'm just one guy with a linux PC and a deskcat. 
    any way, i'm not even suppose to be here today!

     
  13. Like
    CodingJungle got a reaction from SeNioR- in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  14. Like
    CodingJungle got a reaction from Afrodude in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  15. Like
    CodingJungle got a reaction from Arthmoor in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  16. Like
    CodingJungle got a reaction from IBResource ltd. in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  17. Like
    CodingJungle got a reaction from DSystem in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  18. Like
    CodingJungle got a reaction from Kirill Gromov in Upgrade problem... Fatal error: Cannot use "parent" when current class scope has no parent in   
    sorry Daniel, but this is NOT a third party issue. This is an engineering problem inside the framework. This was an issue reported/showed up almost 2 years ago and u guys did nothing to fix it or even comment on it, it was left up to me to debug it and come out with a solution. This is a good example of us using features of php (and of IPS) and since the framework is still mostly a pho 5.3 framework, it not playing nice with the modern versions. This is honestly the kind of nonsense of why I left.
    These are not third party developer issues, don’t let IPS TELL U THEY ARE. these are issues caused by an engineering problem with in the framework as demonstrated by the topic Adriano linked too. They are eval’ing a non extended class to check for errors or something like that and that is where it throws the deprecate notice in 7.4 and the fatal in 8.0+. Put IPS’s feet to the fire, demand better from a software company that charges $300 a year for renewals for mediocre improvements and many years of outstanding bugs they ignore or refuse to fix.
  19. Like
    CodingJungle got a reaction from DSystem in Theme Hook weirdness in 4.6   
    @Adriano Faria its not 4.6 that is at fault per se, IPS is at some fault here due to the way they engineered how the theme hooks work, but it's the latest php 7.4 and 8.0 that is the issue.
    example:
    <?php class myclass { public function myfunction(){ return parent::myfunction(); } } this will error out on the new versions of 7.4 and 8.0, cause myclass isn't a child class of anything, so there is no parent to call. 
    the theme hooks get eval'ed as stand alone classes, they replaced the " extends _HOOK_FILE" with "_tmp" (same with parent::hookData() gets replaced with array() ), so the class would be something like class my_theme_hook_temp {}. during the eval process, it it validating the code and that validation is failing on anything with parent::myfunction() that is being called in the code, that is why the call_user_func_array is working for toolbox, cause it passes the validation, so the template will build. 
    so its not the parent::hookData() that i original thought it was, cause i just took a cursory look at the code, patched my files, it seemed to work cause my datastore wasn't cleared, but as soon as it cleared, i got that error. 
    so in any template overrides you are doing, you need to wrap it with a if(\is_callable('parent::myfunction')){} and then inside the if statement, call the parent method with:
    return \call_user_func_array( 'parent::' . __FUNCTION__, \func_get_args() ); like i have done in the example hook i posted a few post up. if you need further help, send me the app, and i will make the changes so you can see within your code what i'm talking about 🙂
  20. Like
    CodingJungle got a reaction from InvisionHQ in 4.7.2 Beta 3: InnoDB & MyIsam tables   
    foreach( \IPS\Db::i()->getTables() as $table){ $def = \IPS\Db::i()->getTableDefinition($table); if($def['engine'] === 'MyISAM') { $query = 'ALTER TABLE ' . $table . ' ENGINE=InnoDB;'; \IPS\Db::i()->query($query); } } i use this snippet to convert them over to innodb. it is likely your databases default engine type is myisam instead of innodb (cause not every schema has the engine type when the table is created, so the db installer lets the db server select it. this is what looks like what is happening here). 
  21. Like
    CodingJungle got a reaction from Refsmmat in [CJ] Downloads Plus (Support Topic)   
    i've tested the code in php 8, the only thing that i see that is the problem is with scanner.php itself introduced by IPS. I used an import instead of a FQN. imports are supported by php and are not incompatible with PHP 8. 
    I'll release a fix for it, but i really shouldn't have too tbh. 
     
  22. Like
    CodingJungle got a reaction from SeNioR- in scanner.php and non ips libs   
    this is still a problem. i've reported the issue to symfony, but haven't heard anything back from them. I've changed the file manually, but since it is a file that is NEVER used in what i'm calling, its existestance is the problem. been running php 8 for a long while now on my dev for other project and it is ONLY this software suite that seems to have any issues or needs this tool, why is that?
  23. Like
    CodingJungle got a reaction from SeNioR- in Theme Hook weirdness in 4.6   
    @Adriano Faria
    if ( \is_callable('parent::includeCSS') ) { return \call_user_func_array( 'parent::' . __FUNCTION__, \func_get_args() ); } something like this appears to work (change the if statement to the method you are overriding). i haven't tested it exhaustively, but it might be better than waiting for ips 4.12 for a fix 😛 
  24. Thanks
    CodingJungle got a reaction from A Zayed in Theme Hook weirdness in 4.6   
    @Adriano Faria its not 4.6 that is at fault per se, IPS is at some fault here due to the way they engineered how the theme hooks work, but it's the latest php 7.4 and 8.0 that is the issue.
    example:
    <?php class myclass { public function myfunction(){ return parent::myfunction(); } } this will error out on the new versions of 7.4 and 8.0, cause myclass isn't a child class of anything, so there is no parent to call. 
    the theme hooks get eval'ed as stand alone classes, they replaced the " extends _HOOK_FILE" with "_tmp" (same with parent::hookData() gets replaced with array() ), so the class would be something like class my_theme_hook_temp {}. during the eval process, it it validating the code and that validation is failing on anything with parent::myfunction() that is being called in the code, that is why the call_user_func_array is working for toolbox, cause it passes the validation, so the template will build. 
    so its not the parent::hookData() that i original thought it was, cause i just took a cursory look at the code, patched my files, it seemed to work cause my datastore wasn't cleared, but as soon as it cleared, i got that error. 
    so in any template overrides you are doing, you need to wrap it with a if(\is_callable('parent::myfunction')){} and then inside the if statement, call the parent method with:
    return \call_user_func_array( 'parent::' . __FUNCTION__, \func_get_args() ); like i have done in the example hook i posted a few post up. if you need further help, send me the app, and i will make the changes so you can see within your code what i'm talking about 🙂
  25. Like
    CodingJungle got a reaction from media in 4.7.2 Beta 3: InnoDB & MyIsam tables   
    foreach( \IPS\Db::i()->getTables() as $table){ $def = \IPS\Db::i()->getTableDefinition($table); if($def['engine'] === 'MyISAM') { $query = 'ALTER TABLE ' . $table . ' ENGINE=InnoDB;'; \IPS\Db::i()->query($query); } } i use this snippet to convert them over to innodb. it is likely your databases default engine type is myisam instead of innodb (cause not every schema has the engine type when the table is created, so the db installer lets the db server select it. this is what looks like what is happening here). 
×
×
  • Create New...