drupalcore

Events happening in the community are now at Drupal community events on www.drupal.org.
beautifulmind's picture

Newsletter in core

How about integrating newsletter feature in Drupal core which can be turned on/off?

Regards.

Read more
Rosamunda's picture

Can we ever get a usable community site out of the box with Drupal? (Theorical question, opinions wanted)

Hi there!

I´ve been around this group for a while, and there have been a lot of new "drupal-for-2.0-community" stuff lately.
Anyway, there´s this thing that´s bothering me since I´ve started to get my hands dirty with Drupal, and I really need to hear what you think about:
Drupal core profiles: They are not able to be managed as nodes (duh!), and you always need some contrib module to do that for you. Can we get a usable out of the box community site?

Read more
joachim's picture

Generalizing node context

Been sitting on this idea for a while: curious to see what people think.
In a nutshell, the idea is to combine and generalize the various flags for a node that are available in node.tpl.php, and open them up to modules.

For example, instead of the $is_front, $page, $sticky, and $teaser booleans, you'd have an array with entries present if the flag is true. Something like this, for example:

  $context = array(
    'teaser' => array(),
    'sticky' => array(),
    'page' => array(),
    );

Core would take care of shoving those keys in; other modules would given a chance to add their own to a node.

That's the plan. Here's why I think it's cool:

Read more
robertdouglass's picture

Time to move away from timestamp?

In my opinion, the use of timestamps for the representation of dates in Drupal core is problematic. It is fine for recording all events that happen now, and it is even fine for recording historical events, as long as they happened 1970 or later. They are utterly useless if you want to make a geneology site.

More disturbingly, the event module also relies on timestamps for representation of events. As far as I can tell, this is a huge limitation. The CCK date field uses the ISO 8601 standard which saves times as as string: 20060610T20:47:48+01:00. While there are lots of arguments about how the data should be persisted in the database, to me, it is clear that the ISO 8601 string is ideal for representing the date in Drupal code (unless you're doing archeology, then I've got no idea what you do with BC dates).

Read more
Subscribe with RSS Syndicate content