October 2008 - Development - lists.drupal.org

Important note for CCK module developers
by Karen Stevenson 08 Oct '08

08 Oct '08

The new D6 behavior of updating all modules in the modules folder, whether or not they are enabled, and the fact that they are updated in an unpredictable order, has created numerous critical issues for CCK. We have found a fix, but it is very important for every CCK contributed module that has a D6 branch to make sure the fix is implemented immediately in their install file, even if their code is still at the alpha or beta stage, since without it the mere presence of those modules in the modules folder can create critical problems for the rest of CCK. We are very very close to issuing an official release of CCK, but can't do it until we know that CCK field modules have added this update protection. Read http://drupal.org/node/304813 for details about the problem and the suggested fix, and please help us get this fix implemented immediately in all D6 CCK modules. Karen

1 0

expansion / collapse of navigation menu (taxonomy)
by gmt am 08 Oct '08

08 Oct '08

hello everyone, i have a small problem in expansion & contraction (expand/collapse) in my newly prepared navigation block. for eg :- 1 ----1.1 ----1.2 2 ----2.1 ----2.2 -----2.2.1 -----2.2.2 3 ----3.1 ----3.2 it's not working as i expected ( check box is tick marked). If anyone knows how to solve this problem.. Plz Reply Regards Mangesh Sathe

2 1

Internet Explorer Print Loses User Context
by Ron Parker 07 Oct '08

07 Oct '08

I have a situation with Printer-Friendly where I dynamically create the logo displayed on the page to be printed. This works fine in both Internet Explorer and Firefox. However, when "print" is clicked in Internet Explorer. the correct logo is not displayed. I discovered that in Internet Explorer, the printer-friendly page comes up with the correct logo in the browser. But, when "Print" (or "Print Preview") is clicked, the browser makes another httpd call to the site. This call contains NO context info: No user, group, $_SESSION, referrer info, nothing. Therefore, my program cannot select the correct logo. Does anyone understand what's going on here, and have any suggestions? Thanks.

2 1

Filter-sophical question
by Nancy Wichmann 04 Oct '08

04 Oct '08

Since Filter is a core-required module, we do not need to list it as a dependency in filter modules. Technically, this is wrong (not listing a dependency). I have not seen any filter module that actually lists filter as a requirement. While it does not cause any serious problems, it does result in incomplete self-documentation. Should we encourage filter module owners (including me) to correct this? Nancy E. Wichmann, PMP No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.5/1704 - Release Date: 10/2/2008 9:35 PM

2 2

Populating form storage during form build
by fago 04 Oct '08

04 Oct '08

You want to populate the form storage during form build? Or you do so already? Read http://drupal.org/node/302240 - an important issue to make writing multistep forms less complicated. regards, fago

1 0

Better validation for CVS tags now deployed on cvs.drupal.org
by Derek Wright 03 Oct '08

03 Oct '08

The CVS repository used to be very forgiving in what it considered a valid release tag, especially in the 'extra' portion of the tag name. This lead to all sorts of wonky tags that creative developers came up with. My least favorite are the official release tags that end in "-dev", utterly blurring the distinction between official releases and development snapshots. Now, your official release tags must match the format documented here: http://drupal.org/node/93999 For the regexp-enabled, your tag must match this: @^DRUPAL-[567]--(\d+)-(\d+)(-(ALPHA|BETA|RC)[0-9]+)?$@ For the non-regexp-enabled, that basically means that the optional part after the drupal core branch name (e.g. "DRUPAL-6") and the required two digits for your version string (e.g. "--1-0") must be either "ALPHA", "BETA" or "RC" followed by 1 or more numbers. This will also prevent people from abusing the "extra" portion of the tag name as if it was another digit in the version string. 5.x-1.2-1 or 5.x-1.2.1 is no longer allowed. This was never supported, never intended, never documented, and update_status doesn't know what to do with it. Now, you can no longer create tags like this. The next release after 5.x-1.2 should be 5.x-1.3... For history and discussion of this change, see this issue: http://drupal.org/node/252473 Apologies I never locked down this regexp earlier. ;) Cheers, -Derek (dww) p.s. Please don't reply here. If you'd like to discuss this change, reply to issue #252473. Thanks. p.p.s. Nothing changed about the format of valid branch names. Those never had much flexibility in the first place, so there's no problem there. p.p.p.s. Before you write a nastygram about what a tyrant I am, please be aware that webchick, killes, merlinofchaos and pwolanin (among others) all support this change. ;)

