July 2007 - Development - lists.drupal.org

Crossword Puzzle Module for Drupal + Assisted Reading
by Sabine Cretella 13 Jul '07

13 Jul '07

Hi, we are considering to have crossword puzzles for our regional languages and since there are already some Drupal installations in these languages and probably there will be an online newspaper passing over to Drupal in the near future it would be nice to have a Crossword Puzzle Module. This also means: yes, we are working on the localization of Drupal in - Piedmontese: http://pms.i-iter.org/ - Neapolitan: http://nap.i-iter.org/ - Lombard: http://lmo.i-iter.org/ Furthermore a crossword puzzle is also very much an educational product, for example to learn a foreign language. Now there are four ways one would normally create crossword puzzles: *generated out of random expressions (definition + word) *created from a specific terminology set (for students for example) (definition + word) *translation puzzle (word in one language that must be translated into another language) *picture to word puzzle (pictures show what needs to be inserted) The data for the crossword puzzles should be retreived from http://omegawiki.org since there you find a multilingual dictionary under a free license that can indeed handle various kinds of defintions, so the alternate definitions for crossword puzzles are indeed possible. What we don't have right now is the connection to pictures, but this could be solved through an application called instant commons which will make images available with multilingual tags. These images are actually stored on http://commons.wikimedia.org. Besides that I feel that a combination of Drupal with OmegaWiki for certain usages makes sense: only think about the tags attributed to articles ... these tags could be handled in such a way that if someone searches for "dog" on a multilingual Drupal installation he will not only get all articles where you find the term dog, but also all articles that contain the German word "Hund" or the Italian "cane". So if information eventually is not available in one language information in all other languages can be proposed (many people nowadays speak more than one language). Just a note on Assisted Reading: Martin Mai, from the University of Bamberg, created a script that helps us to tag texts with assisted reading. For now the linking is done manually by me. Since we would need this feature as well in Drupal I would just show you what we do now and how we would like to have it work directly from within Drupal: This is an article in Neapolitan language that has the feature: http://www.positanonews.it/menu/default.asp?id=6167&pag=News+%2D+Nutizzie by clicking on the links a small info with dictionary information will open. That is something we would like to see in Drupal as well - it will be needed in universities, schools, in newspapers who want to make their contents accessibile to more people and I can imagine that some very specialised installations also could make use of it to give a better service to their readers. I won't go too deep in all this right now - my actual question is: is there already some kind of module for Drupal around that creates crossword puzzles and therefore could be adapted? If not: which, to your opinion, is the easiest way to get it on its way? And: how to deal with the assisted reading bits and pieces? This e-mail was copied to a group of interested people - as I noted: my e-mail gets into your moderator queue if I copy them all - so here are their names: Bèrto 'd Sèra (i-iter.org) Gerard Meijssen (Open Progress) Antonio D'Urso (PositanoNews) Michele Cinque (PositanoNews) Martin Mai (University of Bamberg, Germany) Kim Bruning (Programs OmegaWiki.org, Mediawiki, OmegaT and others) Giuseppe Lucibello (is very new to our group, php and mysql programmer) Thank you so much for your time and consideration. Best wishes, Sabine Cretella Connectivity and Integration Manager for Open Progress s.cretella(a)openprogress.org skype: sabinecretella blog: http://sabinecretella.blogspot.com

2 1

PHP 4 EOL: 8 August, 2008.
by Gabor Hojtsy 13 Jul '07

13 Jul '07

http://www.php.net/index.php#2007-07-13-1 PHP 4 end of life announcement [13-Jul-2007] Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued. The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5. For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

1 0

Better documentation for working with uploaded files?
by Richard Morse 13 Jul '07

13 Jul '07

Hi! Is there a better source for documentation on how to work with uploaded files than http://drupal.org/node/111782 [the handbook's page]? The list of function for working with files on api.drupal.org is not particularly helpful, and the handbook page is also rather sparse. Specifically, I want to have users upload seven files (all of which must be there), and then save them in a directory *which may not be a subdirectory of the Drupal files directory*. Also, I don't want Drupal's file upload size restrictions to apply for this one use. Or, in this case, would it make sense to just ignore the Drupal file functions and use $_FILES and the php file handling code directly? Would this adversely affect the FormAPI stuff? Would I be able to use a _validate function if I'm not using the Drupal file handling functions? Thanks, Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.

3 4

KEY node_type (type(4)),
by Gerhard Killesreiter 13 Jul '07

13 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The subject is from the CREATE TABLE node statement which we execute at install time. Is there a specific reason to use type(4)? Shouldn't we use type? This is at least inconsistent as use the full type for node_status_type. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlzlHfg6TFvELooQRAkERAKDMXGqHTsxM/gyOoGMGxLsom/6oogCgtKre kUfPKNf84pk7EZ4xAWAJbws= =G8B4 -----END PGP SIGNATURE-----

2 1

