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

Just tried this out.  It's really slick, nice work!  And thanks for contributing.  I'm sure a lot of people will find this helpful.

Thank you in advance!

I'm releasing a free plugin that exports your CMS Builder content straight from the database in nine formats - ready to hand to a developer or paste into an AI assistant like Claude or ChatGPT. I've been using it across my own sites and think it's ready for others to try.

The Problem

Every so often you need to get content out of CMS Builder - to hand a section off to a developer, migrate data, or give an AI assistant the full context of a site so it can answer questions or help you write. Copying records by hand is tedious, and a raw database dump is full of noise you don't want to share.

The Solution

Content Exporter gives you an admin dashboard where you pick any combination of tables, choose a format, and get clean, formatted output you can copy to the clipboard or download in one click. It runs entirely server-side inside your existing admin login - there's no API endpoint and no external service, so the data never leaves your server until you copy or download it. It's admin-only, and the download endpoint is CSRF-protected.

Features

• Nine output formats - JSON (compact + pretty), Markdown, CSV, XML, YAML, SQL INSERT, HTML, and plain text — pick what fits the task
• Pick any combination of tables - a single section, several, or the whole site
• Per-export filters - skip hidden records, system fields, and upload metadata; strip HTML to make wysiwyg content AI-friendly
• Schema summary - optionally include a field-type/label map so the consumer knows the structure
• AI Prompt mode - wrap the output in a customizable preamble ({site} and {date} placeholders) for direct paste into Claude/ChatGPT
• Public URL injection - adds _publicUrl to records with a permalink so an AI can cite or link back
• Token count + size estimate - know whether the output will fit a context window before you paste it
• Copy or download - one-click clipboard copy, or a dated .json / .md / .csv (etc.) download
• Available-table picker in Settings - choose which tables appear on the dashboard; system, session, log, and account tables are skipped by default
• Security and accessibility are top-of-mind with all plugins we develop

Download

• GitHub: https://github.com/sagentic/cmsb-plugin-content-exporter
• Screenshots & direct download: https://public.sagentic.dev/plugins/

Installation

1. Copy the contentExporter folder to /cmsb/plugins/
2. Log into CMS admin and activate the plugin
3. Access via Admin > Plugins > Content Exporter

Requirements

• CMS Builder 3.50+
• PHP 7.1+

Feedback Welcome

I built this because I kept needing to feed site content to AI assistants and other developers in a clean, structured form. I'd love to hear your feedback, bug reports, or feature suggestions. MIT licensed - modify as needed.

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!