While this is not something you would commonly do, here's how I approached converting a FormContainerBlock type to our custom ExtendedFormContainerBlock in Optimizely Forms for CMS 12. You may need to do this if you want to add custom properties or functionality to the standard FormContainerBlock type, and you don't want to rebuild or recreate all previously created forms.

When working with Optimizely Forms, you'll find there are multiple ways to configure the functionality of a form. One of those options an editor can configure is "Allow multiple submissions from the same IP/cookie", which is commonly used to prevent/deny a visitor from resubmitting the form, and it works by creating a browser cookie with the form's information.

While this can be a useful option to have to prevent a visitor from continually resubmitting a form, it's not foolproof. A visitor could easily resubmit the form in incognito mode (private browsing), or simply clear their browser cookies to resubmit the form, or just wait until the cookie expires.

But what if you want to allow the user to resubmit the form after a certain amount of time? Let's look at how we can change the timeout for a form resubmission.

Here's a quick code snippet for adding a logout link to the Quick Navigator menu in Optimizely CMS 12. This is done a bit differently in CMS 12, since the logout page is using Razor Pages instead of WebForms, and the new logout method requires an antiforgery token.

What first started out as a "nice to have" feature, has now turned into a bigger experiment with EditorDescriptor. The original idea was pretty simple: "Can the font be changed in the Optimizely CMS UI for a textarea (string) property editor, maybe to something like a monospaced font where editors can provide additional styles or scripts?"

Here's a quick write-up about what I've learned when creating and modifying client side property editors.

I've recently been working on an Optimizely CMS 12 solution for a customer that creates and publishes a large amount of content during certain times of the year. They typically create all of the content changes and track them within an Project in the CMS, then publish all the changes at once, which is a great benefit of Optimizely's Project feature.

Recently, a question came up about this: "Is there a way we can enforce content to be part of a Project so it can be published?" This feature is more about change control than general functionality. The customer wants to make sure a change to content doesn't get published prior all other content being ready and published.

In the post, I'd like to share an example on how this could be accomplished; how you can require content to be part of a Project in order for it to be published, or on the opposite side, prevent content from being published if it is part of a Project.