echo nl2br(htmlencode($record['name'])); should be easy to implement and probably less frustrating because I always forgot to check that box anyway with any new build or schema, and had to go back in and do it.

MCP Server Beta Feedback — v3.83

We've been testing the new MCP Server hard over the last few days. Big picture: this is a well-designed server. The tool surface is thoughtful, naming is consistent, the layered IP + bearer auth is above typical MCP quality, and the instructions block on initialize is the best I've seen anywhere — you explicitly tell the model when to use CMSB MCP over raw MySQL, warn about hook/timestamp gaps, and point to cmsApiPublic / cmsSignature as guardrails against hallucinated APIs. That's exactly the failure mode those tools should address, and most MCP servers don't bother.

That said, there are some real issues worth flagging before this comes out of beta. Posting them here in severity order so others testing can corroborate or tell me I'm wrong.

Security — Pre-auth info disclosure

Bearer auth is currently only enforced on tools/call. With no Authorization header at all, I was still able to get back:

• The full initialize response including serverInfo.description and the long instructions block
• All 19 tool definitions via tools/list
• Both prompt names and — via prompts/get cms-logs — the entire prompt body, which enumerates internal table names (_error_log, _log_audit, _cron_log, _outgoing_mail) and internal settings keys (serverChangeLog, bgtasks_lastRun, mail.outgoingMail)

Tool invocation itself is safe — I correctly got No Bearer token provided / Invalid API key when I tried to call anything. So this isn't a data breach. But it's pre-auth info disclosure against anyone who's already past the IP allowlist, and if a user ever clears the allowlist the whole discovery surface becomes public.

Fix: require the bearer on every method, not just tools/call.

Bugs

1. cmsApiSearch emits raw PHP warnings before the JSON-RPC payload.

Calling cmsApiSearch {"query":"DB::sel"} returns six PHP warnings, then the JSON:

Warning: include(.../vendor/composer/../../lib/ImageFactory.php): Failed to open stream: No such file or directory in .../cmsb/api/mcp.php:1081
Warning: include(.../vendor/composer/../../lib/Validator.php): Failed to open stream: No such file or directory in .../cmsb/api/mcp.php:1081
... (6 warnings total)
{"jsonrpc":"2.0",...}

Two problems with this:

• Strict JSON / SSE MCP clients will fail to parse. curl tolerates it; a real MCP client may not.
• It leaks absolute filesystem paths.

cmsErrorSummary confirmed these are real errors — it groups six matching entries on mcp.php:1081. Looks like an autoloader/composer issue where ImageFactory and Validator are referenced but not present. Fresh composer dump-autoload might do it.

2. Unknown methods return a fake tool result instead of a JSON-RPC error.

resources/list returns:

{"jsonrpc":"2.0","id":51,"result":{"content":[{"type":"text","text":"Unknown method: resources/list"}],"isError":true}}

Per the JSON-RPC spec this should be {"error":{"code":-32601,"message":"Method not found"}}. Clients that branch on protocol-level errors vs. tool-level errors (most proper MCP clients) will mis-handle this. Same pattern shows up for notifications/initialized returning "Invalid JSON-RPC version" wrapped in a fake result.

3. initialize returns protocolVersion: "2025-11-25" regardless of what the client sent.

I sent "2025-06-18"; the server echoed "2025-11-25". The MCP spec says the server must return the client's requested version if supported, or the highest it supports that's ≤ the client's. Hardcoding a single (and future-dated) version can break strict clients.

4. selectOne silently coerces string → int.

selectOne {"table":"recipes","num":"abc"} returns Record not found: recipes num=abc rather than a validation error. The inputSchema declares num: integer — the server should reject this at schema validation. As-is, "bad input" and "real miss" are indistinguishable to a model.

Tool-design suggestions

