- Development - lists.drupal.org

Crossing information between content types
by Yuval Hager 25 Oct '07

25 Oct '07

Hi all, Let's say I have two content types - a person and a bank account. A person can have several bank accounts, and a person also has an address. Now I need to present a listing if all the people who live in New Jersey and have more than $100k in their bank account. In any database application it would be dead easy - just use a SELECT.. JOIN on these two tables and you're done. However, on Drupal, I am not sure what is the best way to accomplish that. First thing I did was to define these two content types in CCK, install the relativity.module and declare parent-child relationships between the person and her bank account. Then I hit the wall.. I can't combine information in a view from these two content types, and I can't use views fusion module, as it doesn't know about relativity (only nodefamily). My dream solution would be to expose relativity.module into the views admin screens, and just add/filter the fields of the related content types. But since relativity is generic and views uses a flat view of all fields, I really can't think of a way to accomplish that cleanly. Of course I can write the query myself, but since these are CCK nodes, I can't use a direct SELECT, and have to iterate through the nodes manually. It is also not maintainable through the UI being strictly in code (and can't use views plugins etc.). Another option could be to use views hooks (pre_view, query_alter..) to load the parent node, check the condition and manipulate the view accordingly. This doesn't feel right neither. I ended up going back to my dream solution and face it with reality. Since I know my CCK structure and the queries I need, I can go specific. I created a module and added the 'location' table, but not connected to the 'node' table, rather to 'relativity' table, through the 'parent_nid'. This way I can add the parent-city as a field, filter and an argument to the view. As a bonus, I even reused the original location.module city argument handler. The downside is that it's quite a lot of code (although once written can be managed through the views administration). Does this make any sense? Isn't there a simpler solution? Cheers, -- Yuval Hager

4 7

Re: [development] Please be careful marking release nodes "Securityupdate"
by FGM 25 Oct '07

25 Oct '07

I think that this stance tends to generate too many branches and ensures confusion will arise even more. Even for drupal core, even major branches sometimes include incompatible API changes which (IIRC, 4.7.4 did, and broke some sites). More generally, I'd rather say API changes in a branch MUST maintain backwards compatibility for the branch, but they MAY include new upwards-compatible features (addition paths, APIs, tables), as long as these don't remove existing features for the branch. This keeps the number of branches reasonable while maintaining stability. ---- Original Message ---- From: karoly(a)negyesi.net To: development(a)drupal.org Subject: Re: [development] Please be careful marking release nodes "Securityupdate" Date: Thu, 25 Oct 2007 10:52:37 +0200 (CEST) [...] >DB and API changes must happen in a new branch. Any given branch >should not contain anything else but bugfixes just like Drupal core.

1 0

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