December 2005 - themes - lists.drupal.org

Re: Please. Hold on for a second. (was Re: [development] proposal for theming nodes)
by Liza Sabater 16 Dec '05

16 Dec '05

Chris, I am not a developer, so I'd be the worst person to ask to start DIV TAGGING inside modules. Just to explain my previous comments, what I am suggesting is more than just themers asking for a favor from module developers. I believe there is a need for the development group to agree to a standard for 'div tagging' inside modules already in existence and then enforcing it. Again, not everybody is going to move to 4.7. The costs are going to be great to many groups, especially here in the US the political and culture activist groups that have embraced Drupal over Scoop. I guess, I'd have to ask, what does it take for something like this to be happen in Drupal? I am cross-posting to the themes list --we've been remiss in keeping this conversation on both lists. / liza On Dec 15 2005, at 01:31 PM, Chris Johnson wrote: > Liza Sabater wrote: > >> upgraded to 4.7? Is there a way to go back to what is ALREADY >> created and ask module developers to clean what is there based on >> theme parameters that y'all can agree on? Why can't we ask of >> developers to do something as simple as going back to their >> modules and setting DIV TAGS SPECIFIC TO THEIR MODULES? > > Why yes, you can ask module developers to enhance their previous > release (4.6, 4.5, etc.) modules. And if you and some others do > the same, then it would be "we" and it might or might not happen, > depending on the time available to the developer and his or her > inclinations. > > So, by all means, ask! > > No promises, though. :-) > > ..chrisxj > >

2 1

Re: style date differently
by david hodgkins 14 Dec '05

14 Dec '05

While four letter words were used a lot in trying to figure this out, echo wasn't one of them! It worked! Thanks! david (silverwing) Because of the all-important "echo". This should work in node.tpl.php: > > <?php echo format_date($node->created, 'custom', 'D M d Y'); ?> > > -- > David Carrington > > > > > End of themes Digest, Vol 1, Issue 11 > ************************************* >

2 1

Re: style date differently
by david hodgkins 14 Dec '05

14 Dec '05

Just adding that didn't work anywhere. I'm still open to any other suggestions.... > > Message: 1 > Date: Wed, 14 Dec 2005 03:04:35 -0500 > From: erik hopp <drupal(a)mediamutiny.org> > Subject: Re: [themes] style date differently > To: A list for theme developers <themes(a)drupal.org> > Message-ID: <439FD213.8030107(a)mediamutiny.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > try something like this: > > put this at the top of the node.tpl.php or wherever you need it... > > <?php format_date($node->created, 'custom', 'D M d Y') ?> > > hope it helps... i actually have almost no idea what i'm talking about > and its 3am!!!!! > > erik. > > > > > david hodgkins wrote: > > (I've spent a couple hours trying this on my own, but to no avail.) > > > > On my theme Connections, I need to have the date styled differently. It > > should be: > > day date month year, > > Wed Dec 14 2005 or > > D M d(or j) Y > > > > I have no idea what to change, or how to change it. (I have a funny > > feeling that template.php plays a roll in this.) > > > > While I would have loved to come up with an answer on my own, I don't > > think I can. The documentation in the handbook is poor. > > > > The function in the api is at > > http://drupaldocs.org/api/4.6/function/format_date > > > > I'd appreciate it if someone could help me with this. > > > > ~silverwing > > >

2 1

Re: [development] proposal for theming nodes
by Robin Monks 14 Dec '05

14 Dec '05

Mabey we should offer free "learn PHP ultra-quick" ebooks for themers? It's a shame there isn't a way to query variables and other php bits and knowledge from drupaldocs, as well as functions. Robin On 12/14/05, Trae McCombs <occy(a)occy.net> wrote: > > too bad I don't know PHP, as it would be nice for me to comprehend these > theme changes you guys are discussing. I think this is the disconnect > we typically have between themers and developers. > > People will carry on a conversation about something and perhaps it'll > seem like a good idea at the time, until someone finally codes it, and > then we go... "huh"? heh > > I'm simply saying to keep us non-hackers in mind while having all these > discussions. > > Thank you, drive through. > Trae > > > Jose A. Reyero wrote: > > Bèr Kessels wrote: > > > > > >>Hi, > >> > >>way too often i have to hack modules or even core (upload) to make it > *not* > >>append HTML to $node->body. > >> > >>I think this practice of appending stuff to the body is very bad, since > it > >>makes it impossible to add thatdata elsewhere, without duplication. > >> > >> > >> > > > > Yep, I agree, same problem here > > > > > >>I think that teh best option is an additional variable in $node > >>$node->extra > >>containing structured data added by all the modules. > >>$node->extra->upload could, for example contain that uplaod/attachement > table, > >>that is now hardcoded to the body. > >> > >> > >> > >> > > > > First I would like to insist in that *all html* produced should be > > themeable. > > > > About this specific issue, I think we could > > a) Just use themeable functions, that can be overridden, like a > > 'theme_upload_node_body' but, anyway, don't store it into node->body, > > but in node->output or similar > > b) Use that $node->extra->upload you propose but maybe better make it an > > array, $node->extra['upload'] so we can use a simple 'implode' at the > > end. Maybe weights could be useful here too > > > > The ideal would be using both, themeable functions that produce > > structured data, but any of them used separately would just fix the > > problem. However, the way to go, thinking big, would be kind of > > 'generalized form API' that could be useful to build any object -page, > > block, node..- as structured data and then render it to HTML. > > > > > >>Waht do others think > >>Bèr > >> > >>PS: Im not to sure about tis crossposting thing, but there are loads of > theme > >>and developers issues; is it safe to assume that interested parties at > least > >>read development? (so that we can keep this on development) > >> > >> > > > > > > -- > Trae "occy" McCombs || http://occy.net/ > Founder - Themes.org // Linux.com > CivicSpaceLabs - http://civicspacelabs.org/ > -- Robin Monks, CSL Web Administrator robin(a)civicspacelabs.org

