- Development - lists.drupal.org

[drupal-devel] [bug] Bootstrap patch fixes
by Dries 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: Dries Status: patch 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. Dries 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).

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by Dries 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: Dries Status: patch 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). Dries 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

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by Dries 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: Dries Status: patch #2 isn't GPL Dries 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.

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by moshe weitzman 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: moshe weitzman Status: patch 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. moshe weitzman Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 06: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 - 07:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 07: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 - 08: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 - 00: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 - 09: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 - 10: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 - 10:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 10: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 - 12: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 - 12: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.

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by walkah 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: walkah Status: patch 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??) walkah Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 06: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 - 07:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 07: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 - 08: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 - 00: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 - 09: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 - 10: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 - 10:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 10: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?

1 0

[drupal-devel] [task] Installation instructions for PostgreSQL users
by Smirnov 30 Jun '05

30 Jun '05

Issue status update for http://drupal.org/node/25792 Project: Drupal -Version: 4.6.0 +Version: cvs Component: postgresql database Category: tasks Priority: normal Assigned to: Anonymous Reported by: Smirnov Updated by: Smirnov -Status: active +Status: patch Attachment: http://drupal.org/files/issues/INSTALL.txt.patch(install only) (4.48 KB) Updated INSTALL.txt against HEAD, also made it so the instructions pertain to installing to the "public" schema by default (and left a notice on there for people to edit database.pgsql if they need to do otherwise). The previous patches can now be safely ignored (esp. since they were for 4.6.1). Smirnov Previous comments: ------------------------------------------------------------------------ June 26, 2005 - 08:41 : Smirnov Attachment: http://drupal.org/files/issues/INSTALL.txt.oldnew.patch (4.39 KB) Although installing Drupal with PostgreSQL is rather straight forward, there are a few stumbling blocks (needing to load a language into the database and not using the public schema, as well as there being zero instructions): I have added instructions to /INSTALL.txt/ on how to load up the SQL scheme into PostgreSQL, and I have edited /database/database.pgsql/ so that it is easy to install drupal into any schema. As a result, users can now for example install Drupal into database drupal, schema drupal (with the functions in public). This means they could use different modules for different schemas if they wanted to. The instructions include: * Creating a database with /createdb/ * Loading up plpgsql language with /createlang/ * Inserting all the SQL data into the schema of choice * Changing /$db_prefix/ to reflect the schema ------------------------------------------------------------------------ June 26, 2005 - 08:42 : Smirnov Attachment: http://drupal.org/files/issues/database.pgsql.oldnew.patch (588 bytes) Attached the /database/database.pgsql/ patch

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by Steven 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: Steven Status: patch 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? Steven 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.

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 Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. 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.

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: Anonymous +Assigned to: chx Reported by: kubaZygmunt Updated by: chx Status: patch 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. 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.

1 0

[drupal-devel] [bug] Table Prefix
by Bart Jansens 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: Anonymous Reported by: kubaZygmunt Updated by: Bart Jansens Status: patch 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. Bart Jansens 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.

1 0