Apologies, try this instead:

<?php global $CURRENT_USER; ?>
SELECT num, CONCAT_WS(", ", fullname, firstname)
FROM `<?php echo $TABLE_PREFIX ?>accounts`
WHERE hospital='<?php echo $CURRENT_USER['hospital'] ; ?>'
ORDER BY fullname

Thanks,

Try this:

global $CURRENT_USER;
SELECT num, CONCAT_WS(", ", fullname, firstname)
FROM `<?php echo $TABLE_PREFIX ?>accounts`
WHERE hospital='<?php echo $CURRENT_USER['hospital'] ; ?>'
ORDER BY fullname

Note that this needs to be on a page where the user is required to be logged in, since it's using details from the current user's record.

Let me know if that works!

Thanks,

What version of CMSB are you running? Also, what is the correct text that should be displayed in the header bar?

Thanks,

It looks like this is being triggered by an advanced list field, possibly due to an incorrect MySQL query. Can you check the list options for the "new_owner" field? If it's set up to generate the list from a MySQL query, that is probably generating the error. Feel free to copy the query here and I can try to troubleshoot the issue.

Thanks,

That's a great idea - the Email Templates could definitely benefit from the Save & Copy button. Here's a patch you can add to saveAndCopy.php to enable it; on line 21 change this:

  $addButton = isset($menuType) && ($menuType == 'multi' || $menuType == 'category') && ($action == 'add' || $action == 'edit');

To this:

  $addButton = isset($menuType) && ($menuType == 'multi' || $menuType == 'category' || $tableName == '_email_templates') && ($action == 'add' || $action == 'edit');

Try it out and let me know if you have any issues!

Thanks,

Thanks for the suggestions!

For #1, that message is tied to all of the list pages in the CMS so it'd be non-trivial to change it just for the error log, but I can understand how the language feels a bit odd in that spot.

For #2, can you elaborate on the "login log" you're talking about? That sounds different from the built-in Audit Log; is it perhaps a customization or plugin?

Thanks,

We've just released a number of updates to address PHP 8.1 compatibility in some of our more popular plugins. These plugins are:

