CodingJungle

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 :).

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!

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.

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.

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?

this is related to it, as it is not able to detect if an import/alias was used instead of the FQN.

shouldn't the solution to becoming php 8+ compliant, be to start updating and using php 7.x features yourself in your codebase instead of the onus of us not using them? or at least change the error message, instead of making what is being done is php 8 incompatible, its cause the overridden method (on different return types at least) are cause the method being overridden doesn't use php 7 features, cause it is sending the wrong message that these improvements in php 8 aren't php 8 compatible when they are.

Application Dev Toolbox Mismatching parameter list \Symfony\Component\VarDumper\Dumper\AbstractDumper::dumpLine() N/A /applications/toolbox/sources/vendor/symfony/var-dumper/Dumper/CliDumper.php:551 so i have to be sure third party libs pulled in via composer match whatever criteria scanner.php sets out? i wasn't even aware IPS uses anything from symfony, if you do, you probably should namespace it differently since the autoloader isn't psr-4 compliant and there is no way to load/check/compare to your composer.json

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).

Error thrown with message "Call to undefined function IPS\Application\preq_quote()" Stacktrace: #16 Error in /opt/homebrew/var/www/dev/system/Application/Scanner.php:139 it should be preg_quote, not preq_quote 🙂 and if i change it to preg_quote, i get this error: Whoops\Exception\ErrorException thrown with message "preg_match(): Unknown modifier 'o'" Stacktrace: #17 Whoops\Exception\ErrorException in /opt/homebrew/var/www/dev/system/Application/Scanner.php:169

Whoops\Exception\ErrorException thrown with message "explode(): Passing null to parameter #2 ($string) of type string is deprecated" Stacktrace: #13 Whoops\Exception\ErrorException in /private/var/tmp/theme_core_global_forms_texta0ayPh:10 #12 explode in /private/var/tmp/theme_core_global_forms_texta0ayPh:10 #11 IPS\Theme\theme_core_global_forms_text in /opt/homebrew/var/www/dev/system/Theme/Dev/Template.php:171 #10 IPS\Theme\Dev\_Template:__call in /opt/homebrew/var/www/dev/system/Helpers/Form/Text.php:156 #9 IPS\Helpers\Form\_Text:html in /private/var/tmp/theme_core_admin_support_guideSearchFormUsUAi0:60 #8 IPS\Theme\theme_core_admin_support_guideSearchForm in /opt/homebrew/var/www/dev/system/Theme/Dev/Template.php:171 #7 IPS\Theme\Dev\_Template:__call in /opt/homebrew/var/www/dev/system/Helpers/Form/Form.php:519 #6 IPS\Helpers\_Form:customTemplate in /private/var/tmp/theme_core_admin_support_dashboardXIikwy:249 #5 IPS\Theme\theme_core_admin_support_dashboard in /opt/homebrew/var/www/dev/system/Theme/Dev/Template.php:171 #4 IPS\Theme\Dev\_Template:__call in /opt/homebrew/var/www/dev/applications/core/modules/admin/support/support.php:67 #3 IPS\core\modules\admin\support\_support:manage in /opt/homebrew/var/www/dev/system/Dispatcher/Controller.php:118 #2 IPS\Dispatcher\_Controller:execute in /opt/homebrew/var/www/dev/applications/core/modules/admin/support/support.php:48 #1 IPS\core\modules\admin\support\_support:execute in /opt/homebrew/var/www/dev/system/Dispatcher/Dispatcher.php:153 #0 IPS\_Dispatcher:run in /opt/homebrew/var/www/dev/admin/index.php:13 I keep getting this error when switching over to test my apps in php 8.1 when using ips 4.7.1 and 4.7.2 beta 2.

,. i went to go renew my license this morning, and being super early and not having my coffee yet, i didn't want to pull out my debit card and type out the really complicated strings of numbers 😛 (as the card on file is super outdated lol) and i'm done paying paypal fees this month, so i was excited to see "apple pay". So i selected it, thought it was odd it was showing 'GPay', was like "alright, that will work too, i have that". however when i clicked on it, nothing happened. so i thought maybe it was me using chrome, so i tried safari, same thing. it showed the 'GPay" logo, but when i clicked on it, nothing happened. So i ended up having to get my debit card. this is no biggy, just thought i'd let you know, maybe apple pay is too big brained for me, but i couldn't get it to work for renewal.

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 }

a possible solution is to check the data in the \IPS\Request::i()->url() method. if it is the default app on the "homepage", then ->path should be empty: IPS\Http\Url\Friendly Object ( [url:protected] => https://dev.codingjungle.com/ [data] => Array ( [scheme] => https [host] => dev.codingjungle.com [port] => [user] => [pass] => [path] => / [query] => [fragment] => ) [queryString] => Array ( ) [hiddenQueryString] => Array ( [app] => stratagem [module] => view [controller] => projects ) [seoPagination] => [base] => front [seoTemplate] => stratagem [seoTitles] => Array ( ) [friendlyUrlComponent] => ) otherwise it will be populated with the path from the furl: IPS\Http\Url\Friendly Object ( [url:protected] => https://dev.codingjungle.com/stratagem [data] => Array ( [scheme] => https [host] => dev.codingjungle.com [port] => [user] => [pass] => [path] => /stratagem [query] => [fragment] => ) [queryString] => Array ( ) [hiddenQueryString] => Array ( [app] => stratagem [module] => view [controller] => projects ) [seoPagination] => [base] => front [seoTemplate] => stratagem [seoTitles] => Array ( ) [friendlyUrlComponent] => stratagem ) there might be a caveat to this, as i haven't fully tested this. it was something off the top of my head. btw this could be a good method too, as applications and modules get cached, so it shouldn't cost anything noticeable in loads, well nothing more than most servers can afford to use.

you must have a setting enabled i didn't when testing, but the error is the same method, in the same area, so it the new version i release should fix it. i pushed the update here already, so i'm not sure when it will be available, i also release it on my site, but i don't recall where you purchased it from.