Thanks for the report! We were able to reproduce this locally and track it down, and we'll have this fixed in the next release.

If you'd like to patch it now, edit cmsb/lib/data-attr-handlers.js and search for "element.blur()"

And replace this:

                if (!confirm(message)) {
                    e.preventDefault();
                    e.stopImmediatePropagation();
                    element.blur();
                }
            }
        });

With this (adding ", true" before the final brace):

            if (!confirm(message)) {
                    e.preventDefault();
                    e.stopImmediatePropagation();
                    element.blur();
                }
            }
        }, true);

That makes the confirmation dialog run before anything else, so Cancel works again.

Hope that helps, and thanks so much for the bug report and confirmation!  Let me know if you any other questions.

Thank you so much for your help!

It is working now!

Hiroko

~ Deborah

If I click to 'erase' a section from CMS Setup > Database, the confirmation window appears very briefly but the section is then deleted and the message disappears so the table is deleted without confirming.

Let me know if you need any more information.

Thanks, Paul.

The issue is that a checkbox column doesn't support the same data types as a text box. A text box stores NULL by default (or an empty string once you've saved content), but a checkbox only supports 1 or 0, never NULL. It's the same even if the text box had real content in it, since MySQL can't map arbitrary text to a number.

If the field is empty, the easiest fix is to just erase it and create the checkbox fresh. Or you can convert the existing values to 0 first:

UPDATE `your_table` SET `my_field` = 0 WHERE `my_field` IS NULL OR `my_field` = '';

Once the data in the column matches what a checkbox supports (in MySQL: tinyint unsigned NOT NULL), it should let you switch the type with no problem.

Hope that helps!  Let me know any questions.

Steps to reproduce

1. In a section editor, add a new field and set the type to Text Box.
2. Save. (The column gets created across every existing record in the table.)
3. Edit that same field and change the type to Checkbox.
4. Save → error.

Error returned

Error: Data in `my_field` isn't compatible with new type:
tinyint unsigned NOT NULL DEFAULT 0

Please modify your data or column type and try again.

Query: ALTER TABLE `cms_example` CHANGE COLUMN `my_field` `my_field`
       tinyint unsigned NOT NULL DEFAULT 0
in [path]/cmsb/lib/Fields/BaseField.php:510  [Admin View]

Backtrace (CMS paths only)

#0 Script started        cmsb/admin.php:0
#1 require()             cmsb/admin.php:82
#2 include()             cmsb/lib/menus/default/actionHandler.php:65
#3 require()             cmsb/lib/menus/database/actionHandler.php:72
#4 require()             cmsb/lib/menus/database/editField.php:8
#5 submitFormViaAjax()   cmsb/lib/menus/database/editField_functions.php:179
...

Okay, great.  Glad it's working and thanks for the update!

zend_extension=opcache.so;

Then it causes a bit of a conflict and needs to be commented out or removed:

;zend_extension=opcache.so;

I found a quick fix for this.

In cmsb/api/mcp.php search for "// Dispatch" and replace it with the following:

// Block all methods (no tool list, no dispatch) while the MCP server is disabled
mcpProtocolErrorIf(!isStillEnabled(), MCP_ERR_SERVER_DISABLED, 'MCP server is disabled. Enable it at Admin → Advanced → MCP Server');

// Dispatch

That will prevent the MCP server from showing anything if it's not enabled.

Can you give that a try and let me know if that works for you?

Thanks!

That is curious. I've attached a test script that shows whether OPcache is running and the key settings it's using (which php.ini is loaded, where PHP looks for the extension, and so on).

Can you run it from a location where OPcache is already working, and again from your cmsb folder, and let me know how the two differ?

It's also worth dropping it into a parallel directory (e.g.,/opcache_test/) to see if something in the CMSB .htaccess or config files is affecting it.

Let me know what you find. Thanks!

That notice just means the plugin is checking if it needs to create your accounts table on every page load. Newer CMSB versions save schema files as .schema.php, but your plugin is still looking for the old .ini.php files. It never finds them, so it assumes the table still needs creating and runs the full schema sync (and logs that notice) on every page view.

It's harmless, though, your table is fine, and logins work. It's just extra work each load, and your pages will load faster if you fix it. So a few options:

