April 2008 - Development - lists.drupal.org

programmatic creation of node
by Novák Áron 11 Jul '08

11 Jul '08

Hi! While the development of FeedAPI, i faced with a problem. FeedAPI has to create nodes programmatically, i believed that this is a really easy thing to do, feedapi now works like this: $node->data1 = "foo"; $node->data2 = "bar"; node_object_prepare($node); // this is about the default values node_save($node); But I got a report that this is not a good way to do: http://drupal.org/node/196273 Summary: "node_object_prepare() and node_prepare() functions are meant to simulate the demonstration of a node" And some users, who use FeedAPI + 3rd party modules together, really experience bugs around node creation / handling: http://drupal.org/node/195105 (summary: the core forum module uses form_alter to pass taxonomy-like data. And this data is lost now.) Can you suggest me a perfect way to handle this problem? mustafau (http://drupal.org/user/207559) suggested to use drupal_execute($form_id, $form_values), but in this case, i had another problem: drupal_execute has no useful return value and $node structure remains unaltered, so i had to do a node_load after this, which is quite expensive. Thanks, Aron Novak

11 20

RFC: drupal as a moving target
by Caleb Gilbert 08 May '08

08 May '08

> > You are. The community may benefit from Acquia's 'public' > support/choice of contributed modules it in no way, shape or form > establishes a 'gold' repository at drupal.org. Many companies have a > suite of modules they commonly use and track, just don't make public > that list. > Firstly - barring official announcements which I haven't seen, Dries nor Aqcuia have publicly stated that they *would* not help try to inject some sanity into upgrade/development cycles (e.g., making sure that certain contrib module's don't get left too far behind) Also, I never mentioned a 'gold' repository. My original intention was simply to sign on too the idea that catch suggested which I understood it was - 'why release a Drupal version that no one is going to use for any large/critical sites for six months (or possibly ever)'. In addition to myself, I know at least one other (large) shop that has more or less committed to skip Drupal 6. This is what's happening and no one wants to deal with it and just poo-poos such talk as being irrelevant. But it is happening, and it's up to everyone to form their own opinion of any relevancy. (personally I'm fine with the idea that some releases end up this way IF was more publicly acknowledge instead of hushed up, which is what I feel like is happening now to some extent) The real point of all this, which makes this discussion not just a pedantic exercise, is that I truly feel sorry for anyone starting up a big project right now who is just getting into Drupal and trying to make sense of what version to use. I've seen people giving others what I consider to be very bad advice and representing a state of stability/readiness for Drupal 6 which, in my considered *opinion*, is just not there. Regards, Caleb

13 21

RFC: drupal as a moving target
by Ivan Sergio Borgonovo 02 May '08

02 May '08

There are things that should be considered obsolete on the drupal handbook as the OOP policy and the security policy... and a "myth" that the community seems to be proud of: Drupal is a moving target and we aren't scared to break the API. Drupal is now a mature project and people start to rely on it for projects that have a longer life span than the release process of Drupal. Still there are parts of Drupal that aren't still mature enough to provide a "stable" API and freezing them there would hurt the project. I did a rough estimate (sed -e '/5\.[xX]/' | wc) on http://ftp.drupal.org/files/projects/ this doesn't take into account multiple versions, features that moved to core, etc... But the result is indicative: D5: 372 D6: 76 I did read: http://drupal.org/handbook/version-info and http://drupal.org/node/65922 In the face of the current status of Drupal project and on the above data isn't it the time to adjust the above policy a bit? I think that many core dev grew up with Drupal and now have to babysit projects based on Drupal that have a longer lifespan than a Drupal release cycle, so it shouldn't be a problem to actually reflect this in a public policy that will help others to make their plans too. Weren't we saying that Drupal value resides in being a framework rather than a finished product? What is the value of a moving framework for devs? What about the development process and focusing on improving the aspects that will contribute in offering a mature *stable* API... or does this sound as a blasphemy? I saw that the later document got an important revision (August 2007) when life-cycle moved from 6-12 months to 12-24. -- Ivan Sergio Borgonovo http://www.webthatworks.it

