Submit Your Blocs Feature Request for 2026 📢

Announcements
1

After a nice festive break and way too much cheese, we are back and ready to take Blocs even further forward in 2026!

Last week I was battling a case of man-flu :sneezing_face:, however, I still managed to fix up some more bugs, which I have just released in Blocs for Mac 6.3.3.

Next on the list is an update for iPad, Blocs for Mac 6.4 beta and the Blocs for iPhone official release :sweat_smile:.

Of course, this is just the tip of the iceberg, we have a lot more planned for 2026. :smiling_face_with_sunglasses:

As it’s the beginning of a fresh new year, I think it’s always good to check back in with you all and collect some community feedback and feature requests.

What are the top 3 features you would like added to Blocs in 2026?

9 Likes
2

Hi Norm,

  • WordPress Block Theme support (Full Site Editing) besides the current classic theme support
  • SSH-key support (prefer it over passwords) when publishing
  • More support for WordPress data in current elements (for example, being able to use a masonry layout with a WordPress post loop)
4 Likes
3

I would like the ability to open multiple projects

Also give a bigger step in animation / interaction with capabilities like framer or weblflow to create more dynamic and interactive sites. (including easier creation of hero and carrousels without having to pay extra brics or extra code)

And last: Perfect migration from one version of blocs to a newer one. Every time I purchase the latest version of blocs and open older projects they all have some issue, missing classes or different kind of incompatibilities making an extra time to set up all again.

10 Likes
4

Blocs for Apple Watch :rofl:

5 Likes
5

Blocs for Web will enable Blocs to compete with Webflow and Framer, among other web-based platforms.

On a more serious note, get well soon @Norm.

Looking forward to the updates, particularly for the iPad version of Blocs.

As you’re aware, I have many feature requests, especially for the iPad version, which I can’t narrow down to the top three due to their all-important nature. However, I’ve randomly selected three features for the Mac version that I believe could be realistically added as a .X update to Blocs 6 in 2026:

- Ability to select multiple elements on the canvas or in the layer tree

- Dynamic element style changes based on user selection: Currently, when editing the Hover state, users have to guess the final appearance of the element until they go to the Preview mode or hover their mouse over it. This feature would provide real-time feedback on the element’s style changes, making the editing process more intuitive.

- Improved Dark theme mode customization: The Dark theme mode could be enhanced to make it easier for users to customize their designs without having to work with numerous classes. This would simplify the customization process and make it more accessible to users with limited design experience.

Best regards,

Eldar

6 Likes
6

Feel better Norm and I’d be thrilled if SSH keys for SFTP publishing was added.

3 Likes
7
  1. Greatly improve and make more stable the ‘forms’ implementation, and provide better error/help messages when it goes wrong. Also allow custom design/control over ‘success’ / ‘fail’ message presentations.
  2. ‘Mega Menu’ support.
  3. Make pop-up confirmation dialogs appear centred over their parent dialog.
1 Like
8

Get well soon, Norm! Stability is more important to me than lots of new features.

It would be great if it were possible to nest container tags (sections within main).

And perhaps it would be possible to make the form more secure (header, honeypot, time delay, token, etc.).

2 Likes
9

You can build your own with 6+ using custom interactions.

1 Like
10

Thanks for all the feedback so far, keep it coming.

1 Like
11

Hi Norm, Asset Manager - More PDF support. Right Click & Choose Edit In (choose app). Get well soon.

1 Like
12

Open Graph protocol tags

Of course, you can also use the code editor, but it would be great if these tags were available in the page and project settings.

1 Like
13

A Resources folder that files can be added to allow folder structures to organised within Blocs so that extra files can be used and linked to in Blocs. I say this because I use Code Widget a lot and therefore non-blocs files brought in to pages. It would be great if it can be saved as part of the Blocs file, but taking it a step further a tick box to external and the path set to a local folder on the Mac, this way the local designated folder on the Mac is seen as been the Resources folder and when a site is published pulls the dependent files up from the local folder. If that all makes sense.

The next request, you did ask @Norm :grinning_face:, is more of a pipe dream, the ability to add a GLTF or Obj 3D object as an asset on a page similar to a text box or image. That one though is probably more for a specialist Bric development with a customer base of about four people over a five year period. In this day and age of modern content it would be a coup to be the first web builder system to allow embedding of 3D objects as visual content. I would say that though because that’s something I’m after in a web builder :rofl:

Edit: Ooh and I’ve just thought of one more, being able to add an iFrame of content, but having buttons being able to talk to the content in the iFrame. I say this because I had a right going on getting that to happen with some interactive content, the content is embedded in an iFrame, but the buttons for show, hide, activate etc were on the Blocs page and had trouble acting on the content in the iFrame. I got it to work but it was a pig of a job with loads of custom code. If buttons can work parent child with iFrames that would be good. Sorry, again probably a bit too specialist.

2 Likes
14

To be able to sort by Name, Date, Size, Type in the Image Asset Manager. I think I started this request in 2022. In the link below you mentioned changes are coming. Yes, indeed you came through with some good ones, for which I am grateful. So looking forward to this needful change.

2 Likes
15

Have you tried this yet:

If you add a folder in the project settings under the paperclip icon, it will be included in the project unchanged and also exported. I put all the external js API files in there, which works quite well. The folder itself is integrated into my working environment in VS Code. Each Blocs export takes it as it is.

2 Likes
16

I second these requests by @brechtryckaert

2 Likes
17

Hi @Norm ,

1. First, a small but important enhancement related to existing post and custom post type queries: Improve existing post queries (names, not IDs only)

Currently, taxonomy-related filters in post/custom post queries require IDs only (category, tag, author). This creates unnecessary friction and makes queries harder to read, maintain, and share.

