August 2007 - Development - lists.drupal.org

Custom FAPI elements in 6.x
by Karen Stevenson 23 Aug '07

23 Aug '07

I have been working on the CCK 6.x port to rework the widgets to use FAPI. In the process I ran into a number of things that confused me, so I wrote up a tutorial on how to create custom elements in 6.x (at http://drupal.org/node/169815) It includes information on the new #element_validate and #value_callback arguments, as well as how to use hook_elements(), #process, #validate, and #submit, etc., and tries to identify what order things happen in and exactly what information is available at each step in the process. I would love to have anyone else familiar with FAPI check to be sure nothing has been misstated, or add anything that might make it clearer or more useful. It kind of goes along with the forms workflow illustration at http://drupal.org/node/165104. Karen

2 1

Good article on MEMORY temp tables in MySQL
by Caleb Gilbert 22 Aug '07

22 Aug '07

>* This could be particularly relevant to Drupal.org if we are still *>* getting temp tables written to disk. It turns out that even when we *>* specify MEMORY for temp tables, MySQL still has the option of writing to *>* disk if other buffers aren't large enough.* This problem has been driving me totally nuts for months now. Until I read this I've assumed that it was something that I was missing/doing wrong. Thanks for sharing the 411.

2 1

any work done/planned on Drupal "HIBERNATION" feature
by zeljko blace 22 Aug '07

22 Aug '07

Hi! I am developing a lot of small sites with Drupal with limited activity and would like to know if there were ever discussion or needs from other "deployers" to have their Drupal website HIBERNATE for a while? Good example would be websites that: * promote events and are active only just before/during/after event, while rest of the time they have no need for interactive features and dynamic content. Putting a static copy of website would not do it here as website goes back to active mode from time to time. * are temporarily without administrator/webmaster * that want to limit web use to a specific date/time to have people few people that use website come together on-line in sync ...hope this is not too strange and would resonate well with people who understand that web publishing could be more then networked-digitized print ;-) Best - Zeljko

7 9

Improving theme('username') with inspiration from Facebook
by Moshe Weitzman 22 Aug '07

22 Aug '07

We have a handy function, theme('username') which accepts a uid and name and returns a profile link. But perhaps that function should be a bit more expressive. See below for the parameters to the equivalent Facebook function (from http://wiki.developers.facebook.com/index.php/Fb:name) * Required - int uid - The id of the user whose name to show. * Optional - bool firstnameonly - Show only the user's first name. (default value is false) - bool linked - Link to the user's profile. (default value is true) - bool lastnameonly - Show only the user's last name. (default value is false) - bool possessive - Make the user's name possessive (e.g. Joe's instead of Joe). (default value is false) - bool reflexive - Use "yourself" if useyou is true. (default value is false) - bool useyou - Use "you" if uid matches the logged in user. Setting to false doesn't work if you use the "loggedinuser" substitution for uid, since users can get freaked out by that. (default value is true) - string ifcantsee - Alternate text to display if the logged in user cannot access the user specified. (default value is [empty string]) - bool capitalize - Capitalize the text if useyou==true and loggedinuser==uid. (default value is false) Do folks think this is a good idea for Drupal core? If not, why? Could we deal with 'possesive' and 'reflexive' flags in a way that respects all languages? I know that this function can be enhanced in Contrib, but my desire is to improve the core.

10 10

The right way to manage Drupal webiste development
by Michel Levy-Provençal 22 Aug '07

22 Aug '07

Hi, We are 4 developpers using Drupal to realize Blogs and news portals. We use SVN to share drupal PHP code. Each developper has his own instance on his computer with his setting.php and mysql database. This is fine for a one shot development... BUT, (there is a but...) 1/ When we make some changes using the admin interface on a developer instance, we have to extract the DB and restore it into the integration instance... At this time each developper must import the integration DB in his instance each time there's an update. It's a huge work to determine what table is a content table, param table or system table... 2/ When our sites will be online, we will need to continue the development. The only way we found to manage this is to lock param tables on the live instance. And when we'll want to update the live website, we'll have to : - update the php code (thanks svn) - and (this is quite touchy) update the param tables using a sql import.... This is the only way we found today to manage our devs... We are looking for some best practice on this subject. Do you know http://drupal.org/project/DAST ? Do you think it can be a solution? -- Michel Lévy-Provençal +336 23 93 60 16 | mikiane.com

6 6

update.php for Drupal 6, and you other favorites
by Gábor Hojtsy 22 Aug '07

22 Aug '07

Hi, I'd like to remind people that one of the most important patches sitting in the queue waiting for your tests and reviews is the update.php for Drupal 6 patch: http://drupal.org/node/157682 It is obvious that we are not planning on releasing a beta without this patch committed. People would not be able to upgrade any test site properly. I would encourage everyone interested in a beta soon to jump on this important piece, test, tear it apart. It would be great to get this committed soon. Also concentrate on your others "favorite" bugs, so we can advance more into the RTBC queue, and get them fixed. Drupal 6 is not yet close to being rock-solid. Eg. I'd also like to see all the themes supplied with RTL support (Garland/Minnelli and Pushbutton is still to get this), on which the guys involved work very heavily lately. Gabor

1 0

ASP Integration with Drupal?
by Ron Dorman 20 Aug '07

20 Aug '07

A client wants to move an existing site to Drupal. The catch is that the existing site has two pages that are ASP. The ASP pages connect to a 3rd party hosted backoffice package and database. The clients current site is on a dedicated leased Win / IIS / Plesk Control Panel server. The Plesk package provides php 5.2 and MySQL 5 so I do not believe we will have any issues installing and running Drupal on the server. Does anyone know of any development, module, etc. that would allow us to integrate the ASP data into Drupal? Any other gotchas I should be looking for? Thank you all for the work you do and for the Drupal software. Ron D.

19 44

project* 5.x on drupal.org
by Chad Phillips -- Apartment Lines 20 Aug '07

20 Aug '07

as of today, we're running an official 5.x releases of project, project_issue, and cvslog on drupal.org. there have been scores of bugfixes in these modules since their last beta releases, check these links for the full list: http://drupal.org/node/168769 http://drupal.org/node/168773 http://drupal.org/node/168758 my two favorite highlights: Support CCK fields on project_issue nodes that show up in the follow- up form. File attachments now preserved on new issue previews! we've still got a lot more small cleanup tasks before we start our next major task: the daunting port to 6.x... all help welcome :) hunmonk

