April 2009 - Development - lists.drupal.org

watchdog() does not always work - or am I missing something?
by David Cohen 23 Apr '09

23 Apr '09

I'm debugging a situation where one of my drupal menu items is being called via javascript, AJAX style. To debug a problem, I've added watchdog() calls to the callback - as a sanity check that the callback is being reached, and so I can inspect some values. The problem is that the log entries never show the messages I'm trying to write. Its as if the menu callback is never called. However the apache log shows that the path is being requested. Let's say the path is /drupal/my/callback. Now, when I explicitly point a browser to the URL, lets say http://example.com/drupal/my/callback, then the watchdog messages are written to the log! It's as if watchdog only succeeds when the browser explicitly makes the request. I've tried disabling drupal's cache. I've tried refreshing the cache. No matter what I do, either my callback is not being called (despite apache logs to the contrary) or the watchdog calls fail without error (which would be crazy). But only fail when the call is made via javascript. When made explicitly from the browser everything works as expected. BTW, the apache logs indicate the proper number of bytes is returned by the request, and I've changed the size of the page returned to confirm this - evidence that caching is not the cause of this. Has anyone seen this or have any ideas? Many thanks. -Dave

9 11

Watchdog dieing on large queries
by Steven Surowiec 23 Apr '09

23 Apr '09

I've found a workaround for myself for this one but just wanted to put it out there. When a query fails watchdog is used to insert it into the DB, which is fine 99.9% of the time, until that .1% bites you. The problem is that if the query (say inserting a new record into the "cache") causes a query that is larger than the MySQL query buffer limit. This results in a MySQL error that the query is too large to insert, which watchdog then picks up and tries to insert, which fails, which watchdog picks up ... and you get the point. Result? Infinite loop and then either a timeout or PHP runs out of memory and dies. I'd think the proper way to handle this would be to have a check that the specific error code for a MySQL error resulting from a query buffer violation doesn't try to insert the query, again just putting this out there.

5 5

Some of core to contrib?
by Karoly Negyesi 22 Apr '09

22 Apr '09

Hi, So it seems there is quite some talk about moving some of the core to contrib. This talk comes up from time but we did not have testing and now we do. And that makes a big, big difference, I tell you. So let's suppose that aggregator gets moved into contrib. Every core tarball still contains aggregator, the latest tag from the DRUPAL-7--1 branch. But the aggregator people can churn out bugfixes as fast as they can and the tests will make sure they won't break stuff. Meanwhile, new features can get into DRUPAL-7--2. Every user can use --2 invidually, core will come with --1 still. Also, they maintain a DRUPAL-8--1 branch and for every unstable/beta/RC they make sure they have ported aggregator and tag similarly as core does (we can punt some of the unstables -- I could understand that not every module gets DBTNG'd immediately it did not happen anyways). Let's list the benefits again: *) if a company is interested in a module it can grow a community around much easier than with core. They can both release bugfixes and features. *) core does not lose the feedback from its modules Possible problems: *) lose of maintenance *) additional burden on these maintainers w/ HEAD compatibility. Also, aspiring projects can opt for core inclusion (if they accept that a branch can not break APIs and willing to tag along with core) which can be much easier this way. Let's face it, there are much higher quality contribs than the mess called comment module so why not? There is the small problem of how can people using cvs update core now, do they need to run a cvs up for every directory? Hardly. We can create a 'mirror' which pulls together the commits. This is an easily doable (and yes I am willing to script it). Regards Karoly Negyesi

17 36

CMS Research
by Gábor Nyeste 21 Apr '09

21 Apr '09

Dier Developer! I am a student of Corvinus University of Budapest and I'm writing my thesis in the theme of open source web content management systems. I would like to ask you for help to my research so that I can get acquinted with the world of open source development. Please take a moment to fill out my survey. Survey URL: http://survey.e-businessportal.hu/index.php?sid=63134&lang=en Yours fatihfully, Gabor Nyeste

3 2

Re: [development] Very concerned over Drupal's core development
by As If Productions 20 Apr '09

20 Apr '09

Nedjo Rogers and Robert Douglass said some great stuff. Read them again! Core improvements are going in some great directions, but there is an obvious and growing disconnect between these new directions and their assimilation into methodology by contrib developers (and site developers). This gap could be narrowed by *writing more documentation* but we all know how popular that is. Nedjo's points about client development schedules are very pertinent now, much more than ever because Drupal has become mainstream-popular. I've spent so much time patching/fixing/hacking modules for my D6 clients I haven't more than glanced at D7 yet. But I can tell you this - it took A YEAR for D6 to stabilize to the point where I would consider it truly useful, and D5 is still a safer choice for any non-tiny job with a real deadline. IMHO, the plan to release a major rev every year was the worst decision ever. Personally I'd like to spend another year documenting the D6 changes and patching the D6 contribs. LVX TF --- As If Productions http://www.asifproductions.com Interactive Worlds and Immersive Obsessions

2 1

uninstall: deleting all variables of a module
by Eric Schaefer 19 Apr '09

19 Apr '09

Hello List, I want to implement the uninstall hook for scheduler.module (D6). Removing the schema and configuration variables is pretty straight forward. But scheduler lets the user configure some values depending on node type. These variables are called 'scheduler_story' or 'scheduler_touch_event'. To remove these I would need to know all the node types that have ever been used at that site or I could enumerate everything in $conf that begins with 'scheduler_'. What is the recommened way of doing this. Is is even a good idea to access $conf directly? Thanks, Eric

6 6

Block user deletion
by Nabil Alsharif 16 Apr '09

16 Apr '09

The issue is I need some users to be able to edit other users info but not delete them. There is no permission that I can see that allows editing of users profiles but not deleting them. My second guess was to write a module but I don't see anything in the API that will let me control user access the way I need. Neither could I find a way to block the deletion (I know hackish). Any pointers in the right direction are greatly appreciated.

4 5

err...Views DataSource resuming service
by Allister Beharry 14 Apr '09

14 Apr '09

This is a general apology to people who filed issues for my module - apparently I am not subscribed to my own module's issues list. This is pretty embarrassing...but anyway yes the the module is alive and I'll be working on the issue queue for the rest of the evening. I think it should be the default behaviour when creating a project on d.o to be auto-subscribed to the issue queue. Allister -- Muppet Show > Monty Python

3 2

Using multiple databases for drupal?
by Raja Sekharan 09 Apr '09

09 Apr '09

Hi, Is it possible to use multiple databases to power a drupal site without editing the drupal core? Raj

3 3

The router and links tables split - what caused it?
by robert crowther 09 Apr '09

09 Apr '09

Yes, I know they split (Drupal 6, was it?). I seem to remember reading somewhere in code, or near code, documentation that this was not simply for clarity or encapsulation, but performance. If I recall the comment alright, does anyone know what that performance issue was? Were people running, say, college sites, or auction sites, and finding they were bloating the links tables? A more general question - what was the scale of the bloating that caused a database to slow down? Answers to these questions may have a direct impact on the development of my module, http://drupal.org/project/taxonomy_treemenu In response to user discussion I'm considering a complete re-write of the links code. Rob

1 0