- Development - lists.drupal.org

Re: [development] install should optionally create the database
by Michelle Cox 14 Oct '06

14 Oct '06

(Changed the topic to match the other because that one is better -- hope that doesn't screw up threading ) On 10/12/2006 1:03:20 AM, Kamal Mustafa (kamal.mustafa(a)gmail.com) wrote: > what I'm > thinking about. > it's does not worth the effort. everyone that > need to set up a website should at least know how to create the db, > either through the console or their admin cp. For those who don't > know, we can just direct them to their control panel documentation or > the rdbms documentation. In another post, Dries said he thought it was worth it, so I guess we're outvoted. ;) I guess he's right that it would be nice to have the choice. If it would work on my system, I wouldn't mind having the db created just to make test sites easier. I'm curious, though, is there anyone out there on shared hosting that this would work for? Both A Small Orange and Site5 that I've been on have a special interface for creating databases. I can't even create a new one through SQLYog. Michelle

11 15

Re: [development] install should optionally create the database
by Steven Peck 13 Oct '06

13 Oct '06

> -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Drupal Indonesia > Sent: Thursday, October 12, 2006 5:28 PM > To: development(a)drupal.org > Subject: Re: [development] install should optionally create > the database > > > Agree. The core dev must understand that many repeating > thread come from their > self! why not give us a clear view of: > 1. roadmap, and > 2. what drupal will support, and > 3. what drupal won't support > > i.e: I come from PHPNuke, Mambo and Joomla. Most of my > clients agree that Drupal > is better and powefull but more difficult to install and > administer. so, as new > dev we only can give suggestion while we try to learn Drupal > as deep as possible > (and take longer time because there is no comprehensive > handbook for creating > complex module, the example in the handbook is too simple, I > need a handbook > like VB .Net Manual Book). > > now, when core dev tell us (as a new developer) what is > Drupal: roadmap, what > will support and what won't support??? if Drupal official > site say: Drupal will > not support creating database during installation, please > read this discussion. > Then, no one will ask this again over and over. This will > save our time (as new > dev), save core dev time and save much email space. http://buytaert.net/roadmap Short version. The roadmap is what people who contribute code (themselves or pay others) work on. Carry through the patch. Discuss and refine as the development cycle progresses through freeze. ------------ To know and understand the current Development trends, there is no substitute for involvement and / or auditing of the Drupal development list which takes time. We do not have a dedicated person/volunteer to substitute for an equivelent kernel trap site as the Linux kernel project does. There is a synopsis list site somewhere. And someone will link to it but it is still in it's early stages. There is also the devlopment list archives which are searchable. To understand the direction Drupal is going it is important for people to check out the project mission. This is the very first link you will find on the handbooks page on Drupal.org This will help get you started on the project direction. http://drupal.org/History-mission-and-community > http://drupal.org/mission > http://drupal.org/principles Also, common misunderstanding. There is no 'core dev' group. There are active and involved developers who work pretty much on core code. There are those core module maintainers which are responsible for certain core modules. But there isn't a core dev team per se. This is also covered under the above link here: > http://drupal.org/node/21778 I hope these links help clear up some confusion. -sp

1 0

Drupal 5.x Administer Page very difficult
by Drupal Indonesia 13 Oct '06

13 Oct '06

Hi, There are many place to configure Drupal module now. I suggest we don't use administer-setting anymore. All configuration should be put on the administer-modules page. i.e, when user click on administer-module-profiles then the Profile.module setting page displayed! Jonathan.

2 1

Re: [development] Drupal 5.x Installation is Bad!
by Michelle Cox 12 Oct '06

12 Oct '06

On 10/11/2006 2:28:52 AM, Drupal Indonesia (support(a)drupal-id.com) wrote: > Now, how can Drupal 4.7.3 create tabel for me if the db username has no > rights to create table? > Isn't that a security risk? > Or just remove the db username (with create DB rights) after fresh > installation. Simply. Creating tables and creating databases are two totally different animals. As said in other responses, creating a database takes a higher class of user. On my host, creating a DB must be done through their version of cPanel so Drupal couldn't do it anyway. Plus, you don't always want Drupal to use a new database. Many people use a DB that's shared with other apps. I think the installer in 5.x is a great improvement as it creates the _tables_ for you. That's a much harder task than making a database, especially if you use prefixes. Not creating the DB doesn't make it bad at all. Michelle

7 6

Fwd: [General inquiry (other)] Change ownership of nodelist.module
by Dries Buytaert 12 Oct '06

12 Oct '06

Begin forwarded message: > From: nji(a)njivy.org > Date: Wed 11 Oct 2006 14:09:50 GMT+02:00 > To: info(a)drupal.org > Subject: [General inquiry (other)] Change ownership of > nodelist.module > Reply-To: nji(a)njivy.org, droppies(a)drupal.org > > njivy sent a message using the contact form at http://drupal.org/ > contact. > > Please grant wmostrey (http://drupal.org/user/21228) ownership of > nodelist.module (http://drupal.org/project/nodelist) Thank you, > > Nic Ivy (njivy) -- Dries Buytaert :: http://www.buytaert.net/

1 0

What is the similiar Joomla-Mambot in Drupal?
by Drupal Indonesia 12 Oct '06

12 Oct '06

I want to extend blogger.module with blogheader feature. What do I need is something like mambot in Joomla. The mambot can add on before/after a page. So, when use click on http://localhost/drupal/blog/2 then the Blogheader (this is a new field on the user profiles) will be displayed on the top of this blog page. I need any doc or link that can help me doing this task in Drupal. Better if oen can show me any Drupal module that work like mambot. Regards.

5 5

Re: [development] 2k qps
by Tamir Khason 12 Oct '06

12 Oct '06

We have sysstat installed (SAR tool) And what we see nothing in it besides some high load average until everything is stucked. It doesn't succeed to log the real situation when it comes to it, since server doesn't have any resources... No iowait noticed at all. Everything is between php/mysql. Server has good dsics, raid1 and iowait is getting to 10% maximum in bad times..also I run iostat from time to time to see what goes on. I also think change io scheduling but imo the current problem has nothing with io. Dmesg also doesn't point to anything like that. We are trying to dump the apache/mysql status once there is a problem (through mytop/server-status and other things) the problem is that it's too late in most cases and nothing "cooperates" with us. > ---------- Forwarded message ---------- > From: Khalid B <kb(a)2bits.com> > Date: Wed, 11 Oct 2006 07:05:58 -0400 > Subject: Re: [development] 2k qps > To: development(a)drupal.org > > I have another client site that shoots up to 3,000 QPS, but I don't > have > the statistics of page access for it. This one has 4 Xeons 3.2GHZ each > and 4GB. > > Write a simple script to run vmstat every 15 seconds or so, log the > output to a file. Keep it running until the "hang" happens, and then > see what it tells you about the system. Are you out of CPU? Do > you have too many blocked processes or runable processes? > Do you have a lot of wait on i/o? Are you swapping to the point of > thrashing. > > Only after you do this analysis you should decide whether to > upgrade the RAM or just tune things. > > Regarding decreasing the number of Apache processes, yes, that > means you can only serve so many users, but you prevent the chaos > caused by swapping. Think of it as a popular restaurant. If they let > in more people than they have tables/seats, would the customer be > happy? Would the staff cope with it? >

3 4

{Short issue queues need care - 8} The Yellow Team rocks!
by Augustin (Beginner) 12 Oct '06

12 Oct '06

Hello and welcome to the eighth edition of {Short issue queues need care}. This week: 1} The Yellow Team rocks! a) What happened b) The result 2} Featured short issue queues. 3} Why this report and how to cooperate? ******************************************* 1} The Yellow Team rocks! ******************************************* My last report is already a month old: I apologize for the delay. a) What happened ================ Last time, I first pointed to this issue queue: http://drupal.org/project/issues?projects=3060&states=14 I was saying that the Green Team rocks for finding a way to always keep their queue short. Then I pointed to this one: http://drupal.org/project/issues?projects=3060&categories=bug&states=8 And I invited the Yellow Team, who is responsible for dealing with it, to do its best to review those issues so as to make their queue shorter. I posted the 7th edition of {Short issue queues need care} on the 4th of September. And the Yellow Team responded in a way that astounded me: I did not expect the Team to mobilize to such an extent. The results were obvious within hours of the posting of the report. Other people were surprised, too. They are not subscribed to this list, so they didn't read the report... but they wondered why all of a sudden, on the 5th of September, they received so many feedbacks on so many old issues... :) (I guess it was kind of freaky, for some....) That is why I want to doubly apologize for delaying writing this report, because I feel I dropped the ball on this one! :( The yellow queue above was just over 100 issues long on the 4th of September. Within 2 or 3 days, it was under 60 issues, and after a week it was under 50!!! Today, it is back to over 100, though. But this is in itself an achievement: I noticed a handful of developers from the White Team (the team dealing with issues without any patch attached: http://drupal.org/project/issues?projects=3060&categories=bug&states=1 ) submitting scores of patches for review. There has been a strong drive to provide long standing bugs with patches. So, many issues have shifted back and forth between the White, Red, Yellow, Green Teams, and the Yellow Team managed to hold its ground. Well done! b) The result ================ The net result? a) The Green Team is currently a bit overwhelmed and has been all month... ;) http://drupal.org/project/issues?projects=3060&states=14 (21 issues, a handful - 4 - being old). b) The total of ALL open issues has dropped 78 issues, from 2140 issues one month ago to 2062 today (down from 2222 issues mid-august!), which proves that by focussing on short lists of issues, we avoid feeling discouraged and we do achieve something significant. So, the objective for the Yellow Team is for its queue: http://drupal.org/project/issues?projects=3060&categories=bug&states=8 to become and remain as short as the Green Team's one: http://drupal.org/project/issues?projects=3060&states=14 !! Keep going: select one or two of the 7 queues featured below and show us what you can do! Thanks for reading :) and more importantly: Thanks for contributing what you can to the Community. ******************************************* 2} Featured short issue queues. ******************************************* There are 930 subscribers to this mailing list. Is it possible that 20-50 of those read this report and decide to work together to lower the number of issues on each of the 7 queues featured this week? Pick one list. See at the very end if you wish to officially 'adopt' one queue. The number in parenthesis designs the number of issues 2 weeks old or more (i.e. issues most likely forgotten and not being dealt with). (Queue #1) DRUPAL-4-6 critical issues: http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,1… 18/06/2006 : 24 (19) issues. 25/06/2006 : 8 (5) issues. 02/07/2006 : 5 (4) issues. 07/08/2006 : 5 (5) issues. 14/08/2006 : 5 (4) issues. 22/08/2006 : 4 (2) issues. 04/09/2006: 5 (1) issues. 07/10/2006: 5 (4) issues only. Those are really critical issues, already fixed in head and 4.7. A few junior developers (myself and others) have tried to help out, here, but we lack the knowledge to solve them, and the seniority to decide to downgrade those issues ('normal' issue, or 'won't fix'). A senior developer is needed to decide the fate of those issues. If they are indeed very critical, then a patch is needed soon: can you at least tell how they should be fixed. (Queue #2) DRUPAL-4-7 critical issues: http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,1… 18/06/2006 : 31 (19) issues. 25/06/2006 : 12 (8) issues. 02/07/2006 : 7 (5) issues. 07/08/2006 : 19 (13) issues. 14/08/2006 : 7 (0) issues. 22/08/2006 : 7 (0) issues. 04/09/2006: 18 (0) issues. 07/10/2006: 23 (15) issues only! New critical issues keep coming every week, because 4.7 is the most used version. Most are not really critical, though. (It should get better for Killes when 5.0 comes out). (Queue #3) HEAD critical bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 6 (1) issues. 25/06/2006 : 13 (1) issues. 02/07/2006 : 15 (1) issues. 07/08/2006 : 16 (3) issues. 14/08/2006 : 22 (5) issues. 22/08/2006 : 21 (6) issues. 04/09/2006: 33 (8) issues. 07/10/2006: 18 (0) issues only! There are signs that people are readying HEAD for the first Beta release... (Queue #4) DRUPAL-4-6 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=12052,11555,11262,1… 18/06/2006 : 26 (25) issues. 25/06/2006 : 26 (25) issues. 02/07/2006 : 25 (24) issues. 07/08/2006 : 24 (23) issues. 14/08/2006 : 24 (23) issues. 22/08/2006 : 20 (2) issues. 04/09/2006: 11 (0) issues. 07/10/2006: 8 (8) issues. They need to be bumped to 'cvs', if the bug still exists in HEAD. If the bug hasn't been fixed yet, try to reroll the patch for head, or else set as "patch needs work". (Queue #5) DRUPAL-4-7 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=12050,11551,11252,1… 18/06/2006 : 17 (5) issues. 25/06/2006 : 16 (7) issues. 02/07/2006 : 21 (8) issues. 07/08/2006 : 15 (11) issues. 14/08/2006 : 15 (4) issues. 22/08/2006 : 12 (5) issues. 04/09/2006: 9 (3) issues. 07/10/2006: 11 (2) issues only. Make sure to note if the bug has been fixed in HEAD already: it would be silly to have a fix in 4.7, to see the bug reappear when 5.0 comes out. (Queue #6) HEAD Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 72 (67) issues. 25/06/2006 : 71 (67) issues. 02/07/2006 : 77 (66) issues. 07/08/2006 : 72 (59) issues. 14/08/2006 : 88 (59) issues. 22/08/2006 : 81 (57) issues. 04/09/2006: 82 (64) issues. 07/10/2006: 86 (54) issues. As you see, many issues are old (over 2 weeks old: 64 issues), so we have the choice between : re-rolling the patch for current head, set as code needs work, or set as already fixed if appropriate. (Queue #7) Your own list of Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&categories=bug&states=8&part… 1) Follow the search link above, 2) In the URL, replace "your_drupal_user_name" with your actual user name. 3) Reload and bookmark the page. Those are issues you have already participated in, and you should already know the context. Help the person preparing the patch to eventually come up with a patch that can be RTBC. Obviously, if there are many results to the query, start from those issues you are the most familiar with... If everyone does this, the result will be seen in the queues #4, #5 and #6 above. ******************************************* 3} Why this report and how to cooperate? ******************************************* There are now over 2000 issues in the queue. The figure sounds daunting: how can a very few volunteer developers deal with such a huge amount of bugs? The point is that we don't need to worry of the whole issue queue, but by getting somewhat more organized, the most important of those issues can be definitively dealt with. To start with, there shouldn't be anything critical within the Drupal project issues. Critical bugs must be dealt as a matter of priority. But one can get easily discouraged when facing 4 four pages of critical issues. The first step is therefore to sort out what is really critical from what is not. Having a shortlist of what is really critical, two or three developers can focus on a single issue, helping each other, so that one week later there is one really critical issue less. Similarly, 10-12 developers could get rid of 3-4 critical issues and in a few weeks, the list of critical issues would be down to almost nothing (only 1-2 issues caused by a large patch recently introduced in head, for example). If you wish to participate in tackling one of the 7 short issue queues featured here, please reply to the list, quoting only the issue you wish to 'adopt', changing also the subject title of your email to reflect the queue you have chosen. Hopefully, two or three more developers will reply to you, saying they want to help you with the issues in that same queue. Thank you to all the volunteers for your cooperation. Blessings, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

