May 2007 - Development - lists.drupal.org

taxonomy dhtml: seeking maintainer
by Jakub Suchy 26 May '07

26 May '07

Hi, few months ago, i adopted Taxonomy DHTML module. I tried to fix some bugs, released 5.0 version and thought about some improvements. Unfortunately, i am too crowded with my university exams and work, so I am seeking for new maintainer. This module is not too complex, but there are some issues which raise support request regularly. Tasks for nearest future: - go through pending bugreports - rewrite functionality for block - generate <ul> instead of weird -...<br /> lists (possibly remove it and move functionality to Taxonomy Menu module which duplicates it) - prepare 6.x version in future I will help anybody willing to adopt this module with maintaining as much as i can. Thanks, Jakub

1 0

Actions progress
by John VanDyk 26 May '07

26 May '07

Here's a progress report on actions-in-core. Actions now have a new architecture. Instead of a single function, an action now consists of several functions. 1. An implementation of hook_actions_info(). In this hook, an action is described just like it was in the 'metadata' operation of the previous action architecture. And supported hooks are declared: function node_action_info() { return array( 'node_make_sticky_action' => array( 'type' => 'node', 'description' => t('Make node sticky'), 'configurable' => FALSE, 'hooks' => array( 'nodeapi' => array('delete','insert','update', 'view'), 'comment' => array('delete','insert','update', 'view'), ), ), ); } Batchability has been dropped. Instead of actions declaring themselves batchable and a node_save() being done at the end of the batch, "Save node" is now a separate action. 2. The action itself: /** * Implementation of a Drupal action. * Sets the sticky-at-top-of-list property of a node to 1. */ function node_make_sticky_action($context = array(), &$node) { $node->sticky = 1; $node->revision = 0; watchdog('action', t('Made node id %id sticky', array('%id' => $node->nid))); } 3. If the action is a configurable action such as the "Display a message to the user" action, it needs to define a form, validate, and submit function. The submit function is responsible for returning a keyed array with parameters that will be stored and used when the action is fired. E.g., (validate function not shown): function system_message_action_form($edit) { $form['message'] = array( '#type' => 'textarea', '#title' => t('Message'), '#default_value' => isset($edit['message']) ? $edit['message'] : '', '#required' => TRUE, '#rows' => '8', '#description' => t('The message to be displayed to the current user. You may include the following variables: %site_name, %username, %node_url, %node_type, %title, %teaser, %body.'), ); return $form; } function system_message_action_form_submit($form_id, $form_values) { return array('message' => $form_values['message']); } The HEAD version of actions is now stable enough to demonstrate the assignment of actions to various hooks. It runs on Drupal 5 currently. I encourage you to check it out and give me feedback on http://groups.drupal.org/actions or just in an email. Hopefully we can have a facade action that hooks up to any Drupal form id, and uses drupal_execute() to fire the action. That would mean many Drupal forms become "scriptable" automatically. John

5 5

Javascript API introduction
by Augustin (Beginner) 26 May '07

26 May '07

