- Development - lists.drupal.org

[drupal-devel] [feature] please include the bidi.module as a standard module
by alaa 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/13829 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: alaa Status: active the code is already in my sandbox but as Steven demonstrated its a horrible hack and not really ready to be a proper module. I never got around to cleaning it or any of the other EGLUG modules up. alaa Previous comments: ------------------------------------------------------------------------ December 3, 2004 - 03:39 : Anonymous please include the bidi.module as a standard module, which could be found here: http://uniball.dyndns.org/cgi-bin/viewcvs.cgi/www/eglug/modules/bidi.module This is needed to make arabic function correctly. ------------------------------------------------------------------------ January 14, 2005 - 17:40 : killes(a)www.drop.org moving to Drupal. ------------------------------------------------------------------------ March 14, 2005 - 21:04 : kbahey To the original author of the bidi.module: Please commit it to the contrib respository, and create a project page for it. This way everyone can get it. ------------------------------------------------------------------------ March 21, 2005 - 18:09 : Steven This is in fact not needed at all for Arabic. It is needed to /mix/ two languages with different text directions. This is a different thing altogether. The code seems a bit excessive to me: you should use regular expressions for speed, as well as use Unicode character ranges instead of byte-based regexps (use the /u modifier). Finally, the filter settings should be removed, as they are not settings at all. This practice was removed in 4.5. Also, I'm not sure about the setlocale() call. In my tests, PHP seems to ignore the locale for almost everything. ------------------------------------------------------------------------ March 26, 2005 - 22:27 : msameer kbahey, Alaa is the original author of the module, It's in his sandbox in the drupal CVS. I just ported it to drupal 4.5 API. Infact the module isn't that clean. Alaa is sitting in front of me ATM and he'll reply to this issue. Best regards,

1 0

[drupal-devel] [feature] please include the bidi.module as a standard module
by msameer 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/13829 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Anonymous Updated by: msameer Status: active kbahey, Alaa is the original author of the module, It's in his sandbox in the drupal CVS. I just ported it to drupal 4.5 API. Infact the module isn't that clean. Alaa is sitting in front of me ATM and he'll reply to this issue. Best regards, msameer Previous comments: ------------------------------------------------------------------------ December 3, 2004 - 03:39 : Anonymous please include the bidi.module as a standard module, which could be found here: http://uniball.dyndns.org/cgi-bin/viewcvs.cgi/www/eglug/modules/bidi.module This is needed to make arabic function correctly. ------------------------------------------------------------------------ January 14, 2005 - 17:40 : killes(a)www.drop.org moving to Drupal. ------------------------------------------------------------------------ March 14, 2005 - 21:04 : kbahey To the original author of the bidi.module: Please commit it to the contrib respository, and create a project page for it. This way everyone can get it. ------------------------------------------------------------------------ March 21, 2005 - 18:09 : Steven This is in fact not needed at all for Arabic. It is needed to /mix/ two languages with different text directions. This is a different thing altogether. The code seems a bit excessive to me: you should use regular expressions for speed, as well as use Unicode character ranges instead of byte-based regexps (use the /u modifier). Finally, the filter settings should be removed, as they are not settings at all. This practice was removed in 4.5. Also, I'm not sure about the setlocale() call. In my tests, PHP seems to ignore the locale for almost everything.

1 0

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by syscrusher 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/16729 Project: Drupal Version: 4.5.2 Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: syscrusher Status: active BTW, I can also duplicate this bug with the CVS version of Drupal 4.6 as of 2005-03-24. syscrusher Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 00:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 01:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell. ------------------------------------------------------------------------ March 26, 2005 - 14:15 : Steven I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later. ------------------------------------------------------------------------ March 26, 2005 - 15:00 : Junyor Works fine in Safari and Opera with or without that rule. IE 5 seems to have the same problem with or without it. In 4.5.2, the fieldsets aren't displayed at all. In HEAD, they cross the screen, pushing everything else down. In other words, it doesn't seem to have any bad effects on Mac browsers with or without that rule.

1 0

[drupal-devel] Drupal 4.6 "drupal.css" issue with Konqueror browser
by Scott Courtney 26 Mar '05

26 Mar '05