• listTables and cmsErrorSummary take no args. A filter/prefix on listTables (98 tables on a small install; could be much larger elsewhere) and limit / since / minCount on cmsErrorSummary would scale better.
• query / queryWrite take raw SQL, which means a model that bypasses the safer helpers can still do anything. Documenting that tradeoff in instructions is great. Consider a dryRun option on queryWrite that runs EXPLAIN plus (for DELETE/UPDATE) reports affected-row count without committing.
• queryWrite's destructiveHint: true annotation is good, but surfacing affected-rows count on success would make model behavior safer still.
• No _meta/version on tool responses. While the output shape is still changing in beta, a version field would help clients detect drift.
• cmsApiPublic's docstring explicitly says "cheap to call" — that's a nice explicit cost signal to the model. More MCP servers should do this.

What's working well

Not just being nice — these are design wins worth calling out so they survive the next round of changes:

• The instructions block. Already mentioned above; it's genuinely excellent.
• Error messages point the human to the fix UI. "Add it in Admin > Advanced > MCP Server > Allowed IPs" and "Check the Authorization header in your .mcp.json file" tell the human what to do, not just what went wrong. That's the gold standard.
• cmsApiSearch + cmsSignature is a clever pair. The signature response returns file / line / class / inheritance / signature / docblock — exactly the right shape for keeping models from inventing function signatures against stale training data.
• cmsInfo.customUploadDirs surfacing per-field upload overrides is a thoughtful touch. Anything touching uploads needs exactly this.
• Defense in depth is real here. Password redaction in settings worked. MySQL system-table denial worked. Read-only query correctly rejected DELETE with a clear message pointing to queryWrite.
• The two prompts (cms-logs, cms-fix) are substantive runbooks, not placeholder stubs.

Comparison notes — running CMSB MCP alongside our fleet MCP

Some context: we run our own MCP server (mcp.sagentic.dev) for fleet-level portfolio management across 100+ client sites — it's purpose-built endpoints for domain management, support logs, cross-site reports, that kind of thing. Built on the official PHP MCP SDK v0.4.0. It's a very different animal from CMSB MCP (fleet control plane vs. single-site database plane), and we're treating them as complementary, not competing.

Running them side-by-side did surface some patterns worth sharing in both directions.

Things CMSB MCP could borrow

1. Tiered API keys. Our server has creator / standard / full / write tiers with field-level visibility differences — e.g., creator-tier responses hide credentials while standard-tier hides sensitive notes. CMSB has one key and a single "Allow write access" checkbox. For site owners wanting to give a lower-trust AI client read-only access to a subset of tables, tiering would be a big deal.

2. Implement MCP Resources. resources/list currently returns "Unknown method." Natural candidates for CMSB: cmsb://schema/index, cmsb://schema/{table}, cmsb://settings (non-sensitive subset), cmsb://errorlog/recent. Resources are proactively loadable, which fits AI workflows better than on-demand tool calls for schema/reference data.

3. Proper JSON-RPC error codes. Using -32001 Invalid API key, -32600 Invalid request, -32603 Error while executing tool lets strict clients branch on error class. CMSB currently returns everything as a successful result with isError: true and the reason in a prose string. Already covered above but worth reinforcing — this is what the PHP MCP SDK gives you for free.