29 58

adding a filter to a view
by Lluís 30 Apr '08

30 Apr '08

I am creating a module with views, I have just created a page which creates a view with a filter coming from arguments, but the sql fail. The code is: <?php $view = views_create_view('llista_assentaments', 'Llista dels assentaments'); views_view_add_page($view,t('Llista de projectes'), 'comptacau/llista_assentaments', 'table', true, 2, '', 1, false); //trans views_view_add_field( $view, 'node','title',t('nom'), TRUE, 0,'views_handler_field_nodelink'); views_view_add_field( $view, 'comptacau_assentaments', 'projecte_nid', "projecte_nid", TRUE, 0, ''); views_view_add_filter($view, 'node', 'type', '=', 'comptacau_assentament', ''); views_view_add_filter($view, 'node', 'status', '=', 1, ''); views_view_add_filter($view, 'comptacau_assentaments', 'projecte_nid', '=', $nid, ''); drupal_set_message("vista: ".nl2br(print_r($view,true))); //debug views_sanitize_view($view); return views_build_view('page', $view, array(), false); ?> and the error is: <code> SELECT DISTINCT(node.nid), node.title AS node_title, node.changed AS node_changed, comptacau_assentaments.project AS comptacau_assentaments_projecte_nid FROM ccc_node node LEFT JOIN ccc_comptacau_assentaments comptacau_assentaments ON node.nid = comptacau_assentaments.nid INNER JOIN ccc_node_access na ON na.nid = node.nid WHERE (na.grant_view >= 1 AND ((na.gid = 0 AND na.realm = 'all') OR (na.gid = 4 AND na.realm = 'comptacau') OR (na.gid = 1 AND na.realm = '4_comptacau') OR (na.gid = 1 AND na.realm = '4_comptacau_2'))) AND ( (node.type = 'comptacau_assentament') AND (node.status = '1') AND (.projecte_nid = '5') ) //?!?!?!?!?! ORDER BY node_title ASC </code> The problem is it don't detect the table, but I have done a print_r and it appears well done: <code> ......... [filter] => Array ( ................ [2] => Array ( [tablename] => comptacau_assentaments [field] => projecte_nid [operator] => = [value] => 5 [options] => ) ) ............. </code> I thought the problem may be when definig the field, but if i remove this filter, the field is loaded and shown correctly in the screen. any hint of where is the error? thanks -- *Si tu fas una foto a una vaca, la vaca no et diu re. *Envellim quan els records superen les esperances. *Als llocs desconeguts només s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

2 2

RFC: drupal as a moving target
by Caleb Gilbert 30 Apr '08

30 Apr '08

> > There is no 'gold repository' for contributed modules. (Yet another repeated variation on this debate) > > Au, contraire - if I'm not mistaken this is *exactly* what part of Acquia's business model is based on. If this doesn't imply some sort of parallel benefit-of-sanity for the larger Drupal community then I am indeed very confused about many things. - C

3 2

RFC: drupal as a moving target
by Caleb Gilbert 30 Apr '08

30 Apr '08

> > If anything this suggests another approach: if Views and/or CCK don't get as > much into core as we'd like for D7, then perhaps we should consider either > > of them not being ported to D7 a release critical bug for D7 core too, and > not release without them. > > That's the best idea I've heard in a really looong time! I could be wrong but implementing that is probably as close as Drupal can get to letting *everyone* have their-cake-and-eat-it-too. (e.g., in the backwards-compatibility-proponents vs. break-the-api-whenever-proponents saga) - Caleb

1 0

backporting sec patches
by Ivan Sergio Borgonovo 30 Apr '08

30 Apr '08