Greetings! I apologize if I'm not following the right channel for this question, but I've filed an issue on it (with a patch), and I'm not sure where to go next, so I post to the list. There is a problem with drupal.css in all recent versions, back to at least 4.4, that causes the Konqueror web browser (part of KDE) to be unable to edit text input fields if they appear inside an HTML fieldset block. The issue is described in detail here: http://drupal.org/node/16729 Along with the issue report, I provided a one-line change to the CSS file that fixes the problem. I've tested the patch against Konqueror (several versions), Firefox, Mozilla, and IE, and as far as I can tell, it doesn't break any of the other browsers and it definitely fixes the Konqueror problem. My question is, since no one has replied to my issue and we are nearing the release of Drupal 4.6, what do I need to do to try to get this small patch included in the core of 4.6 and also applied to 4.5? I have a CVS account, but only for contribs and not for core (and in any case, I know better than to just apply something to someone else's code without permission!). Thanks for any suggestions. If there's another venue where I should be posting the patch, please let me know and I'll do so right away. Kind regards, Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them scott(a)4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/scott.pubkey

2 2

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by Junyor 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/16729 Project: Drupal Version: 4.5.2 Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: Junyor Status: active Works fine in Safari and Opera with or without that rule. IE 5 seems to have the same problem with or without it. In 4.5.2, the fieldsets aren't displayed at all. In HEAD, they cross the screen, pushing everything else down. In other words, it doesn't seem to have any bad effects on Mac browsers with or without that rule. Junyor Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 06:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 07:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell. ------------------------------------------------------------------------ March 26, 2005 - 20:15 : Steven I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later.

1 0

[drupal-devel] [bug] Menu cache is not locale aware
by elfur 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/13503 Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: chx Reported by: chx Updated by: elfur Status: patch I'd like to +1 this change. I too have a dual language website where changing the language in the language block does not change the language of the navigation block, while all other blocks change. But what also happens is that on my user profile page I can select which language are assigned to the user, and when I swithced that the first time, the language of the navigation block got switched to the selected language of the web - however when I changed that user profile setting back to my preferred language, the navigation block does not change back with it. Infact, when I then change the language in the language block, the navigation does not change back to what it was stuck at before *shrug*. I hope that does make sense to anyone. /me heads over to try that patch to see if it fixes this annoying "feature" thanks elfur http://elfur.is elfur Previous comments: ------------------------------------------------------------------------ November 26, 2004 - 07:13 : chx Attachment: http://drupal.org/files/issues/menu_locale.patch (522 bytes) If you have a multi language site, and change languages, the menu is already cached, thus it can not display the translated version. This simple patch makes the menu cache locale aware. Do I need to file the same patch against HEAD? 'Cos it applies, too. ------------------------------------------------------------------------ November 26, 2004 - 09:13 : Dries Isn't it better to flush the menu cache when someone (or the admin) switches languages? Keeps the cache size down. ------------------------------------------------------------------------ November 26, 2004 - 11:20 : chx There could be several points where the language is changed. i18n for example displays a language selection block which lets you switch anytime. Thus I think this solution is the best. ------------------------------------------------------------------------ November 26, 2004 - 12:26 : Goba See also this issue [1], which is still (again) open. The locale is also changed, when the admin changes it as the default on the admin interface, and the menu cache needs to be flushed then, and the admin needs to be redirected. I don't know how these problems are solved currently, so I would only be able to submit a placebo patch to make that issue pop up again... [1] http://drupal.org/node/11312 ------------------------------------------------------------------------ November 26, 2004 - 13:28 : Bèr Kessels I solved it by adding some logic to the swithcer function in i18n: when a language is switched the cache is flushed. The negative side of this, is that if you have hundred various roles of users reading English and one switching to German, the complete cahce is flushed. But then again, who has so many roles, that this might become an issue? ------------------------------------------------------------------------ November 27, 2004 - 09:59 : Dries I just fixed bug 11312 [2]. I don't see what's wrong with invalidating the user's menu cache when he or she switches language. Just do: <?php cache_clear_all("menu:$user->uid"); ?> [2] http://drupal.org/node/11312 ------------------------------------------------------------------------ January 30, 2005 - 19:26 : Jose A Reyero This is needed also for i18n. Invalidating cache is not a solution here, as we would need to do it also for anonymous users. So I think this is a simple solution and will work fine for both cases, user/locale and i18n. ------------------------------------------------------------------------ January 31, 2005 - 15:15 : Bèr Kessels I found out what is wrong with this: Swithcing and cache are two completely differetn things: The language is a per-session setting. The cache is a per-role setting. So any user can switch langauge on any moment, resulting in a cahce that will get flushed on nearly every page-load. And since roles and sessions are tow different thingsm we should not flush a role based cache because a variable in the session changes. The only correct option would be to have per-locale cache. (as per Jose's patch) ------------------------------------------------------------------------ January 31, 2005 - 15:27 : Bèr Kessels Correction, It was not José that submitteed the patch for locale aware menu's but Károly Négyesi, I got confused because José was the last to comment on that patch. ------------------------------------------------------------------------ February 2, 2005 - 20:44 : moshe weitzman i can't make heads or tails of this patch request. it seems that some folks are confusing menu cache and page cache. and we don't even have a role cache. dries' question remains unanaswered. why can we not just rebuild a user's menu cache when needed? ------------------------------------------------------------------------ February 2, 2005 - 21:17 : Jose A Reyero /why can we not just rebuild a user's menu cache when needed?/ This way you cannot have menus in multiples languages for anonymous users, unles they're not cached at all. ------------------------------------------------------------------------ February 2, 2005 - 21:27 : moshe weitzman Aha! Makes sense now. +1 for this simple patch. ------------------------------------------------------------------------ March 13, 2005 - 22:10 : killes(a)www.drop.org I agree, this should get patched. Still applies. ------------------------------------------------------------------------ March 13, 2005 - 23:24 : stefan nagtegaal Tested against 4.6 RC I and works perfectly! +1 for applying this bug-fix.. ------------------------------------------------------------------------ March 14, 2005 - 13:23 : Bèr Kessels Josés latest comment tels in much less wording what i tried to explain too. Still +1 from me, since with i18n (and other possible language modules) you cannot simply flush the cache. This patch is simple, clean and only adds one row per language to your cache table. That cannot be a problem, now, can it?

