https://www.mythic-beasts.com/

The price and capabilities of hosting can really vary a lot. Personally, I think the market needs some regulation.

Is there somewhere that allows us to set a limit on how many lines are shown for "Recent Changes" under 'General Settings' in the admin interface? Our web host recently ran a maintenance routine, and let's just say that this generated quite a few extra lines in this part of CMSB :).

I think maybe it would be good to show the most recent 20 changes and then have the option to extend that view to display more, albeit perhaps with an upper limit so that older entries can be removed.

display_startup_errors = On
display_errors = On

I'm just wondering why, since it's usually good security practice not to show errors, so shouldn't these two be disabled by default?

<?php
  /* STEP 1: LOAD RECORDS - Copy this PHP code block near the TOP of your page */
  require_once "/system/lib/viewer_functions.php";

  list($my_listRecords, $my_listMetaData) = getRecords(array(
    'tableName'   => 'my_list',
    'perPage'     => '100',
	'loadCreatedBy' => false,
  ));
?>

<form method=POST action="/listings/search.php">
<input type="text" name="title_keyword" value="" size="16" maxlength="35" style="font-size:14px;width:auto;" />
<input type=submit name="search" value=" Search ISP by Name " style="font-size:14px;padding:6px;width:auto;">
</form>

Now this works fine, but I can see there are sometimes bots looking to find weaknesses/exploits in this by searching for lots of much longer strings (e.g. "/listings/search.php?title_keyword=commande+publique+et+marchcats+testing+pays+littlepuppies").

At present I limit the frontend form entry above via maxlength="35" and in CMSB I also set the "Max Length" setting for the 'title' field (under 'Input Validation') to 35. But these are really cosmetic changes, so when you get directly crafted REQUESTS like the example above, then they bypass that.

The only output is just a kind of "no records found" result, but what I'd prefer to do is return our server's generic 404 page or just block any requests longer than 35 characters on the 'title' (title_keyword) field. Any ideas for how to do this in the PHP script, without breaking the search for normal-sized requests?

Deprecated: Constant E_STRICT is deprecated /system/lib/errorlog_functions.php on line 166

Deprecated: Method mysqli::ping() is deprecated since 8.4, because the reconnect feature has been removed in PHP 8.2 and this method is now redundant /system/lib/ZenDB/DB.php on line 198

Deprecated: _errorlog_getCallStackText(): Implicitly marking parameter $e as nullable is deprecated, the explicit nullable type must be used instead in /system/lib/errorlog_functions.php on line 519

Deprecated: schema_addMissingMySqlColumns(): Implicitly marking parameter $mysqlColumns as nullable is deprecated, the explicit nullable type must be used instead in /system/lib/schema_functions.php on line 585

Deprecated: Itools\ZenDB\DB::config(): Implicitly marking parameter $keyOrArray as nullable is deprecated, the explicit nullable type must be used instead in /system/lib/ZenDB/DB.php on line 40

Deprecated: Itools\ZenDB\DBException::__construct(): Implicitly marking parameter $previous as nullable is deprecated, the explicit nullable type must be used instead in /system/lib/ZenDB/DBException.php on line 19

Deprecated: Itools\ZenDB\Assert::sqlSafeString(): Implicitly marking parameter $inputName as nullable is deprecated, the explicit nullable type must be used instead in /system/lib/ZenDB/Assert.php on line 93

I just upgraded from 3.71 to 3.74 on my beta install and noticed that I suddenly started getting deprecated warnings on the admincp. I am using PHP8.3

Deprecated: SmartString::fromArray() is deprecated, use "SmartArray::new($array)" instead.
/system/vendor/itools/smartstring/src/SmartString.php on line 703

This is a new addition since the previous version, so I was a bit surprised that it wouldn't be ready for PHP 8.3. The notice seems to get thrown into the log every time I try to load the 'General Settings' page and the details suggest the call comes from this URL:

https://www.MYDOMAIN.com/system/admin.php?menu=admin&action=generalServerInfoAjax&forceUpdate=1

	RewriteCond %{REQUEST_URI} (/)((.*)crlf-?injection|(.*)xss-?protection|__(inc|jsc)|administrator|author-panel|cgi-bin|database|downloader|(db|mysql)-?admin)(/) [NC,OR]

This would normally be fine, but under CMBS it effectively means that requests for anything in a FOLDER with the name "/database" are going to fail, which is what CMSB uses under /menus/database/. But quite why this didn't occur in 3.66, but it did in 3.71 is unclear. Anyway, all fixed.

As you can imagine, this is kind of a big problem :). I upgraded from v3.66.

<img src="<?php echo htmlencode($upload['urlPath']) ?>" />

I still intend to use that same approach on some pages, but I'd also like to be able to resize a smaller thumbnail for short summaries in order to keep Google's Core Web Vitals happy. So I wondered, is there a simple way to additionally output a 100x100 pixel version of the same image? Without changing the original (primary) thumbnail/image or manually uploading a second smaller version, that would be very laborious.

Essentially, I'm using a multi-record editor and one of my textfields in each record (simply called 'cost') is for the cost of a product, where I put a normal numerical value like 10 or 6.3 etc. But can I use the new Generated Columns field to essentially create a total for all my 'cost' field records? I'm not quite sure how to approach this in CMSB.

https://cspvalidator.org

As usual with Ionos, the information they put on their own website often doesn't accurately reflect the different setups on the servers they sell to consumers.

After a lot of testing, I discovered that in 3.62 I couldn't run my crons for CMS Builder in the way that usually works because the script now expects me to be logged in as a CMS Builder administrator first via the website (something you obviously can't do via a simple cron call).

So this didn't work any more:

0 * * * * /usr/bin/php8.1 /system/cron.php

Just in case anybody else runs into this, I resolved the problem by calling the command line interface version of PHP instead:

0 * * * * /usr/bin/php8.1-cli /system/cron.php

Hopefully this helps anybody else that runs into the same issue. I didn't change anything else in CMSBuilder for the upgrade, so I'm not sure what has changed between 3.59 and .62 to cause this, but I thought it worth highlighting so that others can benefit if they run into the same issue.

header('X-Frame-Options: SAMEORIGIN');

header("X-XSS-Protection: 1; mode=block");

header("X-Content-Type-Options: nosniff");

header("Content-Security-Policy: default-src * data: blob:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'; img-src https: http://www.YOURSITE.com http://*.YOURSITESUBDOMAIN.com data: blob:; frame-src https:; base-uri *; worker-src * https: blob:;");

header("Permissions-Policy: camera=(), geolocation=(), magnetometer=(), microphone=(), midi=(), payment=(), usb=(), hid=()");

But what would be handy is if we could set them in CMSBuilder without needing to edit core files that may change with each update of the CMS. For example, adding them into the config file or via the admincp may be handy.