- Development - lists.drupal.org

[drupal-devel] [bug] node created timestamp changes on node edit
by adrinux 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/24002 -Project: Image +Project: Drupal -Version: 4.6.0 +Version: 4.6.0 -Component: image.module +Component: node.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: adrinux Updated by: adrinux Status: patch No time to test this until next week myself, but It's already got two +'s so I'm moving it to core and re-titleing. Thanks to dtan for hunting this one down :) adrinux Previous comments: ------------------------------------------------------------------------ May 31, 2005 - 17:57 : adrinux When an image node is edited it changes position in the gallery, and in image taxonomy listings. This is not the usual 'most recently edited' item floating to the top. The edited image simply shifts to a different place in the gallery with no apparent logic. As far as I can tell this happens because image module sorts the images in a gallery by the node creation timestamp, and for some reason the creation timestamp is being incremented a little on editing the node. (Of course the changed timestamp also changes as expected.) Here's and example. Lets take this gallery http://sphop.perlucida.com/image/tid/62 And change the title from *sphp_2002_061_henk.jpg* to *Seagulls* on this image: http://sphop.perlucida.com/node/322 Prior to the change we have the following (info extracted from the db): nid: 322 title: sphp_2002_061_henk.jpg created: 1117550744 changed: 1117550744 And the image is listed between *sphp_2002_062_henk.jpg* and *sphp_2002_060_henk.jpg* as you'd expect. We change the title and image moves to appear between *sphp_2002_067_henk.jpg* and *sphp_2002_066_henk.jpg* as you can see: http://sphop.perlucida.com/image/tid/62?from=12 The db now gives: nid: 322 title: Seagulls created: 1117550756 changed: 1117558316 So, why does the *created* timestamp change at all, and can I stop that happening? I should say that the images in the gallery were initially imported using import_image.module - but I don't see what this could have to do with that. ------------------------------------------------------------------------ June 30, 2005 - 01:59 : dtan Attachment: http://drupal.org/files/issues/node.module.created.patch (591 bytes) You'll notice that there is an authored on text box. . .it doesn't provide seconds, so when the timestamp is created, it picks up the current minutes seconds. Thus if you edit a node (any type) and view its created field in the db, and continuously repeat over 60 seconds, you will see the created loop back down. Here is the patch. . .which is actually applied to the *node.module*. ------------------------------------------------------------------------ June 30, 2005 - 02:42 : clydefrog dtan, your patch contains html. ------------------------------------------------------------------------ June 30, 2005 - 04:40 : dtan Attachment: http://drupal.org/files/issues/node_module_created.patch (591 bytes) another one :) ------------------------------------------------------------------------ June 30, 2005 - 16:13 : Jose A Reyero Hey dtan, I'd say very good catch :-) , tested the patch and seems to be ok. Anyway, I think this bugfix needs to be posted to Drupal core. ------------------------------------------------------------------------ June 30, 2005 - 20:22 : mfb +1

1 0

[drupal-devel] important: check_output()
by Dries Buytaert 01 Jul '05

01 Jul '05

Because of the recent security issue, we were forced to modify check_output()'s API. check_output() now takes a third paramter $check. If check = TRUE, check_output() checks whether the current user is allowed to use the specified input format. Note that this will check the permissions of the current user, so you should specify $check = FALSE when viewing other people's content. When showing content that is not (yet) stored in the database (eg. upon preview), set to TRUE so the user's permissions are checked. In DRUPAL-4-6, $check defaults to FALSE. However, in HEAD, $check defaults to TRUE for extra safety. This means you'll have to check your code in DRUPAL-4-6 to see if you don't need to insert a TRUE, and that you'll have to check your code in HEAD, as most of them will need an explicit FALSE. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] [feature] Custom registration fields should appear on admin/user/create
by chx 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/23536 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: normal Assigned to: chx Reported by: moshe weitzman Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/user_reg_0.patch (9.01 KB) It was intentional that the check for required fields are skipped for admins. I deleted that check. chx Previous comments: ------------------------------------------------------------------------ May 24, 2005 - 21:02 : moshe weitzman When creating a new user as an admin, it is useful and even expected to be able to complete all the profile fields which are available on the usual registration form ... the approach might be to consolidate registration so that both users and admins use a single form. ------------------------------------------------------------------------ June 26, 2005 - 00:27 : chx Attachment: http://drupal.org/files/issues/user_reg.patch (8.69 KB) At first I thought it'd be better if I'd keep the separate form, but this version results in shorter code and it's not so ugly. However, if you do not like it, I have the version which only adds the $extra to user_admin_create. ------------------------------------------------------------------------ June 26, 2005 - 20:08 : killes(a)www.drop.org I like this patch. ------------------------------------------------------------------------ June 28, 2005 - 03:53 : moshe weitzman to me, this version is great as it unifies the registration code. i did a code review and all looks good to me. i applied the patch and noticed that - i added a required checkbox field via profile.module. the check appeared on the reg form without the 'required' marker and the registration was accepted without checking the box. then i tried this for a textfield and it properly showed the 'required' marker but it didn't enforce the 'required' bit either. so then i tried to edit the user and even then we seem not to be enforcing the 'required' bit. this looks like a profile.module bug. if you are up for it, you might want to investigate the above. but truly, enforcing the required bit is not related to this patch. so +1 from me.

