- Development - lists.drupal.org

Book module: should it get in?
by dmitri 30 Jun '07

30 Jun '07

The book module patch does not turn book module into anything it is not ATM. It simply brings it back up to date with what we now have at our disposal (node api and menu api). The book module as it stands now is lacking updates for several years, and so it is based on old code that can be done much more simply now. http://drupal.org/node/146425

1 0

Multilingual Drupal?
by Jose A. Reyero 30 Jun '07

30 Jun '07

Hi, Yes, this is one more of the last-minute -desperate- calls for help about patches in queue for Drupal 6 ... So far, we've made a lot of progress with multilingual features for next version. But there are still a lot of elements that cannot be localized or translated, too many for us to say yet "Drupal is multilingual". This is a very minimum set of -small- patches we'd need, most of them not to have it fully implemented in Drupal core, but to allow contributed modules to hook in and do the job. Then we'll be able to pick the best solutions and fully implement the features, maybe in Drupal 7... - Minimum support for multilingual variables, http://drupal.org/node/155381 Just a few lines of code in variable_get() - Object translation wrapper, http://drupal.org/node/155047 Wrapper for content types, aggregator categories... to allow translation before displaying them - Send e-mail to users in their language, **http://drupal.org/node/82499 Simple mail callbacks to send email in the users language. This is the biggest one on this list. - Adding db_rewrite_sql to blocks query, http://drupal.org/node/155282 One line patch to allow blocks per language And if you have the time, here's the full list with some other features that would be nice to have: http://groups.drupal.org/node/3714 Thank you, Jose A. Reyero

1 0

the fate of deletion API
by Chad Phillips -- Apartment Lines 29 Jun '07

29 Jun '07

as some of you already know, dries is considering rolling back the deletion API patch. for any of you that have an interest in why, or care about it's fate, i'd encourage you to read the exchanges he and i are having on the issue (towards the bottom): http://drupal.org/node/147723 in particular, here is a summary post of why i believe this API should be in drupal 6: http://drupal.org/node/147723#comment-267072

1 0

Re: [development] stripping tags during aggregation?
by Ken Rickard 29 Jun '07

29 Jun '07

Ashraf wrote: > Thanks for the suggestion on how to handle input. Filtering input through > the node filter system sounds ideal. Never would have reached this on my > own. I think this is a good idea for output filtering of feed data. As to your original question: I don't think the aggregation parser should strip tags during feed acquisition. Drupal standard is "store what's entered and filter on output." Filtering tags during feed parsing adds cycles to a potentially expensive process (discussed to death previously). There is, by the way, a feature request for this functionality: http://drupal.org/node/89191. -Ken Rickard agentrickard

1 0

Druplicon is dead! Long live Druplicon!
by Morbus Iff 28 Jun '07

28 Jun '07

I started running Druplicon as a Perl bot in 2005. In late 2006, I started a proof of concept called bot.module. Today, bot_module has officially slayed the Perl beast Druplicon and taken its rightful name: Druplicon, the bot, is now a Drupal module. http://drupal.org/project/bot Along with this are some evolutionary features. Here are the help docs: <Morbus> Druplicon: help Factoids <Druplicon> Set factoids with "BOTNAME: cats are furry", "BOTNAME: Drupal is great.", "No, BOTNAME, Morbus is awesome.", "BOTNAME: Drupal is also powerful.", "BOTNAME: cheer is <action>cheers!", or "BOTNAME: ping is <reply>WHAT?!". Retrieve factoids with: "Drupal?" or "BOTNAME: cheer!" Forget factoids with "BOTNAME: forget ping". Factoids can be browsed online at <http://www.disobey.com/bot/factoids>. <Morbus> Druplicon: help Function Lookups <Druplicon> If api.module is installed, the bot can provide function lookups, triggered by "<function>?", based on the host's installed branches (which must have "short names" that match api.drupal.org) Branches besides the default (currently "5") can be specified with "<function>:<branch>?". Besides the factoids being browseable on: http://www.disobey.com/bot/factoid (which makes it very easy to find crappy factoids to "forget", hint, hint), there is now direct integration with api.module, as originally provided via code from Bdragon. By default, function requests work against the latest release: <Morbus> l? <Druplicon> l: Format an internal Drupal link. => l($text, $path, $attributes = array(), $query = NULL, $fragment = NULL, $absolute = FALSE, $html = FALSE) => http://api.drupal.org/api/5/function/l You'll note that there's now a summary (provided by Doxygen), and that there's no longer a restriction on length (so no more "api-l?"). You'll also note the URL is keyed toward DRUPAL-5. But, consider: <Morbus> l:HEAD? <Druplicon> l: Format an internal Drupal link. => l($text, $path, $options = array()) => http://api.drupal.org/api/HEAD/function/l By specifying "<function>:<branch>", you can get the results of a particular branch. I am currently providing DRUPAL-5 and HEAD, updated daily. DRUPAL-5 is the default (so "l:5?" is the same as "l?"). I will contain to provide (starting with DRUPAL-5), the last two releases and the current HEAD. The default will always be the latest release. I am also pulling from contrib/docs/developer too. Because factoids/infobot and the API lookups are now two different modules, we can annotate particular functions with useful information (assuming we use the default/no-branch version). Consider: <Morbus> t? <Druplicon> t: Translate strings to the current locale. => t($string, $args = 0) => http://api.drupal.org/api/5/function/t <Druplicon> Please be very careful about using !... if you don't want italics, use @ instead! <Morbus> url? <Druplicon> url: Generate a URL from a Drupal menu path. Will also pass-through existing URLs. => url($path = NULL, $query = NULL, $fragment = NULL, $absolute = FALSE) => http://api.drupal.org/api/5/function/url <Druplicon> It will do path aliasing automatically; always use the "real" Drupal URL, not the path alias! Finally, the bot is happy to complain about errors in our Doxygen: <Morbus> drupal_render? <Druplicon> drupal_render: [Doxygen summary is not one line. This is a bug. File core patch.] => drupal_render(&$elements) => http://api.drupal.org/api/5/function/drupal_render Please don't hesitate to file bugs at http://drupal.org/project/issues/bot or bug me about it in IRC. Thanks! -- Morbus Iff ( sleep breeds sanity ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus

