October 2007 - Development - lists.drupal.org

The day the critical queue gets empty: Nov 3
by Karoly Negyesi 24 Oct '07

24 Oct '07

Hi, webchick, desbeers, dvessel, davidstrauss and myself will spend part or all of November 3 with one goal in mind: empty out the critical issue queue for Drupal 6. In case we reach this goal and we have more time, well, there are a number of noncritical bugs and an even bigger number of patches that need work. Come, join the fun on #drupal on irc.freenode.net next Saturday! (In case you are many, we will move over to another channel, not a problem.) Regards, NK Ps. I cc'd doc list because doc people would be very useful to be around...

1 0

cmsmatrix.org listing maintainer
by Daniel F. Kudwien 24 Oct '07

24 Oct '07

Hi all, does anyone know who's responsible for the Drupal listing at www.cmsmatrix.org ? See http://www.cmsmatrix.org/matrix/cms-matrix?func=viewDetail;listingId=1050 I just compared some popular CMS and saw that a lot of the provided information is not correct. Based on the current info, 'Drupal sucks' in comparison to Joomla, T3, Xaraya, Xoops aso. sun

2 1

Re: [development] issue followups as comments -- testing needed
by Chad Phillips -- Apartment Lines 24 Oct '07

24 Oct '07

On Oct 24, 2007, at 1:38 PM, Khalid Baheyeldin wrote: > Is it in a shape that is ready for putting it on scratch.d.o? This > way we > get real data, and more people can test it, since they don't have > to set it > up. we won't be using scratch anymore for project module testing. this has all been moved to project.drupal.org > And it is also a test for the migration of the existing followups > (you are > migrating them, right?) i've performed several migration tests already, and will perform one more on a fresh copy of the d.o database just prior to the d.o upgrade.

1 0

issue followups as comments -- testing needed
by Chad Phillips -- Apartment Lines 24 Oct '07

24 Oct '07