1 0

[drupal-devel] Hardened PHP
by Karoly Negyesi 01 Jul '05

01 Jul '05

Hi! One of our users have found that the access control page works extremely strange under hardened PHP: after a given amount of checked checkboxes, if you check one more, you are most likely find yourself logged out. I was given access to his site and can confirm this behaviour. I have not filed a bug report (and looks he did not either) because this is a bigger issue IMO to begin with: is there anyone on this list who uses hardened PHP and willing to become maintainer? If not, we should document that we are untested with hardened PHP. Or, rather is this a bug in hardened PHP? Regards NK

1 0

[drupal-devel] [feature] Menu fast edit node links
by mathias 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/9178 Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: normal Assigned to: mathias Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/menu_fast_edit_0.patch (3.17 KB) Patch has been updated per Dries' suggestions. mathias Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 11:15 : mathias Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB) When developers are creating custom menus, the process of adding content becomes twofold: 1. Create content 2. Navigate to administer > menus > add menu item and add the latest node entry This patch adds a link hook to the menu module. Specifically if a node does not have a menu entry the 'add menu item' link appears. If a menu item exists, the 'edit menu item' and 'delete menu item' are displayed thereby speeding up the publishing workflow. Note: This feature is only present when the menu module is enabled. Status: Waiting for JonBobs blessing ... ------------------------------------------------------------------------ July 10, 2004 - 11:21 : JonBob This is interesting. I do have a couple reservations. This adds a bunch of queries to node listing pages, since it has to check for every node whether that node has a menu item set. I also wonder how much time this saves the user in reality. It saves navigating to the menu admin screen, sure, but provides little other help. It seems that if we are to provide a link to the menu item add page, we should at least be pre-filling in the path and title fields for the user. The provided method is little better than having the menu admin page open in another browser tab. Maybe a node link isn't the right interface for this, anyway? Possibly a tab, or a hook_nodeapi('form admin') injection? If done right, this could finally replace that aging "link title" field in page.module nodes. ------------------------------------------------------------------------ January 24, 2005 - 15:23 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB) This new patch gives users the ability to define menu items on any node creation/editing form. Screenshot here: http://asitis.org/tmp/menu_quick_link_form.png [1] It does this through nodeapi (as suggested by Jonbob), which means that any node has access to these fields unless specified otherwise via the new menu configuration settings. The functionality lives in menu.module, and users with 'administer menus' permission are allowed to edit the menu item fields inside the node form. One more note. I'm also proposing the addition of a misc/drupal.js [2] file to Drupal core (* gasp *). Currently it includes javascript functions to hide regions of a page. When a link is clicked on for a collapsed region, the region unfolds revealing the additional parts of a page. In this case the menu item fields are displayed after clicking the 'Menu item settings' link. I think it helps make best use of screen real estate, but we'll leave that verdict up to the usability experts. Let's remove the js file if it's the only thing stopping this patch from being submitted. I thought it might be worth exploring, especially for form pre and form post regions of the node form. [1] http://asitis.org/tmp/menu_quick_link_form.png [2] http://asitis.org/tmp/drupal.js ------------------------------------------------------------------------ January 24, 2005 - 15:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 07:17 : Bèr Kessels +1 on the feature, I use menu_otf all the time. -1 for the javascript. Not that i am against it, ion contrary. I think we should not start implementing JS on a per-case basis, but we should introduce a javascript system that can do your accordeon-magick on any element. So it should wait IMO. ------------------------------------------------------------------------ January 25, 2005 - 09:07 : Dries I agree with Ber: +1 for the feature, -1 for the Javascript. This would (or should) be easy to implement/integrate as soon the new node forms are done. Both the new node forms, and this feature are crucial. ------------------------------------------------------------------------ January 27, 2005 - 14:39 : mathias Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB) Okay, here's the latest patch, footloose and javascript free. ------------------------------------------------------------------------ February 1, 2005 - 02:04 : robertDouglass +1 to the feature, with or without javascript. The Menu item title:* is showing that it is required, but it can't be required as that would force users to create menu items (and it doesn't validate to be required). The patch does, however, open up a big can of permissions worms, and lacks configuration. I would like to see a checkbox on the Workflow (/admin/node/configure/types/{type}) page so that I can hide this on a per-type basis. Then, I think we need some way of limiting this by role, by user, and by menu. I would at least want an "excluded menus" list where I could, say turn off the main Navigation menu so that people don't go and trash it. Very cool feature in a very important direction! I sincerely hope this makes it into the code freeze. ------------------------------------------------------------------------ February 2, 2005 - 16:37 : Anonymous I removed the required mark next to menu item form field. Thanks for spotting that. I don't completely understand what you mean by this patch 'opening up a big can of permissions worms'. User's with 'administer menus' permission are simply given an easier way to add menu items while creating content. I think it's better to keep it simple to begin with. http://asitis.org/tmp/menu_quick_link_form.png [3] There actually is a configuration interface (settings/menu). Your menu cache probably needed to be cleared after applying the patch :-) On that page you can choose which node types acquire the quick menu item form field as well as define the default menu item. I disagree with putting the menu item form visibility settings on the admin/node/configure/types/{type} page. Those settings are for the default state of the node instance, not what's visible on the form field. For example, I wouldn't want to see a list of all 'form pre' and 'form post' fields on that page to select from, but it could be useful as a standard interface elsewhere. [3] http://asitis.org/tmp/menu_quick_link_form.png ------------------------------------------------------------------------ February 2, 2005 - 16:40 : mathias Last comment by 'learning to login' mathias. ------------------------------------------------------------------------ February 6, 2005 - 04:23 : Dries I'm going to put this on hold until the collapsbile form groups [4] settled. I encourage you to participate in the design and discussion so that it meets your requirements. The same should be done for other parts of the node edit form, so let's try to come up with a generic solution that can be used through an API that shields you from all Javascript details. [4] http://drupal.org/node/16204 ------------------------------------------------------------------------ March 13, 2005 - 16:13 : killes(a)www.drop.org Hmm, should we have a status "on hold"? I am unsure what to do with this one. It still applies. ------------------------------------------------------------------------ March 29, 2005 - 04:15 : TDobes +1 on this... trying to explain to users that they need to add their pages, then add their pages to the menu system (and explain why) was incredibly difficult... menu_otf has helped with this, and I think this sort of functionality really belongs in core. ------------------------------------------------------------------------ March 29, 2005 - 08:05 : Dries Yes, we need something like this in core but as explained, there is a depency on the new node form (and collapsible form/page elements in particular). Is anyone going to work on this? I'm determined to help get this in core ASAP but can't take a lead in this. Takers? ------------------------------------------------------------------------ June 24, 2005 - 15:41 : mathias Attachment: http://drupal.org/files/issues/menu_otf.patch (3.76 KB) Now that collapsible form/page elements are in core it's time to revisit this patch. Attached is the latest version pulled straight from the menu_otf module. Here's a screenshot of it in action: http://asitis.org/images/motf/motf-add-item.png ------------------------------------------------------------------------ June 27, 2005 - 13:01 : Dries 1. Use quotes around strings when indexing an array. It generates warnings. See menu_nodeapi(). AFAIK, the $a3 and $a4 style parameters are deprecated. It's no longer necessary to specify these as module_invoke_all() and friends got fixed. 2. The form descriptions talk about a 'quick item form'. I have no idea what that means, or what it refers to. 3. I'm not too happy with the global 'Default parent item' setting. Is this really necessary? Less settings is better. 4. t('Menu item deleted.') We updated the status messages a couple weeks ago. Messages like these have been reworded for clarity and to use the proper tone. Read up on the old issue for details, or poll either Stefan or occy. (I asked them to write some guidelines, not sure they did. I can't seem to find any though.) 5. There is an ul { at the bottom of the patch? 6. The GUI seems to mix 'menu item' and 'link'. This might be potentially confusing.

