- Development - lists.drupal.org

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

Re: [development] Drupal's CVS policies... including 'foriegn' code in TinyMCE module?
by Michelle Cox 25 May '07

25 May '07

On 5/23/2007 7:27:59 AM, Scott McLewin (drupal(a)mclewin.com) wrote: > When third party libraries become popular they benefit from a move into > core, like jQuery did, and at that point they become the responsibility > of the CVS maintainers to manage. This is a perfectly healthy > progression, but it is one that has 'handle You make it sound like this is a common occurrence. As far as I know, jQuery was a special case, and it's highly unlikely that, say, TinyMCE would become part of core. Michelle

12 18

i18n status
by Dries Buytaert 25 May '07

25 May '07

As the last "i18n call for action" didn't yield the outcome we had hoped for, I figured I'd try again, and pass this post that Jose wrote: http://www.developmentseed.org/blog/node/494 It provides a good overview of the current state of the i18n in core and high-lights the work-needing parts. Go get 'em now and show that you care. For real. :) -- Dries Buytaert :: http://www.buytaert.net/

1 0

js preprocessor
by Matthew Farina 24 May '07

24 May '07

The JS Preprocessor has been sitting around for a bit and it would be nice to get it into core before a patch is rolled to bring in jquery 1.1.3. I just re-rolled the patch against HEAD. Can anyone take a few minutes and review it? http://drupal.org/node/119441 - Matt

1 0