ContentBlocks Most Popular

Core mechanism that functions as a repeatable instance that will create rows or columns of the input types defined within. This way, a block itself is not repeatable, but any (or all) of its input types can be made to be repeatable which adds a minimalistic UI to add multiple value instances.

We heard your feedback that the "drawer" pattern alone is not enough, you want additional settings in a modal window. 

For layout-specific configuration that doesn't need to be immediately visible.

In the current version these are limited to fixed options, but this needs to be dynamic with feature parity with v1 (so ability to use a snippet).

Select2 like in v1.

Same as v1, visually being able to make a nested lists with convenient keyboard controls. 

There's currently a very basic implementation included, but expand this to offer similar functionality for v1. 

Same as v1 but better.

As before, parsing inside out from blocks up to individual layouts. Unlike before, don't use sub-templates, but instead all data inside of a field is available in its template directly using more powerful parsers.

Core parser interface that extracts away implementation details, while allowing the user to use any supported parser for any block/layout as they see fit, using template file extensions to determine the parser to use.

MODX parser support using .tplx extension with some magic to support nested data field types. This will be the default for upgrades.

Twig parser support using .twig extension. Default for new elements. Explore available Twig packages for MODX and determine if we build this into the CB core, or use an abstraction that can share Twig parsers (Commerce?).

Fenom parser support using .tpl extension.

Ability to register parsers through a plugin or configuration.

Fluid API that allows (re-)rendering blocks or elements without needing to know implementation details. 

 Basic core implementation with active, activate_on, and deactivate_on fields added to the core tables. Core-provided plugin to expose the publishing state in a minimal UI form factor, to allow non-core provided plugins to expand on the functionality with complex rules that are evaluated separately and write to the core fields as needed.

User permission allows a user to lock a block or entire layout from editing. When locked, they become read-only in the manager. Only users with the lock permission can unlock and edit them.

Server-side verifications that locked elements have not been edited. 

There's a set of fluid PHP classes to build and generate content, however these are 2+ years old and need to be checked against the current set of features and likely updated. Also generate documentation for them.

For example, adding a setting that adds global padding or margin control to every layout or every block.

These get defined in the canvas configuration.

Currently hardcoded, but needs to be made configurable.

Added as last entry - when we hit this, ContentBlocks 2 will be packaged, installable on MODX3, and documented to allow users to get to work with it. We then hit alpha!

Single toggleable element.

Similar to the chunk input type in v1 - loading the preview of a fixed defined chunk.

Similar to the chunk selector input in v1 - a dropdown of chunks that render in-place.

Similar to v1, but more visual. Optionally allow the output to be rendered while clicking the input type opens a window to edit it with properties. 

For uploading a list of documents. Might not be necessary with repeatable blocks and a single file upload type. 

Similar to v1. Multiple image selection/upload rendered as a gallery.

Similar to v1. Automatically build a UI for snippet properties. Allow a live output where clicking it opens a window with properties to edit. 

Better than v1. Investigate the current state of available dedicated UI libraries or map out a detailed spec for building a custom visual table output. 

Simplified from v1; only input a link or embed code directly rather than a search. 

Proof of concept accomplished. Embed structure information in the copy that would allow it to be pasted on a different page or site entirely and auto-match. 

Review list of extension ideas and verify those are possible. Make sure documentation is up-to-date. 

The migration toolkit will run on the CLI and cover 3 steps:

• "prepare" that reads the v1 configuration and creates a fresh v2 configuration based on it. This will map fields to blocks, rewrite templates, and report any found incompatibilities. The user will be able to change the configuration before moving on to the next step.
• "migrate" that iterates over resources and moves v1 content into a v2 canvas, preserving all content as much as possible, and reporting on any issues that require manual intervention.
  
  • In addition to the CLI approach that migrates all resources at once, it will be possible to migrate one resource at a time through the manager. After preparing the v2 configuration, resources that have not been migrated will show a panel that says they need to be migrated with a button to convert that resource.
    
• "cleanup" which will remove the old v1 content from resource properties, remove the old configuration, etc. While optional, this step is recommended after the user has verified the integration was successful.
  

Once the migration toolkit and other features in this section are complete, we hit beta.