1 0

proposal for theming nodes
by Bèr Kessels 14 Dec '05

14 Dec '05

Hi, way too often i have to hack modules or even core (upload) to make it *not* append HTML to $node->body. I think this practice of appending stuff to the body is very bad, since it makes it impossible to add thatdata elsewhere, without duplication. I think that teh best option is an additional variable in $node $node->extra containing structured data added by all the modules. $node->extra->upload could, for example contain that uplaod/attachement table, that is now hardcoded to the body. In the very very end, the theme_node will iterate over all these ->extra 's and append them to teh body. Now, the code, the patch, should not be too hard to make, its just a few lines to the theme_node functions The hard part, imho is to convert **all** core modules to use this. and with All i mean all :). Taxononomy, for example, should add its terms in there, while book module should add its navigation. The other thing is, that while this annoys me a huge lot, i just don't have time to get a patch going, untill at least end of Januari. Waht do others think Bèr PS: Im not to sure about tis crossposting thing, but there are loads of theme and developers issues; is it safe to assume that interested parties at least read development? (so that we can keep this on development) -- PGP ber(a)webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels(a)gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc

1 0

style date differently
by david hodgkins 14 Dec '05

14 Dec '05

(I've spent a couple hours trying this on my own, but to no avail.) On my theme Connections, I need to have the date styled differently. It should be: day date month year, Wed Dec 14 2005 or D M d(or j) Y I have no idea what to change, or how to change it. (I have a funny feeling that template.php plays a roll in this.) While I would have loved to come up with an answer on my own, I don't think I can. The documentation in the handbook is poor. The function in the api is at http://drupaldocs.org/api/4.6/function/format_date I'd appreciate it if someone could help me with this. ~silverwing

2 1

Rapid Theme Development was: Re: [development] Administration Survey: Theme improvements, theme help system, theme mailing list
by andre 14 Dec '05

14 Dec '05

Sorry for the cross post - but I thought I would move this discussion to the theme list. Dries Buytaert wrote: > Having to create a Drupal theme really turns me > off. > > Making it easier to create a unique, good-looking theme in a matter of > hours is a key challenge for the Drupal community. Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass. But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time. And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules. andre ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

7 8

Drupal 4.7 themes are now being packaged
by Dries Buytaert 08 Dec '05

08 Dec '05

Hello world, the package scripts and project module at drupal.org have been updated to package contributed themes that are branched with the DRUPAL-4-7 tag. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Re: [themes] Disappearing, Reappearing text in IE
by Kobus Myburgh 06 Dec '05

06 Dec '05

This definately is an IE bug - I am having this on my site as well. I am busy implementing Eric's proposed solution on my site. I'll give feedback as soon as I can! Kobus >>> occy(a)occy.net 12/6/2005 3:35:09 AM >>> I'm sure it's an IE bug, try adding position:relative to the element. Trae Tao Starbow wrote: > I had a similar problem with a CSS & nested-divs based rounded corner > design. In the end I admitted temporary defeat and fell back to tables. > So, I am interested in tips on this as well. > > -t > > erik hopp wrote: > >> Hi. >> >> I'm working on a project and we are running into a CSS problem where >> in Windows / IE6, on some pages and at some spots, the text will not >> show up when you load the page, however, if you highlight the text it >> appears. i have seen this before and have read a little about it but >> i was wondering if anyone has foung a solution. >> >> This seems promising, but i haven't gotten a chance to try it yet and >> i am wondering if anyone has: >> http://www.zeldman.com/daily/0103d.shtml#tweaks >> >> thanks for any help! >> >> e. >> >> > _______________________________________________ > themes mailing list > themes(a)drupal.org > http://lists.drupal.org/mailman/listinfo/themes -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ _______________________________________________ themes mailing list themes(a)drupal.org http://lists.drupal.org/mailman/listinfo/themes

2 1

CSTheme - What to do, How to proceed?
by Trae McCombs 06 Dec '05

06 Dec '05

Below is an email I sent to someone discussing what to do with the future of the CivicSpace Theme. Feel free to comment and add ideas. In addition to #drupal-themes I also have a channel for the development and building of the CivicSpace Theme. I feel a lot of these ideas could actually serve ultimately to make for a base Theme all developers start building "Layouts" and "Skins" from. ... I wanted to layout the different tasks that are ahead of us on this CSTheme revamp. Objective: Rebuild the CivicSpace Theme so it is a solid base for building other themes on top of. Background: So, to make sure we are on the same page, currently the way we have things setup is this. - current setup - Base CivicSpace Theme - visual.css, layout.css, others... Layout - layout.css(OVERRIDES MAIN layout.css) + Pulls main CSTheme styling in Skin - custom.css(OVERRIDES MAIN visual.css) + pull Layout stuff. - proposed setup - Base CivicSpace Theme - no visual.css or layout.css Layout - layout.css (Setups up the way this layout is presented) * dictate CLASS SOURCE ORDERING??? [see below] Skin - custom.css (pulls in Layout from it's Parent Layout) Tasks: 1. Class ordering I think it would be important if there were some way a Themer could do source ordering or structuring of classes in page.tpl.php I have NO idea how this would work, but. Example: HTML: <div id="header"><h1>header</h1></div> <div id="menu"><h1>menu</h1></div> <div id="content"><h1>content</h1></div> <div id="sub-section"><h1>sub-section</h1></div> <div id="footer"><h1>footer</h1></div> Let's say a themer wanted to shuffle these around so they could achieve a different layout. It would be nice if there was some way we could accomodate these changes. Depending on floats and what-not, people might want these id's to show up in different places. How can we accomodate these different positions? You do understand we'll have layouts in the "layouts/" directory. Is there a way we could pre-configure all the different combinations of our CSS major classes: example: 1 - header, menu, content, sub-section, footer 2 - menu, header, content, sub-section, footer 3 - This doesn't work either, as that could easily lead to well over 125 combo's alone. :/ There needs to be a way where people could, in perhaps their style.css of thier Layout file put something like: #HEADER,#MENU,#CONTENT,#SUBSECTION,#FOOTER (proper names of course, these are just examples) And then it orders the areas according to what is found in that file? Does that make sense? So your Layout file has something like: /* CIVICSPACETHEME ORDERING */ /* #CONTENT,#MENU,#HEADER,#SUBSECTION,#FOOTER */ /* * =Republica Layout */ body { foo } Does that make sense? And by default, if there wasn't any SOURCE ORDERING stuff present, then it would use the default method. This makes total sense to me, but then again... heh, what do I know?[tm] This also seems like it could be the proper setup for a Wizard to allow people to change areas. Not that we are even talking Wizard stuff now. ... 2. Default Skin Selection Currently, to my knowledge, and the guy who was working on CivicSpace Theme before me (Chris Messina), there is no way to "call" the skin you want to be the default skin, in a way that Drupal will understand. We need to get visual.css out of the base CSTheme directory, and put it in an actual Skin. As well as any other CSS that may get called in the default BASE setup. All of these need to be on a per-Skin basis. ... 3. custom.tpl.php This might be a future feature, but if it's easy to add, I don't see why we don't add it now. The Problem If people want to add custom php to their theme, a lot of time they hack up the page.tpl.php file. When they do this, they break from the default CivicSpace Theme distro and make themeselves Non-upgradeable. If there was a call to say a custom.tpl.php file, that we did NOT ship, but simply refered to, then they could put all of their custom php inside this file and not have to worry about it upon upgrading. ... 4. Javascript calls [on/off] I think we should probably have a javascript.tpl.php that ships with the CSTheme. What we do is, we take all of the javascript crap out of page.tpl.php, and include a toggle switch or config or something that makes it easy for people to enable or disable the javascript stuff in the theme. I personally completely dislike any javascript to load in my themes. I want clean, fast and clear of junk. ... In conclusion, I think these fixes should probably be easy to do. But then again, I don't know how to code do I? ;) Jeremy, please hop on #cstheme if you can from time to time so we can work on some of these issues. Thanks bunches. Trae PS. I think this would be a good email to send to CS-Dev and the Drupal Themes mailing list. What about you guys? -- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/

5 9