December 2005 - Development - lists.drupal.org

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

16 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

20 39

Variables, lookups, and memory usage
by Allie Micka 16 Dec '05

16 Dec '05

Hey folks, I've written a lookup module to store and manage generic name/value pairs, organized by "realms". For example: REALM NAME VALUE state MN Minnesota state TX Texas country US United States The basic premise is to keep this type of data in one place, rather than all over the map (e.g. a states table for ecommerce, a states table for something else, so-on.) With the lookup API, any module can stash/get its codes in the table, and it supports importing from a text file. I got used to working this way at my last job (a big Oracle shop - I think this model is called "one true lookup table") I'm considering using this for module settings to save memory. Some of my modules (e.g. send) have lots of settings for email templates, default message text, etc. It's silly to shove all of this into the variables table and haul it around on each page request, when 1 out of 5,000 page views will actually require it. So, I'd add: REALM NAME VALUE send template <html><body>... send message Here's some content from ... I still have a consistent place to stash these settings ( lookup_set () , lookup_get() ), but I only pull them as needed. An overall memory savings, and handy as well. The lookup_get() is functionally similar to the variable_get() function, except that it requires a $realm parameter: lookup_get($realm, $name=null); // without a name, it returns a keyed array of the whole realm My Questions: 1) There's potential overlap with variables and probably other stuff too. Is there a better way? 2) Is it weird to create a confusing-sounding component module like this and require it for other modules? Should this (or a derivative of this) functionality be available in core instead? Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies

6 11

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

16 Dec '05

It's a shame div's can't be controled using PHP arrays. So each module would be able to "tag" it's div's with aggreed upon array values, and ID them to their linking. Then a themer could do $theme_divs['event']['title'], and have that set to the title of the event, no matter what that div was ID'ed. That would, of course, require CSS files to end in *.php (I know of no browser that would mind that, given it's MIME'd correctly) so these variables could be populated. Just an idea I had bouncing around...don't laugh too hard. Robin On 12/15/05, Liza Sabater <blogdiva(a)culturekitchen.com> wrote: > > 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 > > > > > _______________________________________________ > themes mailing list > themes(a)drupal.org > http://lists.drupal.org/mailman/listinfo/themes > -- Merry Christmas! Robin Monks, CSL Web Administrator robin(a)civicspacelabs.org

1 0

Plus ca change, plus c'est la meme chose
by Karoly Negyesi 16 Dec '05

16 Dec '05

The More Things Change, The More They Remain The Same This comment http://drupal.org/node/250#comment-719 is not less than three years old. Yet it sounds so familiar :)

1 0

4.7 bug fix party - this Saturday, December 17 2005
by Moshe Weitzman 16 Dec '05

16 Dec '05

I hope developers and admins and users and QA folks and all drupal community members will participate in our big fixing efforts for 4.7 release. If you can attend our bug fix party this Saturday, that's great. If not, there are still ways for you to help. See http://drupal.org/node/41320 for details. -moshe

1 0

confused: beta-1 release != head?
by Bèr Kessels 15 Dec '05

15 Dec '05

Hi, I am confused, I assumed beta 1 was just following head, in other words beta1 == head. But I am seeing references around of people mentinoing it as a different thing. What is it ? :) Ber -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber(a)jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |

12 20

Drupal 4.7.0 beta2 / rc?
by Dries Buytaert 15 Dec '05

15 Dec '05

Hello world, I wanted to open up a discussion as how to proceed with the Drupal 4.7.0 release schedule. There are two aspects I'd like us to brainstorm about: 1. When do we release a second beta (or a release candidate)? Given the number of critical/annoying bugs we fixed since beta 1 has been released, I think a second beta might be in order. The sooner, the better? 2. The number of bugs that need fixing grows steadily: http:// drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2. How do we encourage more people to help fix bugs? How do we help people fix bugs? I think there is a need for people dedicated to helping Drupal.org users turn forum topics into bug reports, as well as for people dedicated to reviewing, categorizing and harvesting bug reports. Is the problem description clear? Is the problem easy to reproduce? Is it really critical? If not, help them improve their bug report. Replying with one-liners like 'File a bug report!' or 'RTFM' is not considered helping in this context. The goal is to assist, to be helpful, to pull them on board and hopefully to make them "stick". Similarly, I think there is room for people that review patches like teachers would. In short, we need friendly hosts that help people make their first steps in their Drupal career. Suggestions and concrete action points are welcome, -- Dries Buytaert :: http://www.buytaert.net/

17 28

Re: [development] proposal for theming nodes
by Kobus Myburgh 15 Dec '05

15 Dec '05

> I was thinking more along the lines of all theme functions need to > have unit tests, with default text that can be displayed, so that we > can generate entire mockups of sites without needing to add the content. Hmmm... This sounds indeed interesting. I like this! Will this live in a module, or what? Kobus

10 15

Forwarded mail....
by salvador＠progressivetrail.org 15 Dec '05

15 Dec '05

I sent this to support, and was asked to forward it here. I'd like to modify filter.module so that '<br />' are not inserted with linebreaks, but the '<p>' insertions are retained. I had assumed that this was taking place in "function _filter_autop($text)" in filter.module, but after removing every preg_replace call that involved '<br />' tags, (e.g., "$chunk = preg_replace('|<br />\s*|', "\n\n", $chunk);") from that function, I found that drupal was still inserting the unwanted linebreaks. Can someone please tell me where this is happening in drupal? I've been grepping like crazy trying to find it, but without success. Thanks, Salvador

1 0

Re: [development] Re: proposal for theming nodes
by Ken Rickard 15 Dec '05

15 Dec '05

>>It needs love, true, but it sounds like you are re-inventing and already invented module. Ber- No no no. We've modified Node Aggregator to parse RSS _and_ NITF doctypes ( http://nitf.org/) into the database. :-) Thanks for the leg up. -- Ken

1 0