1 0

[drupal-devel] [bug] Konqueror 3.3.x problems with forms input inside fieldset tags
by Steven 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/16729 Project: Drupal Version: 4.5.2 Component: node system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: syscrusher Updated by: Steven Status: active I believe that piece of CSS is there for IE5, but I can't remember if it was for Windows or Mac. I'll do some testing later. Steven Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 06:33 : syscrusher Certain versions of the Konqueror browser have a serious problem with form input in Drupal 4.4.x and 4.5.x. The symptoms are that keyboard and mouse input is completely ignored in the affected "text" and "textarea" fields. The symptoms only occur on textual fields that occur within a <fieldset>...</fieldset> tag set. This occurs, for example, when the form_group() API function is invoked. I have tested several variants on the fieldset attributes, and as far as I can tell it doesn't matter what attributes are applied. I also tried it with a manually-created <fieldset><input type="text" ... /></fieldset> sequence, to eliminate the subtags such as legend, description, and title. The problem occurs even with a bare fieldset, and immediately goes away when the form elements are used without being in a fieldset. I further tested to ensure that the <table> tag was not involved, because a Google search suggested that there were problems with tables and fieldsets in Konqueror. Again, the problem is duplicable with no table in the fieldset. It took a lot of digging, but I have finally traced the problem to the file misc/drupal.css. Specifically, the following clause appears to be at fault: .node-form fieldset { display: inline; } If I comment out the "display: inline;" attribute, then the fields work correctly. There does not appear to be any ill effect from this so far, but I haven't tested extensively nor have I tested to see if this patch breaks any other browsers. I can duplicate this problem across several patch levels of Konqueror 3.3.0, and across Drupal 4.5.0 through 4.5.2. ------------------------------------------------------------------------ February 4, 2005 - 07:14 : syscrusher I've verified that the patch doesn't break Firefox 1.0, and also that it /does/ fix the problem with Konqueror 3.3.0 in Drupal 4.4, on one of my production sites. Incidentally, the problem doesn't occur with older Konqueror versions, as far as I can tell.