Since I will need a longer life cycle... I know I'll have to support security patches for at least one more older release starting from 5.X. I know that patching your own 3, 4 web sites that lag behind is one thing, providing patches for a whole community is another thing. Providing security support for older modules it is even a larger task. Making proactive security assessment for older versions is absolutely out of my reach. As a minimum I could provide svn patches for security problems that have been discovered in newer versions and that apply to older versions. To make this effective I'd be informed in advance of the security problems that have been signaled to the sec team before they get public. I could start to take care of this in a *very* informal way. That means that I'll make aware people that they CAN'T relay on this service and see how it goes. Depending on how things go, it could be worth to learn something about the Drupal release mechanism, see if other people can help... etc... I don't know. What I think I can handle is: - getting informed in advance of DN and D(N-1) security problems in core - see if they need to be fixed in D(N-2) and publish a svn diff somewhere concurrently to the DN/D(N-1) public security announcement. - try my best to see if a module security problem can be fixed in older core and provide a patch What I know I won't be able to handle is assisting in fixing security problems in older modules or providing a full tar of an older patched version or manage DB update path. That in the hope that: - I could gain access to early warnings - someone will reach me in the task so that if one is busy/ill/etc... the other can still provide some support to the community, me included. If anyone is willing I could reach the sec team to get used to the way they operate now, make some enemies, call some names, help a bit fixing 5.X sec problems till 5.X will be obsoleted and evaluate in the light of my new experience if and how I can sustain what I proposed. -- Ivan Sergio Borgonovo http://www.webthatworks.it

2 2

Re: [development] RFC: drupal as a moving target
by Victor Kane 28 Apr '08

28 Apr '08

On Mon, Apr 28, 2008 at 11:19 AM, John VanDyk <jvandyk(a)iastate.edu> wrote: > At 1:29 PM +0200 4/28/08, Ivan Sergio Borgonovo wrote: > > > Drupal is now a mature project and people start to rely on it for > > projects that have a longer life span than the release process of > > Drupal. > > > > My understanding is that these kind of people are the target market for > Acquia's commercially supported Carbon distribution. > John's comment goes to the heart of the question. I think the security is admirable in Drupal. I want to remove that entirely from the discussion, because moving target or not, we have the best security we could possibly have. But I think the central policy point worth discussing is: in order to obtain a Drupal capable of actually being used in the real world for production sites, must one be forced to opt for commerical products / versions because the real cost is enormous? I use Ubuntu, the free, open source, off-the-shelf release, and I am not forced to pay for a "Red Hat" version to rely upon it. The question being raised is this: Is Drupal being driven to be such a fast moving target that real time-to-market costs can only be afforded by large shops? If the answer were yes, then we are forced to examine whether economic/financial/corporate interests are at work pushing it in that direction. Instead of sweeping the issue under the carpet. Victor Kane http://awebfactory.com.ar

8 9

Unsubscribe Out of office reply Fw: 来自lxdff@sina.com的自动回复
by Ivan Sergio Borgonovo 28 Apr '08

28 Apr '08

I'm posting this to the list since I couldn't see any admin contact in the ml headers. My daughter said it is an out of office reply. I think it is someone subscribed to the dev list. Could someone unsubscribe this address? thanks Begin forwarded message: Date: Tue, 29 Apr 2008 01:49:29 +0800 (CST) From: <lxdff(a)sina.com> To: <mail(a)webthatworks.it> Subject: 来自lxdff(a)sina.xn--com-0x2eo6q3udsr5e8bt 已经收到您发来的邮件，我会尽快给你回复！ -- Ivan Sergio Borgonovo http://www.webthatworks.it

2 2

Re: [development] RFC: drupal as a moving target
by Jens Moewes 28 Apr '08

28 Apr '08

exactly - but there are a bit more companies outside there which can provide corporate solutions, though ;-) . . . you don´t need carbon to provide service level agreements 2008/4/28 John VanDyk <jvandyk(a)iastate.edu>: > At 1:29 PM +0200 4/28/08, Ivan Sergio Borgonovo wrote: > > > Drupal is now a mature project and people start to rely on it for > > projects that have a longer life span than the release process of > > Drupal. > > > > My understanding is that these kind of people are the target market for > Acquia's commercially supported Carbon distribution. >

1 0