• Leave it. If the log noise doesn't bother you, ignore it. Nothing's broken.
• Quick fix. Your accounts table already exists, so you can just comment out the createMissingSchemaTablesAndFields(); call on line 360 of your custom plugin. 
• Proper fix. Download the latest Website Membership, diff it against your custom file, and merge in the schema-file check, making sure it looks for .schema.php. The sync then skips on its own once the table's set up.

Hope that helps, let me know any questions.

zend_extension=opcache.so;
opcache.enable=1;
opcache.memory_consumption=32;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=3000;
opcache.revalidate_freq=180;
opcache.fast_shutdown=0;
opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=1;
opcache.max_file_size=0;
opcache.file_cache=/blah/wwwroot/.opmeow;
opcache.file_cache_only=1;

When I then load admin > General Settings I get a pop-up that says:

"updatePhpMysqlDateTime: [object Object]"

The only option is to click 'Ok'

I then see various errors like these within the same admin page:

Warning: Failed loading Zend extension 'opcache.so' (tried: /usr/lib/php8.5/extensions/opcache.so (/usr/lib/php8.5/extensions/opcache.so: cannot open shared object file: No such file or directory), /usr/lib/php8.5/extensions/opcache.so.so (/usr/lib/php8.5/extensions/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

/MYFOLDER/system/uploads/
Warning: Failed loading Zend extension 'opcache.so' (tried: /usr/lib/php8.5/extensions/opcache.so (/usr/lib/php8.5/extensions/opcache.so: cannot open shared object file: No such file or directory), /usr/lib/php8.5/extensions/opcache.so.so (/usr/lib/php8.5/extensions/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

The php.ini code works in every other PHP based system on the server, so what is going wrong here? I can turn these two 'Off' and the problem goes away, but obviously this isn't a fix:

display_startup_errors = On
display_errors = On

I getting a lot of messages in the error log:

#134387 - Notice: Database schema sync called on frontend. This performance-heavy operation should only occur during plugin installation/upgrades. Update plugins if happening frequently.
/docker_data/services-staging/www/cmsAdmin/plugins/websiteMembershipCUSTOM/websiteMembership_CUSTOM.php on line 360
> in line 360 is the createMissingSchemaTablesAndFields();

using the v3.78 (Build 2904) with a customized Website Membership that we created for a project.

is there anything that i can do in order to stop this generating?

I checked on the checkbox "Old" to redirect in case someone accesses to /services-headspa/, but it seems to redirect to a different page, which is /shibuya/ ( original url is /salonsDetail.php?salon=16)

The permalinks plugin uses the internal "Tablename" and "Record Num" fields to group permalinks together so it can figure out the correct permalink to replace any that get marked "Old".

Those two fields are usually empty when permalinks are manually created, only being given values for automatically generated permalinks instead.

Since those two fields are empty across across each of your permalinks, the plugin treats your permalinks as if they're all in one big group, ignoring any in the group marked "Old", and using whichever happens to be the first one it sees. In your case, the first non-old permalink in the group is /shibuya/.

How can I make my redirect change work for /services-headspa/ to /head-spa-shibuya/ which both are originally /mainPages.php?9 ?

The plugin needs to know that the old permalink (/services-headspa/) and the new permalink (/head-spa-shibuya/) are in a group together, paired-up, with one replacing the other, and unrelated to any outside the group (such as /shibuya/).

You can group the pair together by going to Plugins > Permalinks > Permalinks DB, and editing both the /services-headspa/ and /head-spa-shibuya/ permalinks to have the exact same identical value in the "Tablename" field for each (any short label is fine, e.g. "headspa").

You can leave the "Record Num" field set to 0 for both. The "Tablename" field is enough to group them together. That tells the plugin that any permalinks in that group marked "Old" (/services-headspa/) should redirect to the new replacement permalink instead (/head-spa-shibuya/).

If you ever want to add another redirect to replace /head-spa-shibuya/ in the future, you can group together as many permalinks as you like using that same "Tablename" field, as long as all but one of the permalinks in that group are marked "Old", so the plugin knows which one is the correct replacement to redirect to.

Hope that all helps, let me know if you have any other questions!

Yeah, I think something as simple as:

Maybe the first time you open the MCP menu, we could have an option where you click to enable it, and until then, it returns nothing in the tools list.

would do the trick.

Cheers

Rob

Yes, the CMS will automatically upgrade any .ini.php files it discovers.  Even when adding plugins or ini files after the fact.  

But if any of your plugins aren't working correctly, just download the latest version from the website.

Hope that helps!

So, with fingerprinting, any static response or file (CSS, JS, images, etc.) can be used. You just need to checksum a known response from some files from a given version of any software. There are actually some neat sites that do that (search "What CMS is this site running").

So the best solution for that is just to rename your /cmsb/ folder to something less guessable so no one can find it.

And/or, if you don't need the /api/ folder or /api/mcp.php, you should be able to safely just delete them.

But we want the UX to feel good end-to-end, so if seeing a big list of powerful tools, disabled or not, gives anyone pause, we could look into adding a one-time setting to enable it.  We have a few questions about it already.

Maybe the first time you open the MCP menu, we could have an option where you click to enable it, and until then, it returns nothing in the tools list.

Let me know if that would work for you. Thanks!

My client wants to change the permalink from

/services-headspa/ (original url is /mainPages.php?9)

to

/head-spa-shibuya/ (same url)

I checked on the checkbox "Old" to redirect in case someone accesses to /services-headspa/, but it seems to redirect to a different page, which is /shibuya/ ( original url is /salonsDetail.php?salon=16)

These permalinks are all created manually.

How can I make my redirect change work for /services-headspa/  to /head-spa-shibuya/  which both are originally  /mainPages.php?9  ?

Thank you for your help.

Hiroko

In updating a site with many XXX.ini.php files, will these .ini.php files still correctly provide the structure for site tables?

One lingering thought is less that the list is secret, and more that at an individual site level it fingerprints the install / CMS / MCP surface. I understand public Swagger on a vendor API, but this feels slightly different because it's exposing the capabilities of a specific install rather than the product documentation itself.

So while it's not leaking secrets, it is revealing what technology is sitting behind that particular endpoint and what capabilities exist if authenticated. It doesn't give someone access, but it does tell them what system to go and research.

The Claude restart explanation makes sense, and I can see why you'd want the tool list available for active development. For sites that never need Claude connected (or production environments), would there be any merit in an option to return a generic disabled/auth response to tools/list until a valid key is provided?

We can block it at the edge easily enough by having a CMS-level option would be handy for those of us who'll inevitably roll out an upgrade and forget!

Cheers

Thanks for the report, and good eye. This one's intentional, not a leak.

The tool list is static. It's the same hardcoded list on every install, and it already ships in the source you can download, so tools/list isn't handing out anything you couldn't read straight from our freely downloadable code. The only things we hold back until you authenticate are install-specific hints, like the server's working directory, OS, and shell, since those would fingerprint the actual box. Nothing in the public list is install-specific or secret.

The real security boundary is on running tools, not listing them. That's exactly what you ran into: the list comes back, but the second you try to call a tool, you get "MCP is disabled." Disabled means disabled, nothing executes, and that holds whether MCP is switched off or the auth is missing or wrong.

The other reason we always return the list is so you don't have to restart Claude every time you toggle MCP. Claude grabs the tool list once when it connects and caches it. If we only sent the list while MCP was enabled, every on/off would mean restarting Claude to pick the tools back up. Keeping the static list always on means you can flip MCP on and off, and it just works, since the tools are already known and only execution changes.

So the short version: the listing is public by design; execution is locked down.

This is also a common pattern for APIs built to be called by an external client. Plenty of public APIs serve their full OpenAPI/Swagger spec, every endpoint and parameter, to anyone, and gate only the actual calls behind a key. 

Hope that helps, let me know if you have any other questions or concerns!

I've been playing the new MCP feature and admittedly I know very little about MCP, so this may be completely normal...

I noticed that even with MCP disabled, the endpoint still responds to a `tools/list` request and returns the full list of available tools. Same when using no/incorrect auth.

For example, with MCP disabled (or no auth) I can still see things like:

• serverShell
• serverPhp
• queryWriteserverRead
• upload tools

Attempting to actually run a tool correctly returns an error saying MCP is disabled, so it doesn't look like anything can be executed.

My question is simply whether exposing the tool list when MCP is disabled is intentional?

I'm guessing there's probably a good reason for it, and you guys know the MCP spec far better than I do, but it feels a little odd that a disabled feature still advertises everything it can do.

Just curious whether that's expected behaviour or something worth tightening up.

Cheers

Rob

Try this:

    'where'       => " category LIKE '%Telecoms%' AND num NOT IN (421,83,122)",

Just replace the numbers with the ones you want to exclude.

Let me know if that works for you.