Hello, I need help about javascript, and I would like to document better a few things at the same time (like I did a short while ago about the cache API: I recycled the help I received to make a handbook page where one was lacking). I have never coded any javascript nor used jQuery before, so I deserve my handle more than ever on this topic. Unfortunately, there is no introductionnary and Drupal specific documentation about javascript, and about the proper use of js within Drupal. There are a few js snippets or js related handbook pages here and there (especially within the php snippets section: http://drupal.org/handbook/customization/php-snippets ). I suggest we create a separate handbook section for javascript (see request: http://drupal.org/node/145660) What is missing, is a Javascript API page, that would serve as a general introduction to using js within Drupal. Please help me answer the following questions, and I'll put it all together into a handbook page: Is the Drupal js API limited to those? http://api.drupal.org/apis/5/js What js is included with core, that one can use without messing with any js code? (what is needed here, is at least a short introduction to the core .js files: [augustin@203 misc]$ ls *.js autocomplete.js collapse.js drupal.js jquery.js progress.js tableselect.js textarea.js update.js upload.js when they are used (i.e. included in the page request), what can be done with them without needing adding any additional js code, etc. If jquery is included in core, does that mean that I can start adding the relevant tags in html without bothering with js code?? What else would a beginner need to know, to get started efficiently working with Drupal and js? Beside http://www.learningjquery.com/ , http://jquery.com (hmmm, the latter times out), what other web sites or (Drupal-specific) articles hosted elsewhere would it be useful to link to? Thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

9 10

Data API and JSON/XML for Drupal 6 status
by Nedjo Rogers 26 May '07

26 May '07

Dries wrote: > here is my top-6 things I'd like to see us focus on. In > order of priority: > 5. Paving the path for webservices: data API, being more XML/REST/ > JSON friendly, etc. Three relevant patches in the queue are: 1. http://drupal.org/node/145551, Enable dynamic page loading and rendering into different formats (JSON, XML) This patch enables e.g. a normal page request made with jQuery to be returned automatically in JSON format. There is a sample module with the patch to be used for testing. Ideas needed: how could we use the menu system to detect which format to render a particular theme call in? This patch needs a lot of review and improvement. 2. http://drupal.org/node/113435, Data API, first steps (See also, for context, http://drupal.org/node/145684, Data API, further steps.) This patch introduces a consistent set of drupal_load(), drupal_save(), and drupal_delete() methods for different object types as well as a hook_dataapi() to replace hook_nodeapi(), hook_taxonomy(), etc. It also allows all of these methods to be overridden by contrib implementations. So, possibly, we could develop a schema-aware improved Data API in contrib during the 6.x cycle for merging into core before 7. Would need a lot of testing and people wading in to fix and improve it if it's going to get in before code freeze. 3. http://drupal.org/node/140860, Consistent table names to facilitate CRUD operations This is a simple update to provide consistently named tables. The payoff is that we could then implement e.g. drupal_load('term', 8) using a single generic schema-aware function, rather than needing separate load functions for each object type.

1 0

historical node counters
by Jeremy Andrews 26 May '07

26 May '07

Hello, I roughed out a proof-of-concept patch against the statistics module that makes it retain historical view count information. http://drupal.org/node/142668 Before this patch there's just a global per-node counter showing how many times each node has been viewed since the node was created. There's also a 1-day view counter that is reset every 24 hours, offering a rough estimate of how many times a story is viewed each day. With this patch the information is divided into 1 hour increments, allowing a site admin to see how popular each node has been in the past hour, the past few hours, the past week, at 3 pm a week ago Tuesday, the month before last, etc. The patch is sufficient for collecting the data, and the per-node counters still are displayed properly, but some time needs to be spent building queries for the top-nodes type page/block. (This is reflected by TODO notes in the patch) If merged, the next step would be visualizing this data using simple graphs, allowing you to plot the popularity of one or more nodes over time. (With these changes to the node_counter table, such graphing could be handled by a contrib module). At this point I'm gauging interest to see if 1) someone is willing to finish the patch, crafting the necessary SQL queries that are still missing and marked with TODO's, or 2) if it's worth my time to continue along in this direction. I'm also curious if people think 1 hour granularity is too fine, and it would be better left at 24 hour granularity. Feedback is best made in the issue rather than in response to this email. Cheers, -Jeremy

1 0

Re: [development] Drupal's CVS policies... including 'foriegn' codein TinyMCE module?
by andy＠spiders-lair.com 26 May '07

26 May '07

I've been watching this thread for a while and think it's time to chime in (on a personal basis, not as a d.o CVS Admin). Developers need to be aware that Core has it's own CVS repository to Contrib and it's policies are decided solely by the Core Committers team, so using the "jQuery got in" is a moot point imho. As I see it, the commit of 3rd party libraries in Contrib generally should not be allowed as:- a) It basically creates a duplicate code repository of code that should be availble from a single authoritive source. b) Uses Drupal.Org resources to effectively host "someone elses work". c) It's potentially a security risk, especially if maintainership is slack. Although problems aren't Drupal related directly it presents a sloppy view of the project as a whole imho. I am of the personal opinion however that, where effective, certain pieces of work should be allowed into Contrib when it meets a certain criteria or benchmark. For example, where a 3rd party library is heavily modified to make it more suitable directly and solely for use with Drupal and hence the target is audience is Drupal specific. Such a decision would be based on a case by case merit of "how that commit makes Drupal end users lives so much the better". The only argument against this that I can think of is "who and how makes the decision" as it's basically more work on a volunteer workforce. Well, I suppose discussions like this are the best way :) I think it's fair to say that if such a policy existed, this thread has demonstrated (to me at least) that the maintainers of TinyMCE have successfully argued their case and would be the first Contrib "to pass the acid test" and be permitted to commit it's 3rd party library assuming they have the kind backing of the original authors of the 3rd party library. But I'm still of the opinion that generally (and blindly) committing 3rd party libraries (especially unmodified versions) into Contrib CVS should not happen. </2p> --Andy (AjK)

8 7

OpenID for core
by James Walker 25 May '07

25 May '07

