August 2006 - Development - lists.drupal.org

$node->body
by Dries Buytaert 10 Aug '06

10 Aug '06

Hello world, I just committed http://drupal.org/node/74326. This changes the way $node->body works and will require an update to your node modules and themes. -- Dries Buytaert :: http://www.buytaert.net/

5 4

for those travelling to DrupalCon
by Adrian Rossouw 10 Aug '06

10 Aug '06

"British Airways, acting on instruction from the UK Government, wishes to advise passengers that no items of hand baggage can be carried on board any aircraft departing any UK airport. The UK Government has advised that this instruction will apply to ALL airlines operating from UK airports. http://tinyurl.com/h9tsa Not sure how long this is for , it might just be for the day. * *

6 8

save as draft feature
by justin randell 10 Aug '06

10 Aug '06

hi all, i'm after feedback on exactly what a "save revision as draft"[1] feature should look like in drupal. here are some initial thoughts: 1. make it be possible to save an existing node or revision as a draft by adding a save as draft button - if there is already a draft associated with the node, copy over it 2. make it possible to 'promote' an existing revision to a draft from the 'revisions' tab - if there is already a draft associated with the node, copy over it 3. drafts can be deleted, which sets the node draft column to 0 and deletes the revision 4. drafts can be updated without creating new revisions 5. changes to the published/unpublished status of a draft's 'parent' node has no effect on a draft's status 5. add a draft id column to the node table - one draft per node. the value in this column would correspond to the vid of the row in the node_revisions table for the draft. a value of 0 would represent 'no draft' for a node 6. add a 'draft' tab to the node view, alongside the 'view' and 'edit' tabs 7. add some draft node permissions, so a user can be allowed to edit a node's draft without effecting live content i'm not aiming for a full workflow, just to allow for basic draft functionality. ideas, comments, etc all welcome. cheers justin

4 3

RE: [development] Distilling distributions from configured sites.
by Michelle Cox 10 Aug '06

10 Aug '06

I don't know what the "sites/all thing" is, but I like having all my site specific themes, modules, and files under sites/domain/. What I would like to see in an installer is a series of checkboxes: [ ] Create files directory at sites/domain/files [change] [ ] Create themes directory at sites/domain/themes [change] [ ] Create modules directory at sites/domain/modules [change] I think that gives the user the most flexibility. I especially like the idea of it pre-creating the files directory. Unfortunately, I didn't decide that files would be better in their own site dirs until recently and now I'm stuck. I want to move them but the fact that no one has answered me on http://drupal.org/node/76924 in nearly a week has me scared to try it. LOL Michelle On 8/9/2006 10:59:54 AM, Jeff Eaton (jeff(a)viapositiva.net) wrote: > Eliminates the need *in many cases*... But certainly not in all cases. I > can't imagine someone who wants to put together a web site not putting > at least a few custom modules in, or one or two downloaded (or > customized) themes. > > --Jeff > > > -----Original Message----- > > From: Khalid B [mailto:kb@2bits.com] > > Sent: Wednesday, August 09, 2006 9:53 AM > > To: Adrian Rossouw > > Cc: development(a)drupal.org > > Subject: Re: [development] Distilling distributions from > > configured sites. > > > > > > You are right. > > > > I think the sites/all thing that is in HEAD now eliminates > > the need for site specific modules and themes, and keeps > > things separate from core as well (for upgrades). > > > >

7 7

Re: [development] Distilling distributions from configured sites.
by Adam Cooper 10 Aug '06

10 Aug '06

Earl Wrote: >Ideally the installer would have basic and advanced installs. Basic is, well, basic (hate to reuse the example, but it should be Wordpress-stupid). >Advanced can have a bunch of options in a collapsable group. Can't we just ask one question: "Would you like the ability to host multiple instances of this installation of X?" "Yes" "This will create separate directories for each instances content, themes and modules." "No" "This will create a single configuration... etc" Its simple enough for a single checkbox in the advanced section, and the answer to this question can be used to define whether or not a whole bunch of thing happen; seperate config directories, site specific 'file' directories, host name based config directories the list goes on. Thanks Adam ----------------------------------------------------------------- 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 -----------------------------------------------------------------

1 0

Distilling distributions from configured sites.
by Adrian Rossouw 10 Aug '06

10 Aug '06

