March 2005 - Development - lists.drupal.org

[drupal-devel] Changing node type
by Maykel Moya 07 Apr '05

07 Apr '05

I'd several post of type page, but now, I need to switch them to type book in order to make them sorteable by weigth and not only by posting date. It's safe to change the node type in the database from page to book ? In case it don't, could you suggest please a manner to achieve switching node type. Regards maykel -- ,''`. Debian GNU/Linux : :' : The universal & free Operating System `. `' El Sistema Operativo universal y libre `- http://www.debian.org/

6 8

[drupal-devel] [feature] Multiple translations of the same strings
by Olen 04 Apr '05

04 Apr '05

Issue status update for http://drupal.org/node/19425 Project: Drupal Version: cvs Component: locale.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Olen Updated by: Olen Status: patch In many langages the same english string can (and should) be translated differently, depending on context. Here are two patches, one for locale.inc and one for locale.module that allows the same string to be translated more than once. It adds the correct path (filename) and line number of the translated string as "location" instead of the url where it was first seen. It will also allow you to download the .po-file for only one module at the time. These two improvements makes it a lot easier to find the correct context for the translation. It will use a "best effort" when finding translations, first trying to match on file:line, then only file and at last, any translated string with the same 'source'. Be aware that the first few page loads after a new translation is added are really slow, until the database has been updated with all the new strings and locations. Also note that this will lead to several "unused" strings in the database. I have an idea about some sort of timestamp to check when a string was last used, and a cron job that removes old, unused strings, but I think this could cause more problems than it fixes. Anyway, here are the patches. Let me know if you want them as attachments instead. locale.module: --- locale.module.orig 2005-03-23 08:42:29.000000000 +0100 +++ locale.module 2005-03-25 10:10:39.180616160 +0100 @@ -142,29 +142,67 @@ // We don't have this translation cached, so get it from the DB else { - $result = db_query("SELECT s.lid, t.translation FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid WHERE s.source = '%s' AND t.locale = '%s'", $string, $locale); + $caller = debug_backtrace(); + $docroot = realpath($_SERVER['DOCUMENT_ROOT']); + $file = ereg_replace($docroot, '', $caller[1]['file']); + $basefile = basename($file); + $line = $caller[1]['line']; + $origstring = $string; + $result = db_query("SELECT s.lid, s.location, t.translation FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid WHERE s.source = '%s' AND t.locale = '%s'", $string, $locale); // Translation found - if ($trans = db_fetch_object($result)) { + while ($trans = db_fetch_object($result)) { if (!empty($trans->translation)) { - $locale_t[$string] = $trans->translation; - $string = $trans->translation; + if ($trans->location == "$file:$line") { + // We have 100% match + $locale_t[$string] = $trans->translation; + $string = $trans->translation; + $match = $trans->lid; + $rate = 100; + break; + } + elseif (eregi($basefile, $trans->location) && ($rate < 100)) { + // We have a match in the same file, but on a different line + $locale_t[$string] = $trans->translation; + $string = $trans->translation; + $match = $trans->lid; + $rate = 75; + } + elseif ($rate < 50) { + // We have a match in another file + $locale_t[$string] = $trans->translation; + $string = $trans->translation; + $match = $trans->lid; + $rate = 50; + } + } + } + // We have a translation, but not a full file:line match + if (($match) && ($rate < 100)) { + // Lets update source and target with the correct location + db_query("INSERT INTO {locales_source} (location, source) VALUES ('%s', '%s')", "$file:$line", $origstring); + if ($locale) { + $lid = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s' AND location = '%s'", $origstring, "$file:$line")); + db_query("INSERT INTO {locales_target} (lid, locale, translation) VALUES (%d, '%s', '%s')", $lid->lid, $locale, $string); } } // Either we have no such source string, or no translation - else { - $result = db_query("SELECT lid, source FROM {locales_source} WHERE source = '%s'", $string); - // We have no such translation + elseif (!$match) { + $result = db_query("SELECT lid, source FROM {locales_source} WHERE source = '%s' AND location = '%s'", $origstring, "$file:$line"); if ($obj = db_fetch_object($result)) { if ($locale) { - db_query("INSERT INTO {locales_target} (lid, locale) VALUES (%d, '%s')", $obj->lid, $locale); + $trans = db_fetch_object(db_query("SELECT lid FROM {locales_target} WHERE lid = '%d' AND locale = '%s'"", $obj->lid, $locale)); + // We have no such translation + if (!$trans) { + db_query("INSERT INTO {locales_target} (lid, locale) VALUES (%d, '%s')", $obj->lid, $locale); + } } } // We have no such source string else { - db_query("INSERT INTO {locales_source} (location, source) VALUES ('%s', '%s')", request_uri(), $string); + db_query("INSERT INTO {locales_source} (location, source) VALUES ('%s', '%s')", "$file:$line", $string); if ($locale) { - $lid = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s'", $string)); + $lid = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s' AND location = '%s'", $string, "$file:$line")); db_query("INSERT INTO {locales_target} (lid, locale) VALUES (%d, '%s')", $lid->lid, $locale); } } @@ -410,7 +448,7 @@ include_once 'includes/locale.inc'; switch ($_POST['op']) { case t('Export'): - _locale_export_po($_POST['edit']['langcode']); + _locale_export_po($_POST['edit']['langcode'], $_POST['edit']['filename']); break; } print theme('page', _locale_admin_export_screen()); And for locale.inc --- locale.inc.orig 2005-03-23 18:03:27.000000000 +0100 +++ locale.inc 2005-03-25 09:58:22.433809358 +0100 @@ -176,11 +176,9 @@ if ($key == 0) { $plid = 0; } - $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s'", $english[$key])); + $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s' AND location = '%s'", $english[$key], $comments)); if ($loc->lid) { // a string exists $lid = $loc->lid; - // update location field - db_query("UPDATE {locales_source} SET location = '%s' WHERE lid = %d", $comments, $lid); $trans2 = db_fetch_object(db_query("SELECT lid, translation, plid, plural FROM {locales_target} WHERE lid = %d AND locale = '%s'", $lid, $lang)); if (!$trans2->lid) { // no translation in current language db_query("INSERT INTO {locales_target} (lid, locale, translation, plid, plural) VALUES (%d, '%s', '%s', %d, %d)", $lid, $lang, $trans, $plid, $key); @@ -198,7 +196,7 @@ } else { // no string db_query("INSERT INTO {locales_source} (location, source) VALUES ('%s', '%s')", $comments, $english[$key]); - $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s'", $english[$key])); + $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s' AND location = '%s'", $english[$key], $comments)); $lid = $loc->lid; db_query("INSERT INTO {locales_target} (lid, locale, translation, plid, plural) VALUES (%d, '%s', '%s', %d, %d)", $lid, $lang, $trans, $plid, $key); if ($trans != '') { @@ -213,11 +211,10 @@ else { $english = $value['msgid']; $translation = $value['msgstr']; - $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s'", $english)); + $loc = db_fetch_object(db_query("SELECT lid FROM {locales_source} WHERE source = '%s' AND location = '%s'", $english, $comments)); if ($loc->lid) { // a string exists $lid = $loc->lid; // update location field - db_query("UPDATE {locales_source} SET location = '%s' WHERE source = '%s'", $comments, $english); $trans = db_fetch_object(db_query("SELECT lid, translation FROM {locales_target} WHERE lid = %d AND locale = '%s'", $lid, $lang)); if (!$trans->lid) { // no translation in current language db_query("INSERT INTO {locales_target} (lid, locale, translation) VALUES (%d, '%s', '%s')", $lid, $lang, $translation); @@ -662,7 +659,7 @@ while(strlen($comm) < 128 && count($comment)) { $comm .= substr(array_shift($comment), 1) .', '; } - return substr($comm, 0, -2); + return trim(substr($comm, 0, -2)); } /** @@ -689,18 +686,37 @@ } /** + * Get a list of all files with at least one translatable string + */ +function _locale_active_modules() { + $loc = db_query("SELECT location FROM {locales_source}"); + $filenames[''] = t('All files'); + while ($locat = db_fetch_object($loc)) { + $basename = basename(preg_replace('/:.*/', '', $locat->location)); + if ($basename) { + $filenames[$basename] = $basename; + } + } + ksort($filenames); + return $filenames; +} + +/** * User interface for the translation export screen */ function _locale_admin_export_screen() { $languages = locale_supported_languages(FALSE, TRUE); $languages = array_map("t", $languages['name']); unset($languages['en']); + $filenames = _locale_active_modules(); + $output = ''; // Offer language specific export if any language is set up if (count($languages)) { $output .= '<h2>'. t('Export translation') .'</h2>'; $form = form_select(t('Language name'), 'langcode', '', $languages, t('Select the language you would like to export in gettext Portable Object (.po) format.')); + $form .= form_select(t('File name'), 'filename', '', $filenames, t('Select the file you would like to export strings from.')); $form .= form_submit(t('Export')); $output .= form($form); } @@ -719,13 +735,21 @@ * * @param $language Selects a language to generate the output for */ -function _locale_export_po($language) { +function _locale_export_po($language, $filename = NULL) { global $user; + if ($filename) { + $filename = "/%$filename%"; + $sort = '(substring_index(s.location, ":", -1)+0)'; + } + else { + $filename = '/%'; + $sort = 'substring_index(s.location, ":", 1), (substring_index(s.location, ":", -1)+0)'; + } // Get language specific strings, or all strings if ($language) { $meta = db_fetch_object(db_query("SELECT * FROM {locales_meta} WHERE locale = '%s'", $language)); - $result = db_query("SELECT s.lid, s.source, s.location, t.translation, t.plid, t.plural FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid WHERE t.locale = '%s' ORDER BY t.plid, t.plural", $language); + $result = db_query("SELECT s.lid, s.source, s.location, t.translation, t.plid, t.plural FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid WHERE t.locale = '%s' and s.location like '%s' ORDER BY t.plid, t.plural, $sort, s.source, s.lid", $language, $filename); } else { $result = db_query("SELECT s.lid, s.source, s.location, t.plid, t.plural FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid GROUP BY s.lid ORDER BY t.plid, t.plural"); @@ -750,7 +774,14 @@ // Generating Portable Object file for a language if ($language) { - $filename = $language .'.po'; + if ($filename) { + $filename = preg_replace('/[^A-z0-9\.\-_]/', '', $filename); + if (!$filename) { + $filename = 'all'; + } + $filename .= '.'; + } + $filename .= $language .'.po'; $header .= "# $meta->name translation of ". variable_get('site_name', 'Drupal') ."\n"; $header .= '# Copyright (c) '. date('Y') .' '. $user->name .' <'. $user->mail .">\n"; $header .= "#\n"; Olen

