- Development - lists.drupal.org

[drupal-devel] [feature] List options in profile.module
by chx 01 Feb '05

01 Feb '05

Project: Drupal Version: 4.5.0 Component: profile.module Category: feature requests Priority: normal Assigned to: Alison(a)deanspace.org Reported by: Alison(a)deanspace.org Updated by: chx Status: patch Features can be added only to CVS HEAD not to 4.5.0 and please submit a patch not the whole module http://drupal.org/patch chx Previous comments: ------------------------------------------------------------------------ February 1, 2005 - 15:57 : Alison(a)deanspace.org Add the ability to list the options of a profile field if the field is given but a value isn't to the profile module. For example, right now /profile shows all public user information, /profile/profile_school shows a blank page and profile/profile_school/Miami University shows all public info on users for that school. The purpose of this feature would be to replace the blank page with a listing of the options. ------------------------------------------------------------------------ February 1, 2005 - 15:58 : Alison(a)deanspace.org Attachment: http://drupal.org/files/issues/profile_1.module (22.61 KB) I have written the code that allows a list of all possible schools to show up. -- View: http://drupal.org/node/16554 Edit: http://drupal.org/project/comments/add/16554

1 0

[drupal-devel] [feature] List options in profile.module
by Alison 01 Feb '05

01 Feb '05

Project: Drupal Version: 4.5.0 Component: profile.module Category: feature requests Priority: normal Assigned to: Alison(a)deanspace.org Reported by: Alison(a)deanspace.org Updated by: Alison(a)deanspace.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/profile_1.module (22.61 KB) I have written the code that allows a list of all possible schools to show up. Alison(a)deanspace.org Previous comments: ------------------------------------------------------------------------ February 1, 2005 - 14:57 : Alison(a)deanspace.org Add the ability to list the options of a profile field if the field is given but a value isn't to the profile module. For example, right now /profile shows all public user information, /profile/profile_school shows a blank page and profile/profile_school/Miami University shows all public info on users for that school. The purpose of this feature would be to replace the blank page with a listing of the options. -- View: http://drupal.org/node/16554 Edit: http://drupal.org/project/comments/add/16554

1 0

[drupal-devel] [task] Core image handling
by walkah 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: walkah Reported by: walkah Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/image_0.inc (7.44 KB) Due to popular demand - attached here is an image.inc for inclusion (in includes/), that will offer some basic image detection and manipulation functionality to drupal's core. currently image.inc is responsible for managing image 'toolkits' - these are either PHP modules (e.g. GD) or external programs (e.g. imagemagick) that handle the actual manipulation of images. also included is the default "GD" toolkit (that supports both GD1 or GD2, depending on which is installed). PHP comes bundled with gd as of version 4.3 - therefore this is a reasonable default. However, other toolkits will follow (I presume) - they can be installed in includes/ (as image.$toolkit.inc). There are 5 main functions that modules may now utilize to handle images: * image_get_info() - this function checks a file - if it exists and is a valid image file , it will return an array containing things like the pixel dimensions of the image, plus the 'type' and common extension. * image_scale - resizes a given image to fit within a given width / height dimensions, while maintaining aspect ratio (not distorting the image). - this function can be used to generate thumbnails, or ensure a maximum resolution, etc. * image_resize - similar to image_scale (but will not respect aspect ratio - may well distort the image). * image_rotate - rotate an image by X degrees * image_crop - crops an image to a given rectangle (defined as top-left x/y coordinates plus a width & height of the rectangle). In a follow up I will post a patch that does the following: * adds some default settings to admin/settings : * toolkit selection (and possibly configuration) * default thumbnail dimensions (WxH) - to be used as a system-wide default * maximum dimensions (WxH ) - to be used as a system-wide default * changes the user picture handling to silently resize uploaded pictures to fit within the specified dimensions (rather than throwing errors). * uses image_get_info() to verify logo uploads in admin/theme configuration * patches upload.module to respect maximum dimensions for uploaded images. Contribution modules will now be able to rely on these base manipulation functions to offer additional functionality (such as image nodes, photo galleries, advanced image manipulation, etc) walkah -- View: http://drupal.org/node/16358 Edit: http://drupal.org/project/comments/add/16358