So on the topic of distributions (what I am going to call install profiles from now on), some code I recently wrote for http://drupal.org/node/25745, that allows you to very easily rip out the variables configured on the site and store them as defaults. function export_defaults() { global $conf; foreach ($conf as $name => $value) { $output .= "\$default['$name'] = " . $value . ";\n"; // doesn't work for objects... } return $output; } So that led me to think about what other things we have to import / export for new sites. I also discussed the same with Jaza (who is working on the import/export api.). He has targetted the following things in core that need to be copied : http://basement.greenash.net.au/soc2006/CurrentTodoList Jaza's system is far more complex than our meagre needs for the distributions right now, plus it won't be ready in time for 4.8.I also think my proposed approach has a lot of benefits for both our requirements for the distributions (being able to easily build and maintain them), the Drupal API in general and will actually probably make his life easier, possibly even fast tracking some of his code into core. Now my idea (which is very similar to how the views module does it) , is to use a set of functions such as : function drupal_export($resultset, $function, $id_field, $objects = TRUE) { $x = 0; while ($id = db_fetch_array($resultset)) { $object = $function($id[$id_field]); $output .= "\$object[$x] = new stdClass();\n"; foreach ($object as $field => $value) { if ($field != $id_field) { if (is_object($value)) { $output .= "\$object[$x]->$field = (object) " . var_export((array) $value, TRUE) . ";\n"; } else { $output .= "\$object[$x]->$field = " . var_export($value, TRUE) . ";\n"; } } } $x++; } return $output; } function drupal_import($objects, $function) { foreach ($objects as $object) { $function($object); } } for export : $result = db_query("select nid from node order by nid asc"); print drupal_export($result, 'node_load', 'nid')); // or rather save into a file and then on import : include_once 'distributions/default/node.import'; drupal_import($objects, 'node_save); How I see this working is that each module (or thing), will get placed in the distribution/mydistribution/<driver>.import files which are very simply created, and very simply modified. Since we kind of know what order things need to be imported in we will just recurse through the object and import them. These following things are already handled : system table = enabled modules, and themes. Handled by the .distribution file (until we can get dependencies into core that allows them to be configured in the .meta file (ie: requires:theme-bluemarine, blog)) variables (defaults) = handled by the distribution.inc file. see http://drupal.org/node/25745 The following things desperately need to be handled, cleanly and easily : profile-fields, users, node types, locale ,vocabularies, terms, blocks, aliases, files (more on this later) nodes , comments and finally menus. (in roughly that order.) I'm unsure about locale in that list. (maybe it should be a setting?) These are optional, but i'd like to see them : aggregator: feeds, items and categories .. could be really awesome for networks of sites. views : it already does this, but could be used as both the basis for the api, and one of the most practical uses of it. cck : might already do this, but it's important that it does. action/workflow : don't know if it uses it's own table structure or the variable table, but it would be useful for distribution. any other contrib module that would benefit from this. What this however requires , is that we have a consistent set of _load and _save functions, which are all equal to node_load. I feel this is something we should have to begin with. Additionally, especially with node_load and block_load, we will need a way to access the original php code for php filter fields, and not just the output. Also, we need to decide whether initial imports should support revisions (i am not sure they should). Perhaps we could even get away with just having a module_import and module_export hook, which could do the mappings to whatever it's internal functions currently are. This would be a non-invasive way to implement this functionality, and give us a very good idea of what we need to make consisten _save and _load functions for in future releases. Some of this work is possibly already done as part of jaza's import / export project. Some of the node related code might already be living in publish and subscribe. This moves us further away from doing database dumps, and makes distributions a lot easier to create (you would just run 'scripts/build_distro.php --site mysite.comnewdistroname'. And then new sites would use that as their basis. One of the more awesome side effects of this all, being we can also distribute each of these as packages on drupal.org, and teach the install system to install them all. It provides a clean way for modules to distribute views and cck node types etc, perhaps even custom blocks and templates (with the inline template editor i want to write) There are some issues with this on already running sites, with versioning of all these elements, but i believe the dependencies work will end up helping with this. One of the other things I would like to see us do, is to provide variables that have been submitted as part of the distribution specific form, as variables to the .import files. A perfect example of this is having the first node configured as "welcome to your site $edit[fullname]". Even the creation of the first user (for instance), could be handled via this. Another point I came across, is the files directory. I believe the installer should try and create it, and I also believe the distributions should be able to have default files that are copied to the directory. An example being that a brochureware distribution might ship with a customised logo/favicon, and possibly an initial node configured and made to be the front page, which has a nice piece of stock photography already present (giving people a presentable front page to work from). It might even ship with several different templates and allow you to select which one of them you want your front page to look like. That's a rather rambling post for what is actually really simple in concept, and if we build the framework within which to do it and have a developer per import / export object .. we should hopefully still be able to get something like this into 4.8... and then we can watch the distributions bloom =)

