Blocs 3.1 Beta Build 5


Just in time for the weekend!

Here is Blocs 3.1 Beta Build 5. It includes a bunch of fixes and improvements. But most notably it includes various new features to the developer API.


Template functions - Write data from Brics into additional export files.

New UI items - Font Selector UI Item

Have Fun!
Download Blocs 3.1 Beta Build 5


LOL this is going so fast that I do not even have the time to find bugs…

But enjoying the ride.

Thanks @Norm



Thank you @Norm for every unknown minute you have put into Blocs. You support for making Blocs the #1 web builder for MAC is clear.


The bug that seems to limit the number of rows that can be viewed in the custom Brics’ sidebar is still there. It’s such a huge deal for me right now.

Really happy to see the Dev API et some love. Some really cool additions that I can take immediate advantage of.


Yeah that’s had a few hours of my day but unfortunately I still can’t find the cause. It’ll surface soon. A lot more coming to the API over the next 6 weeks.


Thanks. I really wasn’t going to post. I’m sorry for that. I’m just really excited about what’s on the horizon. The first 2 new additions kinda blew my mind as I wasn’t expecting them at all.

Meantime I’m diving in.

I appreciate you chiming in. I’ll be quiet and let you work sir!


Holy cow, the left sidebar crashing bug is indeed fixed! Whoppee! :slight_smile:

Great work, Norm!


Ok, I’m glad to see variable injection and I have a lot of comments & suggestions on Template bric so here goes:

  1. The BG Color doesn’t seem to work & I’m not sure what bg it’s supposed to work on.

  2. I saw that the Initial Open Button was hardcoded, so I tried adding a control & assigned attribute & value & put % around attribute in Html - doesn’t work, just shows the %attribute% - we really would like to have direct replacement in html as well.

  3. In custom-bric.js I changed “force-newfile”:“yes” When multiple instances of bric are present & exported, don’t see but 1 js file in head (note: see next comment)

  4. When a second instance of the bric is added, it isn’t pulling the custom value

  5. When closing Blocs and reopening, the bric builder is empty, i.e. lost all custom brics.

  6. When users start putting multiple instances of brics on a page or pjt. for that matter, the number of js files written to head will immediately grow to enormous numbers. Our friends using i.e. I think are limited to 32 in the head, which isn’t many really. So, I think a way to create one master js and probably one master for css is quickly going to be needed.

  7. Currently this templating stuff seems to work like this: assign a control that calls a custom function in custom-bric.js, that function assigns attribute/value/template/force to I guess as many controls as you point to that function? and finally a template that appends html to the page using the values. That is what I call spaghetti-works :slight_smile:
    Let me suggest something to make this much easier for development: Add a Template input in the Interface panel - this is where the template filename is specified. If the variable is being written into the basic html then just enter HTML. All that is needed is a hidden unique data attribute assigned to each bric instance (this is done by Brics automatically) - suggestion data-custombricid="~"
    On preview/publish: Brics gets each data attribute and uses that to retrieve the value and loops through each area injecting the value, whether it’s in html, the custom js file, the custom css file, the custom php file. Thus, we eliminate the need for these template files and just use brics.css & includes files. And a lot of the custom js functions will be eliminated as well.



Some feedback

  1. Export the project and click the button, you should see it sets the background colour of the pop up window. All values effect the pop up window.

  2. Templates is for external files. What you are suggesting is wasteful and causes extra work at export. HTML changes should be done with JS in real-time. If I can find a way that does cause additional overheads at export I’ll interstate but I think it’s unlikely.

  3. It requires 2 brics

  4. Did you set all of the attributes to force new file, it’s all or nothing. This should be set in the initial template values found in the bric builder. I can probably make this more reliable and clearer.

  5. I’ve never seen that and have no other reports. Nothing changed that would cause installed Brics to be deleted.

  6. Agree.

  7. I think what we have is fine, it’s flexible as you have complete control and can create eleberate functions that can do a multitude of tasks. What you are suggesting is simple but very limited if I understand correctly.

What if I want a function to do both tasks, write to html within the Bric and write to 3 different external files?

Thanks for the input, lots more on the API to come!


#1, #3, #5 are resolved

#4 When I export at least 2 brics, only the settings from the first one are shown.

#2 & #7 Are really trying to address the creation of an API that will directly replace %variable%, no matter where it occurs. When that happens, I imagine about 2/3rds of the js files in edit mode and all the scraping files will be a mute point - that alone will offset any processing time on preview/publish. After all, the point of an API is to make it easier, not harder to create content :slight_smile: This will still allow the devs to write to the html and to external files.


It is but not at the cost of making the software appear slow. My goal is to offer entry points but balance that with performance.

Another app in this space (that relies on a plugin) that offers what you are suggesting as part of its dev API, has a reputation for being slow and laggy regarding previewing/export. My goal is to avoid the same with Blocs.

I agree with you, but what is good for the developer needs to be good for the end user too. So I’m not saying it’s a bad idea, I’m just not convinced it’s the best idea.

I’ll see what I can do :+1:


I think I know THAT app pretty well and I’ve spent countless hours waiting 20 seconds for page previews on mobile, then the same again for tablet and desktop. Their suggestion to build simpler websites doesn’t really cut it, so guess why I first checked out Blocs?

If Blocs becomes slow in general usage it loses a massive chunk of its appeal…

PS I believe that plugin has never been multicore enabled and we are in 2019.


I think I found a small bug. Maybe someone can reproduce.

After closing the code editor, it reappears after I preview the page. I keep closing it because I no longer need it but then I preview and it reappears. I have to restart blocs to get it to close for good.

Is it me?


Hi @Whittfield

Had a similar issue but with the code widget. I deleted the code widget bric while the code widget editor was still open. Then I closed the editor but it would reappear each time I opened the Page Settings Editor.



Thanks for the info @MDS
I’ll see if I can tie the behavior to some other action I might be taking. I’m not using the widget but maybe it’s tied to something else.


You’re welcome @Whittfield

If I had more time testing I would have tried to reproduce it and report it. I have to finish a project for a client on Thursday, so just on the forum to breathe a bit during let’s say coffee break. :wink:



Hey Bill – Wondering if as you promised you are still creating a ACCORDION & TABS Bric with highly flexible CSS customization?

I recall you stated that this was coming…as this still will determine if I can/will use Blocs – while Blocs 3 is clearly a really nice upgrade, it doesn’t provide the Bric functionality I’ve been waiting for (ie. Accordion & Tabs bric which are easy to make high levels of customization, rather than standard Bootstrap CSS).

If you recall last year you said this was on your todo list…?


Fixed and ready for build 6.

closed #19