August 2006 - Development - lists.drupal.org

message_na() removed from core
by Dries Buytaert 01 Aug '06

01 Aug '06

Hello world, just wanted to let you know that message_na() has been removed from CVS HEAD. * Upgrade instructions: http://drupal.org/node/64279#message-na * Patch: http://drupal.org/node/61893 At least the following modules need to be updated: * cvs.module * evaluation.module * filtercache.module * naggregator.module * subversion.module * theme: civicspace * berkes' node_aggregator * factoryjoe's groundswell theme * killes' "speed drupal" filter.module -- Dries Buytaert :: http://www.buytaert.net/

2 1

pootle for online translations
by Moshe Weitzman 01 Aug '06

01 Aug '06

would be cool if we used pootle (http://translate.sourceforge.net/wiki/pootle) to make a translation site like civicrm has: http://translations.openngo.org/

4 4

Locale support for the installer (with patch)
by Gabor Hojtsy 01 Aug '06

01 Aug '06

Hi, http://drupal.org/node/76555 We discussed providing locale support for the installer. Here is a patch, which works for me, but obviously needs some discussion. What did I do to support a locale in the installer: * Wrapped all strings in the installer files in st() calls. Some having placeholder text were already wrapped. * Made possible to run the PO import in installer mode. Theme() and t() are not defined in this mode, so setting of error messages need to be dealt with as a special case for normal operation and for the installer. * The PO import in installer mode is only interested in st() calls now (no format_plural support). This does not seem to be a problem yet, since format_plural() is not needed in the installer. * In installer mode, the strings are stored in an array and retrieved from the st() function. * The tricky part is indentifying the locale to use. I stepped this over for now. The installer tries to read an installer.po file from a folder named 'locale'. If it does not exist, English is used; if it does exist, the translations in this file are used. There is no support for installer language selection in this patch. First I would like to discuss the approach taken here before stepping further. I have already updated the extractor.php script to handle st() functions, and generate an installer.pot file with all the st() wrapped strings found throughout core, regardless where they are. This enables translation teams to provide that installer.po file st() is trying to look for. Comment on the issue please! Gabor

1 0

dependency system: package descriptors
by Nick Lombard 01 Aug '06

01 Aug '06

Good day guys and girls, I am new here, please be patient with me and I will appreciate any flame, criticisms, praises, suggestions, but most of all I will need your support by helping me become a full fledged druplar. I am sure I will make a few mistakes(like posting this task twice *blush*), use the wrong terminology, wrong code syntax and I'm sure many more things as I get used to the way we at drupal do things. I have added a new task http://drupal.org/node/76550 please take a moment to add your comments. Yours truly, -- Nick Lombard +27 82 413 9931 www.jigsoft.co.za

1 1

Database queries on drupal.org
by Gerhard Killesreiter 01 Aug '06

01 Aug '06

Hi there! Since last night, I let the devel module collect query statistics on drupal.org. We now can see which queries are run very often and which are just slow. Here are the first queries by accumulated time. The first column is accumulated time, the second average time/query, the third the number of times the query was run, the fourth the function which calls the query, the last the query itself: 927.011 0.005 192603 cache_get SELECT data, created, headers, expire FROM cache WHERE cid = S 905.582 0.001 973355 drupal_lookup_path SELECT dst FROM url_alias WHERE src = S 883.059 0.098 8986 theme_forum_topic_navigation SELECT n.nid, n.title, n.sticky, l.comment_count, l.last_comment_timestamp FROM node n INNER JOIN node_comment_statistics l ON n.nid = l.nid INNER JOIN term_node r ON n.nid = r.nid AND r.tid = D 388.902 0.014 28330 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = D 186.896 2.967 63 pager_query SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM node n INNER JOIN users u ON n.uid = u.uid INNER JOIN node_comment_statistics l ON n.nid = l.nid WHERE n.status = D 180.948 0.007 26472 cache_set INSERT INTO cache (cid, data, created, expire, headers) VALUES (S) 157.065 0.022 6983 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = S I am not sure why there are two node_load queries which look identical otherwise. Probably these fields need to be merged. Here are the first few queries by average query time, columns as above. 155.447 3.048 51 pager_query SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM node n INNER JOIN node_comment_statistics l ON n.nid = l.nid INNER JOIN users u ON n.uid = u.uid LEFT JOIN comments c ON n.nid = c.nid AND (c.status = D 186.896 2.967 63 pager_query SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, l.last_comment_timestamp AS last_post, l.comment_count FROM node n INNER JOIN users u ON n.uid = u.uid INNER JOIN node_comment_statistics l ON n.nid = l.nid WHERE n.status = D 94.058 1.844 51 pager_query SELECT COUNT(DISTINCT(n.nid)) FROM node n LEFT JOIN comments c ON n.nid = c.nid AND (c.status = D 109.691 1.155 95 pager_query SELECT DISTINCT m.*, r.*, u.name, u.uid FROM cvs_messages m INNER JOIN cvs_repositories r ON m.rid = r.rid INNER JOIN users u ON m.uid = u.uid ORDER BY m.created DESC LIMIT D 1.03 1.03 1 pager_query SELECT a.aid, a.timestamp, a.url, a.uid, u.name FROM accesslog a LEFT JOIN users u ON a.uid = u.uid WHERE a.path LIKE S ORDER BY a.timestamp DESC LIMIT D 2.536 0.845 3 comment_edit SELECT c.*, u.uid, u.name AS registered_name, u.data FROM comments c INNER JOIN users u ON c.uid = u.uid WHERE c.cid = D 0.614 0.614 1 eval select message, count(message) as count from watchdog where type = S and uid = D 0.434 0.434 1 aggregator_page_sources SELECT f.fid, f.title, f.description, f.image, MAX(i.timestamp) AS last FROM aggregator_feed f LEFT JOIN aggregator_item i ON f.fid = i.fid GROUP BY f.fid, f.title, f.description, f.image ORDER BY last DESC, f.title 0.429 0.429 1 pager_query SELECT q.qid, q.query, q.function, t.*, COUNT(t.qid) AS count, SUM(t.time) AS total_time, AVG(t.time) AS average, STDDEV(t.time) AS stddev FROM devel_queries q INNER JOIN devel_times t ON q.qid = t.qid GROUP BY t.qid ORDER BY total_time DESC LIMIT D The queries have been collected on every tenth page view, so you should multiply the count and total time values by ten for real values. Cheers, Gerhard

10 19

Drupal.org slow queries analyzed with explain: CVS tables
by Kieran Lal 01 Aug '06

01 Aug '06

4 5

A stance on Fantastico De Luxe
by Steven Wittens 01 Aug '06

01 Aug '06

Recently there have been many topics on Drupal.org about broken installs on Fantastico De Luxe, the cPanel application. Personally, I dislike Fantastico a lot and think it's bad for Drupal: - It's bad for the admins, because they get a broken, outdated install without going through our usual documentation. - It's bad for the community of support people, because there is an influx of support questions about non-standard Drupal installs - It's bad for the community at large, because it makes Drupal look buggy and insecure I wrote a text about it and after gathering feedback about it on #Drupal, it was clear that many Drupal people agreed with me on this. So, I posted it to Drupal.org and got a digg story going to spread the word: http://drupal.org/forum/fantastico-de-luxe (the clean URL is for extra google points) http://digg.com/software/Beware_of_Fantastico_De_Luxe Note that the emphasis is on the fact that using Fantastico gets you an insecure / outdated site. We do need to make it sound like we're concerned for our users and not just slamming Fantastico blindly. If you agree with these points, please digg up the article so we can spread some awareness about this. Steven Wittens

1 0