June 2006 - Development - lists.drupal.org

Re: Data-driven database tables and updates
by Barry Jaspan 09 Jun '06

09 Jun '06

I just joined this list on May 30 so I did not see that thread. It was quite a thread, though. :-) I'll follow up with Adrian directly, but I want to make a couple points addressing the major themes of that prior thread: My goal is not abstraction for the sake of portability. I am sympathetic to many that felt that SQL is already an abstraction and it will not necessarily be easier to use a data-structure based API than CREATE TABLE directly. I agree that changing databases will never be easy and is not really a goal. I also am not advocating for removing SQL from the system generally. I haven't thought about using SQL versus Active Record or anything else enough to have an opinion, but "If it works, don't fix it" is a good starting point. I am addressing only table structure. The goals I can think of at the moment are: - Maintainability. We choose to support MySQL and PostgreSQL. The current _install and _upgrade system, with switches and nearly-but-not-quite duplicated code to CREATE/ALTER TABLE, is ugly and unmaintainable. If we can't choose just one (I'm not saying we should), we should try to minimize the duplicated code needed to support both. - Reflection. There are a variety of good things that can happen if Drupal knows its own database schema. For example, the update.php script could actually validate the database layout rather than trusting that the schema version number in the system table is correct. We could have a self-documenting database scheme by adding fields to the data structure: $tables['node']['nid'] = array( '#description' => 'The primary identifier for nodes.', ...); $tables['event']['nid'] = array( '#description' => 'The node this event data belongs to.', // this could be used to build a graphical schema view '#joinswith' => '{node}.nid', ...); We can assign various properties to tables (e.g. configuration vs data) and treat them differently as a result. And so forth. My concern with the approach I saw discussed in May is that it addresses Maintainability but not Reflection. If we have: function foo_install() { $table = array(...whatever...); db_create_table($table); } we haven't taught Drupal about its schema (sure, db_create_table() could cons up a global based on its arguments at each invocation, but it isn't natural). If we have: function foo_install() { $table = array(...whatever...); return $table; } then we can. I'll follow up off-list with Adrian. Thanks, Barry

1 0

Re: [consulting] Install profiles tutorial for Drupal 4.7, Friday 8AM PST
by Kieran Lal 09 Jun '06

09 Jun '06

Skypecast link: skype:+99001110009867852 Kieran On Jun 7, 2006, at 10:17 PM, Kieran Lal wrote: > Hello, CivicSpace Labs is pleased to announce the release of a > Drupal Install Profile System for Drupal 4.7. > > http://civicspacelabs.com/installer-4.7.2.patch > http://civicspacelabs.com/civicspace-installer.tar.gz > > We are offering a tutorial on how to create install profiles. We > hope to add a install profile system to core Drupal in the next > release. We are supporting an install profile for the CivicSpace > distribution based on Drupal 4.7. As an example we will be > providing a new grassroots group events organizing distribution of > Drupal called GoJoinGo. Angela Byron, a.k.a Webchick will be > discussing how you can easily create your own distribution of Drupal. > > If you have ever thought that Drupal could have better defaults > during installation, or should have certain modules available in > the base distribution now it's your chance to show off how you > would make a distribution. We hope that by releasing an install > profile system for Drupal several months in advance of the next > release of Drupal we can help spark the creation of innovative new > Drupal distributions and even make Drupal itself a better > distribution. > > Documentation for creating install profiles is available here: > http://drupal.org/node/67921 > * .install files must have the t() function removed for now > > Link to the Skypecast is here: https://skypecasts.skype.com/ > skypecasts/skypecast/detailed.html?message=talk_updated&id_talk=9875 > > Thank-you, > Kieran > CivicSpace > _______________________________________________ > consulting mailing list > consulting(a)drupal.org > http://lists.drupal.org/mailman/listinfo/consulting

1 0

no .htaccess perms 500 kills drupal.
by Bèr Kessels 09 Jun '06

09 Jun '06

Hello, Today I ran into another server that did not allow .htaccess. If it finds one, it dies with a 500 (I beleive this is non standard, but it might be used in more places, I saw it twice). A person asked for my help because after the secuit upgrades his site died wih this 500. Two things are important and should be dealt with: * We should not make .htaccess files from with Drupal, not on upgrades and not after installation. Or at least not in this particular situation. It locks people out, without a hint whats happening * The only real solution on such a server is to (move to another on, I know) remove .htaccess, and have no rewrite rules. At least untill recently. We now rely on this file, inside the files dir, for security, meaning if you remove that file, you might be less secured. We must at least document this. Just a note. Bèr

2 2

Patch review
by Dries Buytaert 09 Jun '06

09 Jun '06

Hello world, I'd like to see _rigorous_ reviews of the following patches: 1. Pave the path for CCK (http://drupal.org/node/62340) 2. Install system (http://drupal.org/node/48732) 3. File based caching (http://drupal.org/node/45414) 4. Separate mail backend (http://drupal.org/node/28604) NO dump +1's please, but careful reviews with eye for detail, usability and performance. Yes, this takes more than 5 minutes of your time! :-) A while ago it was suggested that we do a better job defining APIs so we don't have to break them that often; this would be a great time to review the APIs of above patches. Thanks for your help! -- Dries Buytaert :: http://www.buytaert.net/