• Website Membership v1.14** (https://www.interactivetools.com/plugins/website-membership/)
• CSV Import v1.14 (https://www.interactivetools.com/plugins/csv-import/)
• CSV Export v1.05 (https://www.interactivetools.com/plugins/csv-export/)
• Download Mail v1.06 (https://www.interactivetools.com/plugins/download-mail/)
• Developer Console v1.07 (https://www.interactivetools.com/plugins/developer-console/)
• Newsletter Builder v3.06 (https://www.interactivetools.com/plugins/newsletter-builder/)
• Outgoing SMS v1.07 (https://www.interactivetools.com/plugins/outgoing-sms/)

** Important note for Website Membership: If your front-end code was generated with WSM v1.08 (released October 29, 2012) or earlier may not be compatible with PHP 8.1. Generated code does not automatically update through plugin updates, so you will need to re-generate and replace any non-compatible code manually.

Please let me know if you have any questions, or if you use any plugins that are not in this list and would like to confirm if they are PHP 8.1-ready.

Thanks!

Without examining the site directly it's difficult to say that the files are 100% safe to delete, but I can say that I've never come across an issue caused by someone clearing their temp folder. The most common use for this folder is to temporarily store files as they're being uploaded or created, however, sometimes the "cleanup" process is interrupted or prevented for some reason, and the temporary file is not deleted automatically.

Can you tell me a few example filenames that are in your temp folder? If they end in ".tmp" then they are genuine temp files and can be deleted.

Thanks,

Yes, the temp directory is intended for files that could be deleted at any time, so it should generally be safe to clear it out (except for the ".htaccess" and "index.html" files; these are important for security). It is possible that custom code could be using it for more "permanent" storage, but it would be irregular. As an extra precaution, you could skip deleting any recently created files which would reduce the chances of deleting something that's still in use.

Thanks,

403 errors are typically generated by the server refusing the request, and so are most commonly due to server configuration rather than the CMS itself. Here are two recent threads that dealt with 403 errors:

• https://www.interactivetools.com/forum/forum-posts.php?postNum=2246151#post2246151
• https://www.interactivetools.com/forum/forum-posts.php?postNum=2246041#post2246041

In one case it was caused by file permissions, and in the other, it was due to a ModSecurity rule. I would first check to see if you have ModSecurity enabled on the server and if yes, work with your webhost to find out if any rules are blocking the embed.

Let me know if you have any other questions!

Thanks,

We've been working on getting some of our more popular plugins updated for PHP 8.1; Website Membership being one of them. They should be getting an official release in the next few days, but let me know if there's anything you need to get updated ASAP and can provide a patch in the meantime.

Also, is there a free scanner/script that can identify code that won't work with PHP 8 or is is just a case of upgrading and then manually testing everything?

Nothing that we're aware of, yet.

I can let you know that the big culprit in PHP 8.1 is that a number of internal PHP functions no longer allow "null" to be used as an empty value (e.g., strlen() or str_replace() which expect strings), which can cause issues in places where "@" is used to silence notices for variables that may not exist if they then get passed to any of these functions. This is a pattern that was used historically in our code, that now needs to be shifted away from. It's simple to fix, but if you have custom code that uses that pattern it increases the likelihood that you'll get errors in PHP 8.1. 

Ideally, these sections should be rewritten to explicitly check whether or not the variable exists, but if you get an error like "Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in ... on line ...", it can be fixed in a pinch by changing this:

strlen(@$_REQUEST['somevar']);

To this:

strlen($_REQUEST['somevar']??'');

(Note that ??'' should be used when the function expects a string. You'd use ??0 if expecting an integer, ??false if expecting a boolean, etc.)

Thanks,

As many of you may already know, PHP 7 will be discontinued at the end of November and will no longer be receiving security updates. As a result, we strongly recommend that everyone upgrade to PHP 8.0 or better.

We've written up a sample email below that you can resend to your clients explaining what's needed and why it's billable.  

You can perform these upgrades yourself by just upgrading CMS Builder and any plugins. We are also happy to offer assistance if you require any help making these upgrades.

Let me know if you have any questions about this or if we can be of any assistance.

Subject:Required Security Updates: PHP 8

Hello [CLIENT],

I wanted to let you know about some important security updates for your website and to schedule some time in the coming weeks to apply them. These updates will require some time to complete, but they are very important to maintain the security of your site.

We've had a number of clients ask about this so I've written up some additional details below if you’d like to know more.

Can you let me know a good time to discuss?

Ongoing security maintenance:

As part of maintaining an internet website, it's important to keep server software and code up to date. A standard website uses software from multiple 3rd parties such as Linux (operating system), Apache (web server), MySQL (database), PHP (programming language), and custom code that we've written specifically for your website.

These different vendors update their software when security issues are discovered and we periodically have those updates installed on the server. We don't charge for this and it often happens automatically. However, sometimes vendors introduce new versions that are not backwards compatible with existing website code which makes updating it necessary.

Upgrading to PHP 8

PHP is one of the most popular programming languages used today and what your website is programmed in. The developers of PHP have announced they're discontinuing PHP 7 and no longer providing security support for it. This means there won't be any way to prevent hackers or malicious users from using newly found security vulnerabilities to exploit websites running this version.

We've already made the required changes to the CMS (Content Management System) code and we can easily upload that, but we still need to review your website’s plugins and any custom code to ensure it will work with PHP 8.

Future updates

PHP versions are actively supported for up to 2 years after their release. So further updates will be required in future years. Usually, they will require minimal testing and changes, but like all internet developers, we need to work with what the vendors provide us with.

You can see a list of currently supported PHP versions and their supported dates here:http://php.net/supported-versions.php

Additionally, other components on the server will require updating from time to time. Usually, we'll do this automatically but we'll let you know if anything extra is required.

Common Questions and Answers

Why didn’t you develop the website to support the latest version?
Often the latest version either didn’t exist yet or was not mature enough to be used. Old unsupported software can contain security vulnerabilities, and brand new software can be buggy and unreliable. We try to take a conservative approach and target development at well-tested, supported software versions that are in common use.

What happens if I don’t upgrade?
If you don’t upgrade your website then you’ll be vulnerable to security exploits and attacks that are discovered. Over the last three years, an average of 8 PHP vulnerabilities are discovered per year. You can find more information about PHP vulnerability trends here:https://www.cvedetails.com/product/128/PHP-PHP.html?vendor_id=74

Should I be concerned about all these security issues?
Actually, no. Part of maintaining an internet presence these days is making routine security updates. You've probably seen ongoing media stories about Apple and Microsoft constantly releasing updates and addressing security issues. It’s something everyone has to deal with but we’re happy to take care of it as part of the service we provide for you.

Are there other benefits of upgrading?
Yes, there are. Updated software releases are often faster and more efficient, allowing your web server to respond more quickly and handle more requests. Additionally, programmers can develop software quicker when they’re able to use the latest features of a programming language.

Shouldn’t you provide these updates for free?
Unfortunately, we can’t anticipate issues before they happen. As the internet evolves, unforeseen changes are sometimes required to maintain server security, to have your site work in the latest browsers, or even address newly introduced laws or regulations. Maintaining a modern internet presence requires that your website evolve as well. Sometimes there are years between these required changes, and sometimes they are more frequent. We stay current on these issues so we can advise you on the best way to address them.

Planned Updates

We’d propose the following process for updating the website for PHP 8:

1. Backup the CMS database and website
2. Upgrade the CMS framework to the latest version (which supports PHP 8)
3. Upgrade any CMS plugins to the latest versions (which support PHP 8)
4. Manually review and update any website code
5. Switch the website over to PHP 8.0 or newer
6. Test and confirm no errors or issues

Let me know if you’d like to go ahead with these updates and any questions.

Thank you!

Hope that helps!  Let me know any questions.

Yes - I'll get that patch in the next CMSB release so you don't have to worry about it being overwritten in future updates.

I believe this specific error is new in PHP 7.4, so it likely worked to disable the search fields in this way when it was written. But it's not something we see commonly used, so the conditions for the error are pretty rare.

In any case, thanks for reporting this!

Apologies, I didn't realize at first this was happening on a CMSB admin page!

It looks like this error shows up if a section isn't configured with any search fields in the section editor (under the "Sorting" tab when editing a section). If you add any search field (or just "_all_"  to restore the default search bar) it should get rid of the errors.

From what I can see, your changes are probably sufficient, but here's a more "official" patch that should fix the errors in that section:

      <!-- simple search -->
      <?php $searchField = getSearchField($primarySearchRow, 'PRIMARY'); ?>
      <?php if (!empty($searchField)): ?>
        <?php if ($searchField['requiresLabel']): ?>
          <div class="row" style="margin-bottom: 5px;">
            <div class="col-md-2">
              <label class="control-label">
                <?php echo $searchField['label'] ?>
              </label>
            </div>
            <div class="col-md-10">
              <?php echo $searchField['html'] ?>
            </div>
          </div>
        <?php else: ?>
          <div class="row" style="margin-bottom: 5px;">
            <div class="col-md-12">
              <?php echo $searchField['html'] ?>
            </div>
            <?php if ($searchField['description']): ?>
              <div class="help-block col-md-12">
                <?php echo $searchField['description']; ?>
              </div>
            <?php endif; ?>
          </div>
        <?php endif ?>
      <?php endif; ?>

This would replace lines 114-137 in /cmsb/lib/menus/list.php (the original version, before your changes)

Let me know if you have any other questions!

Thanks,

There are a few options for ordering uploads. Here is a snippet that will make sure that uploads stay in the order that they were saved in:

addAction('upload_saved', 'uploadOrder_setUploadOrderToUploadTime', null, 4);
function uploadOrder_setUploadOrderToUploadTime($tablename, $fieldname, $recordNum, $newUploadNum) {
  $uploadStartTime = substr(intval(floatval($_SERVER['REQUEST_TIME_FLOAT']) * 1000), 4);
  mysql_update('uploads', $newUploadNum, null, ['order' => $uploadStartTime ]);
}

The main drawback here is that when images are uploaded in bulk, they can finish uploading in different orders, so it's not always fully accurate.

It's also possible to order the uploads when a record is saved, with something like this:

addAction('record_postsave', 'uploadOrder_updateUploadsOrder', null, 4);
function uploadOrder_updateUploadsOrder($tableName, $isNewRecord, $oldRecord, $recordNum) {
  $schemaFields = getSchemaFields($tableName);
  foreach($schemaFields as $field) {
    if ($field['type'] == 'upload') {
      $uploads = mysql_select('uploads', mysql_escapef("`tableName` = ? AND `fieldName` = ? AND `recordNum` = ? ORDER BY filePath, num", $tableName, $field['name'], $recordNum ));
      if($uploads) {
        $order = 1;
        foreach($uploads as $upload) {
          mysql_update('uploads', $upload['num'], null, ['order' => $order]);
          $order++;
        }
      }
    }
  }
}

This should automatically alphabetize the uploads in any record when it is saved. Note that it applies to all upload fields in all tables, but it could be customized to be a bit more specific. $tableName can be used to restrict which section(s) it applies to, and $field['name'] can apply to specific fields.

You can put either of these snippets into a plugin (CMSB comes with samplePlugin.php as a plugin template) to use them.

Let me know if you have any other questions!

Thanks,

In this case, putting an @ in an if condition - when you're just checking for the existence of a value - is generally "safe" though it's no longer considered best practice. A fairly simple and better practice method to avoid the notice is with the empty() function, which checks "does this variable exist and contain a nonzero value?" So instead of this:

<?php if (@$searchField['requiresLabel']): ?>

You would use:

<?php if (!empty($searchField['requiresLabel'])): ?>

Let me know if that helps!

Thanks,

If you've created the form with Form Generator, you will probably have a section of code like this in the generated script:

    if (fg_util_isPartialDate('examination_date'))       { $_REQUEST['examination_date'] = ''; } // clear invalid dates
    else                                     { $_REQUEST['examination_date'] = sprintf("%04d-%02d-%02d %02d:%02d:%02d", @$_REQUEST['examination_date:year'], @$_REQUEST['examination_date:mon'], @$_REQUEST['examination_date:day'], 0, 00, 00); }

These lines are part of the date validation when a date field is being handled by the three dropdowns. Changing to a single input can cause some unexpected behaviour. Try commenting these lines, and let me know if that helps.

Thanks!

I've attached a script that will output the server's PHP version without any extraneous code - can you try running this on your server? If it still reports the wrong PHP version, I would suggest reaching out to your hosting provider, as that would indicate a server configuration issue. You can show them this script to demonstrate that the version is incorrect.

I hope that helps!

Yes, that formatting looks correct! There is one "?><?php" remaining that you can remove, but it's pretty inconsequential.

The confusing part is that I use the same _website_init file on many of my sites and never seemed to have the same issue.

Oh well, better go back and check all the other sites again...

There is a setting that can help PHP ignore some premature output, but I've found it to not always be 100% reliable, and it can be site/server-dependent, so there may be some difference between this environment and other sites where it's been used. In any case, I find it best practice to just remove any unnecessary whitespace to keep code as portable as possible.

Let me know if you have any further issues!

Thanks,

When testing locally using gd and a 30MB PNG, it works with a memory_limit of 512MB, so I'd suggest trying that out. You can change it in /cmsb/lib/init.php - there should be a line like this:

ini_set('memory_limit', '128M');

You can change this to whatever value you need. Note that this value will be overwritten during CMS upgrades, so you should make a note of the change.

Your max_execution_time is 6 minutes which generally should be fine, though if the process hangs for exactly 6 minutes that could be a clue.

Let me know if this helps!

Thanks,

I can see that there's a space after the "?> " on line 7 in provider_profile.php - whitespace will count as "output" and cause this error. To make things as simple as possible, I'd suggest moving the login check to be immediately after the include, like this:

include ("_website_init.php"); 
if (!$CURRENT_USER) { websiteLogin_redirectToLogin(); }
?>

Also, PHP tags that look like this could be outputting a newline which I assume is also being counted as output:

?>
<?php

This shows up a number of times in _website_init.php starting on line 76-77, so I would suggest rewriting the whole file to exist in a single PHP block like this:

//...

list($faqRecords, $faqMetaData) = getRecords(array(
    'tableName'   => 'faq',
    'loadUploads' => true,
    'allowSearch' => false,

  ));

$masterurl = $common_informationRecord['master_url'];

if ($image_libraryRecord['image_1']):
  foreach ($image_libraryRecord['image_1'] as $index => $upload):
    $image1 = $upload['thumbUrlPath2'];
  endforeach;
endif;

// etc, etc.

or simply remove the newlines so there's no space between PHP tags, like this: "?><?php"

Let me know if that helps, or if you have any further questions.

Thanks!

What is the code at line 77 of /home3/mrqsygmy/public_html/_website_init.php line 77? This is where the error indicates the early output is happening. 

In that case, the PHP module for Imagick does not appear to be enabled. This is something that would need to be done on the server by the host, though not all hosts will support it. 

Have you looked into the memory_limit and max_execution_time settings? You can find the current values for both of these settings on the General Settings page in CMSB, under Admin Menu.

Thanks,

Sorry to hear you haven't had any luck yet.

I was able to extract this file from the RPM, I believe it should be the wkhtmltopdf binary for CentOS 7: https://interactivetools.com/uploads/wkhtmltox-0.12.6-1.centos7.x86_64

Let me know if that helps!

Thanks,

It sounds like it may already be enabled as a PHP module. If you go to the CMSB admin under Admin Settings > General Settings, and check the "Server Info" section at the bottom, there should be a line that says "Image Modules" - if your server has Imagick enabled it should be listed here and not crossed out. If it's enabled then it should be used automatically by the system.

Let me know if you have any other questions!

Thanks,