4 9

[drupal-devel] [feature] Let other module use the block matcher
by chx 04 Apr '05

04 Apr '05

Issue status update for http://drupal.org/node/19694 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/blocks_regions.patch (1.74 KB) This patch makes sure that block.module deals by default only with regions 0 and 1 as it does now but lets you use block_list with any region you define. This opens many possibilites. You may do a multi region module, with your admin UI using the blocks table as storage and the block_list matcher. Or you may do a sections module using the block matcher without cluttering the current blocks list. block_list has a phpdoc: * @param $region main|left|right but I have not found anything regarding 'main' so I changed this to left|right|all where all means (left or right). As the current block module would treat 'main' the same as 'right' I doubt it had any usage. In short: no functionality is harmed, lots of possibilities are opened, so please commit. chx

3 5

[drupal-devel] Plain-text checking / text output in Drupal
by Steven Wittens 03 Apr '05

03 Apr '05

I just committed the large check_plain() patch after a green light from Dries: http://drupal.org/node/18817 The main idea is to make sure plain text is handled as plain text... so you can use <> or & in a taxonomy term name or comment subject, and not mess up validation or your site. This should've in fact already been okay, but it seems due to general confusion on what the right way was many people didn't pay much attention to it. After my patch, every single-line field should be plain-text in Drupal, including in particular node/comment titles, which used to be stored as stripped HTML instead (which was really bad for usability, see the issue for more info). A few notable changes: - drupal_specialchars() and check_form() have been merged into check_plain() - node and comment titles are now plain-text and need to be check_plain()'ed before output. Note that due to changes in l(), many cases will be caught already. - theme('placeholder', $text) was added for putting dynamic pieces of text into a sentence ("are you sure you want to delete %block"). It outputs '<em>'. check_plain($text) .'</em>' by default and should be used when appropriate. I've written up a short text on text output in Drupal after my patch... once it's cleaned up a bit, it should go into the documentation somewhere. I'll also add a short blurb to the module upgrading guide. Steven ------------- Text output in Drupal When handling and outputting text to HTML, you need to be careful that proper filtering or escaping is done. Otherwise there might be bugs when users try to use angle brackets or ampersands, or worse you could open up XSS exploits. When handling data, the golden rule is to keep exactly what the user typed. On the database and input side of things there isn't much to worry about. Text remains text. Note that you should never use a plain strip_tags() call to clean up user input. This would strip out all tags, but still force you to use entities for angle brackets or ampersands. You get all the disadvantages of HTML without any benefits. Conversion is done on output where the text has to be placed in another format/context, e.g. HTML. There are two types of text in Drupal: 1. Plain text _____________ This is simple text without any markup. What the user entered is displayed exactly on screen as is, and is not interpreted in any form. This is almost always the format used for single-line text fields. It is good to keep this consistency in your own code. When outputting plain-text, you need to pass it through check_plain() before it can be put inside HTML. This will convert quotes, ampersands and angle brackets into entities. Most themable functions and APIs take HTML arguments, but there are a few which already have check_plain() in it for convenience: * l(): the link caption should be passed as plain-text (unless overridden with the $html parameter). * menus: the menu item titles are plain-text. * theme('placeholder'): the placeholder text is plain-text. Some places require HTML which might not be obvious: * page titles set through drupal_set_title(). The page title is displayed in the HTML, where it makes sense to use tags like <em> for clarity. When the page title is displayed in the HTML <title> tag however, all tags will be stripped out. * block titles passed in through hook_block(). For the same reason as the page title, using HTML here is commonly done. Note that functions which logically take 'data' and not 'output' will almost always take plain-text and require no escaping on your side. A good example is the value passed to form_ functions, e.g. a plain-text field's contents. What the user entered is exactly what you should pass to form_textfield. On the other hand, this does not count for the form item's title or description, which are passed as HTML. This is done so that modules can format the item title as they want. 2. Rich text ____________ This is text which is marked up in some language (HTML, Textile, etc). It is stored in the markup-specific format, and converted to HTML with the various filters that are enabled. This is almost always used for multi-line text fields. All you need to do is pass the rich text to check_output() and you'll get HTML returned, safe for outputting. You should also allow the user to choose the input format with a format widget through filter_form() and should pass the chosen format along to check_output(). URLs ____ A note about URLs. URLs require special handling in two ways: - Putting dynamic data into URLs. If you wish to put any sort of dynamic data into an URL, you need to urlencode() it. If you don't, characters like # will disrupt the normal URL semantics. urlencode() will escape them with %XX syntax. - Putting URLs into HTML. URLs are a common attack vector for XSS exploits. Though we have an XSS filter at the beginning of the page request, it is still smart to be careful. When putting an URL inside an HTML attribute (e.g. <a href="...">), you should pass it through check_url(). Check_url() is similar to check_plain(), but it contains some extra XSS protection. Note that all Drupal functions which return URLs (url(...), request_uri(), etc.) output 'real' URLs which have not been HTML escaped in any way. Remember to use check_url() to escape them when outputting HTML (or XML). Don't use check_url() in situations where a real URL is expected, e.g. in the HTTP 'Location: ...' header. In practice ___________ If this sounds all confusing, there are only a limited number of functions where this is important, and you will easily get to know them. Usually you control your own output in your module so the output process is quite transparent. Every piece of plain-text should be converted with check_plain() once before going into HTML. When in doubt, you can always put some test text like "<u>foo</u>" in your text fields, and see how it comes out. For plain-text fields, the underline tag should not be interpreted, but displayed as is. When displaying a piece of user-submitted text in a message, you should pass it through theme('placeholder', $text) to make it stand out. It will also escape the text for you with check_plain(). Note that you cannot pass HTML entities to functions which accept plain-text. If you need to use high Unicode characters in a plain-text string, input them directly in the code with UTF-8 encoding. It's more compact as well.