13 23

[drupal-devel] [feature] More flexible rss output
by walkah 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: walkah Reported by: walkah Updated by: walkah Status: patch Attachment: http://drupal.org/files/issues/format_rss_item.patch (4.06 KB) this patch does a few things: * alters format_rss_item (in common.inc) to allow the $args paramater to be an array of arrays (optionally), so that extra arguments can have attributes - i.e. think enclosures * introduces a nodeapi option for 'rss item', so that other modules can add additional info to each rss item * patches taxonomy.module to add category information to feeds * patches upload module to add enclosure for feeds (NOTE: rss only allows 1 enclosure per item). this would allow things like, say, podcasts to be available in drupal. walkah -- View: http://drupal.org/node/16513 Edit: http://drupal.org/project/comments/add/16513

5 6

[drupal-devel] [feature] Menu rewrite
by chx 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/menu_rewrite_patch (1.67 KB) robertDouglas asked in the taxonomy rewrite thread whether menu rewrite is possible, so that we can have menu permissions. I have not thought of this earlier, but of course it is possible. And it would have been very small patch, but I needed to document the possibility of this in the PHPdoc of _db_rewrite_query and db_rewrite_query. chx -- View: http://drupal.org/node/16542 Edit: http://drupal.org/project/comments/add/16542

1 0

[drupal-devel] Bug#293120: drupal 4.5.2-1 causes: Table 'drupal.users_roles' doesn't exist
by Hilko Bengen 01 Feb '05

01 Feb '05

James Clark <jamesc(a)bofh.co.nz> writes: > Fatal error: Table 'drupal.users_roles' doesn't exist query: SELECT r.rid, > r.name FROM role r INNER JOIN users_roles ur ON ur.rid = r.rid WHERE > ur.uid = 1 in /usr/share/drupal/includes/database.mysql.inc on line 125 Unfortunately, you didn't tell me from which version you upgraded. It looks as if the database upgrade procedure hadn't been run. You can still run it manually. Cheers, -Hilko

1 0

[drupal-devel] [feature] Menu fast edit node links
by robertDouglass 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: menu system Category: feature requests Priority: minor Assigned to: mathias Reported by: mathias Updated by: robertDouglass Status: patch +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. robertDouglass Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 19: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 - 19: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 - 23: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 - 23:34 : mathias Woops. Setting status to 'patch'. ------------------------------------------------------------------------ January 25, 2005 - 15: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 - 17: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 - 22: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. -- View: http://drupal.org/node/9178 Edit: http://drupal.org/project/comments/add/9178

1 0