1 0

[drupal-devel] [bug] Theming tablesort icons is inconsistent
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/11927 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: stefan nagtegaal Updated by: mfb Status: patch +1 looks good. mfb Previous comments: ------------------------------------------------------------------------ October 22, 2004 - 09:56 : stefan nagtegaal Attachment: http://drupal.org/files/issues/tablesort-sorting-theme-improvement.patch (1.25 KB) Attached is a patch for tablesort.inc much cleaner, friendlier and more consistent way to theme the tablesort icons. Marking as a bug becuase it is inconsistent with the rest of drupal.. Please review and apply! ------------------------------------------------------------------------ October 22, 2004 - 09:57 : stefan nagtegaal Setting status to 'Patch' instead of 'Fixed' so it shows up in the patch queue ------------------------------------------------------------------------ October 23, 2004 - 09:27 : Dries Please move the proposed theme functions to includes/theme.inc (so Doxygen includes them in the list of theme_ functions). ------------------------------------------------------------------------ October 23, 2004 - 13:39 : Steven We should avoid entities like   in the code. This can be achieved through CSS instead in the theme. ------------------------------------------------------------------------ October 23, 2004 - 13:41 : Steven (ack submitted too early) Also, I wonder about the granularity of these theme functions. I don't see the point in putting ascending/descending in a separate function: they are different styles for the same element (the tablesort indicator). ------------------------------------------------------------------------ October 23, 2004 - 17:08 : Dries Stefan's patch actually removes the entities, not (or is my jet lag worse than it appears)? ------------------------------------------------------------------------ October 24, 2004 - 03:56 : stefan nagtegaal Attachment: http://drupal.org/files/issues/tablesort-sorting-theme-improvement_0.patch (1.73 KB) Updated patch which removes the and moves the theme_tablesort_asc() and theme_tablesort_desc() to theme.inc. This is much better imo than the current approach.. ------------------------------------------------------------------------ October 24, 2004 - 08:10 : Steven Yeah the entity was actually a +1... I should stop doing so much things at the same time. My other concern is still valid though: theme functions should theme page /elements/, not versions of that element. Otherwise we would have theme_node(), theme_node_sticky(), theme_node_teaser(), ... ------------------------------------------------------------------------ November 15, 2004 - 05:25 : Dries I agree with Steven. We should have a function called theme_tablesort_header($style) where $style can be either 'ascending' or 'descending'. ------------------------------------------------------------------------ June 20, 2005 - 05:43 : Robin Monks Attachment: http://drupal.org/files/issues/tablesort_header.patch (1.49 KB) Here is a new patch with theme_tablesort_header($style) that takes either asc or desc as arguments. Tested to work on Drupal CVS HEAD. Robin ------------------------------------------------------------------------ June 20, 2005 - 05:47 : Bèr Kessels I am not sure about teh switch; AFAIK there will be only asc and desc. So an if would be enough. Saves some lines of code, like "break"s; etc. ------------------------------------------------------------------------ June 20, 2005 - 06:32 : Robin Monks Attachment: http://drupal.org/files/issues/tablesort_header_0.patch (1.6 KB) Here is a new patch using if instead of the switch. Robin ------------------------------------------------------------------------ June 20, 2005 - 06:43 : Robin Monks Attachment: http://drupal.org/files/issues/tablesort_header_1.patch (1.61 KB) Thox suggested using indicator instead of header. Robin