function node_page_default
by Keizo Gates 13 Jul '07

13 Jul '07

Hello, I've been reading through the node.module code for a project and came accross the node_page_default function. As far as I can tell this is used for the traditional list of nodes for a drupal homepage. The documentation page is here: http://api.drupal.org/api/HEAD/ function/node_page_default My question is, couldn't this function be made to use just one database query? as it stands it uses node_load() for every node that needs to be displayed on the page so if you want to display 30 teasers, that's 30+ database hits. Am I missing something here? Keizo

2 1

MySQL sandbox: running multiple instances of MySQL
by Augustin (Beginner) 13 Jul '07

13 Jul '07

Hello, The other reason why I didn't take part in Drupal 6 dev, is that it required MySQL 4.1, and my operating system (which is only 1 and a half year old) shipped with MySQL 4.0. I am very bad at OS administration and I constantly delayed upgrading the whole OS (actually, I think I won't upgrade but switch to Debian). Anyway, I obviously needed to at least upgrade MySQL, and I wanted to do so without removing the current MySQL (4.0) just in case I made a mistake (I told you I am bad at OS administration). I searched and found the following utility that could be useful to many of you: ""Installing a side instance of MySQL for testing purpose is a task that many administrators can perform without breaking a sweat [...] If, however, your skills are below the Guru level, even to get this task done just once you may find yourself in trouble[...] It would be nice to have a tool that takes care of the dirty details for you and gets the job done quietly, without interfering with existing installations, and without side effects. Such a tool exists, it’s The MySQL Sandbox. It is a framework for testing features under any version of MySQL from 3.23 to 5.1. Whitout fuss, it will install one server under your home directory, and it will provide some useful commands to start and stop it, and to use it within the sandbox. "" http://mysql-sandbox.sourceforge.net/ http://www.oreillynet.com/databases/blog/2006/05/introducing_the_mysql_sand… download: https://sourceforge.net/projects/mysql-sandbox/ It is very simple to install and use, even for someone like myself! And now, I have one instance of Drupal 6 running on my system: I can start updating my contrib modules anytime! FYI, here is the 'official' way to run multiple instances of MySQL: http://dev.mysql.com/doc/refman/5.0/en/multiple-servers.html Blessings, Augustin.

1 0

Re: [development] Blocks and Regions rethink (concept needs feedback)
by Aaron Winborn 12 Jul '07

12 Jul '07

I think that what you're describing, Barry, would be better understood (by me at least) as a 'sub-region'. Node content is normally displayed within a region, such as the content region by default, or perhaps in a sidebar block (using views). Having a region placed within node content would end up being a potentially recursive function, particularly when combined with Views. I would rather see that in the domain of a special module, as what you've proposed. I would envision it being something like Panels, which defines its own regions outside the theme engine. I do not know how your module handles it, but I can think of several ways to implement what you want without resorting to rewriting any template file, most of which involve hook_nodeapi or filters. Aaron ----- Original Message ----- From: "Barry Jaspan" <barry(a)jaspan.org> To: "Sam Tresler" <sam(a)treslervania.com> Cc: development(a)drupal.org, "Barry Jaspan" <barry(a)jaspan.org> Sent: Monday, July 9, 2007 8:22:54 PM (GMT-0500) America/New_York Subject: Re: [development] Blocks and Regions rethink (concept needs feedback) Sam, I gave a perfectly useful example of a module-provided region: "just before the the Nth paragraph of the body of a node." Many sites want to place ads within body content, and such a region would allow them to do so. The module would not need to provide CSS, just insert the block at the specified location with a class and id tag. The site's style.css would then perform necessary themeing. Another example: "Just after the Nth result in a search or views result page." Again, this would be quite useful for ads. Another example: "In $node->content['my_custom_block'] with a #weight of N." This would show among all the other pieces of a node's content. Another example: "Absolutely positioned on the page at offset X,Y." This might be useful for setting a block as an overlay on top of certain pages. In this case, the module would need the provide its own CSS, but it could do so via the standard drupal_add_css() function. In short, regions are NOT just about themes. A region can be defined (or, rather, should be defineable) within any piece of content with a sufficiently predictable structure and for which a hook exists to allow it to be modified. Thanks, Barry At 11:06 AM 7/8/2007, Sam Tresler wrote: >Barry Jaspan wrote: >>My (fairly simple, I think) desired improvement for Regions is to >>allow modules to declare them, e.g. hook_regions(), instead of just >>allowing the theme to declare them. For example, I'd like to have a >>"Node Regions" module that lets me declare a region "floated left at >>the beginning of the third paragraph of a node's body field"; any >>block could then be added to the region. I've actually already >>written the module but it requires manually editing the theme's >>template.php file. It should not have to. >>I should have submitted a hook_regions() patch for D6 but did not, so >>now I'm just trying to get my pet feature added to your rethink. :-) >>Thanks, >>Barry > >Barry, > >Sorry to be a downer, but that is perhaps the one thing that I >wouldn't want in something like this. And I'm not certain why you >would want it in a module-form, so maybe there is something I'm >missing about what you are saying here. > >If we did anything like that it would need to generate CSS with it, >and also need to be overridable. I can't imagine us hitting upon a >default region design that would be even close to universally useful >to people - if one region is floated left in your node-content >-despite the design its in- every time you enable a module, well, >that would get annoying quick - to always need to overrie it to kill >the module specific region. > >Blocks are just content that can be themed, regions are very theme >specific. We need to keep a solid separation of data and design in this. > >I guess what I'm proposing would be changing both the data stored >(allowing blocks to be cloned and appear in multiple regions) and >the input interface - but not really touching on any block's theme() calls.