[drupal-devel] [task] Rewrite to use procedures and conditionally include xmlrpc.inc
by tangent 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: walkah Reported by: killes(a)www.drop.org Updated by: tangent Status: patch It seems that implementing xmlrpc as a (required) module would work around the include issue. I'm working on a xmlrpc.module from scratch, sort of as a Drupal learning exercise, which uses the XML-RPC extension functions instead of the xmlrpc.inc that we're using now and will reduce the code to a few lines instead of the big class that exists now. Before I get too far into it though, I'm interested if anyone may have thoughts about why a module is not the way to go, or if there is some reason we shouldn't be using the XML-RPC functions. tangent Previous comments: ------------------------------------------------------------------------ April 29, 2004 - 13:15 : killes(a)www.drop.org Drupal includes xmlrpc.inc for every non-cached page view. However, the functions from the file are only rarely used. Therefore we need a patch that includes the file from the functions that want to use it. ------------------------------------------------------------------------ May 2, 2004 - 13:30 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc.patch (4.64 KB) Here is a patch that moves the include statement to the functiosn where xmlrpc.inc is actually needed. The patch coul dneed some testing as I do not use those modules (ping, bloggerapi) myself. ------------------------------------------------------------------------ May 3, 2004 - 16:34 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_0.patch (6.38 KB) Patch updated, I had forgotten drupal.module. thanks to crschmidt for spotting this. ------------------------------------------------------------------------ May 3, 2004 - 17:17 : Steven drupal_xml_parser_create() does not require xmlrpc.inc... ------------------------------------------------------------------------ May 3, 2004 - 17:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_1.patch (6.06 KB) Ok, updated. ------------------------------------------------------------------------ May 3, 2004 - 17:41 : Dries If xmlrpc.php includes xmlrpc.inc, why do we have to include it in blogapi module's functions once more? Also, the inclusion of xmlrpc.inc in drupal.module can probably be avoided by including xmlrpc.inc in cron.php? Am I missing something? ------------------------------------------------------------------------ May 3, 2004 - 17:49 : crschmidt Not all of the tasks in drupal.module are run with cron.php: for example, the distributed authentication comes in through drupal.module, which requires code from xmlrpc.inc to create the messages it sends out, as far as I can tell. So, the drupal.module needs it for distributed authentication stuff, not just for pinging servers and so on. ------------------------------------------------------------------------ May 3, 2004 - 18:38 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_2.patch (2.8 KB) "If xmlrpc.php includes xmlrpc.inc, why do we have to include it in blogapi module's functions once more?" As I said, I am not that familiar with that part of Drupal, did not investigate under whch circumstances blogapi functions could be called, and wanted to stay on the safe side. If you are sure that blogapi is always called from xmlrpcs.php, then apply the appended version. ------------------------------------------------------------------------ May 4, 2004 - 00:40 : Dries I'm not 100% sure either, I was merely suggesting an alternative. I think the second patch might work tough, in which case it would be preferred for its simplicity. Not? I'll add "Testing Gerhard's blog API patch to my short term TODO list". Hopefully I get to it tonight after work. Thanks Gerhard. ------------------------------------------------------------------------ May 12, 2004 - 15:12 : Kjartan Good patch, just a few minor comments. - Use single quotes for constant strings. - I noticed some indentations that were off the 2 column, looks like the are in the current code though. - drupal_directory_ping() will only be invoked from xmlrpc.php so there shouldn't be a need to include the file there. ------------------------------------------------------------------------ May 12, 2004 - 17:40 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_2_0.patch (2.64 KB) Updated. Don't know to which spaces you are referring. Guess Drupal CVS needs to be code checked again. ------------------------------------------------------------------------ August 3, 2004 - 20:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_3.patch (2.81 KB) Updated again. It appears that parts of the old patch made it into drupal.module, but the include statement was still in common.inc. ------------------------------------------------------------------------ August 4, 2004 - 00:47 : TDobes +1... I tested the patch with blogapi.module and w.bloggar and it works fine, as far as I can tell. I like any patch that includes less code on each page view. ------------------------------------------------------------------------ August 4, 2004 - 15:36 : Dries Committed to HEAD. Thanks. ------------------------------------------------------------------------ August 13, 2004 - 13:47 : walkah Attachment: http://drupal.org/files/issues/xmlrpc-include.diff (2.38 KB) this patch didn't break blogapi.module, it's true. but it _did_ break drupal.module's distributed authentication feature. the problem is that xmlrpc.inc declares some classes, which will not work if the include statement appears inside a function. see the following for more details: http://us4.php.net/manual/en/language.functions.php (specifically the comment by albaity at php4web dot com) the attached patch restores the drupal.module functionality (as well as reintroduces the include in common.inc). I'm afraid that's just the way it has to be, sorry killes ;) (this patch also fixes a typo in drupal.module where the 'name' array key was not quoted - which may break things under higher error reporting levels). ------------------------------------------------------------------------ August 13, 2004 - 14:23 : Anonymous Can't you include common.inc from drupal.module if it needs that file? locale.module also includes its locale.inc without punishing the user who doesn't care about its functionality. Gerhard ------------------------------------------------------------------------ August 14, 2004 - 01:29 : Dries Including the XML-RPC library at the top of those files/modules that need it sounds like a fair alternative. ------------------------------------------------------------------------ August 14, 2004 - 06:19 : Steven But that doesn't really help unless you have no XML-RPC modules enabled at all... ------------------------------------------------------------------------ August 14, 2004 - 07:58 : JonBob What is more, I don't think it even fixes the bug. The problem is that class declarations in PHP4 are not guaranteed to work correctly when made inside a function. This applies to declarations immediately inside a function definition, or in files included from inside a function definition, or even from files included from files included from function definitions. Note that since module files are included from module_load(), this means class definitions or includes of files that have them cannot safely be in modules. Basically, conditional inclusion of classes is a no-no. To get around this we'd have to rewrite xmlrpc.inc using functions rather than object methods. ------------------------------------------------------------------------ August 16, 2004 - 13:29 : Dries I reverted the patch. ------------------------------------------------------------------------ August 17, 2004 - 10:39 : walkah ya, but you forgot to put the include_once back in common.inc . :) ------------------------------------------------------------------------ August 17, 2004 - 12:59 : killes(a)www.drop.org Can't just somebody step forward and rewrite that class in functions? ------------------------------------------------------------------------ August 31, 2004 - 16:41 : killes(a)www.drop.org I'd like to keep this open. It is so nicely assigned. ;-> ------------------------------------------------------------------------ September 1, 2004 - 07:35 : Anonymous *grumble* ------------------------------------------------------------------------ January 31, 2005 - 18:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmplrpc.patch (695 bytes) Here is an alternative approach. XML-RPC requests are suppoed to be POST requests, not GET. By jvandyk and myself. ------------------------------------------------------------------------ January 31, 2005 - 18:22 : jvandyk This patch affects the inclusion of xmlrpc, which is the xmlrpc client, not xmlrpcs, which is the server and subject to the "all XML-RPC requests are POST requests" rule. Thus, it is ineffective. However, we should consider eliminating the inclusion of xmlrpc.inc at all in common.inc. This would speed up Drupal at the expense of modules that use XML-RPC calls having to include xmlrpc.inc themselves. grepping for xmlrpc_ finds occurrences in drupal.module for cross-drupal-site authentication, foaf.module, livejournalmodule, and waypath.module. ------------------------------------------------------------------------ January 31, 2005 - 18:24 : jvandyk And now that I've revisited JonBob's comments on this, I can see why it's currently the way it is and can't be conditionally included. Blech. -- View: http://drupal.org/node/7458 Edit: http://drupal.org/project/comments/add/7458

