October 2006 - Development - lists.drupal.org

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

Fwd: [drupal:dries] /modules/comment comment.module
by Stefan Nagtegaal 12 Oct '06

12 Oct '06

Begin doorgestuurd bericht: > Van: drupal-cvs(a)drupal.org > Datum: 11 oktober 2006 15:17:24 GMT+02:00 > Aan: drupal-cvs(a)drupal.org > Onderwerp: [drupal:dries] /modules/comment comment.module > Antwoord aan: development(a)drupal.org > > User: dries Branch: HEAD Date: Wed, 11 Oct 2006 13:17:24 +0000 > > Modified files: > /modules/comment comment.module > > Log message: > - Patch #87995 by merlinofchaos: cleaned up CSS and simplified > the code. > > Links: > http://cvs.drupal.org/diff.php?path=drupal/modules/comment/ > comment.module&old=1.489&new=1.490 > > -- > [ Drupal cvs list | http://list.drupal.org/ ] Shouldn't this commit also add the following css to comment.css? .indented { margin-left: 1.5em; }

1 0

LDAP Addressbook: Taking over
by DMX 12 Oct '06

12 Oct '06

Hi all, I thought about making a LDAP addressbook module and I created a project, afterward I found a project with the same name but it's very outdated. I contacted the main developer who redirected me to another but still none of them is willing to continue, as far as I see. So I wanna take over that project and continue from their code base. I hope you can help me. Thanks, Omar

1 0

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

12 Oct '06

On 10/11/2006 7:59:59 PM, Drupal Indonesia (support(a)drupal-id.com) wrote: > The solution is very simple, but we must agree first that the new > installation > should be as easy as possible while the security concern still the best :) >Here: >1. On the installation screen say: "You must enter a db username with >creating >DB rights, otherwise please create the DB first" >2. Step #2: Drupal installation checks if the DB is exists, if not then >create >the DB. >Simple, right? >This is not new techno, I see many CMSs have feature to create DB. I suppose, but I wonder if it's worth it. From my admittedly limited experience, people on shared hosting wouldn't be able to use it because of the need to create databases through cPanel or equivalent. People not on shared hosting probably know enough to not need Drupal to make the DB. So who'd use it? Would be a good survey question, I guess. Michelle

2 1

Remote usability sprint October 27th-29th
by Kieran Lal 12 Oct '06

12 Oct '06

Hello, the third remote usability sprint is upon on us and I am going to be leading an effort to conduct user experience testing of Drupal 5.0 with remote users around the world. The event will take place at Google headquarters in Mountain View. http://www.flossusability.org/ The goal is to teach developers how to conduct remote user experience testing and get good user experience feedback for Drupal 5.0 and beyond. In particular, we will use the 1700+ results of the Drupal administration survey to help create new designs for focus areas identified by the survey. 1) I am looking for core developers to participate remotely. e.g. I'll watch Drupal administrators use Drupal and make notes, mock-up suggested improvements, and file issues. 2) I am looking for volunteers to set up remote user experience testing stations. e.g. I'll set up remote streaming video and skype casts on a computer so that Drupal developers can do direct observation of Drupal administrators while I supervise. 3) I am looking for volunteers to review videos of Drupal administrators using Drupal and file issues, produce mock-ups, and make notes. Cheers, Kieran CivicSpace

1 0

CCK field generation confusion (and how to solve)
by Bèr Kessels 11 Oct '06

11 Oct '06

Hi, I have been fighting CCK fields for the last two days again. My general conclusion already was that it is a little too hard to grok, so let us get that solved. Why? Because it is too hard to grok. Looking closer at the field that are there, you will notice that the developers were: a) inconsistent. Very inconsistent. Every module with fields is completely different. b) using fields where they should have used widgets. And using widgets where they should have used fields. c) seem to be overly confused about the 'multiple' thing. How? Documentation. This is a catch22, because how much I would love to make docs, I am too unfamiliar with CCK to write docs. Even some sketchy notes by/from the original designers (why multiple, what was the idea behind fields vs widgets) can help. Are they anywhere? And more technical: Documentation can help us solve some of the issues. But even with docs and examples, this material is very hard to grok. The workflow is like spaghetti, the hooks, using call-by-refs trace back up-to 5(!) hook calls deep! (meaning: hook_foo calls hook_bar, which calls hook_baz etc, 5 of them is the most I counted). Call by reference: Either all of the stuff should be call by ref in all hooks at all points. Or none. Not have $node as called by ref in some $ops (load) but not in others (insert). Hooks vs FAPI. Because the general Drupal-way seems to be towards _altering of FAPI forms, instead of the 'old' hook mechanism, CCK uses many hooks. To alter forms. But not everywhere. These CCK hooks are well documented already, but when it mixes with form alters, you get a messy spaghetti-bowl again. I'd say: either _alters all over the place, or hooks, but never both. Hence I suggest to drop the hook_*() $op == 'form' in favour of form_alters all trough CCK. Fields widgets and the rest. This is confusing. When I read peoples fields-modules my general idea is that no-one really groks this. Eventhough I understand the database architecture behind it , I still think that a) the names are confusing. b) the associated hook ops are badly named. Hence I suggest to take the widgets out of CCK entirely, and stick them in a widget_library.module. CCK-field modules can pick widgets from that library. If they need additional widgets, then they can add them to the library. This way we can do away with the current 'widgets and fields' confusion. And we can enforce people to think slightly better about their fields vs their widgets. Right now, nearly all of the modules with CCK fields have widgets-who-validate-field-data, or fields-whom-dictate-widgets. An additional benefit is that any module can easily re-use fancy widgets without needing the whole of CCK. Another benefit, is that the amount of code that needs to be changed can be minimised. A big downside is the dependency of CCK on the widget_library.module. Who? There are a lot of users, but very few developers for CCK. The main reason, IMO is the very steep learning curve of CCK development. (see above) But I think that enough people are willing to contribute if CCK were a little more accessible. If we can agree on the abovementioned ideas, or provide better ones, then I hope we can get this started with some patches and issues right away. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

4 9