Zikula Network
Subscribe!
RSS Feed
Thoughts about Themes
In last couple of days I dug deep into the Zikula theme system to find some very cool stuff: Themevariables are my latest discovery. But I also found the whole system pretty inconsistent. I know the development team is already working on the (re-)integration of pnRender and Theme. But there is more to it than just combining the two.
When I joined the community in 2002 Postnuke didn't have a templating system. Themes were PHP files containing some functions that consisted of a bunch of "echo()"-calls. Very hard to handle. Every mistake resulted in a PHP error and took down you site.
Xanthia was a great relief: Displaylogic and application logic were finally separated. But themes still weren't 100% portable - Several settings you had to make in the Xanthia administration were lost, if you uploaded a new theme from a test-site to the live site.
Zikula's Theme enginge introduced .ini files to workaround this problem. Setting can be stored in text files and thus weren't lost anymore.
So much for the good bits. But as flexibility grew, new problems arose. One new problem is connected to blocks. Blocks are also a relic of Postnuke's content concept. They contain pieces of content from modules that are not nescessarily at the moment within the focus of attension: If you call the forum, you can display a photo from a gallery next to it. Module have to provide blocks. They are mostly single PHP files with API-calls. In Zikula's blocks administration you can add and enable them. They have to be assigned to "block-positions" that in turn have to be included into theme templates.
In the times of Postnuke our predecessor was notorious for its three colums layouts. You could see at a glance: "This is Postnuke." That was due to the fact that there was a consensus that three columns were great design. Thus all themes contained calls for left, right and center blocks.
Today layouts have to be more flexible with several rows of different column number. Every column in every row is a block position. left, right and center are usually not enough and if you then add to it more block-positions in the different areas of a site (Forums need much space = fewer and different blocks, Frontpage = a lot of blocks for an overview) you end up with a dozen block positions.
Problem A
The blocks administration doesn't automatically recognize which block positions there are in a theme. Thus you have to set up all of them manually - Block positions are not portable.
Problem B
Old Postnuke themes contained an installation file that told the system, which block positions there were - altought they were always the same three: left, right, center. If you take a modern theme that might contain 5 block positions and another one with another 4 positions, you run into a conflict: If they have the same name you can just go on using them. If they have a different name - should they be added? Assume all of the 9 aforementioned positions had different names - should they all be visible in the administration? If yes: How do I know which position belongs to which theme? If no: How do I assign blocks to a theme, that I am currently working on while another one is live?
IMHO the blocks administration should be part of the theme administration. At the moment you can edit a theme in the administration and set themevariables, theme templates for modules and so on. Why not also administer the blocks there? That would also make it easier to run a site with different themes (normal screen + mobile version). Of course it wouldn't be as easy to switch from one theme to another: You download a new theme, install it and before you see much, you have to enable the blocks you already set for another theme.
Of course blocks settings (which block is were) cannot be part of a theme - you never know which modules someone uses who downloads a public theme. So you can't store in a ini-file "Mediashare random-block, posititon "footer-left", second from top.
But the goal is IMHO to be able to download and install a theme and have the correct block positions automatically set up. Integrating the blocks administration into the theme administration after pnRender is included, would result in the nice sideeffect that really all layout-specific setting can be done in a single place.
Share This | Print
Trackbacks
(The URL to TrackBack this entry is: http://blog.zikula.org/index.php?module=TrackBack&id=26,1-49). If your blog does not support Trackbacks you can manually add your trackback by using this form.Comments
I submitted a long time ago about this, it's should be done at milstone 2
http://code.zikula.org/core/ticket/32
Nevertheless, i don't agree with you thinking about the block module, for me, it should stay as it. If you says it's because "you wan't to initiate position in your template", that "block aspect" should be more considered as something like a "hook" for the theme module.
Comment by:
Julian
26 Mar 2009 - 04:26PM
First off... I hate this comment form if you forget to fill the subject you lose your comment. ugh.
--
One thing that always bothered me about postNuke and Zikula was the was that blocks were managed. I found it silly that the content was fixed and that users were stuck with the content admins provided and where they provided it.
Perhaps we should start thinking about blocks as widgets.
If we look at iGoogle we can find an excellent model. Users need only click "add stuff" and select from a list of available widgets, set some settings, and drag and drop them into place.
The admin should be able to enable any number of widgets, set some master settings and then allow users to configure their own homepages.
A while back I built a theme that allowed a user to drag the block divs all around the page and reorder them using ajax and cookies. Users LOVED it!
Imagine the leg-up with respect to usability that this would give Zikula- allowing USERS to control THEIR homepages!
Comment by:
Harr Voß
27 Mar 2009 - 05:08AM
1. Subjects are not mandatory
2. Flexible Layouts are good in community enviroments but IMHO there are plenty of sites that don't need this feature. Which doesn't mean that it shouldn't be supported by Zikula. But as you said: That's pure theming, isn't it? Can you write an article about what you did?
Comment by:
Julian
27 Mar 2009 - 10:32AM
At the moment I'm really really busy but eventually I can assemble something- It's amazingly easy to set it up. In fact it's easier than the "Wiz-Bang Login in Screen"
Still, I'd love to see someone tackle the idea of a module to enable the selective adding and configuration of block-widgets to a homepage... If I were more capable I'd try but, well, um, I'm more of a duct-tape coder... ;)
I certainly can provide some direction, insight, and a road map perhaps (I've been thinking about this for a while) but I'm wouldn't trust myself with the code ;) !!
Oh, and I meant that in this form if you forget to fill in your email or some other fields you lose your message... :(
Comment by:
HalbrookTech
27 Mar 2009 - 02:39PM
I agree with the main article, the theme needs to handle what positions are available. The end user should not have to create block positions to use a theme. This will make it easier for theme designers to make more complex, out of the box themes, and make it easier to cure one of the common complaints about themes.
As to the widget things. I think it's a great idea, but I don't think it necessary should be a core feature, but a module.
Comment by:
Paul Stewart - TakeIT2
31 Mar 2009 - 10:24PM
In response to Problem A:
Automatic addition of block positions would be great.
Not being a php coder, what seemed like a simple idea to me would be an additional line in the theme\version.php that could have a comma separated list of the themes block positions, which when activating the theme are generated for/into the blocks module via a plugin to theme module. each theme maintaining the 3 core positions L,C,R.
That all said, having to add block position names is not such a big fat hairy deal; if the block position doesn't exist it is ignored, and if you have a block positioned in a theme-unique position it is ignored in another theme.
Adding block positions to the blocks module is not the hard part for an end user. Mucking about in the templates is the hard part for the non-dev end-user. A theme that adds block positions would/should/might document them as a "selling" point.
While I agree having all the layout in one place would be great as well.
In Response to Problem B: (which is really several problems...)
Having core positions standard to all themes is a fail safe and answer to the later variations each site will develop with the modules used and whatever blocks they choose. Sure being used to the structure we know we can name/call a block position anything we choose. (the thought that came to mind was naming the block positions after Kama Sutra positions, but I digress) The theme module knowing what position is available would be answered by the statement in the version.php I proposed before.
With multiple themes in use simultaneously, this condition, is the core problem of problem B. The blocks module is capable of assigning the block to multiple positions no problem, untill you want the same block to use a different style for a different theme in a core position. That is answered in the theme module under Page configurations/Page configurations/edit-the-page/block-position/type/instance selectors.
It is the Instance Selector that is hard to grasp. Each theme will handle it's own instances of block removing the Block control from the blocks module on the theme level - but I think it is in the right place for the task.
The real problem is the style is declared in the block module not in themes along side the template in Page configurations/edit-the-page.
"How do I know which position belongs to which theme?" That is your job as an administrator, but again the simple line declaring available positions in a theme could be added as a "Legend" in the theme Page configurations/edit-the-page page in the least or as a configurable selector, (droplist would be tidy.)
"How do I assign blocks to a theme, that I am currently working on while another one is live?" This is where (if you absolutely need to) a very unique block position name is handy in combination with having user selectable themes turned on and having the theme switcher block active, (your permissions set accordingly.) add your block position name in blocks, and set the block additionally to the position, because blocks instances can have multiple positions.
Adding the block position name to the blocks module is really the easy part, then in your theme you tweek the template you want - but the problem I stated before is the style sheet for the block is declared in the blocks module not in the theme module.
Comment by:
Mateo Tibaquirá
07 Apr 2009 - 04:22AM
Hi all!
About problem A:
Well, i don't have clear under which conditions that Xanthia feature works ok: i mean, Xanthia already creates the block-positions found on a new theme, i saw that in the code but i have no idea why it doesn't works always.
Problem B:
Well, i think we need to discuss good practices managing block positions, and filter options more than active/all will be really good in the Blocks Admin Panel. I haven't implemented a site with many themes + many blocks positions, and i know that it requires a big effort and order of the site-admin.
Theme Engine stuff looks amazing to me, .ini file per any section that we want (in pageconfiguration.ini) is awesome, and i guess that it does its job with blocks: assign different templates depending position/type/bid, there's no more attachments from themes about blocks, just their templates...
Comment by:
Cirurgia Plastica
Latest Comments