It would be extremely helpful if post queries supported:

  • Category by name / slug (not just ID)

  • Tag by name / slug

  • Author by username / nicename

  • Optional multi-select or comma-separated input for each

This aligns with native WordPress query capabilities and would make Blocs queries significantly more user-friendly and self-documenting.

2. Secondly add context-aware taxonomy term query mode

Blocs already handles post queries well, but it lacks native support for querying taxonomy terms themselves. Adding a taxonomy / term query mode would allow terms to be treated as first-class, loopable objects, just like posts.

Loopable term objects

Expose WP_Term properties in loops, including:

  • Term name

  • Term slug

  • Term link

  • Term description

  • Term meta

  • Term thumbnail (where available)

Context-aware term queries

Support dynamic contexts such as:

  • Current term (taxonomy archive)

  • Parent term of current term

  • Children of current term

  • Terms attached to current post

  • Top-level terms within a taxonomy

Hierarchy & filtering

  • Parent / child filtering

  • Include / exclude by ID, name, or slug

  • Hide empty terms

  • Order by name, slug, count, or term ID

Why this matters

Many modern WordPress sites are taxonomy-driven rather than post-driven (e-commerce categories, portfolios, directories, knowledge bases). Without:

  • Human-readable taxonomy filters in post queries, and

  • Native, loopable, context-aware term queries

users are forced into PHP blocks, shortcodes, or external theme logic — breaking Blocs’ visual workflow.

These enhancements would make Blocs a truly CMS-first WordPress builder, not just post-centric.

To better understand what’s possible within Blocs today, I’ve built a couple of custom brics as exploratory work:

  • One bric that extends post queries to support category, tag, and author by name/slug (not IDs only)

  • Another bric that performs taxonomy term queries and loops over WP_Term objects, including basic hierarchy and context awareness

These were created primarily as proofs of concept and workarounds, and they naturally have limitations compared to what could be achieved if this functionality were built directly into Blocs at the core level.

If it would be useful, I’d be very happy to share these brics with you purely as:

Reference implementations

  • UI → query mappings and examples

  • Sample WP_Query / WP_Term_Query logic

  • Real-world taxonomy-driven layout examples and feedback

I strongly believe this functionality would be much better designed and maintained as part of Blocs itself, rather than living in external brics, which is why I’m raising the request here instead of continuing down that path.

Thanks for the continued development of Blocs, it’s been a great 2025.

Ricardo

3 Likes
18

Hi @Norm,

I have a separate request related to the HTML structure Blocs outputs for bric containers.

Reduce Extra Wrapper Levels Inside <bric_container>

Issue:

When a bric uses:

<bric_container></bric_container> and rows/columns (or other elements) are dropped inside it, Blocs currently injects multiple wrapper levels between <bric_container> and the actual dropped-in elements.

These additional wrappers can create styling and layout issues, especially when the dropped-in element is used as a query loop root (for example, a column being repeated). Common side effects include:

  • Unexpected flex / grid behavior

  • Difficulty targeting the loop root

  • Problems with height, spacing, and child selectors

Requested behavior

Ideally, <bric_container> would act as a pure container and introduce no wrapper of its own, so dropped elements become direct children of <bric_container>.

<bric_container>
<!-- dropped content -->
</bric_container>

Optional compromise (if internal wrappers are required)

If Blocs needs an internal wrapper for structural or editing reasons, a practical compromise would be:

  • Limit the output to a single wrapper max

  • Treat <bric_container> as the styling and targeting surface

  • Allow attributes on <bric_container>, such as:

    • class

    • id

    • inline style

    • possibly data-attributes

For example:

<bric_container class="loop-root" style="display:grid">
<div>
<!-- dropped content -->
</div>
</bric_container>

OR both if it made sense:

<bric_container class="loop-root" style="display:grid">
<!-- dropped content -->
</bric_container>

This would:

  • Make styling predictable

  • Allow clean loop targeting

  • Reduce reliance on descendant selectors

  • Avoid brittle CSS caused by unexpected wrapper depth

This change would significantly improve advanced layout control, especially for query-driven content.

Thanks again @Norm for all the hard work you put into Blocs, and your responsiveness to the blocs community needs.

Ricardo

3 Likes
19

I think my main one would be what @Eldar has mentioned is Blocs for web.
I would love to be able to log on anywhere on any device and login and just edit etc.

This would be GREAT for clients too if we can give them certain admin roles and say which areas they can edit themselves.

I think this is the big next development for Blocs.
Or if Wordpress is the way forward in this area, then I would like like what @brechtryckaert has also mentioned for full site editing.

4 Likes
20

Hi Norm,

I know this is already on the roadmap, but I didn’t think a reminder would hurt :wink:

Blocs already allows PHP code to be added directly to extra-functions.php via the code editor. Extending this capability so that brics can register or attach PHP files via the bric API would be a very natural next step.

What this would enable

Allowing a bric to contribute PHP code (via an attached file or managed include) that Blocs appends or includes in extra-functions.php would make it possible to:

  • Keep bric-related logic encapsulated and modular

  • Avoid manual copy/paste of PHP into extra-functions.php

  • Improve reusability and versioning of custom brics

  • Keep layout concerns separate from PHP logic

  • Reduce errors when updating projects or sharing brics

Framing it as an extension, not a change

This wouldn’t replace the existing code editor workflow — it would simply expose the same capability through the bric API, allowing advanced brics to declare their PHP dependencies in a structured way.

From a developer perspective, it would feel consistent with how Blocs already manages:

  • CSS

  • JS

I know this is already planned, but I wanted to reinforce how useful it would be for advanced WordPress and bric-driven workflows.

Thanks again for all the work on Blocs — features like this really enable cleaner, more maintainable projects.

Best regards,

Ricardo

4 Likes