1 0

FAPI's future
by Dries Buytaert 18 Aug '07

18 Aug '07

*** Dries wrote: >>> FAPI and the Schema API: next steps (*) >>> - A plan to get some more CCK/Views into core (*) *** Jeff Eaton and chx replied: >> I do not think we (Eaton+me) will have more ideas for FAPI, all >> the common grunts were solved w/ FAPI3, not until D6 is out, >> modules are ported and projects are ongoing will the flaws come to >> light. Let's get back to FAPI at the spring Drupalcon (Toronto?). > > Yep, I'm with Karoly on this one. There are some cleanup bits and > things we didn't necessarily have time for in FAPI3 (making > form_set_values() and form_set_error() simpler, etc) but those are > tweaks and polishing moves rather than architectural shifts. > > It will take time, time for porting and exploration and envelope- > pushing, to make it clear what changes the next generation will need. Well, I have some issues still. Two simple examples: 1. Say I want to build a "submission throttle module". A user is not allowed to submit more than x forms per hour. If I want to make this module truly generic, I want to make it configurable. Specifically, I want to compile a list of all the forms in the system, and let the administrator enable/disable the forms that should be added to the pool of forms to be throttled. For example, I might include the 'create story form', the 'create comment form', the forms of the privatemsg module, and the guestbook module's form. However, I might want to exclude the search form, and the edit comment form -- I want people to be able to search and edit their comments as much as they want. 2. Take the action module. Right now, we have a hardcoded list of operations that you can attach actions too. While that's nice, imagine a world where you would be able to attach actions to *any* form. All of a sudden, I'd be able to tap into the search form, the sending of private messages, the creation of views, the adding of node types. You name it. The current FAPI does not allow me to build either. So while we have all the power to manipulate *individual* forms, there are no good tools or mechanisms to introduce tools that operate on a large number of forms. For this work, each form needs (i) a human-readable name that can be shown on a configuration page and (ii) all submit buttons require some semantic meta data as well. Right now, 'Submit' can be both 'create' or 'update'. Specifically, I want to be able to work with forms without having to know anything about them. I'd like to see us add some semantic metadata to them. Some of this metadata should be (i) human- readable, some of it should be (ii) machine-readable and (iii) some of it should be both. Thoughts? -- Dries Buytaert :: http://www.buytaert.net/

15 26

Good article on MEMORY temp tables in MySQL
by Robert Douglass 18 Aug '07

18 Aug '07

For those of you who like reading performance tuning stuff: http://www.mysqlperformanceblog.com/2007/08/16/how-much-overhead-is-caused-… This could be particularly relevant to Drupal.org if we are still getting temp tables written to disk. It turns out that even when we specify MEMORY for temp tables, MySQL still has the option of writing to disk if other buffers aren't large enough. -R

2 1