6 6

[drupal-devel] Is anybody doing any major work on subscriptions module?
by Robert Douglass 03 Apr '05

03 Apr '05

Hi all, I began rewriting the subscriptions module a bit today and wanted to check here if anyone else was also working on it? It would be a shame to double our efforts. Here is what I've done so far: You can now subscribe to nodes, users and categories (was nodes, blogs(?) and categories). The /subscriptions screen where all of the nodes and all of the terms for the entire site were listed in one gigantic table is gone. In its place is a screen with three tabs; categories, users, content. The categories tab lets you subscribe using normal select boxes. Content and users tabs only show you your subscriptions and offer you the chance to unsubscribe. I don't think it is a good idea to use these screens as a means for subscribing to nodes and users. Each node has the links (un)subscribe content, (un)subscribe user. Users can decide whether they want immediate notification or digest notification at an admin specified interval. What I hope to finish tomorrow is the digest mailing, the admin screen, and placing a lind (un)subscribe user on each user's page. I will introduce hook_cron to handle digest mailing and probably a second table to store the digest mails between crons. The original subscriptions table is unaltered and a smooth upgrade will be possible. cheers, Robert

10 15

Re: [drupal-devel] some drupal stats
by K B 01 Apr '05

01 Apr '05

Dries, Let me be among the first to respond to this. I personally do not mind it, if it makes money for the Drupal Foundation non-profit organization (you are registering it soon, right? :-), AND that it is ethically acceptable. By ethically acceptable, I mean that it is completely disclosed to all developers and users of Drupal, and that it is not mandatory (users can disable it if they want). No sneaky business like the .css trick used by Wordpress, or a link farm, ...etc. I am not sure what they exactly mean by "integrate AdSense support into Drupal". Do they just want us to make the Drupal default page for the admin to has a link to signup for Adsense? A standard block for Adsense? As long as it is fully disclosed and can be disabled, I do not see anything wrong with a voluntary referral program, since this is effectively what it is. On the other hand, look at this from another angle: Google sees Drupal as important. I have no idea if they made that offer to other blogging software as well or not, but that makes me feel good to be part of the Drupal community. --- Date: Thu, 31 Mar 2005 22:51:51 +0200 From: Dries Buytaert <dries(a)buytaert.net> Subject: Re: [drupal-devel] some drupal stats To: drupal-devel(a)drupal.org, boris(a)bmannconsulting.com Message-ID: <d6c69f7c34744dad259733d3bffb771d(a)buytaert.net> Content-Type: text/plain; charset=US-ASCII; format=flowed > However, on the making-money-for-the-project angle....Dries, do you > want to bring up the Google issue? I don't have the details at hand here so I'd rather bring it up when I'm back in Belgium. Unfortunately, I guess that is too late now. In short: we got an offer from Google to integrate AdSense support into Drupal. For each Drupal user that signs up with Google and enables Google Ads on his or her Drupal site, we would get money from Google. Clearly, this is a great opportunity to generate some money. However, the question arises: do we want to go there, and if so, how?