4 4

project node UI changes deployed on d.o
by Derek Wright 02 Oct '08

02 Oct '08

Since I suspect there might be a backlash, and the questions [1] have already started coming in about the change, I wanted to briefly announce/summarize here. As of around 3pm PDT on 2008-10-01, all of the links to directly submit new issues are gone from project nodes on drupal.org. Duplicate issues suck a huge amount of time, and many of us maintainers spend upwards of 1/2 of our effort in our issue queues just marking things duplicate. This is a drain for maintainers, and isn't all that friendly for the end users, either. To help avoid this, we want to encourage people to view the queues and/or search for an existing issue about their topic before submitting a new one. Now, on the project nodes, you have the following issue-related choices: Support * View open issues * View all issues * View all support requests * Search issues * Report a security issue Development * View pending patches * View available tasks Note that the "View all ..." links bring you to a page that includes closed, won't fix, duplicate, etc, to improve the visibility of those issues. The "Report a security issue" link just brings you to the security team page explaining the proper procedure for reporting suspected vulnerabilities (that's been true since #218571 [2]). Every issue query result page still contains a "Create" link to submit an issue for that particular project. So, worst case, this introduces a single additional click. Furthermore, maintainers still have a "Create" link in your "My projects" [3] pages. For background on this change, check out this issue: "#310446: Remove issue creation links from project pages" [4]. Note, it's very easy to change these links (project.module provides a hook, and we're tweaking it via drupalorg.module, so my usual complaints about keeping things generic for the non-d.o use cases don't apply). So, if people have suggestions for improvements, please add them to #310446. Enjoy, -Derek (dww) p.s. I could definitely see the benefit of a "Create a new issue" link that brings you to the "view open issues" page with a drupal_set_message() about "Please look for an existing issue before you create a new one" or something. If folks are in favor of that, please reopen #310446 and let's discuss there. Thanks. [1] http://drupal.org/node/316097 [2] http://drupal.org/node/218571 [3] http://drupal.org/project/user [4] http://drupal.org/node/310446

5 5

Certify Drupal for use in Government (US) Projects
by Jon Saints 01 Oct '08

01 Oct '08

On a recent project for the US government, half way through the development process, our work was stopped by a government security review which said that Drupal (and open source software in general) is not suitable for use in government projects that house personal information due to security concerns. Because our project had been approved by higher ups within the department, we were paid for our work up to that point and asked to stop. Now, its up to the tax payers to foot a much larger bill for other developers to implement a proprietary and more "secure" (or secretive) solution. The "transparency" of the Drupal project was one of the government's big objections. In their eyes, disclosing and fixing securit holes in a timely manner, is not the same thing as security. They pointed out the 100+ security disclosures since drupal 4.0 as a reason that the system could not be used. We noted that all these disclosures where quickly addressed, but that did not seem to matter. I notice other governments around the world are using Drupal with great success and savings to citizens: http://buytaert.net/new-zealand-government-using-drupal The standards we would need to meet with drupal are: http://csrc.nist.gov/groups/SMA/fisma/index.html My questions are the following: - Have any other developers run into this cerfication problem before? - Is anyone in the drupal community currently working to get Drupal certified for use in US Government projects? - Does anyone know exactly what cerfication would require from a development standpoint? If there is interest in investigating this type of certification further, let me know. NIST, the department that certifies software, is just down the road from me. I could go investigate further. Thanks Jon

23 41

Re: [development] development Digest, Vol 70, Issue 1
by Micah Tapman 01 Oct '08

01 Oct '08

I'm coming in a bit late to the U.S. government discussion but as it's an area of expertise for me I'll weigh in with some thoughts that may (or may not) be of some help. ===Warning, these are my thoughts. They are not your thoughts. They are given for free. Take them for what they are worth. Question them and do some research before taking my word for things!!!=== Software Certification Software certification in the U.S. federal government is handled under either the Common Criteria program or the Cryptographic Module Validation Program. Generally, software is (generally) certified under Common Criteria at level 2 or 4, and that software uses cryptographic modules that were/are certified under the Cryptographic Module Validation Program. For example, Drupal would qualify for a Common Criteria certification. The PHP cryptographic module used in Drupal would be certified under the Cryptographic Module Validation Program. Separating these two pieces is very important in order to assure security (the old adage about never writing "new" cryptographic functions yourself) and to make sure the government security reviewers understand what was reviewed and how it was reviewed. FISMA and NIST The Federal Information Security Management Act of 2002 consolidated most of the U.S. federal government's information security requirements and specifically tasked the U.S. National Institutes of Standards and Technology (NIST) with developing information security guidelines for all U.S. government programs. These guidelines are published in Special Publications, the most important of which is 800-53, Recommended Security Controls for Federal Information Systems. This Special Publication provides the baseline security guidance for all federal information systems, and one of those requirements is for the certification and accreditation of systems prior to deployment. Enterprise Architecture Another aspect of U.S. federal information systems is the recent (last 10 years) move to a standardized enterprise architecture. Unfortunately, the "architecture" term tends to deceive people. What enterprise architecture normally focuses on is not "architecture" as an information architect might envision it, rather it's the selection of products, software and hardware, to be used throughout an organization. For example, an agency's enterprise architecture will state which content management systems are authorized for use within the organization. This list is maintained by the agency's chief information officer and updated on a semi-regular basis. Drupal and Uncle Sam Using Drupal on a federal task requires a couple of specific steps. First, the cryptographic modules used in the system, including those used by Drupal, must be approved by the Cryptographic Module Validation Program. This is the first and most critical security hurdle, and it should be the first question the government's independent security analyst asks when they are vetting the program. Second, if Drupal is not Common Criteria certified (at least level 2), then the program needs to include security testing to ensure the product meets or exceeds the stated claims. What's this mean? It means checking to make sure Drupal performs the functions that it claims to be able to handle, such as session management or access control. Without a Common Criteria certification this testing falls on the development/program office for the new project trying to use Drupal. Third, the actual development effort must meet all of the requirements as dictated by NIST under FISMA, i.e., Special Publication 800-53. These requirements are scaled according to the security level of the system being built, from low (that means standard) to moderate (that means enhanced) to high (that means critical to the nation). All government systems must be secure, obviously, so even low (standard) security requirements are fairly onerous. High (critical) systems true enterprise class efforts with very robust security requirements. Unfortunately, the inclusion of any personally identifiable information, such as names and addresses, elevates a system to moderate (enhanced) security right off the bat. This makes development of even small systems quite complex. Fourth, the development office needs to expand on the NIST security requirements to include functional security requirements, and any other areas specific to the application being developed. Fifth, the application must be scanned and/or tested for vulnerabilities prior to deployment. Sixth, the application must be accredited (this is the second half of certification and accreditation) prior to deployment. Typically, a certification official, independent from the development office, provides an executive (the accrediting authority) with a report on the application's security posture and any deficiencies. This report is the basis for the executive's decision about whether or not to approve deployment. Deploying Drupal My recommendation for anyone trying to deploy Drupal on a federal task is to first and foremost get it on the agency's list of approved products, i.e., the enterprise architecture. This is a time consuming task but it will pay dividends. Second, standardize on a Drupal version and document exactly what cryptographic functions will be used. Cryptography is a complex and touchy subject, probably because most of us (me included) can't really understand it directly, so using an approved cryptographic module is the only way to go. If you don't, and someone asks about it, your entire project may come to a screeching halt. I'd also take the time to go through all of the requirements for the system, whether it's low, moderate, or high, in NIST Special Publication 800-53. Doing that will allow you to interact with the certification and accreditation team on their level and you'll already know all of their questions, it's also a halfway decent security requirements reference. And don't forget to also document and work to fulfill all of your application's specific security requirements! Finally, plan on doing some actual scanning testing of the application and providing this report to the accrediting authority prior to their decision about deploying the application. <self serving promotion>Penetration testing of web applications is really helpful when it comes time to answer the question, "Is this application secure enough to put out on the Internet?"</self serving promotion>. I guess that's a lot of info, to the point of being a TLDR post :-). Sorry for rambling a bit but it's a complex subject and one I've spent more time with than I care to admit. If anyone's interested in more information (you must be crazy!) feel free to drop me a line. Oh, and all this stuff only applies to normal government tasks, sensitive but unclassified stuff, not to national security efforts, those are governed under Department of Defense guidelines, not by NIST. Micah Tapman Principal Quest Consultants LLC 240-297-1014 development-request(a)drupal.org wrote: > Send development mailing list submissions to > development(a)drupal.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.drupal.org/listinfo/development > or, via email, send a message with subject or body 'help' to > development-request(a)drupal.org > > You can reach the person managing the list at > development-owner(a)drupal.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of development digest..." > > > Today's Topics: > > 1. Re: Certify Drupal for use in Government (US) Projects > (Piermaria Maraziti) > 2. Re: Certify Drupal for use in Government (US) Projects > (Bryan Ruby) > 3. Re: Certify Drupal for use in Government (US) Projects > (Jon Saints) > 4. Announcing DRUPAL-7-0-UNSTABLE-1 (Angela Byron) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 01 Oct 2008 01:02:15 +0200 > From: Piermaria Maraziti <piermaria(a)maraziti.it> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: <20080930230359.675E31440B8(a)polimnia.eridia.it> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 17.14 30/09/2008, you wrote: > > >> The "transparency" of the Drupal project was one of the government's >> big objections. >> > > Just as a quick note by a lurker: various organs of the Italian > government (Finance Ministery but not only) judged the "open" is OS > projects to be a very good element for the usual reasons addressed by > OS evangelists, also about security issues. It's a priority, to them, > also the active participation in community: giving help when they can > to receive help when they need (yep: most utilitary, not so > idealistic - but pragmatic and correct). > > Ciao! > > > --8<-----------------------------------fnord----- > Piermaria Maraziti piermaria(a)maraziti.it KALLISTI > ICQ744473 MSN:kallisti@hotmail.it +3934735GILDA > www.gilda.it www.eridia.it www.hovistocose.it > > > > ------------------------------ > > Message: 2 > Date: Tue, 30 Sep 2008 21:47:44 -0500 > From: Bryan Ruby <bryan(a)cmsreport.com> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: <48E2E4D0.9060502(a)cmsreport.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I've read all the messages in this thread, but I want to build on what > Steven has to say here. Please allow one disclaimer so I don't get > myself in trouble. Although I work for the federal government, I do not > speak for the federal government nor from my position in the federal > government. I'm simply a Drupal fan. > > Steven is right about the number of competing standards/programs and > levels of reviews/audits/and certification that go on in the federal > government. In many of the cases with FISMA (one of the standards Joe > links to in his first message), the certification that takes place in > most agencies are for systems and not in particular a single application > such as Drupal. In many respects this is a bottom-up certification > where each person in the chain certifies to their supervisor that a > system follows agency rules, guidelines and federal laws in making sure > the system is secure, properly patched, and all risks have been > identified/minimized. It is a very difficult and laborious process in > trying to policy put into practice. > > My agency utilizes a mix of Unix, Linux, and Windows systems. On our > administrative PCs we run a mix of propriety and open source software > (we've used Thunderbird as our official email client for years). On our > operational systems all our applications and OS are open source or built > in-house applications (utilizing Java, Tcl, Python, and variations of > C). Federal agencies can and do adopt open source for their > applications. In fact, I've seen the certification process knock out > more propriety systems than open source systems especially if they're > aging systems with little in the way of user access control granted. > Every year, I have to have one necessary propriety system given an > exception since it doesn't quite meet the requirements...and this system > can't even be networked into the office LAN. > > Here is my guess as to why Drupal wasn't accepted, without getting deep > into the policy. As I said at the start, from the system owner all the > way up through the agency's management up to the CIO...EVERYONE has to > certify that the system is secure and risks have been > identified/minimized. This is especially true when it comes to > personally identifiable information (PII) and/or if the system is > outside the firewall. In order for all those people to sign on to the > certification, they each have to have an understanding of the system. > My guess is that someone was not comfortable with their own > understanding of Drupal or open source to know whether the system would > meet all the requirements (especially if they're racing to complete > budgets/certifications during the final hours of the fiscal year. The > fact is some agencies or managers in those agencies just don't have an > understanding of the open source model and are very cautious in moving > away from what they know. Eventually, we'll have to educate them. > > Joe, what strikes me as odd though is that before a project is approved > these days the security requirements are understood. It sounds to me as > if someone on the federal side didn't do their job in working with and > informing the IT Security Officer about what this project was all > about. Very interesting and I hope it never happens to me. > > BryanSD > > Steven Peck wrote: > >> Which government security review/standard? >> >> There are dozens if not hundreds of competing standards/programs and >> levels of auditing and determination depending on which department you >> are dealing with. For example just one program was formerly known as >> DITSCAP and is now DIACAP. >> >> Many of these have more to do with procedures and policies then code. >> >> Steven >> >> On Tue, Sep 30, 2008 at 8:40 AM, Jon Saints <saintsjd(a)gmail.com> wrote: >> >> >>> The names of Citizens are collected on the website along with some personal >>> contact information. We were told that our application required the Medium >>> level security certification. >>> >>> For collecting more sensitive information, certification becomes nearly >>> impossible. >>> >>> Thanks >>> Jon >>> >>> On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter >>> <gerhard(a)killesreiter.de> wrote: >>> >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Jon Saints schrieb: >>>> >>>> >>>> >>>>> On a recent project for the US government, half way through the >>>>> development process, our work was stopped by a government security >>>>> review which said that Drupal (and open source software in general) >>>>> is not suitable for use in government projects that house personal >>>>> information due to security concerns. >>>>> >>>>> >>>> Just out of interest: What kind of information are we talking about? >>>> Tax numbers, bank accounts? >>>> >>>> [...] >>>> >>>> >>>> >>>>> I notice other governments around the world are using Drupal with great >>>>> success and savings to citizens: >>>>> http://buytaert.net/new-zealand-government-using-drupal >>>>> >>>>> >>>> Seems like a showcase site only. >>>> >>>> Cheers, >>>> Gerhard >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>> >>>> iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK >>>> BX1vLaioeWG348yH/V/ufKs= >>>> =yFhK >>>> -----END PGP SIGNATURE----- >>>> >>>> >>> >>> >> >> > > > > ------------------------------ > > Message: 3 > Date: Tue, 30 Sep 2008 23:27:17 -0600 > From: "Jon Saints" <saintsjd(a)gmail.com> > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development(a)drupal.org > Message-ID: > <8e779d5d0809302227y6a2d6f41q4bf6f728a496dd9a(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks for all the informative comments. The discussion has been most > helpful. > > Its does appear that our case was the result of a decision of an individual > (who maybe is not familiar with Drupal), and not a sign of general > opposition by the government to Open Source software. > > That is good to know. > > Reading through NIST's documentation it seems that certification for > software to meet the FISMA standards usually takes years. As others have > pointed out, this is just one of many different standards that the > government has for software. Its unclear to me where we could even start to > certify Drupal for government use. > > The lesson here... approval of open source tools seems to happen on a case > by case and department by department basis. Even if your project is > approved by a Department heads, ask for a review of the proposal by the > Security Officer in charge before work begins. In our case, I am not sure > why that did not happen until half way through the project. We are just > learning to work for the government. So this is a lesson we will take > carefully into all our work from here on. > > I have contacted NIST to see if I could sit down and chat with someone to > bring up some of our questions posted in this thread. If I do get a > conversation, I will be sure to post the comments back to the group here. I > have also asked them for alist of the approved content management systems so > we can get an idea of which companies/projects have achieved certification. > > Thanks > Jon > > On Tue, Sep 30, 2008 at 8:47 PM, Bryan Ruby <bryan(a)cmsreport.com> wrote: > > >> I've read all the messages in this thread, but I want to build on what >> Steven has to say here. Please allow one disclaimer so I don't get myself >> in trouble. Although I work for the federal government, I do not speak for >> the federal government nor from my position in the federal government. I'm >> simply a Drupal fan. >> >> Steven is right about the number of competing standards/programs and levels >> of reviews/audits/and certification that go on in the federal government. >> In many of the cases with FISMA (one of the standards Joe links to in his >> first message), the certification that takes place in most agencies are for >> systems and not in particular a single application such as Drupal. In many >> respects this is a bottom-up certification where each person in the chain >> certifies to their supervisor that a system follows agency rules, guidelines >> and federal laws in making sure the system is secure, properly patched, and >> all risks have been identified/minimized. It is a very difficult and >> laborious process in trying to policy put into practice. >> >> My agency utilizes a mix of Unix, Linux, and Windows systems. On our >> administrative PCs we run a mix of propriety and open source software (we've >> used Thunderbird as our official email client for years). On our >> operational systems all our applications and OS are open source or built >> in-house applications (utilizing Java, Tcl, Python, and variations of C). >> Federal agencies can and do adopt open source for their applications. In >> fact, I've seen the certification process knock out more propriety systems >> than open source systems especially if they're aging systems with little in >> the way of user access control granted. Every year, I have to have one >> necessary propriety system given an exception since it doesn't quite meet >> the requirements...and this system can't even be networked into the office >> LAN. >> >> Here is my guess as to why Drupal wasn't accepted, without getting deep >> into the policy. As I said at the start, from the system owner all the way >> up through the agency's management up to the CIO...EVERYONE has to certify >> that the system is secure and risks have been identified/minimized. This is >> especially true when it comes to personally identifiable information (PII) >> and/or if the system is outside the firewall. In order for all those people >> to sign on to the certification, they each have to have an understanding of >> the system. My guess is that someone was not comfortable with their own >> understanding of Drupal or open source to know whether the system would meet >> all the requirements (especially if they're racing to complete >> budgets/certifications during the final hours of the fiscal year. The fact >> is some agencies or managers in those agencies just don't have an >> understanding of the open source model and are very cautious in moving away >> from what they know. Eventually, we'll have to educate them. >> >> Joe, what strikes me as odd though is that before a project is approved >> these days the security requirements are understood. It sounds to me as if >> someone on the federal side didn't do their job in working with and >> informing the IT Security Officer about what this project was all about. >> Very interesting and I hope it never happens to me. >> >> BryanSD >> >> >> Steven Peck wrote: >> >> >>> Which government security review/standard? >>> >>> There are dozens if not hundreds of competing standards/programs and >>> levels of auditing and determination depending on which department you >>> are dealing with. For example just one program was formerly known as >>> DITSCAP and is now DIACAP. >>> >>> Many of these have more to do with procedures and policies then code. >>> >>> Steven >>> >>> On Tue, Sep 30, 2008 at 8:40 AM, Jon Saints <saintsjd(a)gmail.com> wrote: >>> >>> >>> >>>> The names of Citizens are collected on the website along with some >>>> personal >>>> contact information. We were told that our application required the >>>> Medium >>>> level security certification. >>>> >>>> For collecting more sensitive information, certification becomes nearly >>>> impossible. >>>> >>>> Thanks >>>> Jon >>>> >>>> On Tue, Sep 30, 2008 at 9:35 AM, Gerhard Killesreiter >>>> <gerhard(a)killesreiter.de> wrote: >>>> >>>> >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Jon Saints schrieb: >>>>> >>>>> >>>>> >>>>> >>>>>> On a recent project for the US government, half way through the >>>>>> development process, our work was stopped by a government security >>>>>> review which said that Drupal (and open source software in general) >>>>>> is not suitable for use in government projects that house personal >>>>>> information due to security concerns. >>>>>> >>>>>> >>>>>> >>>>> Just out of interest: What kind of information are we talking about? >>>>> Tax numbers, bank accounts? >>>>> >>>>> [...] >>>>> >>>>> >>>>> >>>>> >>>>>> I notice other governments around the world are using Drupal with great >>>>>> success and savings to citizens: >>>>>> http://buytaert.net/new-zealand-government-using-drupal >>>>>> >>>>>> >>>>>> >>>>> Seems like a showcase site only. >>>>> >>>>> Cheers, >>>>> Gerhard >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>>> >>>>> iD8DBQFI4kdWfg6TFvELooQRArp1AKCdXFYZDMztJ7wrhhiOJOFG4q3/lACfbsXK >>>>> BX1vLaioeWG348yH/V/ufKs= >>>>> =yFhK >>>>> -----END PGP SIGNATURE----- >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >

1 0

Announcing DRUPAL-7-0-UNSTABLE-1
by Angela Byron 01 Oct '08

01 Oct '08

Please see http://drupal.org/node/311949 for back-story. Summary: "Unstable" releases are going to be periodic (probably bi-weekly-ish or as otherwise needed) "snap-shots" of what's in HEAD, intended for pre-alpha testers who want to provide very preliminary feedback, core developers rolling "epic" HEAD patches who want something that doesn't change every hour to roll against, and/or contributed module developers who want to get the jump on porting their modules against something that's not a constantly moving target. Drupal 7 is currently being developed heavily, and what is in these unstable releases bears very little resemblance to what the final release of Drupal 7 will look like; this is merely a tool for contributors to do their work more efficiently. Please note that these are called "unstable" releases for a reason. They are intended for developers only, or testers comfortable with things randomly exploding in their face. Do NOT upgrade your production sites to unstable releases. Do NOT expect APIs to remain frozen in any way between unstable releases until code freeze. I'm not going to even include instructions on how to get it, because honestly, if you can't figure it out, you really shouldn't be using it. ;) Now, that said, here's a summary of things that are included in UNSTABLE-1. For the full list, see http://cvs.drupal.org/viewvc.py/drupal/drupal/CHANGELOG.txt?revision=1.280&… which I will try to make a point of actually remembering to update next time I roll an unstable release. :P For developers: =============== - SimpleTest module, an automated code tester, is now in core, along with a bazillion tests. These (should) now all pass, so you can use this as a guideline to know whether your patches / modules have broken anything. See documentation at http://drupal.org/simpletest. http://acquia.com/files/test-results/index.html for an idea of how our overall test coverage is coming along. - A completely new database API, known as "Database: The Next Generation" (DBTNG). This involves a lot of changes, so please see the docs at http://drupal.org/node/310069. - A "code registry" which is a set of database tables holding all of the functions in all of the modules, allowing files to be lazy-loaded. This requires changes to your .info files. See http://drupal.org/node/224333#registry for more details. - WYSIWYG editors now have a hope and prayer of integrating with textareas given the new #input_format property on textareas. - Image toolkits can now be supplied by modules. This is nice, so you don't have to do awkward copying of 'image.imagemagick.inc' into the includes folder. For users: ========== - Core now offers two install profiles: a basic one that sets up stuff like an "Article" and "Page" content type, some Taxonomy vocabularies, etc. The installer requirements check also got a nice makeover and looks more like the status report page. - Removed several modules and extraneous features: Throttle module's gone, Ping module's gone, access rules are gone, that horrible wall of comment settings is gone, etc. - Added drag-and-drop to a bunch of areas (poll results, languages, etc.) that missed them in D6. - Permissions now have descriptions, and node permissions are now sorted by content type rather than by verb. Known Bugs: =========== Plenty, but the most critical one is that you can't currently upgrade 6.x => 7.x: http://drupal.org/node/303889. Actually, I suppose this could also be considered a "feature" of unstable releases, depending on your point of view. ;) Over the next couple weeks, let's continue to hammer on http://groups.drupal.org/patch-spotlight and try and have some new exciting patches in for UNSTABLE-2. :) -- Join us at Do It With Drupal! A large scale, curated education event December 10-12, New Orleans http://www.doitwithdrupal.com

1 0