- Development - lists.drupal.org

alignment
by Mohsen Pahlevanzadeh 19 Jan '06

19 Jan '06

Dear all, I need to set align to right.Typicaly menu,elemnts of forum & everything. My site is Persian language. Please tell me what do i change that i can set alignment to Right. Please guide me.....

2 1

sequences and table prefixing
by Robert Douglass 19 Jan '06

19 Jan '06

If I want to share tables between databases (user, spam, whatever), I usually have to consider issues with the primary key sequences. The solution that comes to mind is to share the sequences table as well. It is nice that Drupal offers this flexibility. Is there a way that one can specify "use db1.sequences for node_id sequences, db2.sequences for user_id sequences, and db3.sequences for spam_id sequences"? I don't think so, but this might be a feature we should consider implementing. Why? Because the current system only allows a database to join a shared pool of something (take spam for now) at the beginning of its lifetime. If I had 5 sites sharing spam tables, and wanted to integrate an existing site, I'd be out of luck if I had to rely on a shared, running sequid for the spam tables. I think it would be very useful if one could specify a sequences array like the $db_prefix array: $db_sequences = array( 'node_id' => 'default', 'spam_id' => 'db_spam.', ); This would result in all sequences being taken from the default sequence table except for the (purely illustrational) 'spam_id' sequence, which would be taken from the db_spam.sequences table. Is there a way to do this currently in Drupal that I've overlooked? Would people be in support of this functionality if a patch appeared? cheers, Robert

4 5

Static Page Caching
by Mike Gifford 19 Jan '06

19 Jan '06

Hi folks, We've worked with jpcache in the past to produce static page caching for dynamic sites. We'd like to see the ability to create and edit pages with drupal that get saved as good old fashioned html files. Perhaps this would happen on a daily basis, perhaps only under severe load, perhaps only for paths with a .html extension, however not all drupal content needs to be loaded from drupal all of the time. Throttle is nice. The page caching is a good step in the right direction too.. But I'd like to cache an entire page so that php isn't even loaded at all to deliver the page. So, I'd just like to know what attempts have been done to do this in the past (if any), and what problems they had (so that hopefully we don't repeat the same ones). We've investigated this for other CMS's, but not for Drupal. Mike -- Mike Gifford, OpenConcept Consulting Free Software for Social Change -> http://openconcept.ca http://del.icio.us/mgifford/drupal http://flickr.com/photos/mgifford/ sets/1178930/ Latest CivicSpace Drupal Launch -> Hameed Law -> http:// www.hameedlaw.ca/

17 24

Yahoo term extraction API and tags
by John Handelaar 18 Jan '06

18 Jan '06

I'll throw this one out there because I won't get to it myself for a couple of weeks at least: Yahoo Web Services' Term Extractor API http://adactio.com/journal/display.php/20060116025204.xml http://developer.yahoo.net/search/content/V1/termExtraction.html Thoughts: a) Would be a *brilliant* way of autofilling tags in the folksonomy modules b) Could enable Google/Yahoo Adwords users to throw those tags at ad invocation and massively increase the relevance of contextual ads for Drupal users. I want b) so much, I'll probably write it. jh

4 4

Path mapping system
by Karoly Negyesi 18 Jan '06

18 Jan '06

Hi! I talked with Ber about path mappings and here are my ideas: *) We remove arg() calls from most of core and use parameters to callbacks. *) Instead of linking to node/$nid , we have a give_me_a_path('node', $nid) function. On admin UI you can choose which handler deals with 'node' type paths. This handler gets $type ('node', 'comment' whatever) and $id as a parameter and creates a path. This is the crux of the matter: instead of dumb string aliasing what path module does currently we create an 'intelligent' subsystem. *) I first thought that we need to add regular expressions to menu to match incoming paths against but I am not sure. The current system, I think is able. See below for an example. For example, a mapping for the type 'user' could describe itself as 'puts usernames into the path'. After choosing this handler when url gets ('user', $uid) , it would hand over these as parameters to the username_path function which would grab name field from user table and return with the path "username/$name". This is one SQL query against user table which is approximately the same amount of work that path does currently -- but it queries an indexed table with a numeric index. The function url() would call only one mapping function per invocation as it is now, with the only change that this function comes from a variable. A menu callback would handle the path 'username', with an argument of $name. This callback is as simple as loading $uid and calling user_page with it. So I think this subsystem could scale nicely. Of course, this is a LOT and LOT of work because we need to change EVERY l/url in core to be an 'intelligent' call. But the results! Regards Karoly Negyesi

12 14

wizard like multi part forms
by Karoly Negyesi 18 Jan '06

18 Jan '06

Hi! I got many requests about this with form API. In contributions/tricks/multipart you will find a module which does this. You will want to delete multipart_menu and multipart_submit and use multipart_fields, multipart_form_alter and _multipart_hide . Any questions are welcome. If someone wants to add a link to handbooks, feel free. Regards NK

1 0

autosave save nodes/drafts
by Theodore Serbinski 18 Jan '06

18 Jan '06