7 11

Help get core out of prison
by Karoly Negyesi 10 Aug '06

10 Aug '06

Let's destroy our LOCKs! http://drupal.org/node/55516

2 1

RE: [development] Distilling distributions from configured sites.
by Michelle Cox 09 Aug '06

09 Aug '06

Ah, I like that. I do have a few modules / themes that I want on every site I put in my multi site so I currently have those off the Drupal root. This is a nice alternative. I still would put most of my modules and themes under sites/domain/, though, as it keeps everything for that site in one spot. This is especially important because I have a tendency to muck around a bit with themes and not rename them... Keeps the changes to one site. ;) Michelle On 8/9/2006 3:47:10 PM, Larry Garfield (larry(a)garfieldtech.com) wrote: > sites/all is a new minor feature in current CVS that adds a 3rd place > where modules and themes can be stored. In addition to /modules/ and > sites/sitename/modules/, they can also be placed in /sites/all/modules/. > Modules in /modules/ and /sites/all/modules/ will be available to all > sites, while modules in /sites/sitename/modules/ are site-specific. It's > primary purpose is that there is now no excuse to put modules in > /modules/ > that don't come with the core system. Leave that directory pure and > pristine! The same applies to theme directories. ALL > installation-specific stuff can now go under /sites/. > > (This was one of the decidedly few patches I had time to contribute myself > recently, so I mention it where I can. <g>) > > --Larry Garfield, who wishes he had more time to work on Drupal

1 0

RE: [development] Distilling distributions from configured sites.
by Michelle Cox 09 Aug '06

09 Aug '06

I haven't looked at the installer as I am using 4.7, but I assumed (perhaps incorrectly) that there would be help text in it. Something along the lines of "Drupal can create some useful directories for you. The Files directory is required while the Themes and Modules directories are only needed if you have multiple sites and would like different themes and modules on each site. You can change the location of these directories by clicking the [change] link. If you are unsure what to do, leave them at the defaults and continue." I suggest files be defaulted to create and the other two default to unchecked. I was a beginner just a year ago and I remember it well. Something like this would have saved me a lot of headaches. Michelle On 8/9/2006 1:17:42 PM, Gabor Hojtsy (gabor(a)hojtsy.hu) wrote: > On Wed, 9 Aug 2006, Michelle Cox wrote: > > > I don't know what the "sites/all thing" is, but I like having all my > > site > > specific themes, modules, and files under sites/domain/. What I would > > like to > > see in an installer is a series of checkboxes: > > > > [ ] Create files directory at sites/domain/files [change] > > [ ] Create themes directory at sites/domain/themes [change] > > [ ] Create modules directory at sites/domain/modules [change] > > > > I think that gives the user the most flexibility. > > Try to think of you as a Drupal beginner. Do you understand what these > options mean? Why are you presented with these options in the first place? > > Goba

1 0

feeds as an attack vector?
by Chris Johnson 09 Aug '06

09 Aug '06

At http://intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite Sam Ruby writes: "It is just a matter of time. One of these days, some hacker will deface a popular site like Engadget. But instead of putting something visible on the site, they will put something invisible in the feed. By the magic of syndication, that data will then be distributed like spores to untold thousands of locations. In the process it will be transported from a relatively untrusted location (like BoingBoing) to a place of equal or greater trust. Places like popular portal sites, or just perhaps, to your very own hard drive. From there, it will lie in wait until you check for news. Invisibly it will spring into action. You won’t even notice it running. It will be able to do things that vary from uploading your preferences and passwords to a remote location, to downloading malware onto your machine. Shortly thereafter, this entry will be marked as read, or scroll off the bottom of your river of news, and you will never know how you just got p0wned." It seems like it would be worth thinking about this when working on any part of Drupal that aggregates or generates feeds. ..chris

3 2