3 5

[drupal-devel] [bug] Poll not properly updating who voted
by cprice 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/18597 Project: Drupal Version: cvs Component: poll.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: cprice Updated by: cprice Status: patch Attachment: http://drupal.org/files/issues/poll_polled.patch (1.74 KB) Apparently there is some contention between the queue module and the poll module, so this is only a problem when both modules are enabled. Both modules use a node->voters variable. The queue module defines this as an array, while the poll module defines this as a string. This causes the poll module to only update the poll.voted column with the last user that has voted, so this only disallows the latest voter as the poll.voted column's data is overwritten after each vote. The best possible fix would probably be to rename the poll.voted column to poll.polled and update the code accordingly. As an interim, I propose the following patch which modifies the query to SELECT votes as polled. This also modifies relevant code to use node->polled instead of node->voted. If the database is modified to accomodate the poll.polled column instead of the poll.voted column, this would then require minimal code change to sync the code to the database. cprice

3 4

[drupal-devel] [task] Make module descriptions consistent
by JonBob 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/19451 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: JonBob Updated by: JonBob Status: patch Attachment: http://drupal.org/files/issues/descriptions.patch (18.88 KB) We have tons of different ways of phrasing module descriptions for the module listing page. This patch rephrases them all to consistently use an active verb, and cleans up some grammar and clarity issues. JonBob

8 10

[drupal-devel] [bug] Minor fixes in INSTALL.txt
by Uwe Hermann 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/19588 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: minor Assigned to: Anonymous Reported by: Uwe Hermann Updated by: Uwe Hermann Status: patch Attachment: http://drupal.org/files/issues/INSTALL.txt.patch (1.44 KB) Hi, here's a tiny patch which fixes some issues in the INSTALL.txt file. Uwe Hermann

5 7

[drupal-devel] [bug] database.pgsql ALTER TABLE sequences is wrong
by danielc 01 Apr '05

01 Apr '05

Issue status update for http://drupal.org/node/19768 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/database.pgsql.sessions.diff (443 bytes) Line 593 in version 1.109 of database.pgsql is problematic. The line creates a unique index for sid. But, sid is already a primary key so doesn't need a unique index on it. Let alone, the syntax is wrong due to wrapping the table name in {}'s. This patch removes the line. danielc

2 1