1 0

[drupal-devel] [bug] The anonymous user account can be edited
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25605 Project: Drupal Version: 4.6.1 Component: user system Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: nysus Updated by: mfb Status: patch With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user. +1 for Robin's patch, which needs to be converted from DOS to UNIX format. mfb Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 06:06 : nysus Any user, anonymous or otherwise, can go to /user/0/edit and edit the account of the anonymous user. ------------------------------------------------------------------------ June 24, 2005 - 04:20 : Robin Monks I'll take care of this one :-) CONFIRMED on WinXP/Xitami CVS Robin ------------------------------------------------------------------------ June 24, 2005 - 04:41 : Robin Monks Attachment: http://drupal.org/files/issues/annon.user.edit.fix (1.92 KB) Here is the patch. It removes the /edit and /delete operation from user 0. Tested to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 24, 2005 - 09:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-edit-fix.patch (999 bytes) The patch didn't apply on head. I also like my solution better. ;) ------------------------------------------------------------------------ June 27, 2005 - 12:17 : Dries killes: your patch looks broken. Shouldn't $user->uid be arg(1)? ------------------------------------------------------------------------ June 27, 2005 - 12:31 : killes(a)www.drop.org One of us is confused, but who? I don't think that $user->uid has to be == arg(1). it is a global var. ------------------------------------------------------------------------ June 28, 2005 - 04:31 : Robin Monks Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion. Robin