4 6

stripping tags during aggregation?
by Ashraf Amayreh 28 Jun '07

28 Jun '07

Hello all, I've recently been going through the question of weather it's useful to preserve the html tags that are part of aggregated content. So rather than dive into this on my own I wanted to see the consensus on this issue from others who probably have more experience in this than I do. If the <content> or <summary> tags in an ATOM feed have an <img> tag I was always pleased to find the image showing up inline in my aggregated content, but what about formatting tags? Allowing arbitrary code could be a herald for XSS attacks as was noted in the a previous thread. Question: Should all tags in aggregated content be stripped? If not, then what tags should be allowed? If I use filter_xss then what tags should I allow? Is there some specification or article on what HTML tags should be allowed to go through? How do aggregation module authors handle this or advise that it be handled? I really appreciate all feedback on this issue. Thanks :)

6 9

Drupal 6 contribs can define a minimum PHP version
by Gabor Hojtsy 27 Jun '07

27 Jun '07

Hello World, Just committed Crell's and dww's patch to add support to Drupal 6 for modules and even themes to specify the minimum PHP version requirements. This allows developers to publish PHP 5 only modules and themes (think XML output for Flex or OpenLaszlo apps in the area of themes, or crazy image manipulation). Anyway, being in the .info files, this will also allow project module to automatically present a compatibility chart for modules and themes. By default, all modules and themes are supposed to be compatible with the present-time minimum PHP requirements of Drupal, if not specified otherwise. Thanks again to Crell and dww for the quick reaction to the ideas popping up! I hope this helps energize the PHP 5 pushing efforts for Drupal 6 contributed functionality. Gabor

1 0

Short downtime tomorrow
by Gerhard Killesreiter 27 Jun '07

27 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, this is to announce a short downtime tomorrow at about 10 am PST (19h MEST, 17h UCT) of about 15 minutes. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGf/gKfg6TFvELooQRAvpmAKC2hZqa6bSeu0oFlSBop1BacSpAWwCdGZTT xnx0dL+4Y21fsH412/PzQBo= =v/4f -----END PGP SIGNATURE-----

3 3

Re: [development] Go PHP 5, Go!
by Karen Stevenson 26 Jun '07

26 Jun '07

I think it's great that there's an effort to get many open source projects behind this. We really do need to get a migration to php5 going, however I do worry about an absolute php 5 requirement since there are so many users that have no real control over what is available to them. Rather than say, 'Drupal 7 is php5 only', why not say 'Works best with php5', then have some really nice features and modules that only work with php5. I think it would be perfectly fine if some core modules and features are php5-only, so long as it is possible to create a basic working site without them. Then add a version test and show php5-only modules as disabled on the modules list with a message that those modules only work in php5 and add help messages wherever there are features that don't work in php4 so users know what they're missing out on. If the php5 features look really good and people want to be able to use them, it still provides pressure on hosts to update to php5. And hosts that provide php5 are going to look much better than hosts that don't. This makes coding more difficult since you have to make sure all basic functionality works with php4 and find ways to carve out php5-only features for special treatment, but it's much less negative than saying php5 or nothing. This discussion reminds me a little bit about discussions on the css mailing list where people who wanted to use cool new css effects would advocate that you should display messages like 'your browser is too old and you need to update it' instead of finding some way to make the site degrade gracefully for old browsers. Anyway, I'm not completely opposed to going php5-only, but I wanted to propose an alternative. Karen ----- Original Message ---- From: Dries Buytaert <dries.buytaert(a)gmail.com> To: development(a)drupal.org Sent: Tuesday, June 26, 2007 2:34:01 AM Subject: Re: [development] Go PHP 5, Go! On 21 Jun 2007, at 08:38, Boris Mann wrote: > Mark my words: a PHP5-only Drupal 7 will leave many, many Drupal > users behind. > > It's OK...every full Drupal update leaves many Drupal users behind > for a significant portion of time. Ponder that :P Except that this time, we risk leaving 70% of the install base behind. The amount of intelligent/constructive feedback to this thread has been surprisingly low. Let's stick to facts and real arguments, please. I'd like to see a _real_ discussion here. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Re: [development] Go PHP 5, Go!
by Ken Rickard 26 Jun '07

26 Jun '07

(Again, missed the whole debate.) Let me remind everyone that the whole GoPHP5 idea was developed in concert with Joomla in order to prevent the problem of one project losing users to the other simply over the PHP4/PHP5 issue. The more people and projects we get on board, the safer our bet becomes. Leveraging PHP5 means more time developing a better application and les time worrying about edge-case support on RASH (nice meme, Boris!). That aside, I think going PHP5 is the best path, and our company already develops for and runs PHP 5.2.x exclusively. - Ken Rickard agentrickard

1 0