January 2007 - Development - lists.drupal.org

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

Drupal 5 Themer Pack
by Earl Miles 24 Jan '07

24 Jan '07

Transferred from my blog at Dries' request. First, the blog post: > Today on drupal.org I just posted my ‘personal battle plan’ and it includes > a fairly large project that doesn’t actually require a great deal of Drupal > experience to help on; it requires just enough coding knowledge to extract > the right amount of code, create the files, and then — probably the only > place where a little bit of coding knowledge is really needed — effectively > separate logic from presentation without adding too much processing time to > the code. > > The idea here is that I think there should be a project called the Drupal 5 > Themer Pack which includes every (or nearly every) theme function in Drupal > 5 core as a .tpl.php and the corresponding template.php code. Right now I > envision the structure that each Drupal ‘system’ might have a file such as > template-forum.php which is included from your standard template.php. It > includes all of the forum theme functions, and each one has a .tpl.php for > presentation. This code does not change the output in any way but makes it > easier for Drupal themers to identify the theme functions they need and > actually modify them. > > As a bonus, it might include alternate versions — maybe a PHPbb-like set of > templates for forum, or whatever. Plug it in, make the changes you need, and > go. > > There is a fair bit of work here, but it’s also learning work — because in > so doing, whoever extracts the theme functions will be forced to learn > something about how Drupal actually does that part of the code. It could > lead to recommendations for patches for future versions of Drupal to improve > the theming functions, and it could make life a whole lot easier for themers > who don’t want to have to know anything about code at all, because they can > take these things that are already created for them and simply tweak them. > That’s a lot easier than doing the actual extraction like they have to do > now. > > Right now I am basically doing an exploration of who might be interested in > contributing to this project, and working to organize effort and get > something good going here. I’m thinking of pitching this to the Drupal Dojo > as something that students can work on as a learning exercise AND contribute > to Drupal. > > Any thoughts? Want to work on it? Make sure I have contact info — as I’ll be > putting together a list. Second, Dries' response: > Earl, for Drupal 5.0, Vlado, Adrian and myself spent a couple of weeks > trying to move all theme functions out of the modules into stand-alone > phpTemplate files. The idea is that designers should simply copy the > template file and start modifying it, rather than having to convert a module > into a theme themselves. > > We created a script that does just that -- and that got us 95% there. It > removes the theme functions from the modules, converts them to template > files, and stores the template files in the module-specific directories. > > It all worked (except for the last 5%), but the problem we ran into is that > it turned out to be 10% slower. > > I'm hoping you and others can pick up the work (with help from us), and help > us get this _in_core_. I think this is a case where we are better of > changing the default behavior. It makes too much sense not to do it in core > -- plus, we already started working on it. > > What needs to be done is "simply" this: we need to make it 10% faster. :-) > > Let's talk more about this on the mailing list? My response: Yes, there are absolutely aspects of this that are a good push toward core. However, there are a couple of important things here: 1) Drupal 6 should be 6 months away, and this kind of project can benefit now, as well as having a future benefit by having the bulk of the theming work be done now. By being useful now, people who might not otherwise participate in this work might participate and contribute. 2) I think it's important to get more themers participating in Drupal, and making this easier is a good way to do it, and to follow up 1, can be a major benefit now. 3) I don't have a solution for the 10% slower yet. 4) This project mitigates that 10% problem by presenting the pack as a pick & choose type deal. You don't include the templates for items you aren't overriding, but for themes that do want to override them, they drop the code in, add a line to their template.php to include the right stuff, and start modifying. To refute 3) above, I might have a solution to the 10% issue which involves template compiling -- I believe the bulk of the slowdown comes from having to read template files into memory over and over again. Compiling all the .tpl.phps into a single file could mitigate that effect. I don't know, it'd have to be proofed and benchmarked. This work could benefit that. Also, I have access to Frando's work on creating .theme files but I don't have access to Adrian/Vlado's work on separating out into .tpl.php. Frando's work includes an extractor, though, that I think can be repurposed to do just that, so I'm not terribly concerned.

14 34

Re: [development] Is DRUPAL-5 branch necessary for module?
by Ken Rickard 24 Jan '07

24 Jan '07

>>I hate to sound elitist, but maybe one of the problems is the ease >>with which hundreds(?) of people have obtained CVS accounts? If you >>either (1) don't know what you are doing with CVS, or (2) are not >>willing to learn how to use it without bugging Derek, then maybe you >>shouldn't have a CVS account? I don't think this attitude is being elitist. It's realistic. The only reason I involved Derek was that the troubleshooting documentation referred issues to the Project issue queue. This misuse of Derek's time has since been identified (and corrected). - Ken Rickard agentrickard

1 0

Re: [development] [drupal:dries] /includes bootstrap.inc common.inc locale.inc menu.inc module.inc path.inc / install.php /modules/aggregator aggregator.module /modules/block block.module /modules/blog blog.module /modules/blogapi blogapi.module /mod
by Johan Forngren 24 Jan '07

24 Jan '07

Interesting that http://drupal.org/node/34755 is still RTBC. On 1/24/07, Stefan Nagtegaal <development(a)istyledthis.nl> wrote: > > > Op 24-jan-2007, om 15:48 heeft drupal-cvs(a)drupal.org het volgende > geschreven: > > Log message: > > - Patch #34755 by chx et al: faster menu system. HEAD is > > temporary broken and there is no upgrade path yet. > > How much faster is this new menu system after all? I tried to find > some benchmark number, but I wasn't able to find/locate any.. > > > > Steef > -- // Johan Forngren /** * Email: johan(a)forngren.com * WWW: http://johan.forngren.com/ * Skype: forngren * MSN: johan(a)forngren.com * IRC: forngren @ freenode * Jabber/GTalk: forngren(a)gmail.com */

1 0

Re: [development] [drupal:dries] /includes bootstrap.inc common.inc locale.inc menu.inc module.inc path.inc / install.php /modules/aggregator aggregator.module /modules/block block.module /modules/blog blog.module /modules/blogapi blogapi.module /modules/book book.module /modules/comment comment.module /modules/contact contact.module /modules/drupal drupal.module /modules/filter filter.module /modules/forum forum.module /modules/help help.module /modules/legacy legacy.module /modules/locale locale.module /m
by Stefan Nagtegaal 24 Jan '07

24 Jan '07

Op 24-jan-2007, om 15:48 heeft drupal-cvs(a)drupal.org het volgende geschreven: > Log message: > - Patch #34755 by chx et al: faster menu system. HEAD is > temporary broken and there is no upgrade path yet. How much faster is this new menu system after all? I tried to find some benchmark number, but I wasn't able to find/locate any.. Steef

2 1

Re: [development] Is DRUPAL-5 branch necessary for module?
by Ken Rickard 24 Jan '07

24 Jan '07

All- As one of the developers who harassed Derek recently ( http://drupal.org/node/108635) let me say a few nice things about him. 1) His documentation is excellent. I never had problems with releases; my problems were with version control (HEAD means what?). 2) Even at my dumbest, he was patient and encouraging. The Drupal community is remarkably good at not discouraging novice developers even when refusing (rightly so) to solve their every minor problem. And I owe Derek several beers. - Ken Rickard agentrickard

4 3