- Development - lists.drupal.org

New maintainer for Gallery Module
by Kieran Parsons 26 Jan '07

26 Jan '07

Hi all, Unfortunately, I am looking for a new maintainer for the Gallery module (Gallery2 integration into Drupal). I can no longer spend sufficient time to update, fix and support the module as well as it needs. The module has been one of the most popular drupal modules (>2000 downloads/month in the last stats released). Gallery module is reasonably complex and some knowledge of Gallery2 internals would be useful (but I had none to start with). There are 4.6, 4.7and 5.x versions available and all work reasonably well. There are a couple of known issues which apply to all versions and some minor bugs. There are also many new potential features that could be fun. I will support as needed. Please let me know if you are interested. Thanks, Kieran (kiz_0987)

1 0

Unexpected behavior with user registration
by Dan Robinson 26 Jan '07

26 Jan '07

Could someone take a look at: http://drupal.org/node/110874 and tell me if I'm off base here? Thanks, Dan

2 2

hook_menu split is inevitable
by Karoly Negyesi 25 Jan '07

25 Jan '07

Hi, The current menu patch does work well. You see a navigation block and you can click links, the menu expands, you can visit pages and they load. All is well. Try this: give administer comments permission to anonymous (no other admin perms) and log out . Observe the comments link in the navigation block on the home page in the Navigation block for Drupal 5. The new patch will not even consider admin/content/comment for display. To do so, it would need to access check every single visible item in the menu table. As the new system does access checking on run time via callbacks, this will lead to slowdowns. We could attack this with various caching strategies but that's not the solution. The simple fact is that hook_menu need and hook_router should not use the same permission system. hook_menu should only do permissions, after http://drupal.org/node/73874#comment-116054 this patch is done it will be just a JOIN. This way, in a sense, hook_menu indeed can access check every single menu item. We will give the permissions a numeric ID and the JOIn can happen over menu_links, permissions_roles, user_roles -- a three table JOIN over numeric keys. Likely to be reasonably fast. So, what will happen eventually is that you are displayed a tree of links that you have permission to see. When you click on an item you might end up with a 403. The 403 comes from hook_router which will be able to use access callback/arguments for access checking because we need to do this only once per page so it wil not be slow. Note that in Drupal 5 no access check is performed on custom items, so for example if you put a node into the menu that the user can't access then the user will see the link but clicking on it will give her a 403. Even if the user has no access content permission, this will happen with Drupal 5. The new menu system will at least check access content, if not node_access. But this makes the split absolutely ineviatable. There are other fun problems with visible links and router items mingled into one: if foo is not defnied, foo/bar is not visible but foo/bar/this is visible and again foo/bar/this/that is not visible then how should we sort these paths? For inheritance purposes, the order I listed them is a must, but visibility purposes foo/bar/this actually appears on the first level. This is another sure sign that menu and router structures are very much not the same. I still propose to get the patch in as it stands. Before the navigation block was added back it was actually hook_router and it was pretty much without problems. Accept that the navigation block I added back yesterday is just a development tool and not the Real McCoy yet -- eventually the quirks above will be smoothed out. It's sheer impossible to do all changes at once. Regards NK

6 9

E_ALL mode
by Dries Buytaert 25 Jan '07

25 Jan '07

Hello world, I just committed http://drupal.org/node/99625 -- this means that E_ALL mode is now enabled in Drupal HEAD. We might want to disable this when we freeze Drupal 6, but for the duration of the development cycle it is a good idea to turn this on. It makes for better code. -- Dries Buytaert :: http://www.buytaert.net/

8 7

Eliminate hooks entirely in Drupal 6
by Earl Miles 25 Jan '07

25 Jan '07