1 0

Re: [development] update module
by FGM 12 Jul '07

12 Jul '07

What would be even better would be a way to specify from which server the module comes, using d.o. only as the default: it would allow easier maintenance of custom modules. ---- Original Message ---- From: development(a)robuustdesign.nl To: development(a)drupal.org Subject: Re: [development] update module Date: Wed, 11 Jul 2007 19:32:24 +0200 >While we are at this, is it possible to exclude an module/theme from > >the update_status list? >Say you have a site specific theme, which you do not want to list on > >the update staus list.. Is that possible at all? > >At the moment, my custom themes for drupal 6 are all in the state of > >'No available releases found'. > > > >Stefan

3 4

Templatizing Drupal's Themes: Documentation Proposal
by Earl Miles 12 Jul '07

12 Jul '07

In an effort to convert as much of Drupal's theme_* functions to tpl.php files as possible, I went through and did the forum module's theme functions (I picked those because I knew they'd be more difficult than some other modules). One thing I encountered is that this new system has no documentation standard for tpl.php files. I propose the following items: We should create a themes.php in contributions/docs/developer that contains definitions for theme_* functions that are being converted (or are new and will never have had a theme_* function before). Everything in this file should be @ingroup themeable. It would contain the full documentation for the theme function, including the @params. All .tpl.php files should contain a Doxy syntax @file directive that summarizes the template and lists variables that are commonly available. This list does not need to be exhaustive but it should include the most important variables, at a minimum. It should contain an @see to the template_preprocess function, if it exists, and a @see to the theme_HOOK function in the contrib docs. The template_preprocess_HOOK function should contain a @see to the theme_ function and a list of the arguments (mostly for reference while looking at the function; since the argument to that function will always just be &$variables, it's nice to get a look at what data is coming in). Both of the above should also contain an @see to the .tpl.php file -- however, in api.module, currently @see doesn't work on files. I think api.module could probably be modified to rectify this for us, or another method of referencing the file could work. Here are some examples. Note that I did these before I thought about a theme.php so these aren't updated for that yet, but I intend to. forum_list.tpl.php: <?php // $Id$ /** * @file forum_list.tpl.php * Default theme implementation to display a list of forums. * * Available variables: * - $forums: An array of forums to display. * * Each $forum in $forums contains: * - $forum->is_container: Is TRUE if the forum can contain other forums. Is * FALSE if the forum can contain only topics. * - $forum->depth: How deep the forum is in the current hierarchy. * - $forum->name: The name of the forum. * - $forum->link: The URL to link to this forum. * - $forum->description: The description of this forum. * - $forum->new_topics: True if the forum contains unread posts. * - $forum->new_url: A URL to the forum's unread posts. * - $forum->new_text: Text for the above URL which tells how many new posts. * - $forum->old_topics: A count of posts that have already been read. * - $forum->num_posts: The total number of posts in the forum. * - $forum->last_reply: Text representing the last time a forum was posted or * commented in. * * @see template_preprocess_forum_list() */ ?> Example in api.module: http://drupal.logrus.com/api/file/drupal/modules/forum/forum_list.tpl.php/h… /** * Process variables for forum_display.tpl.php * * The $variables array contains the following arguments: * - $forums * - $topics * - $parents * - $tid * - $sortby * - $forum_per_page * * @see forum_display.tpl.php */ function template_preprocess_forum_display(&$variables) { Example in api.module: http://drupal.logrus.com/api/function/template_preprocess_forum_list/head

1 0

update module
by Dries Buytaert 12 Jul '07

12 Jul '07

Hello world, I just reviewed the update.module once more and finally committed to to CVS HEAD. Kudos to dww and Earl for their hard work. This is an important module in terms of usability, but also for the security of everything Drupal. When security releases are made available, we'll be in a much better shape. If you were to ask me, this means that Drupal is the first Open Source CMS that takes security to the next level and that is not something to take lightly. (This probably warrants a post on the drupal.org front page post but I'll leave that up to dww and/or Earl to write -- if they want.) Great job, -- Dries Buytaert :: http://www.buytaert.net/

5 8