Please login or register to participate.
Wiki Page

HowTo : Create custom CSS Styles


For creating custom CSS Styles, you will be required to use a technique known as ZMI through-the-web customization.

Steps to create custom CSS Styles :

  1. First login with Site Administrator privileges 
  2. Get to ZMI at http://yourcyninsite/manage
  3. Now find portal_skins and Click on it. You'll get a biggish page - you want to find ubify_custom_styles and click that.
  4. Here you will find all the CSS files that cynin uses. The file that you need to override is banners.css. Click it and go inside.
  5. It will open in read only mode. Click the customize button. It will ask you where you want to place it. Don't change anything, just submit. Your customized banners css will now open for editing, you can maintain this by yourself from that point on.
  6. Bookmark this URL from the breadcrumb, not the address bar, the page is usually in an iframe. You can use the bookmark to directly land inside edit any time you want.

Some tips/points:

  1. This customized file will be maintained even when we upgrade with newer versions of cynin.
  2. If you find yourself using the same style repeatedly, there *is* a way to directly add it to your kupu styles dropdown, it will be available to all content authors though.
  3. Editing what's already there in the file and adding new selectors, classes is easy, but you should take care to *not* override any cynin CSS that is not already present in bannners.css.dtml - this file is loaded last and all overrides will work but UI css is complex and you may end up breaking the UI if you're not careful.
  4. Changes in this file will not appear immediately, when you try to use it. Go to portal_css at /manage and turn on debug mode and hit the save button at the bottom of the page. Remember to turn off debug mode when you're done - it reduces perfomance a bit when debug is on.
  5. Do not override by clicking on customize on any other file - doing that will block your upgrade path for future versions of cynin.
  6. You must already be using Firefox+Firebug, right? :)
Comments (21)
siclyundecided Nov 19, 2009 01:39 PM
forgive me but, might this be outdated? I cannot seem to find the objects in /manage that are refered to here.
dhiraj Nov 19, 2009 01:46 PM
You couldn't find portal_skins at all, or you couldn't find the deeper ones?

The instructions are valid even for v3.0.5, as far as I can see. They are assuming that you are logged in with siteadmin and can access ZMI at /manage on your site. This should be true if you're using the ISO CD way.

If you did a buildout, and went in at the 8080 port then you would also know that you'd have to go one level deeper at /cynin.

So frankly I'm puzzled why this is not working for you. Could you explain in a bit more detail what's happening when you go to /manage? Or if you could dump a few screenshots in Sandbox Space and link them from here?
everythingability Mar 10, 2010 10:21 AM
This may be a daft question, I'm trying to get to the ZMI but none of my login details work, not siteadmin/secret or my username/password...

Do I have to explicitly create users with access to the ZMI?

p.s I used to be a huge Zope fan (almost 10 years ago ) it's nice to be back :-)
everythingability Mar 10, 2010 10:53 AM
OK, so I found the answer, the default login details are admin/secret...

It's not completely clear when installing when it asks for usernames and passwords, which will be used where... I can't say I spotted the admin/secret one...

It seems there are ...
1. The Cynin admin siteadmin/secret
2. The Zope admin admin/secret
3. The root for the box
4. A user for the box (not root... not sure why).

Is this right?

dhiraj Mar 10, 2010 12:43 PM
Absolutely right.

The root user's password *is* asked during the setup from the ISO CD.

You are asked for root password, and then what "normal" username you want on the linux box, and the password for that.

There are 2 users that creates for every out-of-box buildout, admin and siteadmin. Both have a default password of "secret" which you *should* change. Refer to this guide for how to change the admin user's password:[…]/change-admin-password
everythingability Mar 10, 2010 11:29 AM
I think the documentation maybe slight adrift from the latest version... I can get to banners.css (not banners.css.dtml) here...

dhiraj Mar 10, 2010 12:44 PM
In the ZMI, you'll see banners.css, but the file *is* actually banners.css.dtml.