After some discussion this morning, I am putting up a proposal to eliminate hooks entirely (though not the concept of hooks) and replace them with officially registered callbacks. I have identified several areas where this will improve Drupal (primarily in terms of probable performance gains). There are 2 parts to this. Part 1: drupal_register_callback function drupal_register_callback($callback, $function = NULL, $file = NULL) This function is only called from a particular location; ideally in its own separate .register file that only needs to be loaded when the callback registry is being rebuilt. However, it could also be a function within the .module file. There are some questions here, primarily balancing ease of use for the developer versus performance for the system. When it is called, the system should already know which module context is being used. This function would register a given callback (examples: nodeapi, form_alter, etc) with the Drupal system. The registry would replace the logic module_implements uses to determine which module implements which hook. The $function would be what's called. In today's world the function would be called mymodule_nodeapi; and it would likely not change, but we should allow registration to specify the function used. If left blank, the default function name would be constructed. (i.e, modulename_hookname). The $file would be a file that should live in the same directory as the .module file and tells the system which file to conditionally load when that callback is invoked. This is one of the things that creates a big advantage in this system: We could move callbacks into conditionally loaded files, allowing Drupal's minimum per-page codesize to be smaller. The 'nodeapi' hook is not run for every page load, but because hooks are anonymous right now, that code *must* be present. When you can conditionally load, however, the required size of the .module becomes very small. (in fact you would only keep items in that file that are called on every or nearly every page load. Currently that's hook_init and hook_menu but with changes to hook_menu that one may well be eliminated from every-page-load calls, and the .module file itself may not even need to be loaded for every page). Invoking a callback would still be the same: module_invoke('callback', arguments...); Part 2: function drupal_register_theme($theme, $args, $function = NULL, $file = NULL) This works very similarly to callbacks, but it registers a theming function that can be overridden by the theme. The only difference in is the $args argument, which is an array that tells the function how to translate function arguments into the $vars array, for use in .tpl.php files. For example, let's say I have the following theme function: function theme_foo($node, $bar, $baz); The $args array would be: array('node', 'bar', 'baz'). Themes would also have a similar registry; we may need to make it slightly more complex so that it could work with the theme engine to automatically register a template. Which means we might want to find a way to make it simpler for themers to register the templates they're using (for example, a directory scan could find well-named template files and automatically register them based upon already known registered info). This entire system (callbacks and functions) would be cached, so information would only need to be re-read when modules and theme settings are updated. A 'development' mode might be necessary that re-reads this information every page load. There would probably be some way for devel.module to expose this setting and automatically disable development mode when devel.module is enabled. Overall benefits to this system: 1) Some execution time is saved looking up module hooks. I don't believe this is a great deal of execution time, but it is definitely some. 2) A great deal of code can be loaded conditionally, reducing Drupal's footprint. I believe this could be a *very* significant boost to Drupal and could vastly reduce the amount of code that is loaded, making Drupal far, far friendlier to hosts that cannot use an opcode cache. 3) Certain namespace collisions will be avoided. Developers will no longer be penalized for forgetting that mymodule_user() is the user hook. 4) Theme functions will no longer have to hunt around for their function; they will not have to test the file-system to see if templates exist. They will know exactly where to go when the time is right. 5) Theme template files will be easier to include in modules. In fact, if implemented properly, modules could actually include .tpl.php files, make the proper registration, and no theme code will be harmed by being in the .module file *at all*. 6) phptemplate.engine can have much of its code removed to core, making it easier to implement alternative template engines. 7) As an interesting side effect, themes could be made to implement hook_form_alter, if we coded it that way. There is a value to this, and also an argument why this might not be a good thing. Overall cons: 1) Having to register a callback is less convenient than simply naming a function. It's even more inconvenient to have a .register file. However, using the existing naming convention, the module_builder.module *could* be made to scan a module and produce a .register file or a register function. 2) Having to register theme functions is similarly inconvenient but I think it's no worse than we have now. 3) Having to reregister upon making changes is very inconvenient; a development mode would be a must. Thoughts?

17 29

The new menu system -- where we are, what works and what's not
by Karoly Negyesi 25 Jan '07

25 Jan '07

Hi, First of all, read the new menu documentation please. http://drupal.org/node/102338 Please note that everything the menu documentation talks about is intented to work. So if you browse to a page, you should see the page you wanted and the relevant access check must happen. So please give this some thought: "will I be able to upgrade my module to this system"? If you only give this thought when you will really upgrade your module to the new system, well past freeze I will not be able to adjust the API for you. Now is the time to get your voice heard. Also, here is a list of what's known to be broken in HEAD: -- no primary/secondary links -- no tabs -- no new administration page -- if you build a chain of paths like: foo/bar , foo/bar/this, foo/bar/this/that where ony foo/bar/this is a visible link then expect inheritance rules to not work. Core has no such thing IMO. -- if you give permission to role to a link without giving permission to its parents then that link for said permission will be mostly unreachable. There is no point for submitting patches for any of them as the current visible link solution will go down the drain pretty soon. Thanks for bearing with me, Karoly Negyesi

3 5

Is DRUPAL-5 branch necessary for module?
by _craig 25 Jan '07

25 Jan '07

Do I really need to have a separate DRUPAL-5 branch for my contributed module? The documentation* seems to indicate I need to. Is anything preventing me from just tagging files under HEAD with DRUPAL-5--1-0? Right now and in the near future I will only be making changes for 5.x so I don't see the need to have a separate branch. Of course if you look at my module**, it's too late... Thanks! Craig * http://drupal.org/handbook/cvs/quickstart#branch-tag ** http://cvs.drupal.org/viewcvs/drupal/contributions/modules/taxonomy_breadcru mb/taxonomy_breadcrumb.module?view=log&only_with_tag=

13 15

Re: [development] nodify, objectify, CRUD-ify ...
by FGM 24 Jan '07

24 Jan '07

Thanks for looking into it. Do you think it should be turned into a handbook page once refined ? ---- Original Message ---- From: cxjohnson(a)gmail.com To: development(a)drupal.org Subject: Re: [development] nodify, objectify, CRUD-ify ... Date: Tue, 23 Jan 2007 09:49:56 +0100 >Interesting. Thank you for creating the summary table.

3 3

Re: [development] Drag and Drop UI standards
by Ken Rickard 24 Jan '07

24 Jan '07

I have opened the discussion in the Usability group. http://groups.drupal.org/node/2512 - Ken Rickard agentrickard

1 0

Referential integrity -- finally?
by Dries Buytaert 24 Jan '07

24 Jan '07

Hello world, Fact: Drupal 6 will finally drop support for MySQL 3.x. The good news is that we can _finally_ start caring about referential integrity. As of MySQL 4, you can define foreign keys, and even though they don't actually work with MyISAM tables they would work with InnoDB tables. Plus, the PostgreSQL community would love us for it. To make a long story short: more DBAs and/or business critical websites would take us seriously. In other words: I'd happily accept patches that add foreign keys to Drupal tables. It woud not be perfect as we can't use cascading deletes, for example. Nevertheless, it would be a great step in the right direction -- assuming we can make it all work in a SQL- compliant way without leaving MyISAM users in the cold. If you don't know what referential integrity is, please read up on it: http://www.databasejournal.com/features/mysql/print.php/2248101 http://www.databasejournal.com/features/mysql/print.php/ 10897_2248101_2 If you want to make a contribution to Drupal but you don't know where to start, this would be a great project to wetten your toes in Drupal! -- Dries Buytaert :: http://www.buytaert.net/

19 47