In the code block for $colsToValues, what is 'hidden' set to?  And can you try setting it to 0 (that's a zero)?

If that doesn't work, feel free to attach your form and/or email me at dave@interactivetools.com.

Hope that helps!

All of the below is written by Claude. I’ve copied it completely so you can pick out what you need if you think it is something you could improve. Or if you think this is a host problem and I should go to them, let me know.

The issue:

After the upgrade, the site started throwing this fatal error:

Warning: require_once(/home/*********/public_html/cmsb/plugins/developerConsole/consoles/shellConsole.php): Failed to open stream: No such file or directory

Error: Failed opening required '/home/*********/public_html/cmsb/plugins/developerConsole/consoles/shellConsole.php’

I re-uploaded the file and it worked briefly, then the exact same error came back a short time later. This repeated a few times before I dug into it properly.

Root cause:

My host runs CPGuard, which includes a background malware scanner. I found the file in its quarantine log, flagged repeatedly under the signature {HEX}Malware.Expert.php.command.passthru — it's detecting shellConsole.php's use of proc_open() (the mechanism behind Shell Console's command execution) as shell-execution malware and quarantining it, then re-detecting it every time it's restored.

I understand this isn't something you can really "fix" in the sense of making proc_open()-based command execution invisible to malware scanners — a legitimate remote shell-command tool and a malicious one look identical at the code level. Given how common malware scanners are on shared/managed cPanel hosting, I'd guess this could affect other customers too, so I wanted to flag it in case it's useful.

What I did in the meantime:

Since re-uploading the file was never going to stick with the scanner re-checking this aggressively, I disabled Shell Console directly in developerConsole.php rather than keep fighting it — commented out its require_once, its pluginAction_addHandlerAndLink() registration, its entry in the dispatch() match statement, and its nav button in getNavButtons(). MySQL Console and PHP Console are unaffected and working normally. I'm aware this lives in a core-bundled file and will need to be reapplied on the next upgrade.

I've also marked the file as a false positive in CPGuard, which didn't have any effect. The file is still removed from the folder.

Thanks
Jeff

Sorry for taking so long...client went on a sabbatical or something but is back.  THANK YOU!  Works terrific! Brilliant work.

I've tested this form a LOT but I think that was prior to upgrading to v1.03 of the plugin with CMSB v3.84 (Build 3130) . Once the form is filled in by a visitor and clicks "submit" this error pops up in the browser:

Error: Column 'hidden' cannot be null in /home/xxxxxx/public_html/cecmsuAdminxxxx/plugins/formgenerator_1-03/formGenerator/formGenerator.php:125

We usually upgrade both at the same time.  So upload the latest CMSB, then switch PHP over to the latest version your hosting supports.  Then monitor the CMS Developer Log for any issues.

Our upgrade docs are here: https://interactivetools.com/docs/cmsbuilder/getting-started/upgrading/

And if you have older plugins, you may need to upgrade those as well.  But you can wait and see if they generate any errors.

Hope that helps!

I’m preparing to upgrade a fairly old but fully functional CMS Builder installation and would appreciate advice from anyone who has done a similar migration.

Current setup:

• CMS Builder v3.54 (Build 2280)
• PHP 7.4.33
• MariaDB 10.11.19
• Apache

The installation includes several custom sections, custom viewers, and some custom PHP code.

I have already created a complete staging copy, including files and database, so I'll do all testing there before touching production.

My main question is about the safest upgrade sequence.

Would you recommend:

A. Upgrading CMS Builder first while still on PHP 7.4, then moving to PHP 8.x
or
B. Moving directly to a newer CMS Builder release together with PHP 8.x?

I was considering using an intermediate CMS Builder release such as v3.59, since it appears to be one of the last versions compatible with PHP 7.x, but I would be very interested to hear what others have done in practice. Any advice and assistance would be greatly appreciated. 

Kind regards.

Andreas Lazaris

Okay, yea I'd recommend using the latest version.  Also, we have another big update coming very soon!

Error: Call to undefined function DeveloperConsole\phpConsole()

#0 Script started at /home/xxx/public_html/cmsb/admin.php:0
#1 require() at /home/xxx/public_html/cmsb/admin.php:81
#2 include() at /home/xxx/public_html/cmsb/lib/menus/default/actionHandler.php:62
#3 admin_dispatchAction() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:30
#4 require() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:81
#5 Itools\Cmsb\Admin\Plugins\activatePluginAction() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:20
#6 activatePlugin() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:261
#7 include() at /home/xxx/public_html/cmsb/lib/plugin_functions.php:309
#8 Error thrown at /home/xxx/public_html/cmsb/plugins/developerConsole/developerConsole.php:30

That error means plugins/developerConsole/consoles/phpConsole.php isn't defining the phpConsole() function it should. The file is loading (the console registrations just above that line worked), but the file's contents are seemingly not what's expected.

Can you check that file on your server? In a stock 3.82 it's 260 lines (about 10 KB), with function phpConsole() near the top. If yours is empty, truncated, or different, re-upload a fresh copy of the plugins/developerConsole/ folder and that should fix it.

If the file matches the stock one, let me know and I'll dig further.

We generally recommend running the latest release, as it includes the most fixes.   What are you trying to do? 

https://www.interactivetools.com/plugins/sitemap-generator/

I would still like the other versions, but beggars can't be choosers.

Error: Call to undefined function DeveloperConsole\phpConsole()

#0 Script started at /home/xxx/public_html/cmsb/admin.php:0
#1 require() at /home/xxx/public_html/cmsb/admin.php:81
#2 include() at /home/xxx/public_html/cmsb/lib/menus/default/actionHandler.php:62
#3 admin_dispatchAction() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:30
#4 require() at /home/xxx/public_html/cmsb/lib/menus/admin/actionHandler.php:81
#5 Itools\Cmsb\Admin\Plugins\activatePluginAction() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:20
#6 activatePlugin() at /home/xxx/public_html/cmsb/lib/menus/admin/plugins.php:261
#7 include() at /home/xxx/public_html/cmsb/lib/plugin_functions.php:309
#8 Error thrown at /home/xxx/public_html/cmsb/plugins/developerConsole/developerConsole.php:30

Operating SystemLinux 4.18.0-553.141.2.lve.el8.x86_64 (release)

• Server Name:redactted Server IP: redactted
• Disk Space Used: 94%202.33 GB free of 3.58 TB (largest dirs)
• Resource Limits: CPU Time: unlimited Memory Limit: unlimited Processes: 400(ulimit)
• Last Rebooted: 1 days, 10 hours, 5 minutes ago

Control PanelcPanel (cPanel login, WHM login)

Web ServerLiteSpeed v6.3.6

• Using config file: /home/xxx/public_html/cmsb/.htaccess
• PHP Handler: lsapi V8.3 CloudLinux 1.3

Database ServerMariaDB v10.6.27 (variables & status) - Live SQL Monitor >>

• Settings: xxx_yaascmsb.cmsb_* (change)
• Privileges: index, triggers, views, events, functions, temp tables, lock tables, flush, process
• More...

PHP VersionPHP v8.3.31 (phpinfo) - View Errors and Warnings (1) >>

• Running as xxx and using config files:
  • /opt/alt/php83/etc/php.ini
  • /home/xxx/public_html/cmsb/.htaccess
  • /opt/alt/php83/link/conf/alt_php.ini
  • /opt/alt/php83/link/conf/clos_ssa.ini
• Security Modules: ModSecurity
• Caching Modules: None detected
• Image Modules: gd, imagick

Even turning off psr does no fix it.

Good to know - that rules out the psr extension.

The developer console is failing to load on ...parameters on functions.

Can you paste the full error message exactly as it appears? The part that's cut-off there is the important diagnostic bit. The easiest place to copy it from is the Admin Menu > Developer Log in CMSB, where PHP errors and warnings get logged. Your server's PHP error log would work too.

Also, what CMSB version are you running? And what PHP version are you on?

Whc.ca has the psr extension enabled by default. This is causing CMSB developer console to fail to load.

What's the exact error message you're seeing? And is it just the CMSB developer console which fails to load, or any other pages as well?

I also use cacheing with Symphony/Cache via composer.

What is the recommended solution.

The psr extension does conflict with composer's Psr/* packages, because Symfony/Cache requires Psr/Cache, and composer will install it even while the extension is enabled, which creates the conflict.

If your host lets you, you can try disabling the psr extension, as it sounds like that's the most probable fix, but I should be able to give you a more concrete answer if you can provide the exact error message text, along with any other details you have.

I am assuming here that you are using offlineMode v1.02. 

Around line 264 in the offlineMode_getUrl() function, you see a $curl_options being set with CURLOPT_USERAGENT. Change that line to...

$curl_options = [CURLOPT_USERAGENT => $userAgent, CURLOPT_TIMEOUT => 10];

You can give that a try and test different values. You don't want it to be too long. Currently the default is set to 4. 

I believe that will achieve what you are looking for when it comes to setting CURL timeouts. I am not sure if this is going to solve the issue if the script is hanging for another reason. Worth giving it a try.

Let us know if it works out for you.

I commented out the die() statement from within loadINI and it seemed to work without issue...at least that I have seen.

That fix is fine to leave in, it won't cause any problems elsewhere.

We tracked down the root cause on our end, and it's patched in the next release.

I commented out the die() statement from within loadINI and it seemed to work without issue...at least that I have seen.

I'm going to do the same for the other site that is a problem right now, but food for thought on this one.  

If you can fill out the 2nd level support request we can take a look for you to get you up and running ASAP:

https://interactivetools.com/support/request/