1 0

[drupal-devel] New CVS accounts
by Dries Buytaert 30 Jun '05

30 Jun '05

Hello world, I approved a bunch of CVS accounts. The Summer of Google participants also got their CVS accounts. Please welcome our new contributors, and assist them as necessary. -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] [bug] Bootstrap patch fixes
by chx 30 Jun '05

30 Jun '05

Issue status update for http://drupal.org/node/25600 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: kubaZygmunt Updated by: chx Status: patch " From: Simon Willison To: Karoly Negyesi Subject: Re: IXR GPL? Date: 05/25/05 18:40 On 25 May 2005, at 17:35, Karoly Negyesi wrote: > I'd like to get rid of the current XML-RPC implementation in Drupal > and use > IXR instead. Yours seems much more transparent and up to date. > > I plan to rewrite it a bit so that it looses OOP, this enables us to > conditionally include. > > However, Drupal is GPL and I need IXR under GPL to work with. Hmm... since you'll be rewriting it a bit, how's about I just give you permission to use it and relicense it as GPL provided you stick a note that it was derived (with permission) from IXR in a comment at the top somewhere? I really hate software licensing - I just want people to be able to use my code! Thanks, Simon " chx Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 13:28 : kubaZygmunt Attachment: http://drupal.org/files/issues/bootstrap.diff (422 bytes) I've found that new cvs version doesn't get properly db_prefix. In bootstrap.inc (function _drupal_bootstrap($phase) ) I added another global variable $db_prefix, and then it goes . I don't know if my solution is good because on my local site I can't see any blocks and on my internet site I have some caching and I can't see anything :) ------------------------------------------------------------------------ June 23, 2005 - 14:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 14:56 : Jaza Attachment: http://drupal.org/files/issues/db_prefix_global.patch (582 bytes) Also noticed this bug, when trying to install a fresh CVS snapshot. Attached is my patch against CVS HEAD (same as kubaZygmunt's, basically). ------------------------------------------------------------------------ June 23, 2005 - 15:10 : chx Yes, this is a bug, if you look at the bootstrap patch, there were versions when I thought variables in settings.php should be written as $GLOBALS['something'] but then introduced global $something . Forgot when that something is db_prefix . ------------------------------------------------------------------------ June 28, 2005 - 07:26 : Jaza Can this patch be applied to HEAD please? This is not something that should be left sitting around in the issues list. Chx has identified that it was a simple honest mistake on his part, and has indicated that the submitted patch(es) will fix the mistake. Until this patch is applied, anyone who tries to install HEAD using db prefixes will get a fatal error. It doesn't get much more critical than that :-p. ------------------------------------------------------------------------ June 30, 2005 - 16:56 : Bart Jansens Attachment: http://drupal.org/files/issues/20050630.bootstrap-prefix-update.patch (1.21 KB) There is another related problem, it is no longer possible to override variables in settings.php. And update.php no longer works. Updated patch attached. ------------------------------------------------------------------------ June 30, 2005 - 17:04 : chx Attachment: http://drupal.org/files/issues/20050630.bootstrap-patch.patch (2.92 KB) Oh, and XML-RPC client is broken too. I talked with walkah and we found it the best to move xmlrpc.inc to modules which use them. ------------------------------------------------------------------------ June 30, 2005 - 17:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 17:20 : Steven Making XML-RPC a conditional include was discussed a while ago, and decided against due to problems with the class persistency. Why is this now possible? ------------------------------------------------------------------------ June 30, 2005 - 19:36 : walkah basically - it's not. the problem is, well, the xmlrpc.inc is not very well written. It requires / depends on several global variables, etc. which leads to a fair bit of the scoping issues. If you look at what PEAR has done with this (since their XML-RPC module is based on the same original code)... you'll notice lots of $GLOBALS['...'] usage (see http://cvs.php.net/co.php/pear/XML_RPC/RPC.php) . Basically, I think we have 3 options: 1) keep banging on this old code to make it work. 2) switch libraries to either PEAR::XML-RPC or something like incutio's (http://scripts.incutio.com/xmlrpc/) 3) re-write our own custom xml-rpc library personally, I'd +1 #2 - since #1 is ugly, and #3 I personally don't have time for, and I'd rather see our developer resources going to more interesting things. that said, i know there are those with strong feelings against 3rd party libraries... but this needs to get fixed quickly. blogapi and drupal dist_auth are both currently broken in HEAD. (isn't there anyone else here that tests XML-RPC stuff??) ------------------------------------------------------------------------ June 30, 2005 - 19:38 : walkah just to follow up.. chx's patch in #7 only fixes XMLRPC servers... anything that uses XML-RPC client (i.e. drupal_auth or ping) will still be busted. ------------------------------------------------------------------------ June 30, 2005 - 19:48 : moshe weitzman the 'we shouldn't use 3rd party libraries' argument is hogwash. that was recenyly followed up with 'look where that got us recently' which is even more stupid. security problems happen in your own code, and in other people's code. we've had several security mistakes of our own, and those mistakes have persisted a long time. the benefit of 3rd party libraries is that you don't have to write them, debug them, document them, or maintain them. if someone here is willing to do all of this for XMLRPC then great. But thats extremely unlikely so we either have to drop the whole feature set or use a 3rd party library. as you can tell, i favor #2 as well - switching libraries so we can do conditional inclusion. ------------------------------------------------------------------------ June 30, 2005 - 20:01 : Dries #2 isn't GPL ------------------------------------------------------------------------ June 30, 2005 - 20:07 : Dries Looks like WordPress might be using that class though. Weird. I know Wordpress had a least two security issues with their XML-RPC library (and they aren't using Edd Dumbill's). There is no word about this at http://scripts.incutio.com/xmlrpc/ so it looks like it isn't maintained either (which renders the advantages of using third-party libraries moot-ish). ------------------------------------------------------------------------ June 30, 2005 - 20:17 : Dries The WP developers confirmed that they are using this library. Turns out there is a new website for it too: http://simon.incutio.com/archive/2005/05/23/ixr. WordPress' version lives at http://trac.wordpress.org/log/trunk/wp-includes/class-IXR.php. Some extra details at http://trac.wordpress.org/ticket/1400. Looking at the code, it doesn't appear to be PHP5 compliant. Plus, I'm not sure the license is compatible. ------------------------------------------------------------------------ June 30, 2005 - 20:21 : chx I will rewrite the Incutio XML-RPC library for our own usage in July, I know this for quite a long time. a) I intend to start with Incutio's XML-RPC b) I contacted the author already and he is fine with GPL'ing the result. c) the result will be quite a bit different from the original, 'cos I'll make it use procedural notation and overall, more Drupalish.

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by chx 30 Jun '05

