- Development - lists.drupal.org

Guidance on OS X dev setup
by Nik Derewianka 29 Apr '09

29 Apr '09

Hi all, Relatively new to drupal + php, but not to programming and would like a bit of recommendation in tools to use on OSX for drupal development. Tools - Textmate/Coda etc or more full blown eclipse, other ?? Recommended ways to debug drupal so that i can see how things work. Is CVS the only revision control system in use for drupal ? Any plans for a modern CVS/DCVS any time soon ? Slightly more specific to Services + AMFPHP (yes i will be checking out g.d.o soon): With flex the uid property on a serialised object is reserved for flex's tracking of objects so it inevitably clobbers the uid properties being returned by the various user objects in drupal. Currently the amfphp module gets around this by doing: /* * ugly! ugly! ugly! * we need to use a method call wrapper here to convert all 'uid' values in the result * to 'userid'. this is because flex uses the property 'uid' in objects and will overwrite * anything we send with its own value. */ function amfphp_method_call($method_name, $args) { // convert all userid to uid $args = amfphp_fix_uid($args, 0); $result = services_method_call($method_name, $args); // convert all uid to userid $result = amfphp_fix_uid($result); return $result; } /* * ugly! ugly! ugly! */ function amfphp_fix_uid($data, $direction = 1) { $uid = 's:3:"uid";'; $userid = 's:6:"userid";'; $from = ($direction) ? $uid : $userid; $to = (!$direction) ? $uid : $userid; $data = serialize($data); $data = str_replace($from, $to, $data); $data = unserialize($data); return $data; } Ideally, it would be better to expose a duplicate property of userid in user/node/etc classes instead of the huge refactoring task of changing uid to userid etc, but understandably this may not be the ideal solution. Can anyone recommend a possibly different approach than the one taken above ?? (And apologies if this has been already discussed elsewhere, kindly point me to it so that i can read up on it). Thanks, Nik

1 0

Very concerned over Drupal's core development
by Karoly Negyesi 29 Apr '09

29 Apr '09

Hi, I know there are many patches are written, reviewed and committed still. But, without intending to critique of anyone in particular, I see a very dangerous cycle: As Drupal 5 and 6 are very good, rock solid releases, people are satisfied and very busy there, much less is the need, the drive and the availability for core development. This means less patches are written. Also core got bigger. Very, very few people touch actions/triggers, fields, filter system, openid or for that matter, menu just to name a few. Once a patch is written , it needs a review. However, the testing bot, curiously, made patch reviews even harder -- no longer can a novice just install a patch, click around and report back "works" ( the testing bot, of course added a lot of quality to Drupal, I am not saying, down with the bot). This has very severe consequences: we always had too few reviewers and now the entry barrier is even harder as you need to do meaningful code reviews all the time. Low reviewer activity means patches do not get 'bumped' and they linger. Lingering is exacerbated by the loss of Steven and that the single guy who can call the big decisions now has a kid (soon two) and two companies to run. Of course, this leads to frustration on behalf of the patch writers and even less patches get written or reviewed and people draw back into their own little contrib empire where they call the shots... Regards Karoly Negyesi

40 101

Hook_menu_alter doesn't work if menu item changed
by Nancy Wichmann 28 Apr '09

28 Apr '09

If I do anything to a menu item, including changing its position (weight) with menu administration, then hook_menu_alter is unable to change its title. This seems to be contrary to the way the hook should work; essentially the hook is all but worthless in this case. Does anyone know why this is this way? Yes, I can update the menu_links table and change it there just fine, but then Im doing a query to change what a query should be about to do anyway. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.12.4/2079 - Release Date: 4/24/2009 7:04 PM

6 21

varchar(255)
by Dave Cohen 25 Apr '09

25 Apr '09

In another recent thread (about watchdog), Frédéric suggested increasing the size of the watchdog.referer column. And he's right to suggest it because strings that are too long are not written to the database. This brings to 3 the number of columns I increase to varchar(255) on my Drupal sites. The three are watchdog.referer, users.mail, and sessions.sid. If my understanding of mysql is correct, there is no difference between a varchar(128) column filled with 128-byte strings and a varchar(255) column filled with 128-byte strings. However, there is a huge difference between a varchar(128) column filled with 129-byte strings and a varchar(255) filled with 129-byte strings. (The latter will work). So please, when developing for Drupal and wondering what size to make that varchar... stop wondering and use varchar(255). Or if you need it even longer varchar(65535). Note that lengths up to 255 can be represented in one byte, and 65535 in two bytes. Oh and please do correct me if I'm wrong about any of this, -Dave

3 2

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