- Development - lists.drupal.org

modify $node->something from hook_nodeapi
by Fabio Varesano 11 Jun '06

11 Jun '06

Hi everybody, I have a module which create nodes of type "mytype" which has a field called "something" accessible from $node->something. I'm working on another module (mytype_change.module) which need to modify one of the "mytype.module" field. I want to change the "something" field of the just submitted node to something different that the user input. If the user insert 'foo' as value of the something field I want that my mytype_change.module can change the value to 'bar' just before the node insertion on database. So while the user thinks that he inserted 'foo' as value of the something field instead the system has registered 'bar' into the database. I'm doing this through the hook_nodeapi where $op param is 'validate'. then I do something like: function mytype_change_nodeapi(&$node, $op, $teaser) { switch ($op) { case 'validate': if($node->something == 'foo') $node->something = 'bar'; break; } } But the code above does not work. The something value is always 'foo' even if I submit or preview the node. Can someone point me to the right direction??? Thank you. Fabio Varesano

1 0

altering an altered form
by Gabor Hojtsy 10 Jun '06

10 Jun '06

Hi, For the new drupal.hu, I am trying to force the path and node options form groups to be always opened on some node types, and path removed on others. Since the path stuff is added with form_alter, my only way if I understand it correctly is to name my module something post "p", so that it is called after the path module, or manually tinker with the weight of modules in the system table. Am I right, or are there better options? Gabor

9 11

Re: [development] xhtml and embed tag: best way to compliance?
by Karl Rudd 10 Jun '06

10 Jun '06

I ran up against this a while ago and through a tonne of research this is what I have come up with. It's not exactly pretty but it works everywhere, including in XHTML Strict. Note the, of course, for Quicktime, Real, etc objects you'll have to change the "type" and "classid" values.  <object type="application/x-shockwave-flash" width="100" height="100" data="flash.swf">   <param name="movie" value="flash.swf" /> <p>Alternative content.</p> </object> Basically you're providing IE with an alternative version of the opening OBJECT tag. Additionally to deal with the whole "Click to interact with ActiveX control" thing I have, wrapped in conditional comments for "IE only", an external Javascript.  Please note the "defer" attribute, it's very important. Basically it makes the script run after the page body has completed parsing, but while images, objects, etc are still loading. In the "iefixes.js" file I have code like this: var objects = document.getElementsByTagName( 'object' ); for ( var i = 0; i < objects.length; i++ ) objects[ i ].outerHTML = objects[ i ].outerHTML; And that's it. As I said, it's not pretty but it's the "least ugly" and the "least intrusive" way I could find to implement all of this. Karl Rudd Fabio Varesano <fabio.varesano(a)gmail.com> wrote: > Hi everybody, > > I'm working on making my video module full XHTML compliant. > > At the moment the module uses a lot of embed tags for displaying video > content (Quicktime, Flash, Wmv, Real, etc...). > > The problem is that embed tags are NOT part of any W3C standard and > make a Drupal site which uses the Video module NOT W3 standard compliant. > > W3 compliant tag for embedding videos on xhtml pages is object but > it's not well supported by Internet Explorer... so an object only > implementation is not possible. > > So I investigate on some work around to create valid code but still IE > compatible.. > > And I finally get some types of solutions: > 1 - Javascript hacks: > basically leave only the object tag then onLoad add the embed tag to > the document. > 2 - CSS Tricks > creating two nested objects then use some css hacks to hide one > 3 - Extending XHTML > extends default XHTML dtds to create a custom made embed tag > > > While the first and second solutions are only hacks and are prone to > errors and incompatibility between current and future versions of > browsers, the third solution is much more elegant and should be > supported by future versions of browsers without giving us headaches. > > So.. IMHO the best way in doing this is solution 3. > > Extending XHTML can be done in two ways: > - creating a custom made DTD > - extending an existing DTD by adding new rule as an internal subset > directly in the document > > The problem is that using a customized DTD will produce a document not > validable by W3C validator.. Other validators can be used. > > Instead extending DTD directly on document will create a W3 validable > document but browsers (even firefox 1.5) will display a "]>" on the > first line of the page... > > So... I'd like to hear your suggestion in facing this problem. > For me the DTD extension on document is the best solution but I need > to find some hacks to let browsers hide the "]>"... > > What do you think about this??? > > Thank you. > > Fabio Varesano

2 1

Move multiple theme per site support to contrib module
by Adrian Rossouw 09 Jun '06

09 Jun '06

I was playing with theme stuff again, and I realised how completely sub-optimal the current configuration is. How many people actually use user specified themes on their sites? This is the kind of functionality that only really clutters up the default interface, and confuses a lot of people for no good reason. We should simply remove the 'enabled' checkbox, and rename the default radio to 'enable'. This removes a chunk of code , and all this can very easily be done via _form_alter now, for those that need it. What I would also like to see , is that we re-organise the the admin as follows : admin display theme (default tab) regions (tab, ie: what admin/blocks used to be) settings (tab) Also. completely getting rid of the tiered theme setting stuff, and only having one set of settings, per theme (same with the block) I do believe that the block / region settings are very much a display issue. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

16 20

api.drupal.org is annoying.
by Darrel O'Pry 09 Jun '06

09 Jun '06

I *really* miss drupaldocs. The two things I miss are: 1) search block 2) wild card searches. When I first started with Drupal both were invaluable tools to me. They saved me a lot of time and helped me get around not knowing the api by memory. Is there anyway to at least get that search block re-enabled? I understand some code needs to be written to get the wild card searches back, I can sort of live without it now that I know the api better.

5 5

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