Guys, I posted this a while ago, but Thox and Moshe have resurfaced this with positive comments: http://drupal.org/node/25463 Basically, auto-saving nodes every 1min or so, same way Gmail works (so nifty, has saved my butt so many times!). Now, in order for this work, it is going to need to tie into the proposed workflow module I keep hearing so much about. Reason being, is we are going to need to save a node as a type 'draft' because some elements would be incomplete (e.g., title might be missing). I just wanted to bring this up on the development list and get it on people's radar. And hopefully we can bring this up more in Vancouver during the Workflow session. ted

1 0

+= on arrays
by Karoly Negyesi 18 Jan '06

18 Jan '06

Hi! jvandyk raised the question whether += is officially supported by PHP as it is not in the documentation. I contacted Goba who pointed me to lxr.php.net and from there I read the relevant pieces of PHP source code and it's quite clear it does. Stop here if you are not interested in gory details. I said you should stop, right? OK, here are the details if you have not stopped: http://lxr.php.net/search?string=T_PLUS_EQUAL both in Zend and ZendEngine2 we can see that T_PLUS_EQUAL is executed by: zend_do_binary_assign_op(ZEND_ASSIGN_ADD, &$$, &$1, &$3 TSRMLS_CC); so we move on to http://lxr.php.net/search?string=ZEND_ASSIGN_ADD and jump to http://lxr.php.net/source/Zend/zend_execute.c#1162 case ZEND_ASSIGN_ADD: EG(binary_op) = add_function; goto binary_assign_op_addr; and finally we peek into add_function: http://lxr.php.net/source/Zend/zend_operators.c#613 617 if (op1->type == IS_ARRAY && op2->type == IS_ARRAY) { So. We gained the knowledge that it's split into an addition and an assign before the op types are checked. Therefore, if + works for a certain kind of operation, then += does, too. (Zend2 analysis is left as an exercise. It leads to add_function, too.) Regards NK

5 10

reminder: bugfix party tomorrow Wed. Jan. 18
by ae2005 18 Jan '06

18 Jan '06

Reminder: On Wednesday, January 18, 2006 5pm London time (noon eastern time US, 9am US West Coast Time, 7pm Bucharest time), the Drupal community is invited to a Bug Fixing party. Even if you can't attend at that time, you can still help out. See you there! ae2005 http://drupal.org/node/44182

2 1

Why Drupal 4.7 is late? (long)
by Karoly Negyesi 18 Jan '06

18 Jan '06

First of all, it is not late. It'll be out when it's done and noone said it otherwise. However, it was announced quite some ago that "In preparation of the Drupal 4.7.0 release, development of Drupal core will be frozen on September 1st." http://drupal.org/node/28466 On September 1st, Dries announced http://drupal.org/node/30176 that September 15 is the new code freeze date mainly due to form API and upgrade system improvements. He hoped to have a release candidate on October 7. Form API thread http://drupal.org/node/29465 started on August 23. The Form API was committed to core in October 7. In a mere three months it saw 48 revisions. Bootstrap, for example saw 80 in two years. Even node.module needed four months to reach v1.48 but that was almost five years ago and much, much less code and users were affected. Form API is a big change. Not just the way the forms are defined but the whole workflow is changed. You no longer have access to the POSTed information on form build time, you can interact with that later on via various callbacks. This immense change is percieved as hard but it is not. Aaron Welch (also known as crunchywelch) have converted nothing less than flexinode single handedly in three days time and this included several form API fixes -- this was back when form API itself was pretty bogus. His estimate (and mine) is that it can be done in a day now that form API is fixed up. Other modules have also been converted. Ecommerce is under way. Module developers, brace yourselves and try it. It's not hard if you first forget the old ways. But alas the form API conversion of core were not made by form API experts. You know why? It's so simple. Think a bit on it. I think you guessed it: because there were none (with Adrian being the exception, of course). But how could there be? It's a whole new API. We struggled, learned it, added stuff to the API itself when there was a need. So, there are quite a lot of bugs in core resulting from this conversion and the quality is not even. Currently, there are only a handful people who can -- or want? -- to hammer these bugs out. Everyone, it's impossible for a small handful of developers to fix them all. Often patch fixing efforts abandoned and I need to take over. I took the form API mantle but it's impossible to cope with the load! Currently, being a form API maintainer means that I need to understand _all_ core (there are approx. a thousand functions and some 32K LoC) on an astonishing level because various bugs that were introduced by form API fall somehow on me. If I'd be a millionarie with nothing else to do but fixing core bugs, it'd be a different situation but alas I need to earn money. Do you except the menu maintainer to fix all those menu permission issues just because menu system is used? So, I ask for the help of seasoned developers. Form API is not voodoo magic. It is not written in Brainfuck. It's PHP code which you guys can understand pretty well. It's even documented even if the documentation is a bit spotty. But there are good things also -- because fixing all this stuff took this long, the upgrade system could run its course and got commited on December 6. It's also a very good thing, now modules can use the upgrade system. This sounds a bit deceiving but if you think that there is no difference on a database level between create and alter then you'll quickly realize that this is a pillar for install system. And we can also say that when you have added a feature to your site by installing a new module, it's a new version of that particular site, it's indeed an upgrade. Thanks for bearing with me Karoly Negyesi Ps. If anyone wants to start bitching around "you should have released without form API", then first please show your comment with a September date asking for that on Drupal.org -- I met none in the roadmap posts or the form API thread.

17 24