6 6

Re: [development] Drupal 5.x Installation is Bad!
by Metzler, David 12 Oct '06

12 Oct '06

>If they enter the db username that has "create database" permissions into the screen > they are most likely doing it http. So, it's passed along in plain text. Yikes. I'd agree that this is the right approach - asking for a dba username and password on the install form. Whereas this is technically true that the passwords go in clear text, that isn't always a problem. You wouldn't want to do this if you were talking to a remote hosting company that didn't provide you SSL certs, but if the server were in your company, inside a firewall, this isn't any different that how most remote database management tools behave (e.g. PGADMIN III, mysqladmin, etc) It's already been pointed out that most internet remote hosting companies wouldn't allow you to do this using the drupal provided tool anyway.... so.... I say +1 to database creation with a form provided dba username and password, especially if we put a little warning on the form. (Don't do this if your remote managing across the internet).

1 0

Why Drupal 5.x must have built-in WYSIWYG Editor?
by Drupal Indonesia 12 Oct '06

12 Oct '06

Why Drupal 5.x must have built-in WYSIWYG Editor? General discussion · Drupal 5.x Drupal-id.com - October 6, 2006 - 07:18 I am a web developer with long experience in PHP Nuke, OpenPHP, and Mambo/Joomla. After take a deep look at the Drupal source code and coding that available on TinyMCE and FCKEditor module, I can say that next Drupal version must has a builtin WYSIWYG Editor. Please CMIIW, but read my reasons first before you have different opinion: 1. Both TinyMCE and FCKEditor only find <textarea> then translate to their editor interface. Then how to avoid certain Textarea not converted? The anwer is not possible. What TinyMCE does only disable editor on certain page and FCkEditor will work if the textarea >= n rows. The real case is disknode module. When you set disnode to allow more than 1 file per disknode then the <textarea> of file upload list will converted to Editor. Currently, you can disable the <textarea> on this page but the <textarea> for type description of disknode will be disabled too. You may say, that you can enable the rich-editor-toggle, but you can't set 2 default value: the description using Editor and the file upload list using <textarea>. 2. A best solution, IMHO, is provide a function in Drupal to call the Editor. This Editor() function simply call the ediitor if available, but if no editor installed then Editor() uses <textarea>. What are the advantages if Drupal has Editor() function? 1. Developer like me, will be easier to create module that need both Editor and <textarea> in same page/block 2. We can extend the User Administration: adding capability to select which default editor for each users. We can set that default editor for user is: none (mean using textarea), TinyMCE, HTMLArea, FCKEditor or any editor that installed by third party modules. 3. Easier for community website which contain people that aren't not familiar with HTML tag 4. Easier for blogging site, since blogger usually a person with limited website knowledge, such as journalist, teacher, employee or doctor 5. At the rest, Drupal will no doubt called as the killer CMS. This will add more powerful to Drupal, the best CMS that I love.

7 6