• New Max Quantity setting on the Item stack. Set it to limit how many of an item one customer can buy. Set it to 1 forunique, one-of-a-kind items and the cart shows a fixed quantity with no stepper.
• New Max Quantity Warning text setting for the message shown when a customer tries to exceed an item's limit.
• The cart is now emptied after a verified payment on the Return Checkout page.
• The Empty Cart at Checkout setting is now named Empty Cart When Checkout Starts to make clear it clears the cart beforepayment, so a cancelled checkout loses the cart. Leave it off and let the Return Checkout stack empty the cart instead.
• Fixed: the Return Checkout stack always showed the not paid content because it could not reach the PaySnap endpoint.
• Fixed: the PaySnap endpoint falls back to the document root when it cannot find its library at the relative path.

Check out PaySnap at https://www.weavers.space/stacks/paysnap

What to do?

I'm going live today at 11:30am Pacific, and it's the first stream on the new Total CMS channel. The topic is Markdown. Version 3.6.2 just shipped two new Markdown fields: a proper source editor with live side-by-side preview, and a visual editor that saves clean Markdown so your clients never have to learn the syntax. I'll demo both, then show the rest of the Markdown story in Total CMS: rendering it in Twig, keeping public forms safe, storing whole collections as plain .md files you can edit in git, and letting an agent write content straight into them. Bring your questions. I'll leave plenty of time at the end.

Any insights appreciated. Thanks in advance. Craig

1. Does Stacks 6 beta 73 allow the creation of stack groups within the library?

2. What is the current implementation status of Partials?

3. Is Stacks 6.0.0 beta 73 compatible with Joe Workman's SIlelock stacks and Vibralogix Sitelok? I have been unable to make it function in a minimal test site:
   
   https://www.rankingreal.com.br

Can anyone help?

Lighthouse is reporting total CLS of 0.580. Of that, 0.379 and 0.177 are attributed to the containers holding the two Photo Pro galleries, so between them they're accounting for virtually all of it.

They're four-column Grid galleries. We've watched their dimensions during loading and they appear to change height as the galleries initialise/settle, which is presumably what Lighthouse is seeing.

Before I disappear any further down the rabbit hole, is this something you've come across with Photo Pro Grid galleries, or is there a recommended way to reserve their final dimensions before they initialise?

Take a look at this test site. Weird. Am I doing something wrong or is this a Stacks 6 / Foundation 6 issue? All help is welcome!

https://zandbak.wromdrom.com/

This one’s a bigger patch than the number suggests. The headline is two new ways to write in Markdown, plus a round of fixes in the Mailer, Sync, RSS feeds and sign-in — several of them things you told us about. Thank you for the reports.

Write in Markdown, your way

Two new field types store your content as Markdown:

• Markdown is a source editor. You type Markdown, with a toolbar that inserts the syntax for you, a live preview, and a fullscreen mode that puts the source and the preview side by side. Image and file uploads drop straight in as Markdown.

• Styled Markdown is the Styled Text editor you already know, but it saves Markdown instead of HTML. Switch to source view whenever you want to see what’s underneath.

Both store exactly what you wrote, and both save the same thing, so you can switch a field between them later without touching your content. Render either with the markdown filter.

RSS feeds have moved into collection settings — please read this one

Each collection now has its own RSS Feed card where you set the feed’s title, description, which fields become the title, content, date and author, and so on. Feeds are also now off by default: a collection publishes a feed only when you switch it on.

On upgrade, blog and feed collections are switched on for you. Any other collection that had a feed will return a 404 until you turn it on in its settings. If your feed URL used to pass field mappings as parameters, set the same values on the card instead.

Why the change: before 3.6.2, any collection with a URL had a feed, and the feed URL could choose which fields it showed. That let the public read fields you may not have meant to publish. Drafts are now also kept out of every feed, always.

Mailer: Send History and a stack of fixes

A bulk email template now shows its Send History — how many were sent, failed, skipped or are still waiting — so you can see what a send actually did. Alongside it:

• Proofing a send to your own address no longer blocks the real send afterwards.

• A scheduled send goes out at the time you picked, in your site’s timezone.

• The hourly and daily send limits count the right hour.

• The whitelist matches domains exactly and ignores capitalization.

• Bulk sends now say how many objects were left out because they’d already received the email.

Sign-in is stricter about addresses