4. Sessions + Mcp-Session-Id. Streamable HTTP per the MCP spec expects session management. Stateless is tolerable today but forecloses future features (subscriptions, progress notifications, listChanged events — CMSB advertises both as false on the capability flags, which confirms these haven't been wired up).

5. Moving to the official PHP MCP SDK (mcp/sdk v0.4.0). The protocol-level quirks I listed above (hardcoded protocolVersion, fake results for unknown methods, PHP warnings in response bodies) all smell like hand-rolled JSON-RPC. The SDK gives you sessions, error codes, and resource/prompt handling for free. There's one known SDK bug — it silently fails to discover #[McpResource] attributes, so you have to register manually via addResource() — but everything else Just Works.

6. Prompts with arguments. Our prompts take parameters like use_skill(skill, domain, context) to customize the workflow. CMSB's cms-logs / cms-fix are static. Both are valid, but parameterized scales better.

Things our servers should borrow from CMSB

Being honest — CMSB MCP has some patterns our custom servers don't, that we should steal:

1. Live schema / API introspection (cmsSchema, cmsApiSearch, cmsSignature). Our own troubleshooting doc literally calls out two schema quirks — "uses skill_content, not content" and "no api_id column." That's the exact failure mode these tools solve. A schema-lookup endpoint would make those quirks discoverable rather than doc-resident.

2. The instructions block. We have equivalent guidance in our .guides/*.md but it's not wired into the server's initialize response. The PHP SDK supports this — just populate it.

3. UI-pointing error messages. Ours say "Invalid or missing API key. Provide via X-API-Key header or key query parameter." Yours say "Your IP is 170.000.000.000. Add it in Admin > Advanced > MCP Server > Allowed IPs." The difference in helpfulness is real.

Audit logging — question for the devs

CMSB has both _log_audit and api_audit_log tables. Can you confirm MCP writes (insert / update / delete / queryWrite / uploads) are landing in one of them? Didn't see explicit confirmation in the docs and it matters for compliance use cases. If cmsErrorSummary is intended to be the canonical surface for MCP-origin errors specifically (vs. generic PHP errors from the whole site), that'd be worth documenting too.

Suggested priority

• P0 — Require bearer auth on initialize / tools/list / prompts/*.
• P0 — Fix whatever's missing at mcp.php:1081 so cmsApiSearch stops emitting PHP warnings into the response stream.
• P1 — Switch unknown-method / protocol-error paths to real JSON-RPC error objects with proper codes.
• P1 — Echo the client's protocolVersion (or negotiate downward) instead of hardcoding 2025-11-25.
• P2 — Strict type validation on tool inputs (reject num: "abc" rather than coercing).
• P3 — Filter/limit args on listTables and cmsErrorSummary; dryRun on queryWrite.

I didn't run any write operations (insert / update / delete / upload) against production data.

Overall, really good work on this release. The MCP server is a genuinely useful addition to CMSB and most of what I flagged above is protocol-correctness polish rather than design problems. Looking forward to v3.83 final.

Thanks - Claude

The Bug: The update notification cache was storing version comparison results from when the check was performed. The plugin checks the RSS feeds at https://interactivetools.com/plugins/rss.php and https://www.sagentic.dev/public/plugins/rss.php to see if the plugin installed matches the latest version.

When you updated the plugin files, the cache still had the old data showing "you have 1.00, there's 1.01 available" - so it kept showing the update badge even though you were now at 1.01. The cache wouldn't refresh for 24 hours.

The Fix (v1.02): The plugin now re-validates cached update results against your current installed versions before displaying. Update badges should correctly disappear as soon as you update a plugin - no need to wait for the cache to expire.

GitHub: https://github.com/sagentic/cmsb-plugin-manager/issues/1

I appreciate you taking the time to report this!

What Was Wrong:

The plugin had two separate bugs that both prevented settings from being saved properly:

1. CSRF Token Compatibility Issue (Drag-and-Drop Sorting):

   • Field Name Mismatch: The JavaScript was sending the CSRF token with the field namecsrfToken, but CMS Builder's security validation expects it to be named_csrf. This caused all AJAX save operations to fail with "Form _csrf value missing" errors.
     
     
   • Version Compatibility: CMSB changed the session variable name between versions:
     • CMSB 3.81 uses$_SESSION['_CSRFToken'](capitalized)
     • CMSB 3.82+ uses$_SESSION['_csrf'](lowercase)
       
       
   • The plugin was only reading from one format, causing it to fail on 3.81 installations.

2. Settings Page Checkboxes Not Saving:

   • When unchecking any setting (Show inactive plugins, Show system plugins, Group by status, Check for updates), the checkbox would revert back to checked after saving.
     
     
   • Root Cause: The form uses hidden fields withvalue="0"before each checkbox (proper HTML pattern), but the PHP code was usingisset($_POST['fieldname'])which always returnstruebecause the hidden field is always present - even when the checkbox is unchecked.

What's Fixed in v1.01:

✅ Corrected CSRF token field name in all AJAX requests (_csrf instead of csrfToken)
✅ Added backward compatibility to support both CMSB 3.81 and 3.82+ session variable formats
✅ Drag-and-drop sort order now properly saves and persists across page refreshes on all CMSB versions
✅ Fixed checkbox settings logic to check actual POST values instead of using isset()
✅ All settings now properly save both checked and unchecked states
✅ Improved error handling for sort order save operations

Both the kanban-style drag-and-drop sorting and the settings page now work correctly on all supported CMSB versions.

To Update:

If you're already running v1.00, simply replace the plugin files with the new version and refresh your browser cache. No database changes or settings modifications needed.

Thanks again to Jeff for taking the time to test and report both issues. This kind of feedback is invaluable for making sure plugins work correctly across all supported CMSB versions!

I'm releasing a free plugin that gives you a centralized dashboard for managing all your CMS Builder plugins - with Kanban style drag-and-drop organization and automatic update detection. I have been using it on all my websites for a few days and think it's ready for others to use and test.

The Problem

When you manage lots of plugins, you want quick visual access to everything: a dashboard where you can see all your plugins at once, organize them by importance, jump directly to settings, and know when updates are available.

The Solution

Plugin Manager provides a visual dashboard with all your plugins displayed as cards in a 4-column grid. Activate/deactivate plugins with one click, drag-and-drop to organize them, and see update badges when newer versions are available. I added a link to the top menu (using the free Header Menu Admin plugin - https://www.sagentic.dev/public/plugins/header-menu-admin/) so the Plugins Dashboard is always just a click away.

Features

• Visual plugin cards with status badges (Active/Inactive/System)
• One-click activation/deactivation from the dashboard
• Drag-and-drop reordering (saves automatically)
• Keyboard navigation support (Alt+Arrow keys)
• Direct links to all plugin admin pages
• Automatic update detection from Interactive Tools Plugins and Sagentic Plugins RSS feeds
• Show/hide inactive or system plugins
• Group plugins by active/inactive status
• Real-time statistics (total, active, inactive, system)
• Customizable display options via Settings page
• Security and Accessibility are top-of-mind with all plugins we develop

Download

• GitHub: https://github.com/sagentic/cmsb-plugin-manager
• Screenshots & Direct download: https://www.sagentic.dev/public/plugins/

Installation

1. Copy the pluginManager folder to /cmsb/plugins/
2. Log into CMS admin and activate the plugin
3. Access via Admin > Plugins > Plugin Manager (tip: add a link to your header menu or side menu)

Requirements

• CMS Builder 3.50+
• PHP 7.1+
• JavaScript enabled (for drag-and-drop)

Feedback Welcome

I built this because I wanted a better way to access and organize my growing collection of plugins. The dashboard design includes space for future widgets and charts. I'd love to hear your feedback, bug reports, or feature suggestions. MIT licensed - modify as needed.

Thanks, Kenny H

File: cmsb/lib/ZenDB/Config.php

Issue: The variable variable syntax self::${$key} is deprecated in PHP 8.2+ and will be removed in PHP 9.0.

Affected lines:

• Line 40:return self::${$key};
• Line 53:$config[$key] = self::${$key};
• Line 80:self::${$key} = $value;

Recommended fix: Replace with Reflection-based access for static properties:

// Line 40 - in get() method
$reflectionProperty = new \ReflectionProperty(__CLASS__, $key);
return $reflectionProperty->getValue(null);

// Line 53 - in getAll() method
$reflectionProperty = new \ReflectionProperty(__CLASS__, $key);
$config[$key] = $reflectionProperty->getValue(null);

// Line 80 - in set() method
$reflectionProperty = new \ReflectionProperty(__CLASS__, $key);
$reflectionProperty->setValue(null, $value);

Reference: https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation

Bottom line: Nothing breaks. It's just noisy in your logs until the developer fixes it.

The code won't actually break until PHP 9.0 (which is likely 2-3 years away).

Just pushed an update to the IndexNow plugin with enhanced security options.

What's New in v1.01:
- Optional .env.php support for secure API key storage (outside web root) for CMSB 3.82+
- Configurable environment filename setting
- Automatic migration between storage methods
- Fully backward compatible

The plugin automatically notifies search engines (Bing, Yandex, etc.) when you create, update, or delete content. Features include automatic submissions on save, manual/bulk URL submission, retry system for failed requests, and full submission logging.

Download & Info: https://www.sagentic.dev/public/plugins/
GitHub: https://github.com/sagentic/cmsb-plugin-indexnow

Feedback welcome!

Error: Call to undefined method Itools\Cmsb\Schema::tables()

The Schema class method was renamed from getTableNames() to tables() in 3.82. The plugin needed to be updated to use the new method name and it works perfectly again.

I'm releasing a free plugin that lets you create conditional validation rules through the admin UI - no code editing required.

The Problem

Sometimes you need "if this, then that" validation - when one field has a value, another field should be required.

The Solution

Conditional Error Checking Pro provides a visual rule builder where you select a trigger field, a condition, and the field that becomes required. Rules are managed entirely through the admin interface.

Example Rules

• If contact_name is not empty → require phone
• If membership_type equals "premium" → require payment_method
• If shipping_address is not empty → require shipping_city

Features

• 9 condition types (empty, equals, contains, greater than, regex, etc.)
• Works with any CMS table
• Activity logging with CSV export
• Import/export rules as JSON
• Optional email notifications when saves are blocked
• Dashboard with statistics

Download

• GitHub: https://github.com/sagentic/cmsb-plugin-cecp
• Screenshots & Direct download: https://www.sagentic.dev/public/plugins/

Note: There are a few other plugins on the download page that are still in BETA testing. Try them out!

Installation

1. Copy the conditionalErrorCheckingPro folder to /cmsb/plugins/
2. Log into CMS admin and go to Plugins > Conditional Error Checking Pro
3. Start creating rules - tables auto-create on first access

Requirements

• CMS Builder 3.59+
• PHP 8.0+

Feedback Welcome

I'd love to hear your comments, bug reports, or suggestions to improve these plugins. MIT licensed - modify as needed.

Thanks for pointing out my GitHub visibility - just habit to make them private. It's now public. I have a few other Plugins that I am still testing on several websites and will release shortly - Broken Link Checker and Accessibility Checker. They'll have the same Dashboard interface as this IndexNow plugin so I hope them to be very intuitive.

I'm releasing a free plugin that automatically notifies search engines (Bing, Yandex, etc.) when you create, update, or delete content in CMS Builder.

The Problem

Search engines can take days or weeks to discover content changes on your site. This is especially frustrating when you publish time-sensitive content or fix errors on existing pages.

The Solution

IndexNow is a protocol supported by Bing, Yandex, and others that lets websites proactively notify search engines of changes instead of waiting for crawlers to find them. This plugin hooks into CMSB's record save/delete events and handles the notifications automatically.

Features

• Automatic submissions when content is saved or deleted
• Manual submission for bulk URL updates
• Smart URL detection (handles permalinks, single-record sections, detail pages)
• Retry system for temporary failures (rate limits, server errors)
• Complete submission logging with statistics
• Admin UI for configuration - no code editing required
• Settings preserved during plugin updates

Download Latest Version

• GitHub: https://github.com/sagentic/cmsb-plugin-indexnow
• Screenshots & Direct download: https://www.sagentic.dev/public/plugins/

Installation

1. Copy the indexNow folder to /cmsb/plugins/
2. Log into the CMS admin
3. Go to Plugins > IndexNow > Settings and select which tables to monitor. Everything is configured through the admin UI - no code editing required
4. Optional: Add a sidebar shortcut via Admin > Menu Links pointing to ?_pluginAction=IndexNow\adminDashboard

The plugin auto-generates your API key and creates the verification file at your site root.

Requirements

• CMS Builder 3.50+
• PHP 8.0+
• cURL extension

Feedback Welcome

I built this to solve an indexing issue with Bing on one of my client sites and figured it would benefit the community. I'd love to hear your feedback, bug reports, or feature suggestions. The plugin is MIT licensed so feel free to modify it for your needs.

I was just building a huge schema and am going back to check on which fields should be required and which ones not. I was then thinking a red asterisks on the editor pages would be really nice for required fields. Probably in the same spot as the circle-question icon or even before the label itself.

I'll start testing the new beta today on some projects I am working on. Happy 2026!

I did run into a couple of issues. I took screenshots to help illustrate.

1. When I go to CMS Setup >Database> *Database Table* the last two tabs (Advanced and MySQL Source) are aligned to the right and separated from the first three tabs. Is this intentional?
   
   
2. When I go to a single-record table > Enabled Actions > Preview (is the only option available). If I click save and try to visit that item, I get "Modifying records has been disabled for this section!" 
   I can manually change it back in the schema, but if I save it through the interface, it reverts back to '_disableModify' => 1,
   

Still looking at other stuff, but this is pretty cool so far!

That did resolve the issue. I'm not sure how it was before as I rarely check things from this point of view. Most of my websites are locked out from the clients and my CMSB account is the only active account. In the cases where the clients have access, it is very limited (so they don't hurt themselves).

This only came up because I have employees that need access to some of the data in my Development Dashboard, but there is some info I don't want them to see like revenue, API keys, server passwords, etc... HOWEVER, I implemented front-end forms where they can edit limited data and never see the backend of the CMS. 

I don't think it's an issue for me. Maybe a note somewhere that "View" must be turned on for a section before you can give someone "View" access. I just realized that I turned off "View" access since they would be able to see sensitive data regardless of being able to edit it.  I don't have a case where this affects other websites, so it's all good working the way you have it.

• If I set a user to Viewer, they can't see any records.
• If I set them to Viewer & Author, they can't see any other records, but can create them. 
• If I set them to Editor or Author, everything works as expected.

I really enjoy the newest features and can't express just how much they speed things up. Especially these two screens - MySQL Table Schema: (show all schemas: MySQL, CMS) - I can feed these into Claude Desktop / Claude Code and it is off and running a lot faster and with a deeper understanding. Change request: can you make these two links (MySQL, CMS) open in a new tab?

I have also been dealing with the Email Templates a lot more so I am wondering if you could place the tools icons next to it in the side menu. I see them when I go to admin.php?menu=_email_templates at the top of the page, but one less click = one less click.

I am loving all of the new changes that help integrate with AI to help make it faster.

Kenny H

EDIT NOTE: I got legitimately mad when I went to a 3.80 CMSB and saw "MySQL Table Schema (show all)" instead of "MySQL Table Schema: (show all schemas: MySQL, CMS)" - I updated the CMSB right away. This feature is just too handy.

Parse error: syntax error, unexpected token "<<", expecting "]" in /home/xxxxxx/cmsb/data/cache.data.php on line 11 Parse error: syntax error, unexpected token "<<", expecting "]" in /home/xxxxxx/cmsb/data/cache.data.php on line 11

I deleted cache.data.php and it opened up the program without any issues.

I did the same for another website and it didn't give me any errors at all, so it may not be an issue at all.

On a 3rd website update I got the same error until I deleted the cache.data.php

Kenny

so I have done something to run afoul of line 552 of list_functions.php, but I can't figure it out:

// return field label for fieldname in format: articles.title, title, createdBy.username
function _getFieldLabel($fullFieldname) {
  @list($fieldname, $tableName) = array_reverse(explode('.', $fullFieldname));

  // get schema
  $schema = [];
  if  (!$tableName && $GLOBALS['schema']) {
    $schema = &$GLOBALS['schema'];
  }
  else {
    if ($tableName == 'createdBy') { $tableName = 'accounts'; } // workaround for legacy 'createdBy.fieldname' fieldnames
    $schema = loadSchema($tableName, null, true);
  }

  // get label
  $label = $schema[$fieldname]['label'] ?? null;
  return $label;
}

Schema attached. 

Thanks - Kenny