Plone multitheme

Can you check if it has something to do with this:

If you still have problems with, be sure to read this (the part about 'installation'):

If you still are having trouble, go to: and click on the 'chat button' bottom right, and probably someone at the plone dicussion channel can help.

I was not able to figure out so I asked in the discussion forum. Hope to get an answer soon.
Meanwhile, should we continue discussing issues over here or a gitter channel will be better.
Your suggestions @espenmn

I could not find you ..... can you try to download it again, and make sure you have all 'rights to content in that folder' (maybe owner changed when you downloaded it.

I tried downloading again but still issue persists aand what did you mean by above statement.

I have no idea what the error actually means, but make sure that the folder collective.multitheme and its content has the same permissions as the 'src' folder.

When you unzip a file, the owner etc is the user unzipping it, and maybe the buildout / plone user does not have the permissions to read / write in the folder.

permissions are same for both folders but still it gives this error
Can you tag someone who may know about this error so that he/she may help

Can you try to remove multi theme from the buildout and see if everything works ok.
If yes, can you try to download another package from and add that to buildout the same way, and see if that works.

(maybe this error has nothing to do with multi theme, but with your setup)

Also: Please ask on the forum (and hang around for a while, people dont answer straight away)

I tried removing collective.multitheme and it worked fine,
then i installed collective.easyform and Products.EasyLetter, it gave the same error again.

After some searching i found this

It gave the same error as mine. Maybe it is related. Can you have a look at it

I think it is something wrong with your setup, can you try the discussion channel.

Added another fragment (block):

Here's a recipe for doing a fullwidth toggle that doesn't cause side scrolling (an issue I had with other fullwidth implementations).

A full width row only makes sense and looks ok when you don't have portlets available on a page, so please take this into account :wink:

Good catch. I've added a note to the gist.

Actually, portlets do not 'look correct on most themes anyway (because the (CSS) grid does not 'add up').
So if you need portals, you probably have to edit something anyway (?)… at least f you use columns

Is there a way to 'skip the mosaic part of the class'.

I want




(because then I can use already declared css)

For example, adding class 'container' to the row would take care of making the width the same as the 'not fullwidth content'

I think that all of this is a bit of a workaround.
The ideal way to do this is to use .container-fluid, this is the ¨proper way" to use bootstrap to get a fullwidth row.
The issue I'm coming across is that barceloneta and barceloneta based themes make liberal use of .container.

Unless I'm misunderstanding how bootstrap works, the ideal scenario would involve using .container and .container-fluid as they were designed. This would require some tweaks to barceloneta.

In the meantime, I think you could get away with using just .grid-row-fullwidth but I have not tested this.

I think this is similar to your approach:

The TB's CSS class .container-fluid is made for exactly this usecase, but:

  • .container-fluid and .container need to be next to each other, not contained
  • a .container-fluid can never break out of the boundaries of a .container
  • a .container-fluid should be used inside a .container to create a nested grid

So, to break out of a .container and get a full width row, you have to use one of the many hacks available.

As you can see in, the theme only creates a full-width row when there is no portlet defined. But that required some extra classes on the main column to work: (see the additional col-md-* classes).

Why can you not just add this to the add-on (in profiles and css )?

I am solving this 'the other way around'.

With less, it looks like you can do:

.mosaic-grid-row-fullwidth {

Which basically adds all CSS from .container to .mosaic-grid-row-fullwidth class.

(might look a bit odd in (html) code, but maybe more logical that 'fullwidth' starts with fullwidth and you can 'remove it' than the other way around

It can be seen here:

##Fluid / not fluid
The best option could be to toggle between classes 'container' and 'container-fluid', if that was possible ?

@espenmn... funny you mention all of this.. I composed the response below about 2 hours ago but just got around to posting it. Your solution is intriguing, I'll have to look at that.
Regarding themesitesetup, I mentioned it because I'm assuming TTW all the way, but it means they would be on a installation with all those prerequisites.

Exactly, these hacks solve the problem but....
The problem we have is that #content, which is where everything gets rendered is wrapped in a .container. I've thought of using a Diazo rule to kill the wrapping .container but haven't gotten around to the experiment.

What I'd like to see:

It would be nice to make it possible for mosaic to use the .container and .container-fluid as they were designed.
So two options (both I have not explored):

  • Tweak barcelonta to ship with .container-fluid instead of .container by default.
  • Create Diazo rules that remove the .container dynamically when mosaic is enabled.

It would then mean that every mosaic row would be wrapped in a .container by default making each row fixed-width by default.
Then when a user selects fullwidth, it would switch to toggle .container to .container-fluid to make the row become fullwidth. I haven't dug deep enough to know what will happen with such an approach. Best case, the implementation will just work but I'm guessing that something will break with the current mosaic implementation if this is done.

Plone Foundation Code of Conduct