Signing in and password reset now match the email address exactly — smith@example.com no longer resolves to john.smith@example.com. A failed sign-in says “Invalid login credentials” without revealing whether the account exists. And if you’d rather not show “Keep me signed in”, the login form can now hide it.

Also fixed

• Sync no longer removes the receiving site’s files or breaks images inside cards and decks when you push. Both sites need 3.6.2.

• A file depot could be wiped by creating a folder with an empty name. It can’t anymore.

• Site Builder pages answer HEAD requests, so uptime monitors stop reporting working pages as down.

• Form dividers, headers and fieldsets hide along with the fields inside them.

• IndexNow submissions were being rejected with an HTTP 415 — they go through now.

• Hidden collections that still had public read access from an old default (3.0.41–42) are cleaned up automatically, and password hashes are never sent to a browser or API client under any setting.

• The new-object form keeps the cursor in the first field — in Safari too.

For the command line

tcms info now reports the site’s real domain, edition and license (it used to show “unknown” and “trial” on every install), and lists every cache backend you have. And there’s a new tcms check — the admin’s Server Checker from the terminal, with an exit code you can use in deploy scripts.

Docs

The license page has been rewritten, the Mailer finally has full documentation, and there’s a new guide on versioning your content in git safely.

Upgrading: update as usual from Admin → Updates or composer update. Afterwards, check the RSS Feed card on any collection whose feed you rely on, and if your site reads a collection anonymously through the API, confirm its public access is still what you expect.

The full changelog is on GitHub: https://github.com/totalcms/cms/releases/tag/3.6.2

Check out Total CMS 3 at https://totalcms.co

It's me again. here's a second finding from the same project. This one is more serious, because it loses data without any error message.

What happens: The help text of a schema property is rendered as raw HTML in the admin form. I had written a help text that mentioned tags as examples, roughly like this:

"body": {
  "type": "string",
  "field": "styledtext",
  "label": "Body",
  "help": "Paragraphs as <p>, lists as <ol>/<ul>, tables as <table>."
}

The browser turns <ol> and <ul> into real, unclosed list elements. Every .form-field after that ends up inside the list. TotalField.isSubField() finds an enclosing .form-field via closest(), so all of those fields count as sub-fields and are left out of TotalForm.fields. generateData() then doesn't send them.

Because the admin save replaces the whole object, those fields come back empty. In my case a URL, a date and a number were wiped. The save returns 200, the console says "All forms saved successfully", and nothing warns you.

Steps to reproduce:

1. Use the property above in a custom schema, followed by a few more fields (for example url, date, number).

2. Fill all fields through the CLI, then open the object in the admin.

3. Click Save without changing anything.

4. Read the object again with object:get. Every field after the help text is empty.

Workaround: No angle brackets in help, label or description.

Suggestions:

• escape help texts, or if HTML is intended there (for links, say), sanitize it to a small allow-list

• have schema:lint warn about markup in help/label/description

• the skill tells agents to write detailed help texts, so this is easy to run into. A sentence about it in the skill and the docs would help.

Thanks again!

Marcello Lang

I think I found a mismatch between the docs and the code in Total CMS 3.6.1 (Composer install, PHP 8.3).

The docs recommend "type": "integer" for whole numbers:

• resources/docs/fields/number-range.md: "Give the property "type": "integer" instead when only whole numbers make sense"

• resources/docs/schemas/validation.md (examples)

• the agent skill, references/data-model.md, which lists integer among the recognised type names

Steps to reproduce:

1. Import a custom schema with a property like this:

   "position": { "type": "integer", "field": "number", "label": "Position", "default": 0 }

   schema:import and schema:lint --strict both accept it without errors or warnings.

2. Create an object in that collection, for example with vendor/bin/tcms object:create <collection> - or jumpstart:import.

Result: The save fails with Unknown property type for object. The message doesn't name the field, so it took some digging to find the cause.

Cause, as far as I can tell: PropertyFactory::generateProperty() builds the class name TotalCMS\Domain\Property\Data\IntegerData from the type, but that class doesn't exist (there's only NumberData), so it throws.

Workaround: "type": "number" with "multipleOf": 1 works fine, and it still rejects 2.5.

Two small suggestions:

• either support integer (for example by mapping it to NumberData with integer validation), or have schema:lint flag it

• name the property in the error message

Thanks for Total CMS, it's been a pleasure to build with.

Marcelo