1 0

[drupal-devel] cvs log messages
by no-reply＠zind.net 01 Feb '05

01 Feb '05

File: /modules/taxonomy_context/taxonomy_context.module 1.25.2.6 DRUPAL-4-5 Date: February 1, 2005 - 00:16 User: nedjo Applied patch to issue #s 12765 and 11543 as submitted by drupal.org users mcd and geek. ---------------------------------------------------------------------- File: /modules/og/og.module 1.31 Date: January 31, 2005 - 22:11 User: weitzman don't allow empty album title ---------------------------------------------------------------------- File: /modules/og/og.module 1.1.2.27 DRUPAL-4-5 Date: January 31, 2005 - 22:10 User: weitzman don't allow empty album title ---------------------------------------------------------------------- File: /modules/album/album.module 1.2.2.3 DRUPAL-4-5 Date: January 31, 2005 - 22:08 User: weitzman don't allow empty album title ---------------------------------------------------------------------- File: /modules/album/album.module 1.4 Date: January 31, 2005 - 22:07 User: weitzman don't allow empty album title ---------------------------------------------------------------------- File: /modules/folksonomy/folksonomy.module 1.6 Date: January 31, 2005 - 22:01 User: weitzman still fixing the escape string bug. works for 4.5 and probably HEAD, though thats untested ATM ---------------------------------------------------------------------- File: /includes/tablesort.inc 1.31 Date: January 31, 2005 - 21:36 User: dries - Patch #16303 by Gerhard: fixed PHP notices. ---------------------------------------------------------------------- File: /modules/folksonomy/folksonomy.module 1.5 Date: January 31, 2005 - 21:19 User: weitzman escape strings before passing to DB ---------------------------------------------------------------------- File: /modules/taxonomy.module 1.152.2.7 DRUPAL-4-5 Date: January 31, 2005 - 21:17 User: dries - Patch #14658 by Zed Pobre: fixed node-level permission bug in the taxonomy API. ---------------------------------------------------------------------- File: /includes/database.inc 1.37 /modules/node.module 1.455 Date: January 31, 2005 - 20:45 User: dries - Patch #16111 by chx: fixed some bugs in the db_rewrite_sql() code. ---------------------------------------------------------------------- File: /modules/blogapi.module 1.37 Date: January 31, 2005 - 19:36 User: dries - Patch #6195 by nedjo/James: allow posting to multiple node types. ---------------------------------------------------------------------- File: /modules/comment.module 1.332 Date: January 31, 2005 - 19:30 User: dries - Patch by Jose A Reyero: fixed probem with db_rewriste_sql() in the comment.module. ---------------------------------------------------------------------- File: /sandbox/junyor/import/blogger.inc 1.5 /sandbox/junyor/import/CHANGELOG 1.5 /sandbox/junyor/import/import.php 1.5 /sandbox/junyor/import/README 1.4 /sandbox/junyor/import/TODO 1.4 Date: January 31, 2005 - 18:40 User: junyor - Enabled handling of names and home pages for anonymous comments (blogger.inc) - Moved comment creation from import.php to blogger.inc (blogger.inc, import.php) Importing comments *almost* works ---------------------------------------------------------------------- File: /modules/sidecontent/sidecontent.module 1.3 Date: January 31, 2005 - 17:48 User: MegaGrunt deletion of side content (patch by Willmoy) ---------------------------------------------------------------------- File: /modules/cvslog/cvs.module 1.43 /modules/cvslog/cvs.mysql 1.7 Date: January 31, 2005 - 16:21 User: dries - Added an 'import'-utility to import CVS accounts from a CVS passwd file. - Added an 'export'-utility to export CVS accounts to a CVS passwd file. - Made it possible to approve/decline requests for CVS accounts using a web interface. ---------------------------------------------------------------------- File: /modules/attachment/attachment.module 1.5 /modules/attachment/attachment.mysql 1.2 /modules/attachment/attachment.pgsql 1.1 /modules/attachment/INSTALL 1.2 /modules/attachment/README.txt 1.2 Date: January 31, 2005 - 15:15 User: ccourtne * Applied patch by pz to fix array/object bugs and display of deleted attachments * Fixed readme and install to document dependency on filemanager module * Added potential script for postresSQL support (untested) ---------------------------------------------------------------------- File: /modules/filemanager/filemanager.module 1.7 Date: January 31, 2005 - 15:03 User: ccourtne * Fixed typos found by pz, tostinni, moggy, acidrust, wazdog, and raveneris * Corrected behavior of promote file to replace existing file * Applied patch by pz to fix menu caching behavior ---------------------------------------------------------------------- File: /modules/mail_archive/CHANGELOG.txt 1.12 /modules/mail_archive/mail_archive.module 1.14 /modules/mail_archive/README.txt 1.10 Date: January 31, 2005 - 04:43 User: jeremy - mail_archive.module: o fixed permissions issue for deleting messages o initial support for browsing by date (rough around the edges) ---------------------------------------------------------------------- File: /modules/blogroll/blogroll.module 1.10 /modules/blogroll/README.txt 1.6 Date: January 31, 2005 - 02:37 User: grantbow Cleanup of blogroll.module and README ---------------------------------------------------------------------- File: /modules/gallery/gallery.module 1.2 /modules/gallery/INSTALL.txt 1.1 /modules/gallery/README.txt 1.1 Date: January 31, 2005 - 01:58 User: walkah initial commit of the gallery2 integration module (for http://gallery.menalto.com/) ---------------------------------------------------------------------- File: /modules/blogroll/blogroll.module 1.9 Date: January 31, 2005 - 01:22 User: grantbow Added blogroll "community blogroll" and admin/settings/blogroll pages ----------------------------------------------------------------------