2 1

User registration without email
by Robert Wohleb 09 Jun '06

09 Jun '06

I've seen people post patches to past versions of Drupal that allow user registration without requiring an email address. I've recently written a patch to user.module for 4.7 that does the same. The reasoning behind this is due to the application. We are using Drupal for an intranet where access to employee information is not possible, and email is not allowed. Because of this, users have to register and an admin has to approve. I have something that works so I don't need to know how to do it. What I need to know is if there is a better way and if this has any chance of getting in to core. At the moment I just patch user.module. Is it possible to do this with a module? If not, is there enough interest to get this as a core option? Whare are the core developers' takes on this? ~Rob -- ---------------------------------------------------------- It is by Caffeine alone that I set my mind in motion It is by the beans of Java, that my thoughts acquire speed The hands acquire shakes; the shakes become a warning It is by Caffeine alone that I set my mind in motion

8 11

aborting user registration and setting an error
by Trevor Mckeown 08 Jun '06

08 Jun '06

Hi, I wrote a quick couple of lines of code that inserts a user into two other databases durning registration. I accomplished this with hook_user under the $op value of "insert". I want to add a check with this module. The check will search the other two databases for the email and username and make sure a dup is not about to be created. If so I need the user to be redirected back to the register page and user registration aborted. The problem is, that I put such a check and redirect in in my hook_user function, but drupal is still creating the users in it's database and redirecting the registration page with the error. I.E the registration process is not aborted. Maybe I need to use another $op value besides "insert"? Maybe a different hook? Maybe some function I am not aware of? Thanks --Trevor

2 1

In 4.7 you can assign regions to any template (node, comment, etc.)
by Nedjo Rogers 08 Jun '06

08 Jun '06

I at least had overlooked the fact that in 4.7 we have the ability to assign regions not just to the page but to any other PHPTempalte template, e.g., node.tpl.php. I've updated the handbook with instructions on how to do this, http://drupal.org/node/29139. This approach should allow much more flexibility in theme design and in block coding for targetted areas, though some care will be needed to make it work intiutively. Issues include: * Users may be confused if they assign blocks to a region that only appears on node pages * Need to distinguish between full node listings and teasers. See also this issue http://drupal.org/node/67681

9 8

Re: [development] no .htaccess perms 500 kills drupal.
by Kobus Myburgh 08 Jun '06

08 Jun '06

> We now rely on this file, inside the files dir, for security, > meaning if you remove that file, you might be less secured. We must at > least document this. > > Just a note. > > Bèr I didn't know we relied on the file. I don't have that file in the files folder. What exactly are the implications of not having it? Currently I have no files which are worth protecting, but for future reference, this might be handy. Regards, Kobus

3 2

Re: [development] In 4.7 you can assign regions to any template (node, comment, etc.)
by Adam Cooper 08 Jun '06

08 Jun '06

Nice, I'd be quite interested in that howto. Will come in quite useful. Thanks Adam Bèr Kessels <ber(a)webschuur.com> To: development(a)drupal.org Sent by: cc: development-bounces@ Subject: Re: [development] In 4.7 you can assign regions to any drupal.org template (node, comment, etc.) 08/06/2006 11:15 Please respond to development; Please respond to ber Display Group Members: |---------| | [ ] Yes | |---------| > Awesome!! > > I'm cc'ing Docs list, as there now can be some comment cleanup on > that page http://drupal.org/node/29139 regarding just this question. > > Laura FWIW I recently added a HOWTO on designing a frontpage with regions. But I cannot find it back (do we really need to restructure the handbook ever few months? :) ) Bèr ----------------------------------------------------------------------- This message may contain confidential or privileged information, and is intended only for the addressee or other persons entitled to access the information. If you are not the intended or authorised recipient of this message, please notify the sender by return and then delete it from your mailbox. Any dissemination, distribution, copying or use of this communication without prior permission is prohibited. Internet communications are not secure and may be susceptible to data corruption, interception, and unauthorised amendment for which Pall Europe Limited does not accept liability. Whilst we have taken all reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Pall Europe Limited does not accept liability for losses sustained as a result of software viruses. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Pall Europe Limited unless otherwise specifically stated. Registered Office and Corporate Headquarters: Pall Europe Limited, Europa House, Havant Street, Portsmouth, PO1 3PD. Registered No 769075, England. -----------------------------------------------------------------------

1 0

VIEWS MODULE: save a view as php code
by Srimal Jayawardena 08 Jun '06

08 Jun '06

Hi does anyone know how to save a particular view (made using the views module) as php code.. The idea is to tweak that php file to further customise the view page. The page url given as view/myview etc is an internal one right? Anyway i can get the php code of that location? o r is ther e a way to save the view page as a normal php file? tnx in advance Srimail.

2 1