1 0

[drupal-devel] [feature] Link to node on comment edit page
by kps 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/11782 Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kps Updated by: kps -Status: active +Status: patch Attachment: http://drupal.org/files/issues/comment-admin-show-node.patch (579 bytes) Interesting! The patch wasn't in HTML when I uploaded it, and the stated size (579 bytes) matches the size of the plain text file, not the size of the HTML. I'll try again.... kps Previous comments: ------------------------------------------------------------------------ October 20, 2004 - 15:31 : kps Attachment: http://drupal.org/files/issues/comment.module.patch (579 bytes) We have had users manage to post their comments on the wrong nodes, and when reviewing a newly submitted comment via admin/comment/list/approval, there seems to be no practical way to tell which node the comment belongs to. The attached patch adds a link to the node on the comment edit page. ------------------------------------------------------------------------ March 13, 2005 - 19:06 : killes(a)www.drop.org The patch is in html.

1 0

[drupal-devel] Email filter
by Mark Leicester 26 Mar '05

26 Mar '05

Hi all, I've just committed an emailfilter module which interprets a node as a plain text email. Depending on its configuration, it will attempt to indent and colorise threaded conversations, convert URLs into anchors and remove any extra linebreaks. It will also convert &, <, > etc. into HTML entities. You can see an example of its use here: http://www.planetcocoon.com/ I'm using Drupal to collect email traffic to the Apache Cocoon mailing lists in an attempt to render it more attractively. On another related topic, does anyone know how to tweak the mailhandler and listhandler to deal with the non-ASCII characters (such as ø, etc.) that come through in the usernames, subject lines and message bodies? At the moment these characters are all converted to ?. I've tried some experiments with drupal_convert_to_utf8() but I've had no luck so far. As this is my first committed module, I'd appreciate some review; any feedback that people may have to offer would be gratefully received. Regards, Mark

6 13

[drupal-devel] [task] Drupal Install System
by judah 26 Mar '05

26 Mar '05

