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/

I was hoping you'd have a bit of a better answer :).  Oh well, I will try to solve it on my own.

Well I know that $_SERVER["PATH_INFO"] would not be defined if you are attempting to run the code through the Command Line Interface (CLI) like can be done through scheduled tasks. I would start there in finding a cause. In the error message, does it show a filename and line number or is that just appearing on the front-end of the site as a generic error? Do you see anything in the error logs of CMSB?

Have you tried disabling all your scheduled tasks? I am not too familiar with the very old versions of CMSB so perhaps there is a script there that is breaking on the upgrade and could be ran through a scheduled task.

Let us know if you find any additional information. :)

loadINI: Undefined array key "PATH_INFO"

This is at the earliest spot in the upgrade, so I think it's OK to not restore the database.  If I take it back to the saved cmsAdmin folder, it comes up OK.

I looked at the software and it seems to be doing the right thing with PATH_INFO, but I can't say for sure.

I am looking at the code now, but there is quite a bit.  Has anyone run into this?

I also use cacheing with Symphony/Cache via composer.

What is the recommended solution. 

Thanks for the report! We tracked this down, and it's a timing issue with bulk uploads, not a permissions problem or an upload limit.

Two things are going on:

1. The upload form doesn't limit how many files it sends at once. Browsers used to cap this at about 6 requests per server, but on newer hosting with HTTP/2 that cap is gone, so dropping 100 images can start 100 uploads at the same time. Each one is a separate server process resizing images into thumbnails, and 100 of those at once is likely what's causing the hangs.
2. Each upload request also cleans up old temporary upload files. With that many requests running at once, they all try to erase the same files - the first one wins, and the others report "No such file or directory". The CMS was treating that as an error, but nothing is actually wrong: the file was already removed. That's the "Unable to remove file" message your client is seeing.

Here's a patch you can apply to the 3.84 site now. Both changes will also be in the next release.

In cmsb/lib/upload_storage_strategy.php (around line 123), find:

if (!@unlink($filepath)) {
    $error  = "Unable to remove file '" .htmlencode($filepath). "'\n\n";
    $error .= "Please ask your server administrator to check permissions on that file and directory.\n\n";
    $error .= "The PHP error message was: " .errorlog_lastError(). "\n";
    throw new RuntimeException($error);
}

And replace it with:

if (!@unlink($filepath)) {
    clearstatcache(true, $filepath);
    if (is_file($filepath)) {
        \Itools\Cmsb\CMS::log("Unable to remove upload file '$filepath': " . errorlog_lastError());
    }
}

Then in cmsb/lib/menus/default/edit_functions.js (around line 192), find 'multi' : true, and add this line below it:

'simUploadLimit': 10,

That uploads 10 files at a time - the rest queue up in the browser and go automatically, so your client can still select all 100 at once. It should take care of the hangs as well. After updating the .js file, have your client do a hard refresh (Ctrl+F5) so the browser picks up the new version.

Give that a try and let me know if that fixes it for your client. Thanks!

On the error list page (modified for privacy/security):

#135579 - Unable to remove file '/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp' Please ask your server administrator to check permissions on that file and directory. The PHP error message was: unlink(/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp): No such file or directory
/home/xxxxxx/public_html/cmsuAMGP383/lib/upload_functions.php:679
POST https://xxxxxxxxxx.com/cmsuAMGP383/admin.php

and inside the details of the error, the mention of the "upload strategy" file caught my attention:

Backtrace