Ladies and gentlemen, Issue followups as comments is almost a reality on drupal.org! This is a major leap in issue queue functionality, including: 1. multiple file attachments per followup 2. tracker integration 3. ability to edit followups (unpub/delete for admins as well) This is also an important step along the road to porting project* to Drupal 6 (which has to happen before we officially release Drupal 6 -- see http://groups.drupal.org/node/6180 for our current project* roadmap). We're at the final stage now, and need your help testing the UI and reporting any bugs you find. To make things super easy, I've configured http://project.drupal.org with the new code, so you can simply go there to perform your testing -- this is a clone of drupal.org, so your regular username and password will work fine there. Couple of things to keep in mind: 1. We're looking for bug reports and UI tweaking suggestions. If you have a feature request or other major structural suggestion, you're about two months too late, I'm afraid... ;) 2. If you have admin privileges, and you'd like to see what the site looks like from an auth user's perspective, you can login with user: test, pass: test 3. If you're surfing old issues, be aware that the file links will give you a 404, b/c the files aren't on that server. 4. If you find a bug, or have a UI tweaking suggestion, please first search for an existing issue at http://drupal.org/project/issues/ project_issue, and file a new one if you don't find yours reported already. Let's not clog the devel list with random suggestions. If you have any questions, find me in #drupal. Thanks, and happy testing! hunmonk p.s. Thanks to chx for the original IFAC code, and to dww for the extra guidance and help along the way...

4 3

a nasty Java applet case
by Tomas J. Fulopp 23 Oct '07

23 Oct '07

Lads and lassies, I wonder who can explain this one... I've been working on this nasty problem for several weeks... and I am really close to a solution now, but not quite there. Hope you can help. It is really an interesting problem! I maintain the "hypergraph" (HG) module, which currently takes the current-user-visible menu and turns it into a visual map using an open source Java applet -- see http://drupal.org/project/hypergraph or the files in CVS here http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/hypergraph/ I have a multisite install of D5.2, the HG module sits in http://quidne.vacilando.org/sites/all/modules/hypergraph/ folder, and there is also the .jar file of the Java applet. Now, when the page that contains the HG tag loads, the Java applet appears, but it needs to call data from the server. This data is provided by a file that resides in a folder of hypergraph, namely http://quidne.vacilando.org/sites/all/modules/hypergraph/graphs/hg.php (+ some arguments). Note: in the same folder there is a .dtd file that is necessary for the XML data. Quite simple, really. Worked fine on other (non Drupal) sites where I implemented it - e.g. http://www.vacilando.org frontpage But on Drupal, and not only on my multisite install (several users reported it), there is a silly bug: After you open the browser (FF and IE; tested on WinXP) for the first time (with or without clearing cache, I found), the Java applet would throw a cache-related error. When reloaded page, and on all subsequent loads, the Java would display correct data, without any problem. So I looked everywhere and tried to avoid this Java error, finding that JRE 6 has a bug related to cache, etc. Many days after I realized that this error (after fresh opening of the browser) did not occur in other websites I had made that feature the same applet. So I changed focus to the generated XML data, tweaking it to perfection.. But I could not get rid of the bug! I then thought that perhaps I am not properly initializing Drupal. This is in the data provider file hg.php : drupalize(); function drupalize() { while (!@stat('./includes/bootstrap.inc')) { chdir ('..'); } require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); } That should be fine, no? Just to be sure, I tried to put just plain XML file here - not dynamically generated, for a test. Still the same problem!! Then I put both files (the static test XML and the DTD file) elsewhere, on a different subdomain ( in http://www.vacilando.org/temp/tst/ ). Wow -- surprise -- no bug!!!!!! Why??? Why does it not work when XML and DTD are in http://quidne.vacilando.org/sites/all/modules/hypergraph/graphs/ and it works when XML and DTD are in http://www.vacilando.org/temp/tst/ ? No idea! I have a hunch - but I need your thoughts here... the XML file definitely needs its DTD file. Could it be that something - either some consequences of multisite, or the .htaccess rules in the root of Drupal, or something else (what?) cause that the XML does not "see" its DTD even though it is in the same folder..? I tried to put an empty .htaccess file in the folder http://quidne.vacilando.org/sites/all/modules/hypergraph/graphs/ trying to override the basic Drupal's .htaccess - no change. Another suspicion - the Java applet seems to be loading before the page loads, or at least sometimes (when cache has been emptied from the browser before it was closed). Could it be that Drupal somehow forbids anything accessing module directories before session/cookies are set or something? Also tried to put the two files into a folder in the files folder ( in http://quidne.vacilando.org/sites/quidne.vacilando.org/files/tst/ ) - same bug. Any idea? Anybody has experience with a similar problem? If any of you want to test the problem in action, don't go to my website (too many on-going dev changes), just get v1.2 from http://drupal.org/project/hypergraph and install it ( then go to /hypergraph ). Or contact me and I'll quickly set up a demo of the problem on my site. Cheers, Tomáš / Vacilando

1 0

Re: [development] Debugging updates
by Karen Stevenson 23 Oct '07

23 Oct '07

Thanks to everyone for all the suggestions on how to debug updates. Just as a FYI, here's what I ended up with: 1) I think the ideal solution would be to be able to store the devel queries in update.php, and then display all of them at the end of the update. I spent quite a bit of time trying to figure out how to get it working the way I wanted and gave up. I submitted an issue for this at http://drupal.org/node/185844 in case anyone else is interested and knows how to get it working. 2) Turning js off wasn't particularly helpful because the non-js version uses a meta refresh to take you from one page to another, so you still can't see anything you print to the page (unless you trigger an error or add an 'exit' to the code). 3) Var_dump() and print_r() won't work at all in the middle of an update, with or without js turned off. 3) The best solution seems to be using the option of returning array('success' => TRUE, 'query' => 'Something about the update'). I did run into one small issue which is that I was using a progressive update, so that didn't work the same. In a progressive update, I have to return a nested array: array('#finished' => 1, array('success' => TRUE, 'query' => 'Something about the update')); Karen

3 2

Do you search your site?
by Karoly Negyesi 23 Oct '07

23 Oct '07

If yes, then review http://drupal.org/node/146466 . * check whether node indexing works - use cron.php, edit a node after it's been indexed, add a comment, remove a comment, etc, * search syntax - create a couple nodes and then do the four types of searchs (AND, OR, exclude, and phrase searches) and make sure the right results come back * relevancy. create two nodes where in node A one of the words appear more times than in node B. Check searching that word. * add a link from one node to another and make sure that both nodes get reindexed. If document A is linked to by document B, and document A does not refer to word X, but document B does refer to word X, when you search for word X, both documents should return results. This is in essence how linking from one node to another improves the word relevancy of the linked to document. NK

1 0

Security releases and the update status module
by Gerhard Killesreiter 23 Oct '07

23 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, the update status module has introduced a new mechanism for updating everybody's Drupal site. It tells you when a new version becomes available and warns you when you don't install security releases. One issue that has so far not been addressed is: What happens if a module has two branches and there is a security release for one of them? This situation existed with the pathauto module. It has a 5.1 release and a 5.2 development branch with a beta release. There was a security issue found on the 5.2 branch and a security release was created for it. Unfortunately, since the 5.2 branch was made the default branch, every 5.1 user got told to upgrade to the beta release. This is confusing for less tech savvy users since a beta release is usually perceived to be unstable (even though Greg tells me the 5.1 release is actually quite buggy too). So, what I am asking for is this: Can we agree that in the absence of a "real" release, a branch should not be made the default branch? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHGz35fg6TFvELooQRAow5AJ99PFA8ce2QnCjHuyhTrDcWdZZBsACfVX5S F3+yud9Gbh0K/C4apzoLLI4= =pCx+ -----END PGP SIGNATURE-----

3 4

Re: [development] code proposal: localization of currency, ...
by Karen Stevenson 23 Oct '07

23 Oct '07

No, the autotimezone module automatically sets the timezone offset using a fairly simple bit of javascript to automatically update the timezone offset in the user record. I'm talking about the timezone name. There is no javascript-only way to identify and set the timezone name from browser information. In fact, I spent quite a bit of time researching how to do it since the common wisdom is that it can't be done at all. But I finally stumbled on a way to do it with a combination of javascript and PHP5 by building on some example code from a presentation made by Derick Rethans (the maintainer of the PHP5 date functions). Plus, to do anything useful with the user timezone name, you also have to overload the site and user timezone settings to select and store the timezone name instead of the offset, and to do that you have to have a way to manipulate timezone names and offsets to present the selection list. And then of course you need new ways of manipulating dates that use the timezone name instead of the offset to do timezone conversions. I put this in the Date API because it all works together -- you need the PHP5 date functions or their equivalents to detect and store the timezone name, and you need a different way of handling dates to do anything useful and reliable with the timezone name once you have it. I can propose patches for the autotimezone module, but they would be radical changes to the way the module works. It would have to be something like a completely new version of the module that requires PHP5, that both updates the offset as is done now for backwards compatibility with with old-style date handling but which also detects and stores the timezone name for applications that can use that information. And it would have to overload the user and site timezone handling forms to list and store timezone names instead of offsets. And autotimezone would then become a required module for any application that wants to use PHP5 date handling or store timezone names in user records. If it seems like this belongs in autotimezone, I can propose patches to it. Karen ----- Original Message ---- From: Moshe Weitzman <weitzman(a)tejasa.com> To: development(a)drupal.org Sent: Monday, October 22, 2007 7:18:17 PM Subject: Re: [development] code proposal: localization of currency, ... @karen - I suspect you have reimplemented autotimezone module - http://drupal.org/project/autotimezone. if you have any improvements, consider posting them in its issue queue.

2 1

Re: [development] code proposal: localization of currency, ...
by Karen Stevenson 23 Oct '07

23 Oct '07

<clip> > There is the time of the server and there is the time of the user. > You don't know where the user is and you've to ask which timezone he > prefer. Guessing where the user is and which timezone he is in, is a > risk that doesn't fit to much in core. ... > Once you ask... well you don't need the Olson bag with you. > Computations with dates should be a language task not drupal task. </clip> I'm not quite sure how a thread about localization of currency drifted off into date handling, but if we're going to debate how dates should be handled I guess it's time to jump in: * In PHP5 we can do lots of intelligent things with timezone information, including getting dates that automatically adjust for daylight savings time without any need for any intervention by either users or administrators. PHP5 date handling could certainly be expanded on, but it is still significantly better than PHP4 methods. * In D7, we will want to quit asking users what their *offset* is (the current behavior) and start asking what their *timezone* is. Once we know that, in PHP5 we can make the necessary conversions. * PHP5 timezone handling gets its power from the Olson timezone database. It is inaccurate to say "once you ask you don't need the Olson bag with you" -- you still need some method of converting dates from one timezone to another where you can be sure your conversion has been adjusted to the right value (and you need a method that works even when the site and the server and the user use different timezones and one or more of the timezones need adjustments for daylight savings time). And keep in mind that you can't just store the user's offset and use that as the adjustment for all future dates, because the offset can be wrong if the user is currently in daylight savings time but the date you are adjusting is not. * Some part of this must go in core. We currently attempt to do timezone adjustments, but sometimes get it wrong because of the problems working with dates in PHP4, so anything we can do to improve on that must also go into core. Unless we get rid of timezones completely and use GMT for everything, which I'm sure is *not* an acceptable solution :) I took a stab at getting better date handling into core in D6 but it didn't make it. And killes and others have tried to get it into core in earlier versions. It will be much better to do it in D7 anyway, because that way we can use PHP5 date handling. In earlier versions it was going to require some nasty cludges to work right in PHP4. BTW, although we don't need to guess the user's timezone, since we're just going to ask them, I have come up with a method of making an intelligent guess of the user's timezone using a combination of PHP5 and javascript that could be used to pre-populate timezone info until the user verifies it. I have code to do that in the HEAD of the Date API right now and hope to set up a page that people with different browsers and systems can use to test how well it works. Karen

2 1