- Development - lists.drupal.org

Administrator locale aware watchdog logs
by Gabor Hojtsy 01 Aug '06

01 Aug '06

Hi, http://drupal.org/node/76588 The problem with the current watchdog() calls is that the messages are stored in the actual locale used to present that page. Ie. if you have a German, French and English section (version) of your site, watchdog logs will be recorded in all three languages intermixed with each other. Administrators reviewing logs are supposed to understand all languages used on the site to understand possible problems. This is not the desired user experience. To make the watchdog logs admin locale aware, we need to postpone the t() call to the time the log is presented to the administrator and should not t() the string on storage time. This also means that we should store the message in English, and the variables separately in a different field. I have chosen serialize()/unserialize() to store the array. We should note that for backward compatibility the previous watchdog messages should have an 'N;' value in the field (the serialization of NULL). This needs an upgrade path, which is not yet implemented in the patch, but is quite simple. Some messages in system.install for example also log stuff which is user defined, so t()-ing it is not desired. With specifying N; in the variables field, it is possible to keep those away from t(). Pros of this approach: * Actual locale used to present messages to the administrator * Messages stored before any locale is available (ie. install time messages) are later translated so easier to review and understand Cons: * Tablesorting of watchdog messages on the admin interface is not directly done using the displayed value. So eg. 404 messages with different file names will not get sorted by the filename, which is only added after the tablesort is done. * Slightly more storage requirement for the watchdog table. In my patch, I have updated the watchdog() function used to store messages and the two watchdog review interfaces in watchdog.module. As an example, I also updated the user.module (also fixing some missing theme placeholder calls). This is not a complete patch, updating of other watchdog calls and the upgrade path is also required. /Since this change requires all watchdog() calls changed to run without errors, I have not tested the change in runtime. First I would like to gather opinions on the viability of the patch to put more work into it./ Please review and comment on the issue! Gabor

1 0

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

RE: [development] Drupal Administration survey II -- lookingvolunteers to do interviews
by Steven Peck 31 Jul '06

31 Jul '06

> -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Dries Buytaert > Sent: Sunday, July 30, 2006 11:27 PM > To: development(a)drupal.org > Subject: Re: [development] Drupal Administration survey II -- > lookingvolunteers to do interviews > > > On 30 Jul 2006, at 19:59, Kieran Lal wrote: > > I am looking for some volunteers to help re-design the survey and > > make sure the questions will lead to effective responses. The > > survey should help the Drupal development community understand > > Drupal users and the goal and needs of Drupal > administrators. I am > > asking the Drupal development community to help conduct 10 live > > interviews to help to refine the survey questions and language > > I can probably do one live interview. How would it work? > > -- > Dries Buytaert :: http://www.buytaert.net/ > Not knowing what's involved I'd like a few more details. Is this 'us' interviewing site admins/Drupal users from a set of questions or? -sp

2 1

Modules page rework
by Earl Miles 31 Jul '06

31 Jul '06

While waiting for the admin patch to finish gelling, tonight I got started on the modules page rework I want to do. First, here's the screenshot (thanks sepeck): http://www.blkmtn.org/node/347?size=_original 1) I'm using a module metadata file. It's a .ini file, because that's easy. All the discussions I've read/been involved with in the past showed the .ini file as being the least offensive of the various possibilities (of which there are many) due to the fact that it's extremely simple to code, and very familiar to use. One problem I immediately have with the .ini file, however, is translations. My best solution is to run items from the meta file through t() and modify the string grabber to grab appropriate strings from the meta file automatically? Not sure how we tag them, though. Maybe we put them as t() and then strip them? I welcome suggestions. 2) The meta file contains the following: * description (replacing the hook_help call) * version (arbitrarily filled in by module author) * package (currently: required modules, drupal core modules, contrib -- contributed modules can make stuff up if they need, but are otherwise encouraged to list themselves as contrib. *this is just an idea for now, but I think it's the easiest to get behind because it doesn't do *much* categorization but allows us to solve the problem I think needs solving). * links -- a list of administrative links (I couldn't think of a way to collect this automatically; possibly we could modify the menu system to mark them in some way which would be more consistent?) * dependencies -- (not implemented, but basically a list of modules that must be active before this module can be activated. It's a very simple dependency system and has flaws but we should start simple and improve over time rather than trying to get it completely right the first time). * drupal version -- what drupal version(s) this module works on. Only the major and minor numbers (i.e, 4.8) will be used. 4.8.x is assumed to have a stable API). 3) Given the above, I've reorganized modules by 'package'. The checkmark is moved to the left which is slightly easier. Throttle is gone entirely from here and will be its own page. The uncategorized module you see there is a module without a metafile; it will probably actually be disallowed in the future, rather than listed as uncategorized. This forces modules from 4.8 onward to have meta files, which forces a lot of useful things, such as modules only being allowed to be turned on if they have the password. I mean meta file with drupal version #. 4) Oh yea, I meant to automatically put 'help' links in the links section, but those aren't there yet. Those can appear, however, with relative ease. I'm actually much happier with what I've started than not, but I'd like to get some discussion on this. I think this is a good direction to take the module administration page. Some specific questions I have: a) Enabled modules are currently sorted only alphabetically. Should they be sorted by package, then alpha? I'm torn on this one. b) is 'drupal core modules' too long and should maybe just be 'drupal core' (and by extension, 'required' ?) c) There isn't a c) that's all I can think of just now.

15 40