#0 Script started                                         at /home/xxxxxx/public_html/cmsuAMGP383/admin.php:0
#1 require()                                              at /home/xxxxxx/public_html/cmsuAMGP383/admin.php:82
#2 require()                                              at /home/xxxxxx/public_html/cmsuAMGP383/lib/menus/default/actionHandler.php:106
#3 require()                                              at /home/xxxxxx/public_html/cmsuAMGP383/lib/menus/default/uploadForm.php:4
#4 submitUploadForm()                                     at /home/xxxxxx/public_html/cmsuAMGP383/lib/menus/default/uploadForm_functions.php:24
#5 removeExpiredUploads()                                 at /home/xxxxxx/public_html/cmsuAMGP383/lib/menus/default/uploadForm_functions.php:38
#6 DefaultUploadStorageStrategy->removeUploadsForRecord() at /home/xxxxxx/public_html/cmsuAMGP383/lib/upload_functions.php:679
#7 RuntimeException thrown                                at /home/xxxxxx/public_html/cmsuAMGP383/lib/upload_storage_strategy.php:130
   -> Unable to remove file '/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp'

Please ask your server administrator to check permissions on that file and directory.

The PHP error message was: unlink(/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp): No such file or directory

and 
RAW LOG DATA: 
errfile          => "/home/xxxxxx/public_html/cmsuAMGP383/lib/upload_storage_strategy.php"
errline          => 130
errno            => "RuntimeException"
errstr           => "Unable to remove file '/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp'\n\nPlease ask your server administrator to check permissions on that file and directory.\n\nThe PHP error message was: unlink(/home/xxxxxx/public_html/images/uploads/thumb2/35-img-6665-jpg.webp): No such file or directory\n"
exceptionClass   => "RuntimeException"
exceptionCode    => 0
externalFilePath => "/home/xxxxxx/public_html/cmsuAMGP383/lib/upload_functions.php"
externalLineNum  => 679
logType          => "exception"

 So I am just wondering (because I'm still a programming neophyte) if the "upload strategy" file has some limiter in this case, or something?  Or is it just a challenge with the hosts' resources?

It seems when he's uploading around 100 images at one time it occurs, and if he has a problem, he gets around it uploading 20 at a time (but it drives him crazy).  I will mention here that there was a similar challenge that was worked out several years ago and he does have a plugin (built by IT) for resorting the images after saving. 

Thank you for your attention to this.

does it have to do with the '_action=' placement?

That's exactly it - it's the '_action=save' that's doing it.

So '_action=save' is the internal name of the Save button, and the Save & Copy plugin gives its own button that exact same internal name as well.

While the ordering plugin was matching on names, it saw two buttons called _action=save and kept them together, which is why Save & Copy came along with Save when you moved it to the front.

I've attached an updated version of the plugin Dave posted that matches on the label shown on the button instead. The labels are all distinct, so Save & Copy can now sit wherever you'd like.

For the specific order your customer wants:

$buttonOrder = ['Save', 'Preview', 'Save & Copy', 'Erase', 'Cancel'];

Let me know if that works for him!

It ALMOST works perfectly...I changed the top line order to be:

$buttonOrder = ['_action=save', 'preview', '*', 'Erase', 'cancel'];

but the "save and copy" button appears first...does it have to do with the '_action=' placement?

He prefers the following visual order: save > preview > save and copy > erase > cancel

Thank you kindly! This is awesome.

Happy to help with this one. In v3.83 we standardized the button order across all the admin pages: destructive actions (like Erase) on the far left, and the primary action (Save) always on the far right with Cancel beside it. That follows the convention Mac, iOS, and Android all use, but I can see how a change like that would throw off someone who's had years of muscle memory with the old layout.

I've attached a plugin that restores the buttons to their previous order (Cancel, Erase, Preview, Save). Just upload it to your cmsb/plugins/ folder and activate it under Admin → Plugins.

If your customer wants a different arrangement, there's a single line at the top of the plugin you can edit:

// Buttons appear left to right in the order below - rearrange as desired
// '*' is where buttons added by other plugins appear, e.g. "Save & Copy".
$buttonOrder = ['cancel', 'Erase', 'preview', '*', '_action=save'];

Rearrange those as desired. The '*' is where buttons added by other plugins (like Save & Copy) appear.

And good news on the "keep it from future changes" part: the plugin re-sorts whatever buttons the CMS generates, so the order will stick through future updates.

Let me know if that works for him!

Dave