Hello world, So, we've all heard mention that OpenID support is "in the plan" for Drupal 6 ( http://lists.drupal.org/pipermail/development/2007-May/023616.html ). Here's an update on where things are: Background: The "dist auth" system (a la drupal.module) that's been in Drupal *forever* has some long standing security issues. Essentially they boil down to the fact that you give the password for your "identity provider" site (e.g. @drupal.org) to the site where you're logging in. This makes it very easy for "bad guys" to capture this information and use it to compromise your @drupal.org (or other) account - with full control. Because of this, OpenID is not a "drop-in" replacement - it works fundamentally differently. But, quickly, here are some reasons "why OpenID": * It's a publicly available, open standard - meaning OpenID for drupal works with all other openid-supporting systems. * There is ever-growing momentum behind OpenID - Microsoft, AOL, Sun have all at least pledged support for OpenID - as well has several "web2.0" companies and services. * It addresses the security concerns with drupal's native dist-auth. Some basic info: * The issue for tracking is : http://drupal.org/node/131026 * All of the code up for consideration is in the HEAD branch of the openid module in contrib: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/openid/ * The module uses all drupal-native code (no external library dependencies) and implements the 1.x and 2.x authentication protocols as a "relying party" (see http://openid.net/specs.bml) Features: * The module form_alters the user_login form (and block) to add a "log in with OpenID" link and login box where you can enter your OpenID url. where you can then do a standard login. * For new accounts - full user_register validation is performed - which means only valid user accounts are created (unlike current distauth that creates users without email addresses). This also means if you have things like required profile fields for registration, people can not bypass this via openid login. (/me waves to Angie). To simplify this for users, I've included support for "nickname" and "email" from the "Simple Registration Extension" - which is supported several major openid providers. * For existing accounts, when the module is enabled, you will have a page under "my account" where you can add & remove OpenID's associated with that user account (and new openids are validated before adding). So you can use multiple OpenID for existing accounts. "APIs" (since nothing gets drupal developers going like a new API): There are two major functions that can be used if you want to do OpenID authentication for other purposes (say - use OpenID to validate an "anon" commenter without creating a local user account) : * openid_begin($claimed_id) : this initiates the openid authentication (discovery, association and authentication redirect) for the given "claimed ID". * openid_complete($response) : this verifies and finalizes the data returned from the OpenID Provider. Status: >From my point of view the code is feature complete for a core offering. Dries has asked me to post here to bring attention to the issue and get some additional reviews. (Oh, and I need to add openid.schema as of this morning ;) Thanks to all that have tested and offered patches/feedback/etc. Can't wait to see this one land :P -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net

1 0

Schema API committed for D6
by Barry Jaspan 25 May '07

25 May '07

Dries committed the Schema API patch this morning. Henceforth, all tables should be declared in .schema files and update functions should use the Schema API instead of explicit SQL or the former pgsql-only db_add_column()/db_change_column() functions in update.php. (Explicit SQL and those pgsql-functions will keep working, of course, so this does not represent a "flag day" for contrib.) The schema.module in contrib will automatically generate a schema data structure for any table that already exists in the database; you can then copy and paste it into your .schema file. I'll be writing some handbook pages for all of this in the near future. Thanks, Barry

3 2

Re: [development] Drupal's CVS policies... including
by Ken Rickard 25 May '07

25 May '07

I see both sides here. Compromise proposal. Include a section in the Project description that lets the developer place links to the supported third-party libraries hosted on external sites. These would be similar to the CVS / Documentation link fields that we have now. Data needed: - TItle - Link - Module Release Version(s) - Notes (optional) It might also be good to have a function that could check the user's installed library hash against the "sanctioned" version used by the module developer. This feature would be similar to (incorporated into) the update_status module. The proposed hook would simply be a function that let the module pass hook_hash($path, $filename). We might store the library hash values in the module.info file. If the hash check fails, update_status would flag the module as needeing an update. Seem like a plan? - Ken Rickard agentrickard

9 11

Re: [development] Actions progress
by Michelle Cox 25 May '07

25 May '07

On 5/25/2007 8:13:28 AM, Karoly Negyesi (karoly(a)negyesi.net) wrote: > > There are two pending core patches that may be action-ified: > > 1. http://drupal.org/node/146076 - ban the author while deleting > content > > May. Or may not. If the action patch lands. If this gets converted. > > The patch is there, the patch is ready. I really would like to see it > committed -- we can always remove it when a better solution comes along. I'm with chx. I really want to see this get in and be used on d.o. If we have something that's working, let's go for it. Being able to delete spam and then having to go file and issue or hunt down an admin for the block is a pain. I'd love to be able to just do it all in one action. Especially when you get a prolific spammer that adds 20 more before you can get someone to block them. Michelle

1 0