Nu ook in het Nederlands.
 

clemens's blog

ip lookup

Have setup the statictics modules I note ip adres 66.249.73.205.

Using http://ip-lookup.net/index.php reveils it's a google bot. Thanks!

But how do I know the other ip's. It would be nice to have this lookup build into the statistics.

Just browsing the drupal 6 module list.

It's amazing to see so many modules being converted.

I definitely needs to start converting my modules too!

It take quite some time to upgrade my modules. I guess coder.module will help a lot with all hints.

Some references

Writing an article without pointer is pointless. So here is a start.

Version dependencies are described here http://www.debian.org/doc/debian-policy/ch-relationships.html

For a functional dependency specification (Nix and NixOS) see

direct debit payment method for ubercart

Call me stupid but I thought it was easy. Building a new payment method. I know drupal development a little. I read the core_systems and ubercart_hooks. No sweat developing this new payment method.

mysql cycle

I still forget how to do the database and user creation and drop goes. So why not make a note.

Creating

create database test;
create user 'test' identified by 'pwtest';
grant all on test.* to 'test'@'localhost' identified by 'pwtest';

Cleaning up

drop user test;
drop database;

Yeah ... call me stupid ;-)

ubercart documentation

In building my clieop3 module together with uc_payment_direct_debit I ran into the missing of documentation about the callback parameter $op of hook_payment.

That was a bummer. Because the drupal development process is still a lot of reverse engineering. Having read Pro Drupal Develpment eases the pain a little. Finding ones way studying other modules is ok if it's not on a daily basis. I must be doing something wrong.

The good side is that this $op gets documented now.

Conclusion

My conclusion would be to make module.inc the key module for module and project dependency management.

Changes to install.php, system.module, update.php are relative easy to do afaik.

What i haven't covered is schema update dependencies.

Steps to take:

  1. make drush_mm more robust as a showcase
  2. patch module.inc with lessons learned from drush_mm
  3. provide the project provides files same like status_update
  4. with this into place drush (D7) could have lean and mean drush_pm and drush_mm modules

project dependency management

This is a tricky part of package management. I have no ready solution apart from 'have a look at debian packagemanagement'.

For installation the dependencies attribute of a module should contain a version expression. In example dependencies: token (<= 1.4)

downloading projects in core

Apart from security risk i think it would be great to have drupal install modules needed for a profile. For a commandline solution provided by drush the advantages are great.

Combining 'project provides' and clean dependency checks multi site users would get rid of the burden to get modules in place before installing.

uninstalling dependentless

When uninstalling modules the code uses a simple foreach to call drupal_uninstall_module.

My guess is that this should be in TSL order. And it will be easy to implement when we have the dependency graph of the modules to uninstall.

Question remains whether dependent modules should be uninstalled together. That is without the user selecting what modules to uninstall.

Pages

Subscribe to RSS - clemens's blog