June 2007 - Development - lists.drupal.org

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

Re: [development] PHP 5 > aggregator.module rewrite to XML API?
by Ken Rickard 26 Jun '07

26 Jun '07

All- (I was offline for a week and missed the whole debate.) I'm one of the mentors for Aron Novaak's Summer of Code project, so let me clarify a few issues/goals. 1) Everyone should please comment on his wiki pages ( http://groups.drupal.org/rss-aggregation) 2) The target is a lightweight Aggregator for Drupal core, working in Drupal 5 as a contributed module, with expectations that it will remain contrib for Drupal 6 and become core in Drupal 7. 3) The API element is the fundamental improvement, allowing different sites to enable or disable features and methods as needed. Remember that one of those features (and the reason Robert and I drafted the first API spec) was to allow non-administrative users to safely add feeds. Those users will expect the behavior of iGoogle or MyYahoo, where feeds just work (or gentle errors are given when the user makes a blatant error). 4) From a Google perspective, code review, benchmarking, and design feedback (such as Morbus' comments on the schema) are all acceptable. Inevitably, Aron will be taking code from several existing projects, so feel free to contribute patches, etc. to his project. I don't believe they will violate the terms of his project, and I write the evaluations. What he's trying to do is unite the Aggregators in a way that is useful to the community, so part of his project will be building consensus and coordination of resources. 5) There are some Aggregator core patches waiting for some review love before code freeze, too: http://drupal.org/node/43245 (make blocks optional) http://drupal.org/node/61456 (fix special characters in titles) - Ken Rickard agentrickard

1 0

Deletion API hits core
by Chad Phillips -- Apartment Lines 25 Jun '07

25 Jun '07

well, after three development cycles, i've apparently written something worth committing for Drupal's deletion system... ;) thanks to all the folks who helped it along, esp. chx and steven -- couldn't have done it w/o you! now, on to other matters: upgrade docs are done, and here: http://drupal.org/node/ 114774#deletion-api a complete writeup on the API is here: http://drupal.org/node/153904 hook_delete_pre() and hook_delete_alter() have been added to the developer docs in contrib. the new functions are on api.drupal.org in HEAD. their formatting is a bit crappy, and i'm not sure if that's an api module bug or something i did. at any rate they're usable, and i'll look into getting them prettier in a bit. :) currently, only node and comment deletions use the API in core. we have about 8 days until the code freeze, so i wanted to get opinions on what else in core we might want to try and convert. IMO, the one that should definitely get converted is user deletions, which i'm happy to write. anybody else have thoughts on other important areas that we should focus on before the code freeze??

6 5