30 Jun '05

Issue status update for http://drupal.org/node/25600 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: kubaZygmunt Updated by: chx Status: patch I will rewrite the Incutio XML-RPC library for our own usage in July, I know this for quite a long time. a) I intend to start with Incutio's XML-RPC b) I contacted the author already and he is fine with GPL'ing the result. c) the result will be quite a bit different from the original, 'cos I'll make it use procedural notation and overall, more Drupalish. chx Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 13:28 : kubaZygmunt Attachment: http://drupal.org/files/issues/bootstrap.diff (422 bytes) I've found that new cvs version doesn't get properly db_prefix. In bootstrap.inc (function _drupal_bootstrap($phase) ) I added another global variable $db_prefix, and then it goes . I don't know if my solution is good because on my local site I can't see any blocks and on my internet site I have some caching and I can't see anything :) ------------------------------------------------------------------------ June 23, 2005 - 14:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 14:56 : Jaza Attachment: http://drupal.org/files/issues/db_prefix_global.patch (582 bytes) Also noticed this bug, when trying to install a fresh CVS snapshot. Attached is my patch against CVS HEAD (same as kubaZygmunt's, basically). ------------------------------------------------------------------------ June 23, 2005 - 15:10 : chx Yes, this is a bug, if you look at the bootstrap patch, there were versions when I thought variables in settings.php should be written as $GLOBALS['something'] but then introduced global $something . Forgot when that something is db_prefix . ------------------------------------------------------------------------ June 28, 2005 - 07:26 : Jaza Can this patch be applied to HEAD please? This is not something that should be left sitting around in the issues list. Chx has identified that it was a simple honest mistake on his part, and has indicated that the submitted patch(es) will fix the mistake. Until this patch is applied, anyone who tries to install HEAD using db prefixes will get a fatal error. It doesn't get much more critical than that :-p. ------------------------------------------------------------------------ June 30, 2005 - 16:56 : Bart Jansens Attachment: http://drupal.org/files/issues/20050630.bootstrap-prefix-update.patch (1.21 KB) There is another related problem, it is no longer possible to override variables in settings.php. And update.php no longer works. Updated patch attached. ------------------------------------------------------------------------ June 30, 2005 - 17:04 : chx Attachment: http://drupal.org/files/issues/20050630.bootstrap-patch.patch (2.92 KB) Oh, and XML-RPC client is broken too. I talked with walkah and we found it the best to move xmlrpc.inc to modules which use them. ------------------------------------------------------------------------ June 30, 2005 - 17:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 17:20 : Steven Making XML-RPC a conditional include was discussed a while ago, and decided against due to problems with the class persistency. Why is this now possible? ------------------------------------------------------------------------ June 30, 2005 - 19:36 : walkah basically - it's not. the problem is, well, the xmlrpc.inc is not very well written. It requires / depends on several global variables, etc. which leads to a fair bit of the scoping issues. If you look at what PEAR has done with this (since their XML-RPC module is based on the same original code)... you'll notice lots of $GLOBALS['...'] usage (see http://cvs.php.net/co.php/pear/XML_RPC/RPC.php) . Basically, I think we have 3 options: 1) keep banging on this old code to make it work. 2) switch libraries to either PEAR::XML-RPC or something like incutio's (http://scripts.incutio.com/xmlrpc/) 3) re-write our own custom xml-rpc library personally, I'd +1 #2 - since #1 is ugly, and #3 I personally don't have time for, and I'd rather see our developer resources going to more interesting things. that said, i know there are those with strong feelings against 3rd party libraries... but this needs to get fixed quickly. blogapi and drupal dist_auth are both currently broken in HEAD. (isn't there anyone else here that tests XML-RPC stuff??) ------------------------------------------------------------------------ June 30, 2005 - 19:38 : walkah just to follow up.. chx's patch in #7 only fixes XMLRPC servers... anything that uses XML-RPC client (i.e. drupal_auth or ping) will still be busted. ------------------------------------------------------------------------ June 30, 2005 - 19:48 : moshe weitzman the 'we shouldn't use 3rd party libraries' argument is hogwash. that was recenyly followed up with 'look where that got us recently' which is even more stupid. security problems happen in your own code, and in other people's code. we've had several security mistakes of our own, and those mistakes have persisted a long time. the benefit of 3rd party libraries is that you don't have to write them, debug them, document them, or maintain them. if someone here is willing to do all of this for XMLRPC then great. But thats extremely unlikely so we either have to drop the whole feature set or use a 3rd party library. as you can tell, i favor #2 as well - switching libraries so we can do conditional inclusion. ------------------------------------------------------------------------ June 30, 2005 - 20:01 : Dries #2 isn't GPL ------------------------------------------------------------------------ June 30, 2005 - 20:07 : Dries Looks like WordPress might be using that class though. Weird. I know Wordpress had a least two security issues with their XML-RPC library (and they aren't using Edd Dumbill's). There is no word about this at http://scripts.incutio.com/xmlrpc/ so it looks like it isn't maintained either (which renders the advantages of using third-party libraries moot-ish). ------------------------------------------------------------------------ June 30, 2005 - 20:17 : Dries The WP developers confirmed that they are using this library. Turns out there is a new website for it too: http://simon.incutio.com/archive/2005/05/23/ixr. WordPress' version lives at http://trac.wordpress.org/log/trunk/wp-includes/class-IXR.php. Some extra details at http://trac.wordpress.org/ticket/1400. Looking at the code, it doesn't appear to be PHP5 compliant. Plus, I'm not sure the license is compatible.

1 0