1 0

[drupal-devel] [task] Rewrite to use procedures and conditionally include xmlrpc.inc
by jvandyk 01 Feb '05

01 Feb '05

Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: walkah Reported by: killes(a)www.drop.org Updated by: jvandyk Status: patch And now that I've revisited JonBob's comments on this, I can see why it's currently the way it is and can't be conditionally included. Blech. jvandyk Previous comments: ------------------------------------------------------------------------ April 29, 2004 - 18:15 : killes(a)www.drop.org Drupal includes xmlrpc.inc for every non-cached page view. However, the functions from the file are only rarely used. Therefore we need a patch that includes the file from the functions that want to use it. ------------------------------------------------------------------------ May 2, 2004 - 18:30 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc.patch (4.64 KB) Here is a patch that moves the include statement to the functiosn where xmlrpc.inc is actually needed. The patch coul dneed some testing as I do not use those modules (ping, bloggerapi) myself. ------------------------------------------------------------------------ May 3, 2004 - 21:34 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_0.patch (6.38 KB) Patch updated, I had forgotten drupal.module. thanks to crschmidt for spotting this. ------------------------------------------------------------------------ May 3, 2004 - 22:17 : Steven drupal_xml_parser_create() does not require xmlrpc.inc... ------------------------------------------------------------------------ May 3, 2004 - 22:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_1.patch (6.06 KB) Ok, updated. ------------------------------------------------------------------------ May 3, 2004 - 22:41 : Dries If xmlrpc.php includes xmlrpc.inc, why do we have to include it in blogapi module's functions once more? Also, the inclusion of xmlrpc.inc in drupal.module can probably be avoided by including xmlrpc.inc in cron.php? Am I missing something? ------------------------------------------------------------------------ May 3, 2004 - 22:49 : crschmidt Not all of the tasks in drupal.module are run with cron.php: for example, the distributed authentication comes in through drupal.module, which requires code from xmlrpc.inc to create the messages it sends out, as far as I can tell. So, the drupal.module needs it for distributed authentication stuff, not just for pinging servers and so on. ------------------------------------------------------------------------ May 3, 2004 - 23:38 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_2.patch (2.8 KB) "If xmlrpc.php includes xmlrpc.inc, why do we have to include it in blogapi module's functions once more?" As I said, I am not that familiar with that part of Drupal, did not investigate under whch circumstances blogapi functions could be called, and wanted to stay on the safe side. If you are sure that blogapi is always called from xmlrpcs.php, then apply the appended version. ------------------------------------------------------------------------ May 4, 2004 - 05:40 : Dries I'm not 100% sure either, I was merely suggesting an alternative. I think the second patch might work tough, in which case it would be preferred for its simplicity. Not? I'll add "Testing Gerhard's blog API patch to my short term TODO list". Hopefully I get to it tonight after work. Thanks Gerhard. ------------------------------------------------------------------------ May 12, 2004 - 20:12 : Kjartan Good patch, just a few minor comments. - Use single quotes for constant strings. - I noticed some indentations that were off the 2 column, looks like the are in the current code though. - drupal_directory_ping() will only be invoked from xmlrpc.php so there shouldn't be a need to include the file there. ------------------------------------------------------------------------ May 12, 2004 - 22:40 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_2_0.patch (2.64 KB) Updated. Don't know to which spaces you are referring. Guess Drupal CVS needs to be code checked again. ------------------------------------------------------------------------ August 4, 2004 - 01:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmlrpc_3.patch (2.81 KB) Updated again. It appears that parts of the old patch made it into drupal.module, but the include statement was still in common.inc. ------------------------------------------------------------------------ August 4, 2004 - 05:47 : TDobes +1... I tested the patch with blogapi.module and w.bloggar and it works fine, as far as I can tell. I like any patch that includes less code on each page view. ------------------------------------------------------------------------ August 4, 2004 - 20:36 : Dries Committed to HEAD. Thanks. ------------------------------------------------------------------------ August 13, 2004 - 18:47 : walkah Attachment: http://drupal.org/files/issues/xmlrpc-include.diff (2.38 KB) this patch didn't break blogapi.module, it's true. but it _did_ break drupal.module's distributed authentication feature. the problem is that xmlrpc.inc declares some classes, which will not work if the include statement appears inside a function. see the following for more details: http://us4.php.net/manual/en/language.functions.php (specifically the comment by albaity at php4web dot com) the attached patch restores the drupal.module functionality (as well as reintroduces the include in common.inc). I'm afraid that's just the way it has to be, sorry killes ;) (this patch also fixes a typo in drupal.module where the 'name' array key was not quoted - which may break things under higher error reporting levels). ------------------------------------------------------------------------ August 13, 2004 - 19:23 : Anonymous Can't you include common.inc from drupal.module if it needs that file? locale.module also includes its locale.inc without punishing the user who doesn't care about its functionality. Gerhard ------------------------------------------------------------------------ August 14, 2004 - 06:29 : Dries Including the XML-RPC library at the top of those files/modules that need it sounds like a fair alternative. ------------------------------------------------------------------------ August 14, 2004 - 11:19 : Steven But that doesn't really help unless you have no XML-RPC modules enabled at all... ------------------------------------------------------------------------ August 14, 2004 - 12:58 : JonBob What is more, I don't think it even fixes the bug. The problem is that class declarations in PHP4 are not guaranteed to work correctly when made inside a function. This applies to declarations immediately inside a function definition, or in files included from inside a function definition, or even from files included from files included from function definitions. Note that since module files are included from module_load(), this means class definitions or includes of files that have them cannot safely be in modules. Basically, conditional inclusion of classes is a no-no. To get around this we'd have to rewrite xmlrpc.inc using functions rather than object methods. ------------------------------------------------------------------------ August 16, 2004 - 18:29 : Dries I reverted the patch. ------------------------------------------------------------------------ August 17, 2004 - 15:39 : walkah ya, but you forgot to put the include_once back in common.inc . :) ------------------------------------------------------------------------ August 17, 2004 - 17:59 : killes(a)www.drop.org Can't just somebody step forward and rewrite that class in functions? ------------------------------------------------------------------------ August 31, 2004 - 21:41 : killes(a)www.drop.org I'd like to keep this open. It is so nicely assigned. ;-> ------------------------------------------------------------------------ September 1, 2004 - 12:35 : Anonymous *grumble* ------------------------------------------------------------------------ January 31, 2005 - 23:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/xmplrpc.patch (695 bytes) Here is an alternative approach. XML-RPC requests are suppoed to be POST requests, not GET. By jvandyk and myself. ------------------------------------------------------------------------ January 31, 2005 - 23:22 : jvandyk This patch affects the inclusion of xmlrpc, which is the xmlrpc client, not xmlrpcs, which is the server and subject to the "all XML-RPC requests are POST requests" rule. Thus, it is ineffective. However, we should consider eliminating the inclusion of xmlrpc.inc at all in common.inc. This would speed up Drupal at the expense of modules that use XML-RPC calls having to include xmlrpc.inc themselves. grepping for xmlrpc_ finds occurrences in drupal.module for cross-drupal-site authentication, foaf.module, livejournalmodule, and waypath.module. -- View: http://drupal.org/node/7458 Edit: http://drupal.org/project/comments/add/7458

1 0