- Development - lists.drupal.org

Drupal administration survey draft based on 10 interviews
by Kieran Lal 10 Aug '06

10 Aug '06

The survey questions and responses listed below are derived from interviews conducted with Drupal administrators from novice to expert. The responses must be evaluated for clarity and conciseness. All questions are multiple selection in that the survey taker can select those that apply to help us best understand the Drupal users in aggregate. Each question in the survey will have an other selection so we can look for answers that did not surface during interviews. The survey will be done using SurveyMonkey.com. It will run for 45 days linked from the front page of Drupal.org. If you complete all the questions in this survey and would like to be recognized as a contributor to improving Drupal user experience please indicate your Drupal.org username Drupal.org username_______________ How would you describe yourself as a Drupal administrator? (select all that apply) New user Non-technical user developing community or social change web site forced to become "accidental technologist" Inexperienced with Drupal but curious. Learning fast based on other web site building experience Experienced user, comfortable with configuring site rapidly Module developer who understands what's going on behind the scenes Other_______________ How frequently do you administer you your Drupal site? (select all that apply) Monthly Once every couple of weeks Several times a week Daily for 30-60 minutes of website management Daily for several hours in site development and deployment Other_______________ How long do you administer your Drupal site in a single sitting approximately? (select all that apply) Thirty minutes to an hour Few hours Half a day All day long Other_______________ How does Drupal help you accomplish your goals as a web site administrator? (select all that apply) Rapid deployment of features and ability to meet customer requirements saves time Web based content publishing is easy and allows for end user contributions Learnable website that can be taught to users and allows website developers to leverage existing learning when building new sites Allows for monitoring and logging of the website Module configuration, extensibility with new modules, and clean code make it easier to configure the website as you need it Dynamic and exciting community allows for rapid and fun learning Other_______________ Why do you use Drupal? (select all that apply) Features, extensibility, integration of modules, clean code allow you to customize your site Speed of deployment and re-use of existing functionality Quality community is helpful, has smart people, is very active, and is working on community solutions not just technical capabilities Allows users to create content, categorize content, and add navigation to the site Other_______________ How does Drupal help your users? (select all that apply) Gives them the features they want quickly Allows users to create web based content such as forum posts, or blogs Drupal community innovates and provides community building capacity with Drupal Cost effective and winning over non-technical decision makers Other_______________ What are some common Drupal administration tasks? (select all that apply) Monitor site through reviewing logs, looking at user activity Manage spam through comments, track backs, forum, and user registration Configure modules Update modules, install modules, test patches, track fixes for modules Work on themes and add theme template to customize module output Learn about Drupal capabilities and features, understand terminology, and plan improvements Manage users accounts, change permissions Respond to user feedback during testing and make changes Create web pages through the creating content types Other_______________ What are some infrequent Drupal tasks? (select all that apply) Add new features by adding modules or coding new features Manage spam, delete content and comment, and banning users Modify existing content such publishing to the front page, making content sticky, or changing titles Layout content in positions with blocks, views, or designing a content section Change site theme or theme a content section Modify site navigation Other_______________ When you administer your site you find it easy to: (1 is not easy, 5 is very easy) 1-5 Add new features and install modules 1-5 Automate tasks using cron 1-5 Manage user information by editing user account permissions 1-5 Change themes or make changes to layout with theme templates 1-5 Post, edit, and version web pages and other content types 1-5 General settings such as changing titles, or date format When you administer your site you find it hard to? (1 is not hard, 5 is very hard) 1-5 Discover where to configure site settings, or where all the different places where a site needs to be configured are 1-5 Understanding Drupal specific concepts or understand technical language without pictures 1-5 Upgrade modules manually, manage module conflicts in output, download modules that don't include dependencies 1-5 Manage content specifically creating new content types, viewing differences in node versions, importing content, or seeing multiple previews of content on a single page 1-5 Manage large groups or users, nodes, menu items, comments, blocks 1-5 Get overview of new content and activities on site 1-5 Configure user permissions with existing granularity 1-5 Manage menus such as changing menu block weights for all menus on a page, or ordering menu items within a menu What other important tasks did not fit into the categories above for you? (select all that apply) Analyzing logs to understand the state of your site Integrating modules and resolving clashes in the output Setting up a testing process including creating a test role, soliciting feedback from users, configuring corrections, and working with module development process to get bugs resolved Work on the theme and templates to create structure and distinct looks to sections of the site Hide output from modules such as node links or browsing links Managing menus with the menu editing interface, bulk menu editing, and menu options Manage performance of the site Identify popular content Aggregate content from other sources into a site Here is table which was used to manually cluster responses from the interviews: http://drupal.org/node/77193. The clusters were used to make up the survey responses. If one of the survey options is confusing or needs to be reworded please consult the table and source interviews to help in making the responses clearer. Interview 1: http://groups.drupal.org/node/1136 Interview 2: http://groups.drupal.org/node/1135 Interview 3: http://groups.drupal.org/node/1133 Interview 4: http://groups.drupal.org/node/1137 Interview 5: http://groups.drupal.org/node/1134 Interview 6: http://groups.drupal.org/node/1139 Interview 7: http://groups.drupal.org/node/1143 Interview 8: http://groups.drupal.org/node/1144 Interview 9: http://groups.drupal.org/node/1146 Interview 10: http://groups.drupal.org/node/1148

7 11

$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