Issue status update for http://drupal.org/node/5496 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: judah Status: active I was just about to start creating an install system for modules when someone mentioned you were already working on one. Here is my design specs, http://drupal.org/node/19427 I could not contact you via any other means so please advise what the current status is on this. Thanks judah Previous comments: ------------------------------------------------------------------------ January 29, 2004 - 03:10 : adrian I am in the process of developing a new Install API for the drupal core, which will allow a completely web based install / set up process, as well as allow contributed modules to integrate more directly into this system. A more detailed description of the system is available in this thread. This task has been created to place each of the successive patches in the patch queue. ------------------------------------------------------------------------ January 29, 2004 - 03:20 : adrian Attachment: http://drupal.org/files/issues/install_api_first_level.patch (6.42 KB) Kjartan correctly identified one of the problems in creating a unified install system. There's a lot of code that gets run by simply including the core files (bootstrap.inc, database.inc, session.inc and common.inc). A lot of this code relies upon the database connection going off without a hitch, like for instance the current system variables, themes and session code. To work around this i created a new drupal_init() function, which needs to be called when you want the system to initialize. drupal_init has a 'db_init' argument, which allows you to bypass the loading of all the database related code with a simple flag. install.php needs to run drupal core, while ignoring any database connections .. until atleast the point where the configuration settings for the database are entered, and confirmed to work. There is a new function created called 'database_connected()' , which returns a boolean true only if the database both connected and the table was selected successfully. This patch does not have a suitable error message for index.php upon not being able to make a database connection ,but that message should very likely be discussed and finalized. In the next level of the patch I will introduce the major changes, or rather additions. I haven't modified any existing files beyond the ones in this patch (at this time). ------------------------------------------------------------------------ January 29, 2004 - 06:24 : Kjartan This patch has some serious flaws though. <?php include_once "includes/bootstrap.inc"; -drupal_page_header(); include_once "includes/common.inc"; ?> By removing the drupal_page_header() you break the whole point of bootstrap as the common.inc stuff is included when its not necessary. It needs some more thought. Maybe you should take the time to make a workflow of the current Drupal init process before modifying it. Also the naming of constants, I would prefer calling them DATABASE_ATTEMPT as it makes it easier to tell them appart. ------------------------------------------------------------------------ February 9, 2004 - 14:18 : adrian I have reworked the patch into a very minimal set of requirements. To prevent the .inc files from running any code when you don't want them to , you 'define' a constant called 'DRUPAL_NO_INIT' before including bootstrap.inc. This relatively small patch is required for the install stuff to work. ------------------------------------------------------------------------ February 9, 2004 - 14:22 : adrian Attachment: http://drupal.org/files/issues/drupal_no_init_flag.patch (3.88 KB) i'll even attach it this time. ------------------------------------------------------------------------ February 9, 2004 - 14:48 : adrian Attachment: http://drupal.org/files/issues/database_init_return.patch (1.96 KB) The following patch is a modification to the includes/database*.inc set of files, to make db_connect return a boolean value depending on wether the connection was successfully made. I have changed database.inc to die() upon connection error with the message "Database Connection Unsuccessful". Cleaning up that message and placing a help page might be a good idea from an user experience point of view. This patch is required for the install system, in that it needs to test wether it has made a successfull database connection before it allows you to actually install the schema. ------------------------------------------------------------------------ February 9, 2004 - 19:15 : adrian Attachment: http://drupal.org/files/issues/install_system_alpha.tar.bz2 (11.59 KB) This is an alpha version of the new install API code. It is completely capable of installing the drupal core system without requiring any interaction with the database side. There are currently 5 configuration screens , but the API is sound for us to add / remove / change these screens as we need. In it's current state, it isn't capable of updating the base system, however the backend stubs exist, and have been tested. In the push to get the install process running smoothly i simply disabled the update interface. The previous 2 patches on this node need to be applied, but have been combined into install_system_alpha.patch which is included in this distribution. The rest of the files are new , and should not interfere with the drupal core at all. They are includes/install.inc ... the file that hosts the install api. install.php ... the front end script that initializes the install api (a total of 5 lines) install/system.install ... the install module for the core. It contains the bulk of code from update.php, and all the configuration information needed to successfully install the core. In the future , the install api will be able to easily install any contrib module through the modulename.install file that will hopefully become well supported. Note: I need to update the postgres compatibility in this .install file, and as such only mysql is fully tested now. I have posted some screenshots at my site ------------------------------------------------------------------------ February 10, 2004 - 12:22 : adrian Unconed just pointed out there is a conflict with windows installations in that there can not be an 'INSTALL' file and an 'install' directory (which contains the system.install currently) He suggested that we rename the README and INSTALL files to README.txt and INSTALL.txt. I personally move that we store the .install files within the modules directory , as in the future installing a contributed module should be as simple as dropping the module directory (containing .install , .module and whichever external files) into modules/ , and then installing the module within drupal. ------------------------------------------------------------------------ February 11, 2004 - 23:10 : moshe weitzman I played around with the patch, and successfully installed a new Drupal instance on the fitst try. Nice work, Adrian! I reviewed the code too, and found it quite Drupalish and satsfactory. Here are some notes from my install: - On the configuration file page, I selected from the radio button options a file which was not conf.php and thus did not exist. I strugged with the 'file is not writeable' error for a while until I realized that you expected me to create the file and then the installer would edit it ... in general, this page is a pretty complex introduction into drupal. I suggest simply assuming 'conf.php' here. I haven't thought about this much though. - Similar to above, I figured Drupal would create a database for me. Not so, I had to create it and then Drupal takes over. Some simple help text adddresses this point. - Use form_password() or similar when requesting a database password - The default $base_url was missing a slall for me. It said 'http://medrinstall' instead of 'http://me/drinstall' - After completing the DB install, there is no page telling you what to do next. A link to the home page is all thats needed IMO. -The site_name chosen during the install was not saved in the 'variable' table. - When you return to install.php some time later, you have no indication what a working site already exists. Not sure thats the right thing to do. Not a big deal though. P.S. Adrians suggestion to store the .install files in module specific subdirs under modules makes sense to me. Thus system.install would move to modules/system/system.install ------------------------------------------------------------------------ February 12, 2004 - 22:04 : skip I had to set up a pMachine blog yesterday for a client. I have to say... it was the easiest install process I've ever gone through (CMS-wise). Very user friendly. Lots of feedback to the user. If you haven't seen it before, you should check it out for ideas. ------------------------------------------------------------------------ February 17, 2004 - 23:26 : adrian Attachment: http://drupal.org/files/issues/install_phase2.tar.bz2 (12.96 KB) So I have spent far too much time over the last few weeks battling with this install system. My current results are in this here tarball. This time I am even less sure of it fully working in all cases, than last time. With this release I added extensive error checking to the install process, finished MOST of what is needed for the update process , but most importantly... it is a lot more secure than previously, and is specifically built to allow people to host their multiple drupal installs from just a single root. I have handled this by adding a global variable to the config file (allow_override_config) , which is checked by the install script before a new configuration file is made that would override the currently active one. There are three settings to this : 'no' , 'any' and 'auth'. I feel auth is generally the best option, as it requires anyone trying to override a working configuration file to enter the username and password for the site he is trying to override. Added checking also exists for the minimum requirements of running a drupal system (the tests probably need to be fleshed out), aswell as refusing to install a database dump into a db_url/db_prefix which seems to have a valid site installed. When a working configuration is detected on startup , the default action is to require the administrator user of the site to log in. This is for security reasons. The install script has lots of code that stops it from ever overwriting any config file that has already been created, but as I said .. it allows for the creation of a config file that will be parsed before the current valid install, but only with the express permission of that config. Config files have been moved to './conf/' , and the default config has been renamed to 'conf/default.php'. I have split install.inc into install.inc and install.module, as there was a lot of interface code specifically for the update/install sequence (and it is best available for reuse .. so i didnt wanna put it in install.php). This has an unrelated quirk for xtemplate .. I left it in the patch because for some reason I was unable to get a working default theme because xtemplate refused to populate the 'path' template variable. I also have an extensive 'gallery' of the new changes if you just want to see what it looks like. Directions for use : untar in a drupal cvs tree , and 'patch -p0 < install_alpha_2.patch' go to http://mysite/install.php ... previous configs in includes/ will be ignored for extra fun , create a hostname entry to sitea.siteb.sitec.sited.mysite , and watch the install script pick up the valid configs. ------------------------------------------------------------------------ February 18, 2004 - 09:14 : TDobes Adrian, thanks for all your work on the install system... I'll check it out once I get home this evening. Just FYI, here's a link to the XTemplate bug [1] you mentioned. (It's a simple two-line patch.) [1] http://drupal.org/node/view/5858 ------------------------------------------------------------------------ June 20, 2004 - 14:29 : adrian taking out of patch queue. Still on my todo list, but I have to get some other things done first. ------------------------------------------------------------------------ July 27, 2004 - 09:25 : JonBob The install system should (will?) handle version numbers. Some related issues to examine: None of these are really duplicates of one another, so while I'd like to close them I can't. Consider this a reminder to do so if and when the install system addresses the problems. New 'version' system field and Drupal version [2] Module dependencies [3] Show drupal version to admins [4] Meta tag with drupal version [5] Version number [6] [2] http://drupal.org/node/view/5811 [3] http://drupal.org/node/view/8402 [4] http://drupal.org/node/view/2986 [5] http://drupal.org/node/view/2828 [6] http://drupal.org/node/view/8762 ------------------------------------------------------------------------ March 13, 2005 - 10:03 : publian It made it based on install_phase2. It makes it with drupal CVS as of 2005.03.14. The improvement point is as follows. 1) The installation query command execution read database/database.mysql or database/database.pgsql. 2) Two head bytes of $_SERVER 'HTTP_ACCEPT_LANGUAGE' were seen, and the installation language was distinguished automatically. This sees the install.lang file in the languege folder. (funcution lt() like funcution t()) Making) 3)　In the installation process, the mother tongue can have been selected. (The import is done from the file in the translations folder. ) 4) Additionally, a detailed place was corrected. The bug moves though thinks many still. -- Drupal Japan ------------------------------------------------------------------------ March 13, 2005 - 10:10 : publian Attachment: http://drupal.org/files/issues/install_phase3.tar.gz (134.72 KB) It is as for appending.

1 0