Hmm.... but you're probably right, that URL should probably be fixed.
everythingability Mar 10, 2010 11:43 AM
So I tried editing banners.css (creating a custom version) and adding...


...hoping that it might show up in the h1 used throughout the site, but it doesn't... the yamlbase.css seems to get loaded last and renamed by a caching thing along the way ... I added the CSS to that file and I still don't see any changes in my site.
everythingability Mar 10, 2010 11:49 AM
Ah, so turning on debug mode made the changes stick... it's beautiful!
dhiraj Mar 10, 2010 12:50 PM
Yeah, debug mode in CSS is essential to see any changes actually happen (else you have to restart the server).
everythingability Mar 10, 2010 11:50 AM
p.s It's an irksome bug that when commenting you have to click in and out of the comment box to get a "post" button
dhiraj Mar 10, 2010 12:49 PM
Yeah, this is a javascript problem that is causing this. Doing a Ctrl + F5 usually fixes the problem permanently.

It's an intermediate bug (doesn't always happen) that is due to a combination of 2 different event handles (we want to catch focus on the comment textbox to clear the prompt text that we show ("Post a comment"), plus, we want to show the Cancel, Post buttons) and in only some browsers.

We'll re-work this soon.
everythingability Mar 10, 2010 11:51 AM
p.p.s It's an irksome feature that I don't have any styling tools (a bold or bullets would be nice for comments...
dhiraj Mar 10, 2010 08:32 PM
Yes, to date we've not put rich commenting in. This is not planned either, ATM.

Not saying it's not possible, but the approach *is* fraught with difficulty. As you no doubt experienced, commenting is designed to be high-throughput, and that it must remain, above all else.

I must admin though, a little bit of formatting *does* help with breaking up the monotony in a long comment. Some formatting with markdown syntax was actually possible at one point of time with commenting but this was replaced in lieu of auto-URL highlighting within comments (yes, it was unfortunately mutually exclusive at that point of time, and the markdown rendering itself was suboptimal). With some investigation this could perhaps be taken up. All this ultimately drills deep down into Plone's portal_transforms content transformation engine, internally.
everythingability Mar 10, 2010 11:51 AM
p.p.p.s I could go on, and probably will.. :-)
dhiraj Mar 10, 2010 12:45 PM
Please go ahead, we're always looking for feedback and don't worry someone is always at least looking, if not responding immediately!
everythingability Mar 10, 2010 06:12 PM
I'm already impressed with your response... I will then...
everythingability Mar 11, 2010 11:00 AM
It says I can sub-class banners.css but if I do so with other files that my site won't be "upgrade ready". Is this right? Surely I could edit a few other files (by customising them into "custom" and the skin will still work.
dhiraj Mar 11, 2010 11:31 AM
The problem is that we add changes there ourselves, *frequently*. We have purpose-created a banners.css file which we don't touch, and you can safely customize it.

Like for example if you were running v3.1 and had customized plone_custom.css, then you wouldn't get the lovely CSS shadows that we added in 3.1.1 in your installation, because your customized one would not have them.

Instead, you can take a selector from anywhere you want, and add it in and customize away in banners.css - this way you will *override* only any changes you make, while the new stuff we add can keep coming in.
dhiraj Mar 11, 2010 11:33 AM
Also, customizing the other files is dangerous for another reason. A lot of the jQuery, AJAX UI is based on toggling and changing of CSS classes.

So if you inadvertently modify these without knowing what you're doing, you could break the UI a lot more than what you would think is possible! :)
richtelford Nov 25, 2011 01:18 PM
I'm fairly new to Cynin, Plone and Zope... so got a steep hill to climb here but I love what I've seen from Cynin already. I'm editing the banners.css file and added an obvious change body{ border: 5px solid orange; } to make sure I'm editing the correct file. When I saved the changes I can see that it's gone in to the /custom/ folder but I'm not seeing the change on the site. You mentioned a "debug" setting or restarting the server. How do I enable debug mode?