From bryan at cmsreport.com Wed Oct 1 02:47:44 2008 From: bryan at cmsreport.com (Bryan Ruby) Date: Tue, 30 Sep 2008 21:47:44 -0500 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E24756.4050900@killesreiter.de> <8e779d5d0809300840s68501af1peb2501b849ad8d21@mail.gmail.com> Message-ID: <48E2E4D0.9060502@cmsreport.com> 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 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 >> 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----- >>> >> > > > From saintsjd at gmail.com Wed Oct 1 05:27:17 2008 From: saintsjd at gmail.com (Jon Saints) Date: Tue, 30 Sep 2008 23:27:17 -0600 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E2E4D0.9060502@cmsreport.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E24756.4050900@killesreiter.de> <8e779d5d0809300840s68501af1peb2501b849ad8d21@mail.gmail.com> <48E2E4D0.9060502@cmsreport.com> Message-ID: <8e779d5d0809302227y6a2d6f41q4bf6f728a496dd9a@mail.gmail.com> 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 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 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 >>> 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----- >>>> >>>> >>> >>> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20080930/1f9a91d6/attachment.htm From drupal-devel at webchick.net Wed Oct 1 05:29:45 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Wed, 01 Oct 2008 01:29:45 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-1 Message-ID: <48E30AC9.7090705@webchick.net> 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&view=markup&pathrev=DRUPAL-7-0-UNSTABLE-1 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 From m.tapman at questconsultantsllc.com Wed Oct 1 06:19:00 2008 From: m.tapman at questconsultantsllc.com (Micah Tapman) Date: Wed, 01 Oct 2008 02:19:00 -0400 Subject: [development] development Digest, Vol 70, Issue 1 In-Reply-To: References: Message-ID: <48E31654.7000509@questconsultantsllc.com> 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. 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?". 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 at drupal.org wrote: > Send development mailing list submissions to > development at 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 at drupal.org > > You can reach the person managing the list at > development-owner at 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 > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development at drupal.org > Message-ID: <20080930230359.675E31440B8 at 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 at maraziti.it KALLISTI > ICQ744473 MSN:kallisti at 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 > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development at drupal.org > Message-ID: <48E2E4D0.9060502 at 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 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 >>> 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" > Subject: Re: [development] Certify Drupal for use in Government (US) > Projects > To: development at drupal.org > Message-ID: > <8e779d5d0809302227y6a2d6f41q4bf6f728a496dd9a at 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 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 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 >>>> 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----- >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.drupal.org/pipermail/development/attachments/20080930/1f9a91d6/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Wed, 01 Oct 2008 01:29:45 -0400 > From: Angela Byron > Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-1 > To: development at drupal.org > Message-ID: <48E30AC9.7090705 at webchick.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > 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&view=markup&pathrev=DRUPAL-7-0-UNSTABLE-1 > 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. :) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5281 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.drupal.org/pipermail/development/attachments/20081001/90917c23/attachment-0001.bin From lapurd at gmail.com Wed Oct 1 07:40:17 2008 From: lapurd at gmail.com (Drupal Developer) Date: Wed, 01 Oct 2008 03:40:17 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> Message-ID: <48E32961.8090208@gmail.com> Wow, I would like everybody to notice something right here. In the message I reply to, Matt Farina said: "The security team handles things in a tight way. When something is reported it's not opened up to the world. If the issue is valid it's handled behind closed doors until a fix and advisory is sent out." /end of citation/ I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary? I'm very concern about that and invite everybody to collaborate on this one. Does Matt represent a real situation at this matter in Drupal development community? If not, then I'm sure that many people would like to know exactly what the process is for handling security issues from the moment they have been reported? Thanks in advance, Alex matt at mattfarina.com wrote: > Jon, > > Thanks for your interest in this. I'm interested in this as well. > > Some of their concerns seem to be over some misconceptions that might > help to be cleared up. > > Someone correct me if I'm wrong but drupal 4.0 was 10 major releases > ago. 100 + advisories over 10 major releases isn't as many as the 3 > which the numbering might look like. Before drupal 5 the major > releases were point releases and not full number releases. On top of > that, the security advisories cover contributed modules and have > included other libraries used by drupal modules, such as getID3. > > The security team handles things in a tight way. When something is > reported it's not opened up to the world. If the issue is valid it's > handled behind closed doors until a fix and advisory is sent out. > Those advisories come out on Wednesdays so they can immediately be > acted on. > > I would be very curious as to what it would take to certification as > well as their concerns. > > Matt > > Quoting Jon Saints : > >> 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 From victorkane at gmail.com Wed Oct 1 07:59:09 2008 From: victorkane at gmail.com (Victor Kane) Date: Wed, 1 Oct 2008 00:59:09 -0700 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E32961.8090208@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> Message-ID: On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer wrote: > Wow, I would like everybody to notice something right here. > > In the message I reply to, Matt Farina said: > > "The security team handles things in a tight way. When something is reported > it's not opened up to the world. If the issue is valid it's handled behind > closed doors until a fix and advisory is sent out." /end of citation/ > > I thought that Drupal is an open community of open source developers working > under GPL license. > Does it mean that ALL issues have to be openly reported to all community for > everybody to review? > Don't you all think that handling security issues behind closed doors until > a fix and advisory will be sent out is sound more like corporate way of > thinking on a way to develop something proprietary? It's a GPL license, that's why I am sure the security team is open to anyone who is interested in helping out on that very important front. But GPL doesn't mean that we have to be stupid as a community, and advertise exploits before a fix can be made and people given a chance to have a security fix to use. Just as the corporate world, as we are finding out all over the world these days, certainly has no "monopoly over intelligence", or over doing what's best for all, open source communities can be smart too. There's nothing proprietary about that. Quite the opposite, in fact: defending ourselves against conspiracies to wreak havoc certainly has to be the right of open source communities, Victor Kane http://awebfactory.com.ar > > I'm very concern about that and invite everybody to collaborate on this one. > > Does Matt represent a real situation at this matter in Drupal development > community? > If not, then I'm sure that many people would like to know exactly what the > process is for handling security issues from the moment they have been > reported? > > Thanks in advance, > Alex > > > matt at mattfarina.com wrote: >> >> Jon, >> >> Thanks for your interest in this. I'm interested in this as well. >> >> Some of their concerns seem to be over some misconceptions that might help >> to be cleared up. >> >> Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. >> 100 + advisories over 10 major releases isn't as many as the 3 which the >> numbering might look like. Before drupal 5 the major releases were point >> releases and not full number releases. On top of that, the security >> advisories cover contributed modules and have included other libraries used >> by drupal modules, such as getID3. >> >> The security team handles things in a tight way. When something is >> reported it's not opened up to the world. If the issue is valid it's handled >> behind closed doors until a fix and advisory is sent out. Those advisories >> come out on Wednesdays so they can immediately be acted on. >> >> I would be very curious as to what it would take to certification as well >> as their concerns. >> >> Matt >> >> Quoting Jon Saints : >> >>> 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 > From mike at mikeyp.net Wed Oct 1 08:06:04 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Wed, 1 Oct 2008 01:06:04 -0700 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E32961.8090208@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> Message-ID: <018D860C-D280-4698-AEAC-1322FA3BDE16@mikeyp.net> http://drupal.org/security-team#report-issue It's on the top of every "Submit Issue" page on drupal.org. Any code that is in an official release of Drupal is 100% open. Nothing in the GPL prevents the bug fixes *prior* to release from being performed in a non-public manner. -Mike On Oct 1, 2008, at 12:40 AM, Drupal Developer wrote: > Wow, I would like everybody to notice something right here. > > In the message I reply to, Matt Farina said: > > "The security team handles things in a tight way. When something is > reported it's not opened up to the world. If the issue is valid it's > handled behind closed doors until a fix and advisory is sent out." / > end of citation/ > > I thought that Drupal is an open community of open source developers > working under GPL license. > Does it mean that ALL issues have to be openly reported to all > community for everybody to review? > Don't you all think that handling security issues behind closed > doors until a fix and advisory will be sent out is sound more like > corporate way of thinking on a way to develop something proprietary? > > I'm very concern about that and invite everybody to collaborate on > this one. > > Does Matt represent a real situation at this matter in Drupal > development community? > If not, then I'm sure that many people would like to know exactly > what the process is for handling security issues from the moment > they have been reported? __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From lapurd at gmail.com Wed Oct 1 08:19:04 2008 From: lapurd at gmail.com (Drupal Developer) Date: Wed, 01 Oct 2008 04:19:04 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> Message-ID: <48E33278.3050406@gmail.com> Don't get me wrong. Nobody talking here about stupidity. All what I meant is all developers in the community would like to have at least a clue about what security issues are discovered. And deal with them on temporary basis on they own sites until final solution will be published. I'm not talking about detail explanation of what and how reported security issue can harm Drupal site. But may be some clue in order to deal with it. Or may be we need some special procedure to subscribe to such information. But I'm sure that many of us would like to know what is going on with fresh security discoveries. Victor Kane wrote: > On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer wrote: >> Wow, I would like everybody to notice something right here. >> >> In the message I reply to, Matt Farina said: >> >> "The security team handles things in a tight way. When something is reported >> it's not opened up to the world. If the issue is valid it's handled behind >> closed doors until a fix and advisory is sent out." /end of citation/ >> >> I thought that Drupal is an open community of open source developers working >> under GPL license. >> Does it mean that ALL issues have to be openly reported to all community for >> everybody to review? >> Don't you all think that handling security issues behind closed doors until >> a fix and advisory will be sent out is sound more like corporate way of >> thinking on a way to develop something proprietary? > > It's a GPL license, that's why I am sure the security team is open to > anyone who is interested in helping out on that very important front. > > But GPL doesn't mean that we have to be stupid as a community, and > advertise exploits before a fix can be made and people given a chance > to have a security fix to use. > > Just as the corporate world, as we are finding out all over the world > these days, certainly has no "monopoly over intelligence", or over > doing what's best for all, open source communities can be smart too. > > There's nothing proprietary about that. Quite the opposite, in fact: > defending ourselves against conspiracies to wreak havoc certainly has > to be the right of open source communities, > > Victor Kane > http://awebfactory.com.ar > >> I'm very concern about that and invite everybody to collaborate on this one. >> >> Does Matt represent a real situation at this matter in Drupal development >> community? >> If not, then I'm sure that many people would like to know exactly what the >> process is for handling security issues from the moment they have been >> reported? >> >> Thanks in advance, >> Alex >> >> >> matt at mattfarina.com wrote: >>> Jon, >>> >>> Thanks for your interest in this. I'm interested in this as well. >>> >>> Some of their concerns seem to be over some misconceptions that might help >>> to be cleared up. >>> >>> Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. >>> 100 + advisories over 10 major releases isn't as many as the 3 which the >>> numbering might look like. Before drupal 5 the major releases were point >>> releases and not full number releases. On top of that, the security >>> advisories cover contributed modules and have included other libraries used >>> by drupal modules, such as getID3. >>> >>> The security team handles things in a tight way. When something is >>> reported it's not opened up to the world. If the issue is valid it's handled >>> behind closed doors until a fix and advisory is sent out. Those advisories >>> come out on Wednesdays so they can immediately be acted on. >>> >>> I would be very curious as to what it would take to certification as well >>> as their concerns. >>> >>> Matt >>> >>> Quoting Jon Saints : >>> >>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/0ca71db9/attachment-0001.htm From catch56 at googlemail.com Wed Oct 1 08:44:58 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 1 Oct 2008 09:44:58 +0100 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E33278.3050406@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> Message-ID: > > I'm not talking about detail explanation of what and how reported security > issue can harm Drupal site. But may be some clue in order to deal with it. > Our public SAs don't give details of how to exploit vulnerabilities, while of course the commit logs are there (but it's not always obvious from them either) - this is by design so that we're not simply giving out instructions to people on how to hack sites which don't upgrade in a timely fashion (of which there are many). However, to fix an issue, you need to know how to exploit it, so I'm not really sure what you're asking for here. If a contributed module is extremly insecure and there's not an immediate fix for it, we unpublish the module until an SA can be released for it (and you'll be informed that the module has been 'revoked' by update status). > Or may be we need some special procedure to subscribe to such information. > You can get SAs as soon as they're published via e-mail or RSS from http://drupal.org/security. > > But I'm sure that many of us would like to know what is going on with fresh > security discoveries. > Those who want to help fix new discoveries can offer to join the security team, I don't think 'would like to know what's going on' is sufficient though. Nat > > > > Victor Kane wrote: > > On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer wrote: > > Wow, I would like everybody to notice something right here. > > In the message I reply to, Matt Farina said: > > "The security team handles things in a tight way. When something is reported > it's not opened up to the world. If the issue is valid it's handled behind > closed doors until a fix and advisory is sent out." /end of citation/ > > I thought that Drupal is an open community of open source developers working > under GPL license. > Does it mean that ALL issues have to be openly reported to all community for > everybody to review? > Don't you all think that handling security issues behind closed doors until > a fix and advisory will be sent out is sound more like corporate way of > thinking on a way to develop something proprietary? > > > It's a GPL license, that's why I am sure the security team is open to > anyone who is interested in helping out on that very important front. > > But GPL doesn't mean that we have to be stupid as a community, and > advertise exploits before a fix can be made and people given a chance > to have a security fix to use. > > Just as the corporate world, as we are finding out all over the world > these days, certainly has no "monopoly over intelligence", or over > doing what's best for all, open source communities can be smart too. > > There's nothing proprietary about that. Quite the opposite, in fact: > defending ourselves against conspiracies to wreak havoc certainly has > to be the right of open source communities, > > Victor Kanehttp://awebfactory.com.ar > > I'm very concern about that and invite everybody to collaborate on this one. > > Does Matt represent a real situation at this matter in Drupal development > community? > If not, then I'm sure that many people would like to know exactly what the > process is for handling security issues from the moment they have been > reported? > > Thanks in advance, > Alex > > matt at mattfarina.com wrote: > > Jon, > > Thanks for your interest in this. I'm interested in this as well. > > Some of their concerns seem to be over some misconceptions that might help > to be cleared up. > > Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. > 100 + advisories over 10 major releases isn't as many as the 3 which the > numbering might look like. Before drupal 5 the major releases were point > releases and not full number releases. On top of that, the security > advisories cover contributed modules and have included other libraries used > by drupal modules, such as getID3. > > The security team handles things in a tight way. When something is > reported it's not opened up to the world. If the issue is valid it's handled > behind closed doors until a fix and advisory is sent out. Those advisories > come out on Wednesdays so they can immediately be acted on. > > I would be very curious as to what it would take to certification as well > as their concerns. > > Matt > > Quoting Jon Saints : > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/904e17d7/attachment.htm From lapurd at gmail.com Wed Oct 1 09:29:25 2008 From: lapurd at gmail.com (Drupal Developer) Date: Wed, 01 Oct 2008 05:29:25 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> Message-ID: <48E342F5.90102@gmail.com> Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues. Thanks in advance, Alex Nathaniel Catchpole wrote: >> I'm not talking about detail explanation of what and how reported security >> issue can harm Drupal site. But may be some clue in order to deal with it. >> > > Our public SAs don't give details of how to exploit vulnerabilities, while > of course the commit logs are there (but it's not always obvious from them > either) - this is by design so that we're not simply giving out instructions > to people on how to hack sites which don't upgrade in a timely fashion (of > which there are many). However, to fix an issue, you need to know how to > exploit it, so I'm not really sure what you're asking for here. > > If a contributed module is extremly insecure and there's not an immediate > fix for it, we unpublish the module until an SA can be released for it (and > you'll be informed that the module has been 'revoked' by update status). > > > >> Or may be we need some special procedure to subscribe to such information. >> >> > You can get SAs as soon as they're published via e-mail or RSS from > http://drupal.org/security. > > > >> But I'm sure that many of us would like to know what is going on with fresh >> security discoveries. >> >> > > Those who want to help fix new discoveries can offer to join the security > team, I don't think 'would like to know what's going on' is sufficient > though. > > Nat > > > >> >> Victor Kane wrote: >> >> On Wed, Oct 1, 2008 at 12:40 AM, Drupal Developer wrote: >> >> Wow, I would like everybody to notice something right here. >> >> In the message I reply to, Matt Farina said: >> >> "The security team handles things in a tight way. When something is reported >> it's not opened up to the world. If the issue is valid it's handled behind >> closed doors until a fix and advisory is sent out." /end of citation/ >> >> I thought that Drupal is an open community of open source developers working >> under GPL license. >> Does it mean that ALL issues have to be openly reported to all community for >> everybody to review? >> Don't you all think that handling security issues behind closed doors until >> a fix and advisory will be sent out is sound more like corporate way of >> thinking on a way to develop something proprietary? >> >> >> It's a GPL license, that's why I am sure the security team is open to >> anyone who is interested in helping out on that very important front. >> >> But GPL doesn't mean that we have to be stupid as a community, and >> advertise exploits before a fix can be made and people given a chance >> to have a security fix to use. >> >> Just as the corporate world, as we are finding out all over the world >> these days, certainly has no "monopoly over intelligence", or over >> doing what's best for all, open source communities can be smart too. >> >> There's nothing proprietary about that. Quite the opposite, in fact: >> defending ourselves against conspiracies to wreak havoc certainly has >> to be the right of open source communities, >> >> Victor Kanehttp://awebfactory.com.ar >> >> I'm very concern about that and invite everybody to collaborate on this one. >> >> Does Matt represent a real situation at this matter in Drupal development >> community? >> If not, then I'm sure that many people would like to know exactly what the >> process is for handling security issues from the moment they have been >> reported? >> >> Thanks in advance, >> Alex >> >> matt at mattfarina.com wrote: >> >> Jon, >> >> Thanks for your interest in this. I'm interested in this as well. >> >> Some of their concerns seem to be over some misconceptions that might help >> to be cleared up. >> >> Someone correct me if I'm wrong but drupal 4.0 was 10 major releases ago. >> 100 + advisories over 10 major releases isn't as many as the 3 which the >> numbering might look like. Before drupal 5 the major releases were point >> releases and not full number releases. On top of that, the security >> advisories cover contributed modules and have included other libraries used >> by drupal modules, such as getID3. >> >> The security team handles things in a tight way. When something is >> reported it's not opened up to the world. If the issue is valid it's handled >> behind closed doors until a fix and advisory is sent out. Those advisories >> come out on Wednesdays so they can immediately be acted on. >> >> I would be very curious as to what it would take to certification as well >> as their concerns. >> >> Matt >> >> Quoting Jon Saints : >> >> >> 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 >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/6a23367a/attachment-0001.htm From gerhard at killesreiter.de Wed Oct 1 09:59:45 2008 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 01 Oct 2008 11:59:45 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E342F5.90102@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> Message-ID: <48E34A11.4000106@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Drupal Developer schrieb: > Okay, what is procedure then in order to join security forces here? > If that is the only way to get information necessary to get the picture > about latest security issues. Based on your comments I'll veto you joining the team. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI40oRfg6TFvELooQRAnI8AJ0Znjj7GuEqtjwVQmFUXp1c4PLqRACeM202 jt0q7PeW1EdnQgz3qdBIV3s= =m+Mo -----END PGP SIGNATURE----- From lapurd at gmail.com Wed Oct 1 10:12:22 2008 From: lapurd at gmail.com (Drupal Developer) Date: Wed, 01 Oct 2008 06:12:22 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E34A11.4000106@killesreiter.de> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <48E34A11.4000106@killesreiter.de> Message-ID: <48E34D06.5070201@gmail.com> In my view it is just demonstration of corporate nature of your thinking. BTW, if somebody in the open community got power to veto somebody out from doing something good, then how do you think it is reflecting on image of this community as "open" one? It is not the way to operate in the open community of developers. If I have some different opinion on something like how vulnerabilities have to be reported to community before they got fixed, it does not mean that I can not help security team to fix it. Gerhard Killesreiter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Drupal Developer schrieb: > >> Okay, what is procedure then in order to join security forces here? >> If that is the only way to get information necessary to get the picture >> about latest security issues. >> > > Based on your comments I'll veto you joining the team. > > Cheers, > Gerhard > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFI40oRfg6TFvELooQRAnI8AJ0Znjj7GuEqtjwVQmFUXp1c4PLqRACeM202 > jt0q7PeW1EdnQgz3qdBIV3s= > =m+Mo > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/55a7fbdb/attachment.htm From drupal at dwwright.net Wed Oct 1 10:21:45 2008 From: drupal at dwwright.net (Derek Wright) Date: Wed, 1 Oct 2008 03:21:45 -0700 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E342F5.90102@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> Message-ID: <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> On Oct 1, 2008, at 2:29 AM, Drupal Developer wrote: > Okay, what is procedure then in order to join security forces here? > If that is the only way to get information necessary to get the > picture about latest security issues. Nat's email already told you this: On Oct 1, 2008, at 1:44 AM, Nathaniel Catchpole wrote: > Those who want to help fix new discoveries can offer to join the > security team, I don't think 'would like to know what's going on' > is sufficient though. As a member of the (overworked and understaffed) security team, I can tell you right now that we'd reject your application on these grounds. And not because we're demonstrating a "corporate" thinking process. We're trying to protect the very openness of the developer community you're trying to be so concerned with. If you said "I'm really interested in security and want to help fix vulnerabilities, here are my skills I'm bringing to the table, references that prove [sic] I'm not malicious, etc", we'd strongly consider it. But, based on the motivation you've already put forward in this thread -- "I wanna be the first to know so I can try to protect my sites" -- is not going to fly. On Oct 1, 2008, at 1:19 AM, Drupal Developer wrote: > All what I meant is all developers in the community would like to > have at least a clue about what security issues are discovered. http://drupal.org/security > And deal with them on temporary basis on they own sites until final > solution will be published. > I'm not talking about detail explanation of what and how reported > security issue can harm Drupal site. But may be some clue in order > to deal with it. Again, the only way to give a "clue in order to deal with it" is to "give a clue how to exploit it". I'm sure the hackers reading that information will be much better suited to act on these clues than the average site admins who aren't well versed in security exploits. > Or may be we need some special procedure to subscribe to such > information. Any "special procedure to subscribe to such information" that scales to a group of people larger than the security team can't possibly keep the "bad" people out and only let in "good" people. It's already a risk we take letting new forces join the security team itself. No way could we have any reasonable hope of keeping the "initial clue about possible vulnerabilities" list secure. Malicious users *will* read that information, and use it to harm Drupal sites. > But I'm sure that many of us would like to know what is going on > with fresh security discoveries. Indeed, especially hackers. ;) Drupal follows a long established policy of "Responsible disclosure"[1] of discovered vulnerabilities. Nothing about this contradicts the GPL or the openness of the Drupal community in general. In fact, if we did what you suggest, I'm sure far fewer people would be using Drupal (rightfully so). Cheers, -Derek (dww) [1] http://www.sans.org/reading_room/whitepapers/threats/932.php From lapurd at gmail.com Wed Oct 1 10:37:09 2008 From: lapurd at gmail.com (Web Developer) Date: Wed, 01 Oct 2008 06:37:09 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> Message-ID: <48E352D5.9080903@gmail.com> It is just sad that the only thing you see in my notes is intention to get this kind of information at soon as possible. But you are denning to see that I also can help you. Do not you think that it is the one of the natural reason to join any kind of security team, and second reason to fix those problem? Derek Wright wrote: > > On Oct 1, 2008, at 2:29 AM, Drupal Developer wrote: > >> Okay, what is procedure then in order to join security forces here? >> If that is the only way to get information necessary to get the >> picture about latest security issues. > > Nat's email already told you this: > > > On Oct 1, 2008, at 1:44 AM, Nathaniel Catchpole wrote: > >> Those who want to help fix new discoveries can offer to join the >> security team, I don't think 'would like to know what's going on' is >> sufficient though. > > > > As a member of the (overworked and understaffed) security team, I can > tell you right now that we'd reject your application on these > grounds. And not because we're demonstrating a "corporate" thinking > process. We're trying to protect the very openness of the developer > community you're trying to be so concerned with. If you said "I'm > really interested in security and want to help fix vulnerabilities, > here are my skills I'm bringing to the table, references that prove > [sic] I'm not malicious, etc", we'd strongly consider it. But, based > on the motivation you've already put forward in this thread -- "I > wanna be the first to know so I can try to protect my sites" -- is not > going to fly. > > > On Oct 1, 2008, at 1:19 AM, Drupal Developer wrote: >> All what I meant is all developers in the community would like to >> have at least a clue about what security issues are discovered. > > http://drupal.org/security > >> And deal with them on temporary basis on they own sites until final >> solution will be published. >> I'm not talking about detail explanation of what and how reported >> security issue can harm Drupal site. But may be some clue in order to >> deal with it. > > Again, the only way to give a "clue in order to deal with it" is to > "give a clue how to exploit it". I'm sure the hackers reading that > information will be much better suited to act on these clues than the > average site admins who aren't well versed in security exploits. > >> Or may be we need some special procedure to subscribe to such >> information. > > Any "special procedure to subscribe to such information" that scales > to a group of people larger than the security team can't possibly keep > the "bad" people out and only let in "good" people. It's already a > risk we take letting new forces join the security team itself. No way > could we have any reasonable hope of keeping the "initial clue about > possible vulnerabilities" list secure. Malicious users *will* read > that information, and use it to harm Drupal sites. > >> But I'm sure that many of us would like to know what is going on with >> fresh security discoveries. > > > Indeed, especially hackers. ;) Drupal follows a long established > policy of "Responsible disclosure"[1] of discovered vulnerabilities. > Nothing about this contradicts the GPL or the openness of the Drupal > community in general. In fact, if we did what you suggest, I'm sure > far fewer people would be using Drupal (rightfully so). > > Cheers, > -Derek (dww) > > [1] http://www.sans.org/reading_room/whitepapers/threats/932.php > > > From damz at prealable.org Wed Oct 1 10:21:03 2008 From: damz at prealable.org (Damien Tournoud) Date: Wed, 1 Oct 2008 12:21:03 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E34D06.5070201@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <48E34A11.4000106@killesreiter.de> <48E34D06.5070201@gmail.com> Message-ID: On Wed, Oct 1, 2008 at 12:12 PM, Drupal Developer wrote: > In my view it is just demonstration of corporate nature of your thinking. > BTW, if somebody in the open community got power to veto somebody out from > doing something good, then how do you think it is reflecting on image of > this community as "open" one? > It is not the way to operate in the open community of developers. > If I have some different opinion on something like how vulnerabilities have > to be reported to community before they got fixed, it does not mean that I > can not help security team to fix it. > "Corporate nature" of Gerhard? You are so funny. First, let me point out that "Drupal Developer" is not that good a name for sending emails to a community mailing list (that, or your mother was really angry when she named you). You are not applying to yourself the transparency principles that you are promoting. Then, our community (and most other opensource communities) values action and contribution against anything else. That's why Gerhard speak has a lot of value here. Damien Tournoud -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/966ab15e/attachment.htm From gerhard at killesreiter.de Wed Oct 1 10:56:42 2008 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Wed, 01 Oct 2008 12:56:42 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E34D06.5070201@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <48E34A11.4000106@killesreiter.de> <48E34D06.5070201@gmail.com> Message-ID: <48E3576A.9070804@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Drupal Developer schrieb: > In my view it is just demonstration of corporate nature of your > thinking. The nature of my thinking is of no concern to you. > BTW, if somebody in the open community got power to veto somebody "veto" was not correctly chosen, "vote against" would be more correct. > out from doing something good, What good would you want to do? To me it seems your main interest would be to get to know potential security issues before others. > then how do you think it is > reflecting on image of this community as "open" one? It is not the I've personally never been a proponent of "everything must be open at all cost". > way to operate in the open community of developers. If I have some I am not sure, but I guess every other OS security team operates in the same way. > different opinion on something like how vulnerabilities have to be > reported to community before they got fixed, it does not mean that I > can not help security team to fix it. If you are actually qualified to work on the security team and your motives are others than what I think they are, you are welcome to apply at security at drupal.org. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI41dqfg6TFvELooQRAuV7AJ4uJX+0tSzEp19JJKC/sG4Lf4ow0wCeM11v QBRakG9MYkxUveU4Bpbo52s= =DMQh -----END PGP SIGNATURE----- From drupal at dwwright.net Wed Oct 1 11:00:39 2008 From: drupal at dwwright.net (Derek Wright) Date: Wed, 1 Oct 2008 04:00:39 -0700 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E352D5.9080903@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> Message-ID: <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> On Oct 1, 2008, at 3:37 AM, Web Developer wrote: > It is just sad that the only thing you see in my notes is intention > to get this kind of information at soon as possible. It is just sad that you're not paying attention to what we're saying. Another reason you probably wouldn't be a good fit for the security team. ;) I explicitly wrote: >> If you said "I'm really interested in security and want to help >> fix vulnerabilities, here are my skills I'm bringing to the table, >> references that prove [sic] I'm not malicious, etc", we'd strongly >> consider it. You *never* said *anything* like that in this entire thread. All you've said can be summarized with these 3 quotes: 1) "I thought that Drupal is an open community of open source developers working under GPL license. Does it mean that ALL issues have to be openly reported to all community for everybody to review? Don't you all think that handling security issues behind closed doors until a fix and advisory will be sent out is sound more like corporate way of thinking on a way to develop something proprietary?" 2) "All what I meant is all developers in the community would like to have at least a clue about what security issues are discovered. And deal with them on temporary basis on they own sites until final solution will be published." 3) "Okay, what is procedure then in order to join security forces here? If that is the only way to get information necessary to get the picture about latest security issues." Many of us have tried to point out the weaknesses in the logic of #1 and #2, and tried to explain why #3 is not a sufficient reason to join the security team. You've just kept coming back saying that the security team is closed (true), corporate (false), and that no one is reading between the lines of your messages that what you *really* mean is "I'd love to help fix vulnerabilities because I'm a security expert and I have an established track record of closing exploits through careful audits, thorough testing, and responsible disclosure." Please. I'm glad you raised your concern (we are an open development community, and discussing concerns like this is part of that), but the overwhelming response has been: "NO, that'd be crazy, we prefer a closed security team and responsible disclosure". It's ok to be outvoted, just be honest and graceful about it and no one will think poorly of you... -Derek (dww) From mikkel at hoegh.org Wed Oct 1 12:42:16 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Wed, 1 Oct 2008 14:42:16 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> Message-ID: On 01/10/2008, at 13.00, Derek Wright wrote: > I'm glad you raised your concern (we are an open development > community, and discussing concerns like this is part of that), but > the overwhelming response has been: "NO, that'd be crazy, we prefer > a closed security team and responsible disclosure". I'd just like to say that Derek is completely and absolutely right here. Responsible disclosure is the only way we can reasonably handle security vulnerabilities, and were it not for that policy, I would not be using Drupal for anything remotely important, because the chance of some guy being quicker than me and hitting me with a zero-day exploit would be unreasonably high. So while you might disagree, I think the great majority of Drupal developers are quite happy about this policy, and I don't think it'll change in the near future. -- Kind regards, Mikkel H?gh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081001/36821543/attachment.bin From lapurd at gmail.com Wed Oct 1 13:19:38 2008 From: lapurd at gmail.com (Web Developer) Date: Wed, 01 Oct 2008 09:19:38 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> Message-ID: <48E378EA.2000101@gmail.com> If you think that oldest BugTraq "full disclosure" listing has a weak logic behind, then you are mistaken (http://www.securityfocus.com). BugTraq as well expose vulnerabilities that does not have solutions yet. All what I have tried to explain that it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come out. For me as for open source developer it is kind of natural to associate limited disclosure or after solution disclosure with corporations like a Microsoft and such but not with open source community. Another good reason well explained on : "Analysis and risk rating ensure the quality of the disclosed information. The analysis must include enough details to allow a concerned user of the software to assess his individual risk or take immediate action to protect his assets." Which is, btw, is very well mentioned in NIST Special Publication 800-51 "Use of the Common Vulnerabilities and Exposures (CVE) Vulnerability Naming Scheme" . If Drupal security team made a decision to follow another path, its okay. But you should not judge another people in this matter so quick. Anyway, I have tried to be polite but since I have receive such a suspicious in bad intentions and arrogant perception here (at least that is what I feel now), I think I will standout for now in my true intentions to help and let you enjoy status of "overworked and understaffed" security team. Alex Derek Wright wrote: > > On Oct 1, 2008, at 3:37 AM, Web Developer wrote: > >> It is just sad that the only thing you see in my notes is intention >> to get this kind of information at soon as possible. > > It is just sad that you're not paying attention to what we're saying. > Another reason you probably wouldn't be a good fit for the security > team. ;) > > I explicitly wrote: > >>> If you said "I'm really interested in security and want to help fix >>> vulnerabilities, here are my skills I'm bringing to the table, >>> references that prove [sic] I'm not malicious, etc", we'd strongly >>> consider it. > > You *never* said *anything* like that in this entire thread. All > you've said can be summarized with these 3 quotes: > > 1) "I thought that Drupal is an open community of open source > developers working under GPL license. > Does it mean that ALL issues have to be openly reported to all > community for everybody to review? > Don't you all think that handling security issues behind closed doors > until a fix and advisory will be sent out is sound more like corporate > way of thinking on a way to develop something proprietary?" > > 2) "All what I meant is all developers in the community would like to > have at least a clue about what security issues are discovered. And > deal with them on temporary basis on they own sites until final > solution will be published." > > 3) "Okay, what is procedure then in order to join security forces > here? If that is the only way to get information necessary to get the > picture about latest security issues." > > Many of us have tried to point out the weaknesses in the logic of #1 > and #2, and tried to explain why #3 is not a sufficient reason to join > the security team. You've just kept coming back saying that the > security team is closed (true), corporate (false), and that no one is > reading between the lines of your messages that what you *really* mean > is "I'd love to help fix vulnerabilities because I'm a security expert > and I have an established track record of closing exploits through > careful audits, thorough testing, and responsible disclosure." Please. > > I'm glad you raised your concern (we are an open development > community, and discussing concerns like this is part of that), but the > overwhelming response has been: "NO, that'd be crazy, we prefer a > closed security team and responsible disclosure". It's ok to be > outvoted, just be honest and graceful about it and no one will think > poorly of you... > > -Derek (dww) > > > From lapurd at gmail.com Wed Oct 1 13:49:34 2008 From: lapurd at gmail.com (Web Developer) Date: Wed, 01 Oct 2008 09:49:34 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> Message-ID: <48E37FEE.3030409@gmail.com> If more of Drupal community members will know about newest vulnerabilities, then faster these vulnerabilities will be resolved. As I have mention in my previous message - it is not necessary to expose exploit info. Some might say that hacker will then make more damage. Well let me inform you - hacker can exploit problems on your server on they own even without any problem description. You can be your own "hacker" by simply evaluating your web applications and web sites with many vulnerabilities assessment and testing tools available on a market (many of them is open source). The only issue here that I see is security team is not trust to Drupal community own members. May be some solution is possible here like a member certification program. Which can be considered as transitional from "non-trusted" (simple Drupal user) to trusted developer who can help in his spare time without be under pressure of security team bosses. Alex Mikkel H?gh wrote: > On 01/10/2008, at 13.00, Derek Wright wrote: >> I'm glad you raised your concern (we are an open development >> community, and discussing concerns like this is part of that), but >> the overwhelming response has been: "NO, that'd be crazy, we prefer a >> closed security team and responsible disclosure". > > I'd just like to say that Derek is completely and absolutely right > here. Responsible disclosure is the only way we can reasonably handle > security vulnerabilities, and were it not for that policy, I would not > be using Drupal for anything remotely important, because the chance of > some guy being quicker than me and hitting me with a zero-day exploit > would be unreasonably high. > > So while you might disagree, I think the great majority of Drupal > developers are quite happy about this policy, and I don't think it'll > change in the near future. > > -- > Kind regards, > > Mikkel H?gh From info at 33rdprime.com Wed Oct 1 13:51:43 2008 From: info at 33rdprime.com (Patrick Teglia) Date: Wed, 1 Oct 2008 07:51:43 -0600 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E378EA.2000101@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E378EA.2000101@gmail.com> Message-ID: it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come out. I am sorry, but even a guy with a Security+ certification (in other words, me :) ) can see the flawed logic in this statement. A detailed description of the problem is a description of the vulnerability that attackers would EXACTLY be looking for. Patrick Teglia On Wed, Oct 1, 2008 at 7:19 AM, Web Developer wrote: > it does not mean that exploit information has to be exposed. But detail > description of the problem can help on its own even before solution come > out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/bf3036d9/attachment.htm From catch56 at googlemail.com Wed Oct 1 13:55:39 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Wed, 1 Oct 2008 14:55:39 +0100 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E37FEE.3030409@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E37FEE.3030409@gmail.com> Message-ID: On Wed, Oct 1, 2008 at 2:49 PM, Web Developer wrote: > trusted developer who can help in his spare time This describes al members of the security team > under pressure of security team bosses. > > This doesn't describe any members of the security team. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081001/fda83475/attachment-0001.htm From lapurd at gmail.com Wed Oct 1 14:08:59 2008 From: lapurd at gmail.com (Web Developer) Date: Wed, 01 Oct 2008 10:08:59 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E378EA.2000101@gmail.com> Message-ID: <48E3847B.6060503@gmail.com> Is it everybody here so quick to see another person logic flaw, where in fact you just have to think a little further? I did not suggest that you have to give such detail description that will expose exploit right away. But I'm sure in most cases experienced developer/tester can come up with explanatory description without exposing too much. I agree that some problem could be so obvious so any explanation will expose exploit info. Okay, but it is only one case. There are many problems that are not so obvious. Alex Patrick Teglia wrote: > it does not mean that exploit information has to be exposed. But detail > description of the problem can help on its own even before solution come > out. > > I am sorry, but even a guy with a Security+ certification (in other words, > me :) ) can see the flawed logic in this statement. A detailed description > of the problem is a description of the vulnerability that attackers would > EXACTLY be looking for. > > Patrick Teglia > > > On Wed, Oct 1, 2008 at 7:19 AM, Web Developer wrote: > > >> it does not mean that exploit information has to be exposed. But detail >> description of the problem can help on its own even before solution come >> out. >> > > From eric at openflows.com Wed Oct 1 14:21:38 2008 From: eric at openflows.com (Eric Goldhagen) Date: Wed, 1 Oct 2008 10:21:38 -0400 (EDT) Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E3847B.6060503@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E378EA.2000101@gmail.com> <48E3847B.6060503@gmail.com> Message-ID: <55380.66.108.140.130.1222870898.squirrel@webmail.mayfirst.org> I think that the process currently in place has proven itself over time to be reliable and accountable to the community. There are very few restrictions in place that would prevent a member of the Drupal community from joining the security team, but I am glad that there is a vetting process that ensures that the skills and motivation of the security team members is in-line with the goals of that team and the community-at-large. The security review and resolution process at drupal is one of the things that has allowed my company to use drupal as a part of systems that handle ePHI (electronic protected health information) which have been successfully audited as HIPAA (Health Insurance Portability and Accountability Act) compliant. --Eric On Wed, October 1, 2008 10:08 am, Web Developer wrote: > Is it everybody here so quick to see another person logic flaw, where in fact you just have to think a little further? > > I did not suggest that you have to give such detail description that will expose exploit right away. > But I'm sure in most cases experienced developer/tester can come up with explanatory description without exposing too much. > I agree that some problem could be so obvious so any explanation will expose exploit info. Okay, but it is only one case. > There are many problems that are not so obvious. > > Alex > > > Patrick Teglia wrote: >> it does not mean that exploit information has to be exposed. But detail description of the problem can help on its own even before solution come >> out. >> I am sorry, but even a guy with a Security+ certification (in other words, >> me :) ) can see the flawed logic in this statement. A detailed description >> of the problem is a description of the vulnerability that attackers would >> EXACTLY be looking for. >> Patrick Teglia >> On Wed, Oct 1, 2008 at 7:19 AM, Web Developer wrote: >>> it does not mean that exploit information has to be exposed. But detail >>> description of the problem can help on its own even before solution come >>> out. > From damz at prealable.org Wed Oct 1 14:31:01 2008 From: damz at prealable.org (Damien Tournoud) Date: Wed, 1 Oct 2008 16:31:01 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E3847B.6060503@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E378EA.2000101@gmail.com> <48E3847B.6060503@gmail.com> Message-ID: On Wed, Oct 1, 2008 at 4:08 PM, Web Developer wrote: > I did not suggest that you have to give such detail description that will expose exploit right away. > But I'm sure in most cases experienced developer/tester can come up with explanatory description without exposing too much. > I agree that some problem could be so obvious so any explanation will expose exploit info. Okay, but it is only one case. > There are many problems that are not so obvious. Our security process can be thought as complying with "responsible disclosure", as described for example in the RFPolicy [1]. Close cooperation between security researchers and vendors (ie. us, the Drupal community) in private before the security vulnerability has been disclosed has largely proven to be the good way to deal with this kind of issues. Our community is open. Discussing issues "inside" the community means nothing more than discussing those publicly. Damien Tournoud [1] http://www.wiretrip.net/rfp/policy.html From matt at mattfarina.com Wed Oct 1 14:31:15 2008 From: matt at mattfarina.com (matt at mattfarina.com) Date: Wed, 1 Oct 2008 10:31:15 -0400 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E3847B.6060503@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <48E32961.8090208@gmail.com> <48E33278.3050406@gmail.com> <48E342F5.90102@gmail.com> <02FBB3FF-F534-47B9-B20D-959B9DEBB373@dwwright.net> <48E352D5.9080903@gmail.com> <5E49DD92-F106-42F1-A066-BF7FB9C7378C@dwwright.net> <48E378EA.2000101@gmail.com> <48E3847B.6060503@gmail.com> Message-ID: <20081001103115.jz93xh0ogo0ssgk4@webmail.mattfarina.com> If you really feel this is the better way to go I'd suggest a change of strategy. The current process is not only popular but works well and is useful. If there is going to be a change from it to something else there needs to be a an obvious benefit that works with the cost/time/resources needed to do such a thing. Put together a proposed change from the current setup, preform a cost benefit analysis on that, and then try to sell the people who can affect a change on this in the drupal community. In trying to sell them show them the personal benefit to them and the community over the current process. (You aren't doing this now and seem to be alienating the very people you need to sell this to.) If you don't think you can sell them or this seems like too much work I'd suggest saving face and backing down on this issue. Otherwise a bunch of us have to read emails (or spend time deleting them) in what is turning into an unproductive conversation. Quoting Web Developer : > Is it everybody here so quick to see another person logic flaw, where > in fact you just have to think a little further? > > I did not suggest that you have to give such detail description that > will expose exploit right away. > But I'm sure in most cases experienced developer/tester can come up > with explanatory description without exposing too much. > I agree that some problem could be so obvious so any explanation will > expose exploit info. Okay, but it is only one case. > There are many problems that are not so obvious. > > Alex > > > Patrick Teglia wrote: >> it does not mean that exploit information has to be exposed. But detail >> description of the problem can help on its own even before solution come >> out. >> >> I am sorry, but even a guy with a Security+ certification (in other words, >> me :) ) can see the flawed logic in this statement. A detailed description >> of the problem is a description of the vulnerability that attackers would >> EXACTLY be looking for. >> >> Patrick Teglia >> >> >> On Wed, Oct 1, 2008 at 7:19 AM, Web Developer wrote: >> >> >>> it does not mean that exploit information has to be exposed. But detail >>> description of the problem can help on its own even before solution come >>> out. >>> >> >> From news at unleashedmind.com Wed Oct 1 14:41:05 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Wed, 1 Oct 2008 16:41:05 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E378EA.2000101@gmail.com> Message-ID: <0b6701c923d3$bc36a820$2602fd0a@structworks.com> > All what I have tried to explain that it does not mean that exploit > information has to be exposed. This is what actually happens already: Security team receives a security report, does deep analysis of the potential problem, and if the report turns out to be valid, the security team aids the corresponding module maintainer to fix the vulnerability. The exploit information is made public when a fix for all users is available. > "Analysis and risk rating ensure the quality of the disclosed > information. The analysis must include enough details to allow a > concerned user of the software to assess his individual risk or take > immediate action to protect his assets." This, too, is what happens: All subscribers of the security announcements newsletter receive a mail for each and every fixed vulnerability throughout Drupal core AND contributed modules. > If Drupal security team made a decision to follow another > path, its okay. > But you should not judge another people in this matter so quick. > Anyway, I have tried to be polite but since I have receive such a > suspicious in bad intentions and arrogant perception here (at > least that > is what I feel now), I think I will standout for now in my true > intentions to help and let you enjoy status of "overworked and > understaffed" security team. > > Alex Look, I do not belong to the security team either (albeit I considered to join for helping out already). However, I /feel/ very safe knowing that we have top-notch contributors in this team, doing an excellent job on reviewing and solving all security issues. To be honest, I would not like to see an arbitrary "Web Developer" (ex. "Drupal Developer") there either. As a regular Drupal contributor and user, I know the contributions of /each/ security team member, which makes me believe that they are experts in all Drupal areas - and friends I can trust. I would recommend you to contribute more to Drupal, get some kudos for your valuable contributions, and then ask again. Thanks, Daniel From michael at favias.org Wed Oct 1 14:51:35 2008 From: michael at favias.org (Michael Favia) Date: Wed, 01 Oct 2008 09:51:35 -0500 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <48E32961.8090208@gmail.com> References: <8e779d5d0809300814yf1c004bl154ce7693d0e1e5d@mail.gmail.com> <20080930112458.71lf61wyqsocc0ks@webmail.mattfarina.com> <48E32961.8090208@gmail.com> Message-ID: <48E38E77.6080101@favias.org> Drupal Developer wrote: > Wow, I would like everybody to notice something right here. Please stop feeding the troll. Those of us who pay attention all understand and agree with the existing security infrastructure and appreciate the hardwork and thankless job that is managing exploits in a timely fashion. There isn't a debate to be found here, only a waste of time. -- Michael Favia From news at unleashedmind.com Wed Oct 1 15:37:47 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Wed, 1 Oct 2008 17:37:47 +0200 Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <55380.66.108.140.130.1222870898.squirrel@webmail.mayfirst.org> Message-ID: <0b7401c923db$a7d20a20$2602fd0a@structworks.com> Back to topic: > The security review and resolution process at drupal is one > of the things that has allowed my company to use drupal as a > part of systems that handle ePHI (electronic protected health > information) which have been successfully audited as HIPAA > (Health Insurance Portability and Accountability Act) compliant. > > --Eric This sounds like a handbook page about certifications, policies, and auditions of Drupal is in order? Maybe we can add consultants/agencies/shops who managed to achieve or approve them for each entry as a reference. That list might also contain revoked attempts, and would fit best in the "About Drupal" handbook, of course. Cross-posting this to consulting list. Daniel From eric at openflows.com Wed Oct 1 15:52:34 2008 From: eric at openflows.com (Eric Goldhagen) Date: Wed, 1 Oct 2008 11:52:34 -0400 (EDT) Subject: [development] Certify Drupal for use in Government (US) Projects In-Reply-To: <0b7401c923db$a7d20a20$2602fd0a@structworks.com> References: <0b7401c923db$a7d20a20$2602fd0a@structworks.com> Message-ID: <37262.66.108.140.130.1222876354.squirrel@webmail.mayfirst.org> On Wed, October 1, 2008 11:37 am, Daniel F. Kudwien wrote: > Back to topic: > >> The security review and resolution process at drupal is one >> of the things that has allowed my company to use drupal as a >> part of systems that handle ePHI (electronic protected health >> information) which have been successfully audited as HIPAA >> (Health Insurance Portability and Accountability Act) compliant. --Eric > > This sounds like a handbook page about certifications, policies, and auditions of Drupal is in order? Maybe we can add > consultants/agencies/shops who managed to achieve or approve them for each > entry as a reference. That list might also contain revoked attempts, and > would fit best in the "About Drupal" handbook, of course. > > Cross-posting this to consulting list. > > Daniel > > I'd like to make sure that this discussion happens in one place so it can be easier to follow. In the future, it would be nice to be asked before a part of my email is send with no context to another list. here is what I posted to the consulting list: I would be glad to participate a discussion about your idea, but let me start by saying that I'm not comfortable with one paragraph of an email from me that was part of a lengthy discussion about durpal security issues crossposted without any additional context. For those not on the development list, you can read the thread at http://lists.drupal.org/pipermail/development/2008-October/031097.html to put my statement in full context of the larger discussion. --Eric From drupal at dwwright.net Thu Oct 2 07:10:59 2008 From: drupal at dwwright.net (Derek Wright) Date: Thu, 2 Oct 2008 00:10:59 -0700 Subject: [development] project node UI changes deployed on d.o Message-ID: 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 From mikkel at hoegh.org Thu Oct 2 08:18:28 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Thu, 2 Oct 2008 10:18:28 +0200 Subject: [development] project node UI changes deployed on d.o In-Reply-To: References: Message-ID: <700E9DE0-C2B7-45B4-A12E-4AFDE5F77BAF@hoegh.org> Well, on the bright side, the new link structure of > * View open issues > * View all issues > * View all support request is, in my opinion, a great improvement, since usually don't care which kind of issue (task, bug, feature, etc.) it is that I'm looking for, so this will save me an extra click and a pageload every time i view an issue queue. Thanks :) When it comes to removing the add issue link, I'm not thrilled about it, but I understand your reasoning. I do, however, think that this is a desparate measure. Making it harder to submit bugs is not really what we want. We want higher quality issues, not just less of them. What we need is a workflow like they have in Ubuntu: http://skitch.com/mikl/atwd/report-a-bug-about-ubuntu http://skitch.com/mikl/atwf/report-a-bug-about-ubuntu I know the counter to that is that it would be a lot of work to implement and the Project module maintainers don't have the time, and I can sympathise with that. That is another thorny issue for Drupal, that we have made our own tools for everything. I've once before tried advocating moving parts of what we do (translations) to Launchpad, and I'm not willing to stick my head in that particular hornet's nest again anytime soon. -- Kind regards, Mikkel H?gh On 02/10/2008, at 09.10, Derek Wright wrote: > 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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081002/321006d4/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081002/321006d4/attachment.bin From drupal at dwwright.net Thu Oct 2 08:48:55 2008 From: drupal at dwwright.net (Derek Wright) Date: Thu, 2 Oct 2008 01:48:55 -0700 Subject: [development] project node UI changes deployed on d.o In-Reply-To: <700E9DE0-C2B7-45B4-A12E-4AFDE5F77BAF@hoegh.org> References: <700E9DE0-C2B7-45B4-A12E-4AFDE5F77BAF@hoegh.org> Message-ID: <24A8BC36-58DF-48A3-A6B2-300D1063FFE0@dwwright.net> On Oct 2, 2008, at 1:18 AM, Mikkel H?gh wrote: > What we need is a workflow like they have in Ubuntu: Search before you post... ;) http://drupal.org/node/19386 (Sorry, couldn't resist). But yes, you're absolutely right. That's what we need. A related problem is that, especially for d.o, you need to search a bunch of different issue queues if you really want to avoid a duplicate: http://drupal.org/node/192714 > I know the counter to that is that it would be a lot of work to > implement and the Project module maintainers don't have the time, > and I can sympathise with that. Not at all. Well, yes, the (current) maintainers don't have the time, but we're obviously not the only people on this list who are qualified for the job. Any interested party is more than welcome to pick up the ball and run with either of these issues. #192714 used to be blocked on search-related problems (back when d.o's DB was being crippled by core search.module) but we're now running xapian on d.o, so perhaps that one can be revived without too much trouble. I don't include so many issue links in my posts to this list just for the archival fun of it. I genuinely hope that someday, people will actually jump into an issue and solve a problem or add a feature if their itch is scratchy enough. ;) Cheers, -Derek (dww) From darrel.opry at gmail.com Thu Oct 2 14:50:31 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Thu, 2 Oct 2008 10:50:31 -0400 Subject: [development] project node UI changes deployed on d.o In-Reply-To: <24A8BC36-58DF-48A3-A6B2-300D1063FFE0@dwwright.net> References: <700E9DE0-C2B7-45B4-A12E-4AFDE5F77BAF@hoegh.org> <24A8BC36-58DF-48A3-A6B2-300D1063FFE0@dwwright.net> Message-ID: Hooray!! for once I won't give you a hard time.. ;) Keep up the good work dww. .darrel. On Thu, Oct 2, 2008 at 4:48 AM, Derek Wright wrote: > > On Oct 2, 2008, at 1:18 AM, Mikkel H?gh wrote: > > What we need is a workflow like they have in Ubuntu: >> > > Search before you post... ;) > > http://drupal.org/node/19386 > > (Sorry, couldn't resist). But yes, you're absolutely right. That's what > we need. > > A related problem is that, especially for d.o, you need to search a bunch > of different issue queues if you really want to avoid a duplicate: > > http://drupal.org/node/192714 > > I know the counter to that is that it would be a lot of work to implement >> and the Project module maintainers don't have the time, and I can sympathise >> with that. >> > > Not at all. Well, yes, the (current) maintainers don't have the time, but > we're obviously not the only people on this list who are qualified for the > job. Any interested party is more than welcome to pick up the ball and run > with either of these issues. #192714 used to be blocked on search-related > problems (back when d.o's DB was being crippled by core search.module) but > we're now running xapian on d.o, so perhaps that one can be revived without > too much trouble. > > I don't include so many issue links in my posts to this list just for the > archival fun of it. I genuinely hope that someday, people will actually > jump into an issue and solve a problem or add a feature if their itch is > scratchy enough. ;) > > > Cheers, > -Derek (dww) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081002/a1bc75a0/attachment-0001.htm From drupal.beginner at wechange.org Thu Oct 2 16:09:25 2008 From: drupal.beginner at wechange.org (augustin (beginner)) Date: Fri, 3 Oct 2008 00:09:25 +0800 Subject: [development] project node UI changes deployed on d.o In-Reply-To: References: Message-ID: <200810030009.26206.drupal.beginner@wechange.org> On Thursday 02 October 2008 15:10:59 Derek Wright wrote: > 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. Good move. Thank you very much :) Augustin. From dries.buytaert at gmail.com Thu Oct 2 19:08:52 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Thu, 2 Oct 2008 21:08:52 +0200 Subject: [development] project node UI changes deployed on d.o In-Reply-To: References: Message-ID: <752ACF25-A02F-4AFC-8215-3C84CF31E496@gmail.com> Rock on Derek! :) On 02 Oct 2008, at 09:10, Derek Wright wrote: > 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. -- Dries Buytaert :: http://buytaert.net From drupal at dwwright.net Fri Oct 3 01:02:53 2008 From: drupal at dwwright.net (Derek Wright) Date: Thu, 2 Oct 2008 18:02:53 -0700 Subject: [development] Better validation for CVS tags now deployed on cvs.drupal.org In-Reply-To: <15C6AC42-5B66-4C42-8042-91A101457193@dwwright.net> References: <15C6AC42-5B66-4C42-8042-91A101457193@dwwright.net> Message-ID: On Sep 18, 2008, at 4:57 PM, Derek Wright wrote: > 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. Update... Since core has now introduced the "UNSTABLE" tags for D7 development [1], that's now an allowed "extra" modifier for contrib tags, too. See http://drupal.org/node/252473#comment-1040786 and later comments if you happen to care about the discussion around this. Cheers, -Derek (dww) [1] http://lists.drupal.org/pipermail/development/2008-October/ 031094.html From nuppla at zites.net Sat Oct 4 12:32:40 2008 From: nuppla at zites.net (fago) Date: Sat, 04 Oct 2008 14:32:40 +0200 Subject: [development] Populating form storage during form build Message-ID: <1223123561.6234.41.camel@butterfly-2> 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 From nan_wich at bellsouth.net Sat Oct 4 15:29:53 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 4 Oct 2008 11:29:53 -0400 Subject: [development] Filter-sophical question Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081004/d2df632d/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 5675 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081004/d2df632d/attachment-0001.jpeg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 0 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081004/d2df632d/attachment-0001.bin -------------- next part -------------- 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 From nan_wich at bellsouth.net Sat Oct 4 15:50:00 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Sat, 4 Oct 2008 11:50:00 -0400 Subject: [development] Filter-sophical question - Never Mind In-Reply-To: Message-ID: When I did this in one of my filters, I looked to see how it documents and discovered my own answer. This could get absurd because then we should have everyone who supplies a block list the block module, and etc. So never mind. Nancy E. Wichmann, PMP -----Original Message----- From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]On Behalf Of Nancy Wichmann Sent: Saturday, October 04, 2008 11:30 AM To: Development at Drupal. Org Subject: [development] Filter-sophical question 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081004/f8314512/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 5675 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081004/f8314512/attachment.jpeg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 0 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081004/f8314512/attachment.bin -------------- next part -------------- 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 From metzlerd at metzlerd.com Sat Oct 4 16:51:13 2008 From: metzlerd at metzlerd.com (David Metzler) Date: Sat, 4 Oct 2008 09:51:13 -0700 Subject: [development] Filter-sophical question - Never Mind In-Reply-To: References: Message-ID: <2F8CA8CE-53C4-4CBA-8D21-CFECCEEF8031@metzlerd.com> Actually that argument doesn't follow. Many modules, (e.g. views) provide blocks, but do not require them in order to function. If your module is one of those it doesn't make sense to indicate blocks as a dependency. I haven't researched it but I do believe that most block providing modules fall into that category. Dependencies should be reserved for such cases when your module simply will not function without the other module. I think you could still make that argument for modules that exist to only provide a filter, but it shouldn't be viewed as documentation for what features a module provides. \\Dave On Oct 4, 2008, at 8:50 AM, Nancy Wichmann wrote: > > When I did this in one of my filters, I looked to see how it > documents and discovered my own answer. This could get absurd > because then we should have everyone who supplies a block list the > block module, and etc. > > > > So never mind. > > > > Nancy E. Wichmann, PMP > > > > > > -----Original Message----- > From: development-bounces at drupal.org [mailto:development- > bounces at drupal.org]On Behalf Of Nancy Wichmann > Sent: Saturday, October 04, 2008 11:30 AM > To: Development at Drupal. Org > Subject: [development] Filter-sophical question > > > > 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 > > > > > > > This message cannot be displayed because of the way it is > formatted. Ask the sender to send it again using a different format > or email program. > > multipart/alternative > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081004/0ae699fb/attachment-0001.htm From sysop at scbbs.com Tue Oct 7 17:45:11 2008 From: sysop at scbbs.com (Ron Parker) Date: Tue, 7 Oct 2008 10:45:11 -0700 (PDT) Subject: [development] Internet Explorer Print Loses User Context In-Reply-To: <6263922.38671223401444423.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <17382485.38691223401511713.JavaMail.root@zimbra.thefiengroup.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081007/d1e1a37a/attachment.htm From andrewberry at sentex.net Tue Oct 7 19:16:53 2008 From: andrewberry at sentex.net (Andrew Berry) Date: Tue, 7 Oct 2008 15:16:53 -0400 Subject: [development] Internet Explorer Print Loses User Context In-Reply-To: <17382485.38691223401511713.JavaMail.root@zimbra.thefiengroup.com> References: <17382485.38691223401511713.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <82DE9D91-CF73-40E4-839A-D5C3392968BF@sentex.net> On 7-Oct-08, at 1:45 PM, Ron Parker wrote: > 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. It must have some kind of session info. What if the node is not viewable by the current user? If that wasn't being checked, then all print views would be viewable by the world. It sounds like a server issue to me. If you can, it might be worth running tcpdump and inspecting the headers. --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2692 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081007/f1d5fb12/attachment.bin From kyle at codeincarnate.com Tue Oct 7 23:24:57 2008 From: kyle at codeincarnate.com (Kyle Cunningham) Date: Tue, 07 Oct 2008 18:24:57 -0500 Subject: [development] Timezone Changes Depending on Page Message-ID: <48EBEFC9.9080205@codeincarnate.com> Hi Everyone, I'm having an interesting problem on which the timezone of my site (Drupal 6.4) will change depending on the page being viewed. This has led to very strange results (such as story postings dates being off) and there doesn't seem to be much rhyme or reason to which pages work (have the correct timezone) and which don't. I have the date.timezone variable set in the php.ini, but this doesn't seem to be effective. The only thing I can think of is that there is possibly a problem with date.module, but things are working correctly on a different server. Has anyone else experienced this or have any idea how to fix this? Best, Kyle Cunningham From gmtampm at gmail.com Wed Oct 8 07:59:36 2008 From: gmtampm at gmail.com (gmt am) Date: Wed, 8 Oct 2008 13:29:36 +0530 Subject: [development] expansion / collapse of navigation menu (taxonomy) Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081008/062fc243/attachment.htm From bharanikumariyerphp at gmail.com Wed Oct 8 08:33:11 2008 From: bharanikumariyerphp at gmail.com (bharani kumar) Date: Wed, 8 Oct 2008 14:03:11 +0530 Subject: [development] expansion / collapse of navigation menu (taxonomy) In-Reply-To: References: Message-ID: <2240033d0810080133q58c6f5ceu7241779bf4cf5a6a@mail.gmail.com> USE TAXONOMY MANAGER MODULE On Wed, Oct 8, 2008 at 1:29 PM, gmt am wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081008/e4f14cc4/attachment.htm From karen at elderweb.com Wed Oct 8 12:02:42 2008 From: karen at elderweb.com (Karen Stevenson) Date: Wed, 8 Oct 2008 05:02:42 -0700 (PDT) Subject: [development] Important note for CCK module developers Message-ID: <885939.17238.qm@web65611.mail.ac4.yahoo.com> 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 From agentrickard at gmail.com Wed Oct 8 14:40:09 2008 From: agentrickard at gmail.com (Ken Rickard) Date: Wed, 8 Oct 2008 10:40:09 -0400 Subject: [development] Timezone Changes Depending on Page In-Reply-To: <48EBEFC9.9080205@codeincarnate.com> References: <48EBEFC9.9080205@codeincarnate.com> Message-ID: <25b45da00810080740w4e281491w2e2c5d7b7c093aec@mail.gmail.com> Try resetting the global timezone variable in hook_init(). mymodule_init() { // figure out the page request and set a $zone var to the offset accordingly. $zone = -14400; // the timezone offset in seconds (EDT here) global $conf; $conf['date_default_timezone'] = $zone; } This should temporarily override the site's timezone setting. On Tue, Oct 7, 2008 at 7:24 PM, Kyle Cunningham wrote: > Hi Everyone, > I'm having an interesting problem on which the timezone of my site > (Drupal 6.4) will change depending on the page being viewed. This has > led to very strange results (such as story postings dates being off) and > there doesn't seem to be much rhyme or reason to which pages work (have > the correct timezone) and which don't. > > I have the date.timezone variable set in the php.ini, but this doesn't > seem to be effective. The only thing I can think of is that there is > possibly a problem with date.module, but things are working correctly on > a different server. Has anyone else experienced this or have any idea > how to fix this? > > Best, > Kyle Cunningham > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From matt at mattfarina.com Wed Oct 8 15:40:19 2008 From: matt at mattfarina.com (matt at mattfarina.com) Date: Wed, 8 Oct 2008 11:40:19 -0400 Subject: [development] Timezone Changes Depending on Page In-Reply-To: <25b45da00810080740w4e281491w2e2c5d7b7c093aec@mail.gmail.com> References: <48EBEFC9.9080205@codeincarnate.com> <25b45da00810080740w4e281491w2e2c5d7b7c093aec@mail.gmail.com> Message-ID: <20081008114019.ds65i5deqsok4ooo@webmail.mattfarina.com> Not sure how your site is setup but, are people from around the world viewing your pages anonymously with their timezones being used and then the pages being cached? Quoting Ken Rickard : > Try resetting the global timezone variable in hook_init(). > > > mymodule_init() { > // figure out the page request and set a $zone var to the offset accordingly. > > $zone = -14400; // the timezone offset in seconds (EDT here) > global $conf; > $conf['date_default_timezone'] = $zone; > } > > > This should temporarily override the site's timezone setting. > > > On Tue, Oct 7, 2008 at 7:24 PM, Kyle Cunningham > wrote: >> Hi Everyone, >> I'm having an interesting problem on which the timezone of my site >> (Drupal 6.4) will change depending on the page being viewed. This has >> led to very strange results (such as story postings dates being off) and >> there doesn't seem to be much rhyme or reason to which pages work (have >> the correct timezone) and which don't. >> >> I have the date.timezone variable set in the php.ini, but this doesn't >> seem to be effective. The only thing I can think of is that there is >> possibly a problem with date.module, but things are working correctly on >> a different server. Has anyone else experienced this or have any idea >> how to fix this? >> >> Best, >> Kyle Cunningham >> > > > > -- > Ken Rickard > agentrickard at gmail.com > http://ken.therickards.com > From sysop at scbbs.com Thu Oct 9 01:13:00 2008 From: sysop at scbbs.com (Ron Parker) Date: Wed, 8 Oct 2008 18:13:00 -0700 (PDT) Subject: [development] Internet Explorer Print Loses User Context Message-ID: <16493387.39931223514780881.JavaMail.root@zimbra.thefiengroup.com> > 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. I seem to have resolved my problems by adding this to my code in a couple of places: header('Expires: Mon, 26 Jul 1997 05:00:00 GMT'); header('Cache-Control: no-store, no-cache, must-revalidate'); header('Cache-Control: post-check=0, pre-check=0', FALSE); header('Pragma: no-cache'); cache_clear_all(); This doesn't help the problem with the $user context disappearing (I solved that by creating a variable using the user's ip address and storing the info I need there - very crude, but works), but by forcing the browser not to cache the image I am dynamically creating. Thanks for the suggestion. -ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081008/a8a00f14/attachment.htm From mistknight at gmail.com Thu Oct 9 11:49:34 2008 From: mistknight at gmail.com (Ashraf Amayreh) Date: Thu, 9 Oct 2008 14:49:34 +0300 Subject: [development] Internet Explorer Print Loses User Context In-Reply-To: <16493387.39931223514780881.JavaMail.root@zimbra.thefiengroup.com> References: <16493387.39931223514780881.JavaMail.root@zimbra.thefiengroup.com> Message-ID: Just out of curiosity, does all these calls pass through drupal's menu system? Anything that doesn't will naturally not contain any of drupal's context variables. On 10/9/08, Ron Parker wrote: >> 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. > > I seem to have resolved my problems by adding this to my code in a couple of > places: > > header('Expires: Mon, 26 Jul 1997 05:00:00 GMT'); > header('Cache-Control: no-store, no-cache, must-revalidate'); > header('Cache-Control: post-check=0, pre-check=0', FALSE); > header('Pragma: no-cache'); > > cache_clear_all(); > > This doesn't help the problem with the $user context disappearing (I solved > that by creating a variable using the user's ip address and storing the info > I need there - very crude, but works), but by forcing the browser not to > cache the image I am dynamically creating. > > Thanks for the suggestion. > > -ron > -- Ashraf Amayreh http://aamayreh.org From mikkel at hoegh.org Sat Oct 11 10:20:24 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Sat, 11 Oct 2008 12:20:24 +0200 Subject: [development] Git-mirror of Drupal core now on Github Message-ID: For anyone who's been using/playing with my Git-mirror of Drupal core CVS at http://git.lion47.com/ (which is currently on a slow and unstable connection), I have created a mirror on Github, so feel free to use that instead. I will keep updating it every 12 hours. http://github.com/mikl/drupal/tree/master -- Kind regards, Mikkel H?gh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081011/5e737c38/attachment.bin From drupal at samboyer.org Sat Oct 11 14:14:58 2008 From: drupal at samboyer.org (Sam Boyer) Date: Sat, 11 Oct 2008 09:14:58 -0500 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: References: Message-ID: <200810110915.05852.drupal@samboyer.org> On Saturday 11 October 2008 05:20:24 am Mikkel H?gh wrote: > For anyone who's been using/playing with my Git-mirror of Drupal core > CVS at http://git.lion47.com/ (which is currently on a slow and > unstable connection), I have created a mirror on Github, so feel free > to use that instead. I will keep updating it every 12 hours. > > http://github.com/mikl/drupal/tree/master > -- > Kind regards, > > Mikkel H?gh The public clone url for that repo is: git://github.com/mikl/drupal.git As the one given above fails. Thanks for this, Mikkel! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20081011/98a20b5e/attachment.pgp From dmitrig01 at gmail.com Sat Oct 11 14:25:53 2008 From: dmitrig01 at gmail.com (Dmitri Gaskin) Date: Sat, 11 Oct 2008 07:25:53 -0700 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: References: Message-ID: <6A0D030E-455E-45A4-87FC-D40F4A0FB702@gmail.com> Thank you - i've been waiting for this. Dmitri On Oct 11, 2008, at 3:20 AM, Mikkel H?gh wrote: > For anyone who's been using/playing with my Git-mirror of Drupal > core CVS at http://git.lion47.com/ (which is currently on a slow and > unstable connection), I have created a mirror on Github, so feel > free to use that instead. I will keep updating it every 12 hours. > > http://github.com/mikl/drupal/tree/master > -- > Kind regards, > > Mikkel H?gh > From weitzman at tejasa.com Sat Oct 11 15:03:55 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Sat, 11 Oct 2008 11:03:55 -0400 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: References: Message-ID: <6117a7500810110803w58823351p1acf5d9ce581538e@mail.gmail.com> It would be ideal for core development if it could update very frequently like once per hour. That way we would be less likely to generate fuzzy patches. Most cron runs will result in no git push but perhaps you have reasons why thats not desireable. On Sat, Oct 11, 2008 at 6:20 AM, Mikkel H?gh wrote: > For anyone who's been using/playing with my Git-mirror of Drupal core CVS at > http://git.lion47.com/ (which is currently on a slow and unstable > connection), I have created a mirror on Github, so feel free to use that > instead. I will keep updating it every 12 hours. > > http://github.com/mikl/drupal/tree/master > -- > Kind regards, > > Mikkel H?gh > > From mikkel at hoegh.org Sat Oct 11 15:32:31 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Sat, 11 Oct 2008 17:32:31 +0200 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: <6117a7500810110803w58823351p1acf5d9ce581538e@mail.gmail.com> References: <6117a7500810110803w58823351p1acf5d9ce581538e@mail.gmail.com> Message-ID: <3EF1A75E-56A5-4634-9C90-13BCE56B5040@hoegh.org> No, no specific reason, besides not wanting to upset the admins at cvs.drupal.org ? I do not know how much strain a git-cvsimport puts on the CVS server, but when I first set this up, I wanted to be on the safe side. If it's okay to do so, I have no problems increasing the frequency. That server is doing almost nothing anyways :) And yes, as Sam said, the URL i posted earlier is to the Github HTML interface. The clone URL is git://github.com/mikl/drupal.git ? sorry for the confusion. -- Kind regards, Mikkel H?gh On 11/10/2008, at 17.03, Moshe Weitzman wrote: > It would be ideal for core development if it could update very > frequently like once per hour. That way we would be less likely to > generate fuzzy patches. Most cron runs will result in no git push but > perhaps you have reasons why thats not desireable. > > On Sat, Oct 11, 2008 at 6:20 AM, Mikkel H?gh wrote: >> For anyone who's been using/playing with my Git-mirror of Drupal >> core CVS at >> http://git.lion47.com/ (which is currently on a slow and unstable >> connection), I have created a mirror on Github, so feel free to use >> that >> instead. I will keep updating it every 12 hours. >> >> http://github.com/mikl/drupal/tree/master >> -- >> Kind regards, >> >> Mikkel H?gh >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081011/a6793d66/attachment-0001.bin From sysop at scbbs.com Sat Oct 11 16:23:07 2008 From: sysop at scbbs.com (Ron Parker) Date: Sat, 11 Oct 2008 09:23:07 -0700 (PDT) Subject: [development] Internet Explorer Print Loses User Context In-Reply-To: <28133370.251223742180575.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <29686996.271223742187503.JavaMail.root@zimbra.thefiengroup.com> Just out of curiosity, does all these calls pass through drupal's menu system? Anything that doesn't will naturally not contain any of drupal's context variables. Yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081011/424585af/attachment.htm From drupal at samboyer.org Sat Oct 11 16:50:04 2008 From: drupal at samboyer.org (Sam Boyer) Date: Sat, 11 Oct 2008 11:50:04 -0500 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: <3EF1A75E-56A5-4634-9C90-13BCE56B5040@hoegh.org> References: <6117a7500810110803w58823351p1acf5d9ce581538e@mail.gmail.com> <3EF1A75E-56A5-4634-9C90-13BCE56B5040@hoegh.org> Message-ID: <200810111150.17426.drupal@samboyer.org> I'm assuming that your workflow looks something like this: $ cd /path/to/local/git-cvsimport/of/drupal/core $ git cvsimport -a $ git push --mirror Which will pull in all the recent changes from core, then push them out to your github repo. If that's the case, git-cvsimport doesn't put much strain on the servers, as it does its work by incrementally importing changesets. If you were very concerned about server load, you could always run the git-cvsimport off a copy of drupal cvs that you keep rsync'd locally, but I suspect that the performance impact on drupal's cvs server would be negligible in either case. Of course, if we were talking contrib, that might be a little different... :) s On Saturday 11 October 2008 10:32:31 am Mikkel H?gh wrote: > No, no specific reason, besides not wanting to upset the admins at > cvs.drupal.org ? I do not know how much strain a git-cvsimport puts on > the CVS server, but when I first set this up, I wanted to be on the > safe side. > > If it's okay to do so, I have no problems increasing the frequency. > That server is doing almost nothing anyways :) > > And yes, as Sam said, the URL i posted earlier is to the Github HTML > interface. The clone URL is git://github.com/mikl/drupal.git ? sorry > for the confusion. > -- > Kind regards, > > Mikkel H?gh > > On 11/10/2008, at 17.03, Moshe Weitzman wrote: > > It would be ideal for core development if it could update very > > frequently like once per hour. That way we would be less likely to > > generate fuzzy patches. Most cron runs will result in no git push but > > perhaps you have reasons why thats not desireable. > > > > On Sat, Oct 11, 2008 at 6:20 AM, Mikkel H?gh wrote: > >> For anyone who's been using/playing with my Git-mirror of Drupal > >> core CVS at > >> http://git.lion47.com/ (which is currently on a slow and unstable > >> connection), I have created a mirror on Github, so feel free to use > >> that > >> instead. I will keep updating it every 12 hours. > >> > >> http://github.com/mikl/drupal/tree/master > >> -- > >> Kind regards, > >> > >> Mikkel H?gh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.drupal.org/pipermail/development/attachments/20081011/ca06a39a/attachment.pgp From mikkel at hoegh.org Sat Oct 11 16:57:17 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Sat, 11 Oct 2008 18:57:17 +0200 Subject: [development] Git-mirror of Drupal core now on Github In-Reply-To: <200810111150.17426.drupal@samboyer.org> References: <6117a7500810110803w58823351p1acf5d9ce581538e@mail.gmail.com> <3EF1A75E-56A5-4634-9C90-13BCE56B5040@hoegh.org> <200810111150.17426.drupal@samboyer.org> Message-ID: <9F4C9A92-3700-48DE-A331-C70221A25D9E@hoegh.org> Yeah, that's basically my cron-script sans a bit of the nitty-gritty details, but it is an incremental operation, although the average runtime is around 13 seconds when there are no changes. I've upped the frequency, so it now runs at :07 every hour :) -- Kind regards, Mikkel H?gh On 11/10/2008, at 18.50, Sam Boyer wrote: > I'm assuming that your workflow looks something like this: > > $ cd /path/to/local/git-cvsimport/of/drupal/core > $ git cvsimport -a > $ git push --mirror > > Which will pull in all the recent changes from core, then push them > out to > your github repo. If that's the case, git-cvsimport doesn't put much > strain > on the servers, as it does its work by incrementally importing > changesets. If > you were very concerned about server load, you could always run the > git-cvsimport off a copy of drupal cvs that you keep rsync'd > locally, but I > suspect that the performance impact on drupal's cvs server would be > negligible in either case. > > Of course, if we were talking contrib, that might be a little > different... :) > > s > > On Saturday 11 October 2008 10:32:31 am Mikkel H?gh wrote: >> No, no specific reason, besides not wanting to upset the admins at >> cvs.drupal.org ? I do not know how much strain a git-cvsimport puts >> on >> the CVS server, but when I first set this up, I wanted to be on the >> safe side. >> >> If it's okay to do so, I have no problems increasing the frequency. >> That server is doing almost nothing anyways :) >> >> And yes, as Sam said, the URL i posted earlier is to the Github HTML >> interface. The clone URL is git://github.com/mikl/drupal.git ? sorry >> for the confusion. >> -- >> Kind regards, >> >> Mikkel H?gh >> >> On 11/10/2008, at 17.03, Moshe Weitzman wrote: >>> It would be ideal for core development if it could update very >>> frequently like once per hour. That way we would be less likely to >>> generate fuzzy patches. Most cron runs will result in no git push >>> but >>> perhaps you have reasons why thats not desireable. >>> >>> On Sat, Oct 11, 2008 at 6:20 AM, Mikkel H?gh >>> wrote: >>>> For anyone who's been using/playing with my Git-mirror of Drupal >>>> core CVS at >>>> http://git.lion47.com/ (which is currently on a slow and unstable >>>> connection), I have created a mirror on Github, so feel free to use >>>> that >>>> instead. I will keep updating it every 12 hours. >>>> >>>> http://github.com/mikl/drupal/tree/master >>>> -- >>>> Kind regards, >>>> >>>> Mikkel H?gh > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081011/745ae1d2/attachment.bin From drupal at dwwright.net Sun Oct 12 02:12:19 2008 From: drupal at dwwright.net (Derek Wright) Date: Sat, 11 Oct 2008 19:12:19 -0700 Subject: [development] FYI: you can now commit .inc files to contributions/profiles Message-ID: <48CEEA53-64A9-4AC8-9172-C7AB040762AF@dwwright.net> Sorry this took so long, but I just discovered an issue that's been languishing in the queue: http://drupal.org/node/267313 I just fixed that, so you can now commit .inc files to installation profiles. Thanks to mikey_p for reporting the problem in the first place and supplying a patch, and to aclight for bringing it to my attention. ;) Cheers, -Derek (dww) From development at robuustdesign.nl Sun Oct 12 08:52:21 2008 From: development at robuustdesign.nl (Stefan Nagtegaal) Date: Sun, 12 Oct 2008 10:52:21 +0200 Subject: [development] Webchick: The blessing for Drupal 7 Message-ID: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> Dear list and webchick, After - what feels like - an enormous amount of time I'm back to drupal theming and development, and there is only one reason for it which is Webchick (Angela Byron). She gives the community the pulse it needed after the absense(s) of Dries and his lack of committing patches which are waiting much to long in the patch queue. (Although, no offense Dries!) Dries, this is you best decision since you started Drupal! Webchick, I feel deep respect for you, your way of working and your patience for helping out people. And I definatly look forward - after getting up to speed with drupal again - to let you review and apply the many usability patches I want to work at, together with perhaps some new or improved core theme(s). Webchick, thank you for bringing back my trust and belief in Drupal! You absolutely rock girl... Stefan Nagtegaal From rob at robshouse.net Sun Oct 12 09:03:04 2008 From: rob at robshouse.net (Robert Douglass) Date: Sun, 12 Oct 2008 11:03:04 +0200 Subject: [development] Webchick: The blessing for Drupal 7 In-Reply-To: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> References: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> Message-ID: <875C4FD0-F1D8-4B3C-9AA9-D94C0722FFA0@robshouse.net> Amen, and welcome back Stefan =) On Oct 12, 2008, at 10:52 AM, Stefan Nagtegaal wrote: > Dear list and webchick, > > > After - what feels like - an enormous amount of time I'm back to > drupal theming and development, and there is only one reason for it > which is Webchick (Angela Byron). > She gives the community the pulse it needed after the absense(s) of > Dries and his lack of committing patches which are waiting much to > long in the patch queue. (Although, no offense Dries!) > > Dries, this is you best decision since you started Drupal! > > Webchick, I feel deep respect for you, your way of working and your > patience for helping out people. > And I definatly look forward - after getting up to speed with drupal > again - to let you review and apply the many usability patches I > want to work at, together with perhaps some new or improved core > theme(s). > > Webchick, thank you for bringing back my trust and belief in Drupal! > You absolutely rock girl... > > > Stefan Nagtegaal From mikkel at hoegh.org Sun Oct 12 12:48:13 2008 From: mikkel at hoegh.org (=?ISO-8859-1?Q?Mikkel_H=F8gh?=) Date: Sun, 12 Oct 2008 14:48:13 +0200 Subject: [development] =?windows-1252?q?Drupal_Camp_in_Copenhagen_=96_an_i?= =?windows-1252?q?nvitation?= Message-ID: Dear sirs, As you might be aware of, mortendk and a couple of other guys and I are trying to put together a Drupal Camp in Copenhagen at 14.-16. november, and we have almost gotten it all straightened out with venue and sponsors (still a few more needed if you're interested ;)), but we would really love to see some more speakers from the Drupal community, so we're hoping to talk some of the people that live not too far away into coming and holding a session or two. Our budget is still a bit tight, but we might be able to help you finance travel expenses. As the numbers are now, we have 52 attendees, so it won't be a complete waste of time. We would particularly like if anyone from Acquia would be willing to drop by and tell a bit about what they're doing, since I'm sure that it is a thing that many newbies into Drupal would be curious about: "Oh, the project lead earns money? We can't have that?" ;-) So if you are at all willing and capable to come to Copenhagen and talk about Drupal to 50-100 Drupal-interested people (mainly Scandinavians, but the official language is English), please let us know, so we can work something out :) -- Kind regards, Mikkel H?gh -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1929 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081012/e002e4d1/attachment-0001.bin From aldo at caonao.cu Sun Oct 12 16:07:24 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Sun, 12 Oct 2008 12:07:24 -0400 Subject: [development] hello from a newbie Message-ID: <200810121207.24757.aldo@caonao.cu> i am a new user of drupal, and i want to learn drupal developing, so, i'm doing a module for my study, and i want to know if may i integrate other module in the mine, i mean, may i insert a functionality of upload module in my module administrative interface?? -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From bharanikumariyerphp at gmail.com Sun Oct 12 16:40:32 2008 From: bharanikumariyerphp at gmail.com (bharani kumar) Date: Sun, 12 Oct 2008 22:10:32 +0530 Subject: [development] hello from a newbie In-Reply-To: <200810121207.24757.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> Message-ID: <2240033d0810120940o2f050378la6e1a85459584b91@mail.gmail.com> sure u can On Sun, Oct 12, 2008 at 9:37 PM, Aldo Martinez Selleras wrote: > i am a new user of drupal, and i want to learn drupal developing, so, i'm > doing a module for my study, and i want to know if may i integrate other > module in the mine, i mean, may i insert a functionality of upload module > in > my module administrative interface?? > > -- > ---------------------- > Aldo Martinez Selleras > Administrador del Nodo > CITMATEL GND Camaguey > Tel: 32-291661 > E-mail: aldo at caonao.cu > Linux User #364356 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081012/9786593a/attachment.htm From aldo at caonao.cu Sun Oct 12 16:36:48 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Sun, 12 Oct 2008 12:36:48 -0400 Subject: [development] hello from a newbie In-Reply-To: <2240033d0810120940o2f050378la6e1a85459584b91@mail.gmail.com> References: <200810121207.24757.aldo@caonao.cu> <2240033d0810120940o2f050378la6e1a85459584b91@mail.gmail.com> Message-ID: <200810121236.48715.aldo@caonao.cu> could u tell me how, remember, i'am a newbie, and i have been looking for an example but can not find any, please. -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From bharanikumariyerphp at gmail.com Sun Oct 12 16:50:34 2008 From: bharanikumariyerphp at gmail.com (bharani kumar) Date: Sun, 12 Oct 2008 22:20:34 +0530 Subject: [development] hello from a newbie In-Reply-To: <200810121236.48715.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> <2240033d0810120940o2f050378la6e1a85459584b91@mail.gmail.com> <200810121236.48715.aldo@caonao.cu> Message-ID: <2240033d0810120950vced5eeep4aa74ea5ef9712eb@mail.gmail.com> First track the upload function , Once u find the upload function , simply u call that function into ur module, Drupal main advantage is, u call the function ... On Sun, Oct 12, 2008 at 10:06 PM, Aldo Martinez Selleras wrote: > could u tell me how, remember, i'am a newbie, and i have been looking for > an > example but can not find any, please. > > -- > ---------------------- > Aldo Martinez Selleras > Administrador del Nodo > CITMATEL GND Camaguey > Tel: 32-291661 > E-mail: aldo at caonao.cu > Linux User #364356 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081012/0e1286e3/attachment.htm From mpartap at gmx.net Sun Oct 12 20:50:11 2008 From: mpartap at gmx.net (Marcel Partap) Date: Sun, 12 Oct 2008 22:50:11 +0200 Subject: [development] hello from a newbie In-Reply-To: <2240033d0810120950vced5eeep4aa74ea5ef9712eb@mail.gmail.com> References: <200810121207.24757.aldo@caonao.cu> <2240033d0810120940o2f050378la6e1a85459584b91@mail.gmail.com> <200810121236.48715.aldo@caonao.cu> <2240033d0810120950vced5eeep4aa74ea5ef9712eb@mail.gmail.com> Message-ID: <48F26303.7010707@gmx.net> > could u tell me how, remember, i'am a newbie, and i have been > looking for an > example but can not find any, please. grep -rnI is your friend to find function calls and distinctive strings.. and api.drupal.org! To start coding a module, reading modules and understanding the code is a very useful thing to do. Good luck! -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future From drupal-devel at webchick.net Sun Oct 12 22:05:39 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sun, 12 Oct 2008 18:05:39 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 Message-ID: <48F274B3.4030404@webchick.net> I just rolled the second in the series of Drupal 7 unstable releases for developers (see http://lists.drupal.org/pipermail/development/2008-October/031094.html for more info). Among the highlights this release are: * Several awesome File API improvements. Files are now "first-class objects" like nodes and users are, the API has been dramatically cleaned up for better consistency, AND there are a slew of new hooks like hook_file_load() and hook_file_validate() for contrib modules to react to when stuff happens to files. This is a great enabler for some awesome stuff in core like image handling and document management. See http://api.drupal.org/api/search/7/hook_file for more info. A HUGE shout-out to Andrew Morton (drewish) for sticking with this patch throughout its long, LONG development cycle. :) * Also in additional hooks, hooks are now fired whenever modules are installed, uninstalled, enabled, or disabled. See http://api.drupal.org/api/search/7/hook_modules for more info. This should pave the way for some nice DX patches in future unstable releases. * In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters are now gone. Instead of having to switch on $op and figure out what in the world '$arg1' is in the 'load' context (UGH), you instead implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're dealing with. * Permission names are now localizable, which gives permissions human-friendly names in addition to descriptions. This changed the hook_perm() array somewhat. See http://drupal.org/node/224333#descriptions-permissions for more details. * Better security! Drupal 7 is now caught up to Drupal 6 on security patches. Now you can setup a Drupal 7 test site with far less pwnage! ;) Incidentally, for those brave contrib module authors who want to chase HEAD, the Updating Modules page is now broken down by unstable release so you can make changes incrementally: http://drupal.org/node/224333. One thing there is *not* in this release is a lot of major usability enhancements. I'd really like to see this change over the next couple of unstable releases. Drupal 7's API is shaping up nicely, and we're getting tons of patches in that enable new things for our developers as well as clean up silly crap that's been annoying us collectively for a long time. But I'd like to get some focus on real "Wow-factor" things for our end users, too... and sooner than later so we can test them ahead of release and make sure they actually /do/ make things easier to use. :) The Usability team has identified 3 top usability issues to focus on at http://groups.drupal.org/node/7074. If any of you out there have "make Drupal 7 kick ass" as one of their todos, they would really appreciate help on how to break down these major issues into smaller, actionable items, and need some folks to write and test patches to get them addressed. There are also a number of smaller, more bite-sized issues that would be nice improvements, and new features that would make Drupal easier to use. http://groups.drupal.org/patch-spotlight is where this sort of "bubbling up" of important issues is being organized. Since UNSTABLE-1 was released on the 1st, and UNSTABLE-2 on the 12th, let's shoot for UNSTABLE-3 to be towards the end of the month, hopefully with some nice usability improvements in addition to more goodies for developers. Looking forward to reviewing and committing your patches! :) -Angie From drupal-devel at webchick.net Sun Oct 12 22:21:34 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Sun, 12 Oct 2008 18:21:34 -0400 Subject: [development] Webchick: The blessing for Drupal 7 In-Reply-To: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> References: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> Message-ID: <48F2786E.2010301@webchick.net> Stefan Nagtegaal wrote: > Dear list and webchick, > > > After - what feels like - an enormous amount of time I'm back to drupal > theming and development, and there is only one reason for it which is > Webchick (Angela Byron). > She gives the community the pulse it needed after the absense(s) of > Dries and his lack of committing patches which are waiting much to long > in the patch queue. (Although, no offense Dries!) > > Dries, this is you best decision since you started Drupal! > > Webchick, I feel deep respect for you, your way of working and your > patience for helping out people. > And I definatly look forward - after getting up to speed with drupal > again - to let you review and apply the many usability patches I want to > work at, together with perhaps some new or improved core theme(s). > > Webchick, thank you for bringing back my trust and belief in Drupal! You > absolutely rock girl... Oh, wow. Thanks so much for your kind words, Stefan. :) I think you give me too much credit though. Dries has been committing his fair share of patches, and of course we wouldn't have /any/ patches to commit if awesome Drupal core developers weren't constantly hard at work. :D But that would be GREAT to have you back in the core queue again. I'd just love Drupal 7 to really step it up in terms of usability and design, and you are a wonderful person to drive this sort of effort forward. :) Welcome back! -Angie From gabor at hojtsy.hu Mon Oct 13 06:57:20 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 13 Oct 2008 08:57:20 +0200 Subject: [development] Webchick: The blessing for Drupal 7 In-Reply-To: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> References: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> Message-ID: <86ca3ccb0810122357x6b869ca0xe08b1a99c3cda12b@mail.gmail.com> Stefan, It is great to hear that you are joining this already awesome group of people at http://groups.drupal.org/usability again and make the horizon of Drupal 7 even more awesome. G?bor On Sun, Oct 12, 2008 at 10:52 AM, Stefan Nagtegaal wrote: > Dear list and webchick, > > > After - what feels like - an enormous amount of time I'm back to drupal > theming and development, and there is only one reason for it which is > Webchick (Angela Byron). > She gives the community the pulse it needed after the absense(s) of Dries > and his lack of committing patches which are waiting much to long in the > patch queue. (Although, no offense Dries!) > > Dries, this is you best decision since you started Drupal! > > Webchick, I feel deep respect for you, your way of working and your patience > for helping out people. > And I definatly look forward - after getting up to speed with drupal again - > to let you review and apply the many usability patches I want to work at, > together with perhaps some new or improved core theme(s). > > Webchick, thank you for bringing back my trust and belief in Drupal! You > absolutely rock girl... > > > Stefan Nagtegaal > From gabor at hojtsy.hu Mon Oct 13 07:23:33 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 13 Oct 2008 09:23:33 +0200 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <48F274B3.4030404@webchick.net> References: <48F274B3.4030404@webchick.net> Message-ID: <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> On Mon, Oct 13, 2008 at 12:05 AM, Angela Byron wrote: > Incidentally, for those brave contrib module authors who want to chase HEAD, > the Updating Modules page is now broken down by unstable release so you can > make changes incrementally: http://drupal.org/node/224333. Well, this is all great. Except that I modified the existing hook_perm() docs (there were changes to hook_perm() in UNSTABLE_1 and UNSTABLE_2 as well). I thought it would be best to have docs carry over people from Drupal 6 to 7 all at once, but this goes somewhat against the grouping you intend. What I did now, is that I've included the link to the _perm() changes in both sections and modified the perm intro to say this: (issue) released in UNSTABLE_1 and (issue) released in UNSTABLE_2. If you know something better to make cross-UNSTABLE changes documented with a single doc, it would be great to put forward :) Gabor From aldo at caonao.cu Mon Oct 13 11:31:03 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Mon, 13 Oct 2008 07:31:03 -0400 Subject: [development] hello from a newbie In-Reply-To: <48F26303.7010707@gmx.net> References: <200810121207.24757.aldo@caonao.cu> <2240033d0810120950vced5eeep4aa74ea5ef9712eb@mail.gmail.com> <48F26303.7010707@gmx.net> Message-ID: <200810130731.03639.aldo@caonao.cu> well, i has been reading a lot of documentation, and books, including module codes, and in the drupal.org site, there is a many documentation and tips, by example, there is one which explain how to call a function if(module_exists('name')){ name_funct(); } so, is single! but, i think the big problem in this case, its how i know what is the main function for call, i was looking the code, and the module, and him use de hook_nodeapi() for include the Upload Form in the nodetypes define in the settings for the module, so? i just want to do this because i think, if drupal have a upload module, why may i implement a single upload system form my module? PD: please, i am no very good in my english, sorry. :) -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From dries.buytaert at gmail.com Mon Oct 13 12:35:03 2008 From: dries.buytaert at gmail.com (Dries Buytaert) Date: Mon, 13 Oct 2008 14:35:03 +0200 Subject: [development] Webchick: The blessing for Drupal 7 In-Reply-To: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> References: <1460FFC6-C421-4216-8226-E10191086DD2@robuustdesign.nl> Message-ID: <61bca48a0810130535r190c4b18s3133fd5e386c16ed@mail.gmail.com> On Sun, Oct 12, 2008 at 10:52 AM, Stefan Nagtegaal wrote: > After - what feels like - an enormous amount of time I'm back to drupal > theming and development, and there is only one reason for it which is > Webchick (Angela Byron). > She gives the community the pulse it needed after the absense(s) of Dries > and his lack of committing patches which are waiting much to long in the > patch queue. (Although, no offense Dries!) > > Dries, this is you best decision since you started Drupal! You're welcome Stefan, and welcome back. webchick is rocking it, for sure. Let us know when we can see your contributions! :) -- Dries Buytaert :: http://buytaert.net/ From earnie at users.sourceforge.net Mon Oct 13 13:02:43 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Mon, 13 Oct 2008 09:02:43 -0400 Subject: [development] hello from a newbie In-Reply-To: <200810130731.03639.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> <2240033d0810120950vced5eeep4aa74ea5ef9712eb@mail.gmail.com> <48F26303.7010707@gmx.net> <200810130731.03639.aldo@caonao.cu> Message-ID: <20081013090243.vho5cvwcqstccoo4@mail.progw.org> Quoting Aldo Martinez Selleras : > well, i has been reading a lot of documentation, and books, including module > codes, and in the drupal.org site, there is a many documentation and tips, by > example, there is one which explain how to call a function > > if(module_exists('name')){ > name_funct(); > } > > so, is single! > > but, i think the big problem in this case, its how i know what is the main > function for call, i was looking the code, and the module, and him use de > hook_nodeapi() for include the Upload Form in the nodetypes define in the > settings for the module, so? > > i just want to do this because i think, if drupal have a upload module, why > may i implement a single upload system form my module? > > PD: please, i am no very good in my english, sorry. :) > Your English is good enough to communicate. If it is Drupal core you're looking for see api.drupal.org. If it is a contributed module you can always look in the module itself or perhaps use http://drupal.kollm.org/doxygen/_contrib/drupal-contrib-phpdoc/dirs.html to browse the contribution/module repository. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From cxjohnson at gmail.com Mon Oct 13 14:02:16 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 13 Oct 2008 09:02:16 -0500 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <48F274B3.4030404@webchick.net> References: <48F274B3.4030404@webchick.net> Message-ID: <9ea8d6030810130702j7ce667ectbc87316b0c00430a@mail.gmail.com> Uh, DX? What does that mean? ..chris On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron wrote: > I just rolled the second in the series of Drupal 7 unstable releases for > developers (see > http://lists.drupal.org/pipermail/development/2008-October/031094.html for > more info). Among the highlights this release are: > > * Also in additional hooks, hooks are now fired whenever modules are > installed, uninstalled, enabled, or disabled. See > http://api.drupal.org/api/search/7/hook_modules for more info. This should > pave the way for some nice DX patches in future unstable releases. > > * In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op parameters > are now gone. Instead of having to switch on $op and figure out what in the > world '$arg1' is in the 'load' context (UGH), you instead implement > hook_nodeapi_load(&$node, $teaser, $page) and know exactly what you're > dealing with. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081013/7f7f95ff/attachment.htm From mathews.kyle at gmail.com Mon Oct 13 14:04:24 2008 From: mathews.kyle at gmail.com (Kyle Mathews) Date: Mon, 13 Oct 2008 08:04:24 -0600 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <9ea8d6030810130702j7ce667ectbc87316b0c00430a@mail.gmail.com> References: <48F274B3.4030404@webchick.net> <9ea8d6030810130702j7ce667ectbc87316b0c00430a@mail.gmail.com> Message-ID: DX == Developer Experience http://groups.drupal.org/node/15368 Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Mon, Oct 13, 2008 at 8:02 AM, Chris Johnson wrote: > Uh, DX? What does that mean? > ..chris > > On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron wrote: > >> I just rolled the second in the series of Drupal 7 unstable releases for >> developers (see >> http://lists.drupal.org/pipermail/development/2008-October/031094.htmlfor more info). Among the highlights this release are: >> >> * Also in additional hooks, hooks are now fired whenever modules are >> installed, uninstalled, enabled, or disabled. See >> http://api.drupal.org/api/search/7/hook_modules for more info. This >> should pave the way for some nice DX patches in future unstable releases. >> >> * In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op >> parameters are now gone. Instead of having to switch on $op and figure out >> what in the world '$arg1' is in the 'load' context (UGH), you instead >> implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what >> you're dealing with. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081013/aca9d1d3/attachment.htm From aldo at caonao.cu Mon Oct 13 14:22:32 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Mon, 13 Oct 2008 10:22:32 -0400 Subject: [development] hello from a newbie In-Reply-To: <20081013090243.vho5cvwcqstccoo4@mail.progw.org> References: <200810121207.24757.aldo@caonao.cu> <200810130731.03639.aldo@caonao.cu> <20081013090243.vho5cvwcqstccoo4@mail.progw.org> Message-ID: <200810131022.32275.aldo@caonao.cu> i'm just creating a module for study, i think that is a good way for learn about drupal development , i don't think could be a drupal contribute, but if cutomize my drupal behavior, and create some one module for specific work. this module whihc i'm creating is a gallery, i think with this may i use almost all drupal functions, i mean, database, menu, manage image, create the settings, user management, and the use of some hooks, that is the razon to select that project for my study. now, while working, i think if could i use other module functionality in my module, and yersterday 'kumar' tell me that was posible, but i can't do with the solution! :( the module what i want to integrate it's Upload, for the moment when the images will be uploaded to the server for be public later in the gallery. -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From agentrickard at gmail.com Mon Oct 13 15:07:13 2008 From: agentrickard at gmail.com (Ken Rickard) Date: Mon, 13 Oct 2008 11:07:13 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: References: <48F274B3.4030404@webchick.net> <9ea8d6030810130702j7ce667ectbc87316b0c00430a@mail.gmail.com> Message-ID: <25b45da00810130807l25d95a6bq6ad8974d6a1b81b7@mail.gmail.com> Sample DX fix for D7 -- though not yet patched. Developers will no longer need to uninstall their own schemas, permissions, or (hopefully) variables when their module is uninstalled. system_modules_uninstalled() can now handle all that for you, which means less for you to worry about and less redundancy in the code. See http://drupal.org/node/306027 for example. On Mon, Oct 13, 2008 at 10:04 AM, Kyle Mathews wrote: > DX == Developer Experience > http://groups.drupal.org/node/15368 > > Kyle > > Research Assistant > eBusiness Center @ BYU > kyle.mathews2000.com/blog > > > On Mon, Oct 13, 2008 at 8:02 AM, Chris Johnson wrote: >> >> Uh, DX? What does that mean? >> ..chris >> >> On Sun, Oct 12, 2008 at 5:05 PM, Angela Byron >> wrote: >>> >>> I just rolled the second in the series of Drupal 7 unstable releases for >>> developers (see >>> http://lists.drupal.org/pipermail/development/2008-October/031094.html for >>> more info). Among the highlights this release are: >>> >>> * Also in additional hooks, hooks are now fired whenever modules are >>> installed, uninstalled, enabled, or disabled. See >>> http://api.drupal.org/api/search/7/hook_modules for more info. This should >>> pave the way for some nice DX patches in future unstable releases. >>> >>> * In the DX clean-up realm, hook_user() and hook_nodeapi()'s $op >>> parameters are now gone. Instead of having to switch on $op and figure out >>> what in the world '$arg1' is in the 'load' context (UGH), you instead >>> implement hook_nodeapi_load(&$node, $teaser, $page) and know exactly what >>> you're dealing with. >>> > > -- Ken Rickard agentrickard at gmail.com http://ken.therickards.com From michael at favias.org Mon Oct 13 16:50:52 2008 From: michael at favias.org (Michael Favia) Date: Mon, 13 Oct 2008 11:50:52 -0500 Subject: [development] hello from a newbie In-Reply-To: <200810131022.32275.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> <200810130731.03639.aldo@caonao.cu> <20081013090243.vho5cvwcqstccoo4@mail.progw.org> <200810131022.32275.aldo@caonao.cu> Message-ID: <48F37C6C.8000401@favias.org> Aldo Martinez Selleras wrote: > this module whihc i'm creating is a gallery, i think with this may i use > almost all drupal functions, i mean, database, menu, manage image, create the > settings, user management, and the use of some hooks, that is the razon to > select that project for my study. > Welcome to drupal. A relatively new and very popular choice for creating online galleries is to combine a couple of popular existing modules like so: Enable cck module and create a new content type. Enable Imagefield module and imagecache module and create a new field on your new content type. Enable Views modules and create a view that includes the desired imagecache derivative in the desired format. You have tons of extra options including adding things like "thickbox module" for ajax zooms, or other "field formatters" for the cck imagefield. If youd like to write your own module i might suggest writing an imagefield formatter instead of rewriting everything from scratch. Druapl stands on the shoulders of the people who wrote apache, php and mysql, the contrib modules stand on the shoulders of drupal core and i highly recommend augmenting existing functionality through our extensive system of hook over reinventing the wheel for your desired functionality. -mf From drupal-devel at webchick.net Mon Oct 13 17:00:10 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Mon, 13 Oct 2008 13:00:10 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> References: <48F274B3.4030404@webchick.net> <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> Message-ID: <48F37E9A.1050107@webchick.net> G?bor Hojtsy wrote: > On Mon, Oct 13, 2008 at 12:05 AM, Angela Byron > wrote: >> Incidentally, for those brave contrib module authors who want to chase HEAD, >> the Updating Modules page is now broken down by unstable release so you can >> make changes incrementally: http://drupal.org/node/224333. > > Well, this is all great. Except that I modified the existing > hook_perm() docs (there were changes to hook_perm() in UNSTABLE_1 and > UNSTABLE_2 as well). I thought it would be best to have docs carry > over people from Drupal 6 to 7 all at once, but this goes somewhat > against the grouping you intend. > > What I did now, is that I've included the link to the _perm() changes > in both sections and modified the perm intro to say this: > > (issue) released in > UNSTABLE_1 and (issue) > released in UNSTABLE_2. > > If you know something better to make cross-UNSTABLE changes documented > with a single doc, it would be great to put forward :) Ah, this is how I would handle this: * Keep the text of the page geared toward people updating 6 to 7 all at once. (issue) and (issue); no need to specify when it was added. * In the table of contents though, under UNSTABLE-2, add the permission change with a link to the place that talks about both. This way, the ToC can be for incremental updaters, but the text can be for the "all-at-once" folks. Make sense? -Angie From gabor at hojtsy.hu Mon Oct 13 17:02:46 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 13 Oct 2008 19:02:46 +0200 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <48F37E9A.1050107@webchick.net> References: <48F274B3.4030404@webchick.net> <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> <48F37E9A.1050107@webchick.net> Message-ID: <86ca3ccb0810131002h2c44e41bq4414612ed7565d2e@mail.gmail.com> On Mon, Oct 13, 2008 at 7:00 PM, Angela Byron wrote: > Ah, this is how I would handle this: > > * Keep the text of the page geared toward people updating 6 to 7 all at > once. (issue) and (issue); no need to specify when it was added. > > * In the table of contents though, under UNSTABLE-2, add the permission > change with a link to the place that talks about both. "Place that talks about both" would be the same as in the * before, right? Somehow we'd still need to point people on what changed in that section from one UNSTABLE to the other, right? Or did I miss something? Gabor From catch56 at googlemail.com Mon Oct 13 17:13:46 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 13 Oct 2008 18:13:46 +0100 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <86ca3ccb0810131002h2c44e41bq4414612ed7565d2e@mail.gmail.com> References: <48F274B3.4030404@webchick.net> <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> <48F37E9A.1050107@webchick.net> <86ca3ccb0810131002h2c44e41bq4414612ed7565d2e@mail.gmail.com> Message-ID: I don't think we should maintain documentation for API changes between UNSTABLE versions, that seems like a recipe for a huge mess to me and lots and lots of duplicate work. There seems to be two ways you'd upgrade a contrib module: 1. Every time there's an unstable release, upgrade your contrib module 2. wait a while, then upgrade to the latest UNSTABLE (or beta, or 7.0) Maintaining two sets of upgrade documentation seems to be accounting for 3. Wait a while, then go through UNSTABLE-1, UNSTABLE-2, UNSTABLE-3 one at a time. 3. just looks like a lot of work for no gain to me. Therefore, if an API changes between UNSTABLE-1 and UNSTABLE-2 - then we should document the 6.x - 7.x upgrade in UNSTABLE-2 as 'this is the most recent unstable release where this particular API was changed'. If UNSTABLE-2 is out, no-one should be trying to upgrade to UNSTABLE-1 at all. If you're upgrading from UNSTABLE-1 to UNSTABLE-2, then the fact that (in this example) permissions changes are there again, means you ought to be able to work out what to do. In the same way we don't provide database updates for different versions of HEAD, I don't think we should provide API updates for different versions of HEAD either. Or have I missed something really obvious? Nat On Mon, Oct 13, 2008 at 6:02 PM, G?bor Hojtsy wrote: > On Mon, Oct 13, 2008 at 7:00 PM, Angela Byron > wrote: > > Ah, this is how I would handle this: > > > > * Keep the text of the page geared toward people updating 6 to 7 all at > > once. (issue) and (issue); no need to specify when it was added. > > > > * In the table of contents though, under UNSTABLE-2, add the permission > > change with a link to the place that talks about both. > > "Place that talks about both" would be the same as in the * before, > right? Somehow we'd still need to point people on what changed in that > section from one UNSTABLE to the other, right? Or did I miss > something? > > Gabor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081013/81d6139b/attachment.htm From gabor at hojtsy.hu Mon Oct 13 17:16:24 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Mon, 13 Oct 2008 19:16:24 +0200 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: References: <48F274B3.4030404@webchick.net> <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> <48F37E9A.1050107@webchick.net> <86ca3ccb0810131002h2c44e41bq4414612ed7565d2e@mail.gmail.com> Message-ID: <86ca3ccb0810131016j1f060953s637c8762c6a1237a@mail.gmail.com> On Mon, Oct 13, 2008 at 7:13 PM, Nathaniel Catchpole wrote: > Therefore, if an API changes between UNSTABLE-1 and UNSTABLE-2 - then we > should document the 6.x - 7.x upgrade in UNSTABLE-2 as 'this is the most > recent unstable release where this particular API was changed'. If > UNSTABLE-2 is out, no-one should be trying to upgrade to UNSTABLE-1 at all. > If you're upgrading from UNSTABLE-1 to UNSTABLE-2, then the fact that (in > this example) permissions changes are there again, means you ought to be > able to work out what to do. You say we should just move these sections around as if no hook_perm() change would have happened in UNSTABLE_1? G?bor From news at unleashedmind.com Mon Oct 13 17:22:25 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Mon, 13 Oct 2008 19:22:25 +0200 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <86ca3ccb0810131016j1f060953s637c8762c6a1237a@mail.gmail.com> Message-ID: <013f01c92d58$42d8db90$0200a8c0@structworks.com> > You say we should just move these sections around as if no > hook_perm() change would have happened in UNSTABLE_1? > > G?bor Yes, I too think that would be sufficient in such cases. Daniel From catch56 at googlemail.com Mon Oct 13 17:29:06 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Mon, 13 Oct 2008 18:29:06 +0100 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <86ca3ccb0810131016j1f060953s637c8762c6a1237a@mail.gmail.com> References: <48F274B3.4030404@webchick.net> <86ca3ccb0810130023p7b3585fdp305dde776437c531@mail.gmail.com> <48F37E9A.1050107@webchick.net> <86ca3ccb0810131002h2c44e41bq4414612ed7565d2e@mail.gmail.com> <86ca3ccb0810131016j1f060953s637c8762c6a1237a@mail.gmail.com> Message-ID: On Mon, Oct 13, 2008 at 6:16 PM, G?bor Hojtsywrote: > > > > You say we should just move these sections around as if no hook_perm() > change would have happened in UNSTABLE_1? > > G?bor That's exactly what I mean yes. Once UNSTABLE_2 comes out, there should be no need for specific documentation for UNSTABLE_1 (except it's useful to have the division there for people upgrading from UNSTABLE_1 to UNSTABLE_2. Upgrading from 6.x to UNSTABLE_1 to UNSTABLE_2 all in one go doesn't need to be supported - same as we don't support that for sites either. Nat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081013/6e04b9c4/attachment-0001.htm From larry at garfieldtech.com Mon Oct 13 19:23:45 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Mon, 13 Oct 2008 14:23:45 -0500 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: References: Message-ID: <66b7c53eca0e6efa0132e07f34727da2@localhost> On Mon, 13 Oct 2008 18:29:06 +0100, "Nathaniel Catchpole" wrote: > On Mon, Oct 13, 2008 at 6:16 PM, G?bor Hojtsywrote: >> >> >> >> You say we should just move these sections around as if no hook_perm() >> change would have happened in UNSTABLE_1? >> >> G?bor > > > That's exactly what I mean yes. Once UNSTABLE_2 comes out, there should be > no need for specific documentation for UNSTABLE_1 (except it's useful to > have the division there for people upgrading from UNSTABLE_1 to > UNSTABLE_2. > Upgrading from 6.x to UNSTABLE_1 to UNSTABLE_2 all in one go doesn't need > to > be supported - same as we don't support that for sites either. > > Nat In principle I'd agree with Nat here. Once UNSTABLE-2 is out, there's no reason for anyone to upgrade specifically to UNSTABLE-1. They can and should "chase unstable", as that's exactly what we want them to be doing. --Larry Garfield From aldo at caonao.cu Mon Oct 13 20:32:01 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Mon, 13 Oct 2008 16:32:01 -0400 Subject: [development] webFM module and OG In-Reply-To: <200810131022.32275.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> <20081013090243.vho5cvwcqstccoo4@mail.progw.org> <200810131022.32275.aldo@caonao.cu> Message-ID: <200810131632.01534.aldo@caonao.cu> how can i show de webFM module into my OG post ?? i mean, when doing click in the webfile manager link on the Navigation menu, le result is show out of the group, may i do something for that not happen ?? thks a lot -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From michael at favias.org Tue Oct 14 00:14:13 2008 From: michael at favias.org (Michael Favia) Date: Mon, 13 Oct 2008 19:14:13 -0500 Subject: [development] webFM module and OG In-Reply-To: <200810131632.01534.aldo@caonao.cu> References: <200810121207.24757.aldo@caonao.cu> <20081013090243.vho5cvwcqstccoo4@mail.progw.org> <200810131022.32275.aldo@caonao.cu> <200810131632.01534.aldo@caonao.cu> Message-ID: <48F3E455.6070404@favias.org> Aldo Martinez Selleras wrote: > how can i show de webFM module into my OG post ?? > > i mean, when doing click in the webfile manager link on the Navigation menu, > le result is show out of the group, may i do something for that not happen ?? > This is a bit more like qa support request. Please see that modules issue queue, the appropriate mailing list, or #drupal-support for additional information. Please restrict communications on the devel list to strictly development related questions. Thanks, -mf From drupal at dwwright.net Tue Oct 14 08:00:22 2008 From: drupal at dwwright.net (Derek Wright) Date: Tue, 14 Oct 2008 01:00:22 -0700 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <66b7c53eca0e6efa0132e07f34727da2@localhost> References: <66b7c53eca0e6efa0132e07f34727da2@localhost> Message-ID: <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> On Oct 13, 2008, at 12:23 PM, Larry Garfield wrote: > They can and should "chase unstable", as that's exactly what we > want them to be doing. The point of having upgrade docs split up by UNSTABLE-N is precisely to make it easier for contrib maintainers to "chase unstable". cvs_deploy is currently ported to UNSTABLE-1. It'd be nice if I could just look somewhere and see what APIs changed between UNSTABLE-1 and UNSTABLE-2 that would require further porting to keep cvs_deploy working in UNSTABLE-2. Anyone "chasing unstable" is in the same boat. Yes, I could figure it out via reading through all the CVS log messages since UNSTABLE-1, but that's time consuming and contains a lot of noise if the signal I'm looking for are API changes that would break my module(s). Since there's no release node for UNSTABLE-2, and webchick decided not to mess with documenting these things by unstable version in CHANGELOG.txt, there's no good place to see the relevant changes since UNSTABLE-1. While we were hashing all this out in IRC, webchick suggested splitting up the module upgrade docs by UNSTABLE version, so at least there'd be somewhere (where contrib authors are looking anyway) to see all API changes between each unstable. If this high-signal info is not in CHANGELOG.txt, there's not a release node, and it's not in the upgrade docs, where do y'all propose to put it? If there's no such high-signal info anywhere, it makes "chasing unstable" more of a chore, and you can bet fewer contrib maintainers will bother. Cheers, -Derek (dww) From drupal at dwwright.net Tue Oct 14 08:07:36 2008 From: drupal at dwwright.net (Derek Wright) Date: Tue, 14 Oct 2008 01:07:36 -0700 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> References: <66b7c53eca0e6efa0132e07f34727da2@localhost> <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> Message-ID: <7624292A-E86A-4DBB-92C3-6242630654D6@dwwright.net> On Oct 14, 2008, at 1:00 AM, Derek Wright wrote: > If this high-signal info is not in CHANGELOG.txt, there's not a > release node, and it's not in the upgrade docs, where do y'all > propose to put it? p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an unstable, it'd sure suck if the upgrade docs have all been "merged" again except for unstable2 => unstable3. I don't see any value in destroying this information once we have it. If we think the upgrade docs will get too confusing if the table of contents (TOC) is organized by unstable, then we need a different solution. But we need something that preserves the high-signal info about API changes for each unstable, since we can't be sure who needs which parts of it. I don't see anything wrong with keeping the TOC organized by unstable during the entire lifecycle of unstable. Once we hit beta1, we can move the per-unstable TOC stuff to the bottom of the page as an appendix, and make a new merged TOC organized by importance or subsystem or however else people think the info should be merged for the "final" doc. Cheers, -Derek (dww) From catch56 at googlemail.com Tue Oct 14 09:26:30 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 14 Oct 2008 10:26:30 +0100 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <7624292A-E86A-4DBB-92C3-6242630654D6@dwwright.net> References: <66b7c53eca0e6efa0132e07f34727da2@localhost> <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> <7624292A-E86A-4DBB-92C3-6242630654D6@dwwright.net> Message-ID: The idea wasn't to merge everything, but it's to only keep the most recent version of any particular API. For example, hook_nodeapi just got split up, there's a chance the $a3 and $a4 arguments might get removed too. I don't see that having a single 'hook_nodeapi has changed' entry makes things any more confusing than having two separate entries with somewhat conflicting information if it's a bit different between two unstable versions. Similarly when dbtng was first committed, people were encouraged to use ? placeholders and :named placeholders interchangeably - we now only recommend :named placeholders due to query logging - surely it's better to have a single line on this than have the docs change all the way through. Same for permissions arrays getting the extra 'title' index etc. I can't think of many other things where a particular upgrade instruction would have to change between one unstable release and another - so IMO it's better to have one block of documentation in those (fairly rare) cases than two contradictory and partial ones. Everything else would still be grouped by unstable release. So far, the differences have all be pretty minor, we could always leave a note in the earlier documentation saying 'this change was subsequently revised, see below and '#issue'. Nat On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright wrote: > > On Oct 14, 2008, at 1:00 AM, Derek Wright wrote: > > If this high-signal info is not in CHANGELOG.txt, there's not a release >> node, and it's not in the upgrade docs, where do y'all propose to put it? >> > > p.s. If life swallows me whole, spits me out 3 weeks later, and I missed an > unstable, it'd sure suck if the upgrade docs have all been "merged" again > except for unstable2 => unstable3. I don't see any value in destroying this > information once we have it. If we think the upgrade docs will get too > confusing if the table of contents (TOC) is organized by unstable, then we > need a different solution. But we need something that preserves the > high-signal info about API changes for each unstable, since we can't be sure > who needs which parts of it. > > I don't see anything wrong with keeping the TOC organized by unstable > during the entire lifecycle of unstable. Once we hit beta1, we can move the > per-unstable TOC stuff to the bottom of the page as an appendix, and make a > new merged TOC organized by importance or subsystem or however else people > think the info should be merged for the "final" doc. > > Cheers, > -Derek (dww) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081014/f9804829/attachment.htm From drupal-devel at webchick.net Tue Oct 14 11:07:34 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Tue, 14 Oct 2008 07:07:34 -0400 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: References: <66b7c53eca0e6efa0132e07f34727da2@localhost> <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> <7624292A-E86A-4DBB-92C3-6242630654D6@dwwright.net> Message-ID: <48F47D76.4050209@webchick.net> Maybe I wasn't clear enough in my first response, or I'm confused by the follow-ups. I really don't think this needs to be that complicated. UNSTABLE-1: - Blah-dee-blah got a new foo thingy ... UNSTABLE-2: - Blah-dee-blah got a new bar thingy ...

Blah-dee-blah has changed

(issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it has a new FOO and a BAR thingy. Here's the before/after code: ... --- The body of the document is written for people who are not chasing stable, so that we don't need to make huge changes to it before release. The ToC is organized by unstable releases so that someone chasing HEAD can get a quick summary of the changes since the last time they updated. If they already added a foo thingy, it's pretty easy to read the code and see that they need a bar thingy too. Agreed? -Angie Nathaniel Catchpole wrote: > The idea wasn't to merge everything, but it's to only keep the most > recent version of any particular API. > > For example, hook_nodeapi just got split up, there's a chance the $a3 > and $a4 arguments might get removed too. I don't see that having a > single 'hook_nodeapi has changed' entry makes things any more confusing > than having two separate entries with somewhat conflicting information > if it's a bit different between two unstable versions. > > Similarly when dbtng was first committed, people were encouraged to use > ? placeholders and :named placeholders interchangeably - we now only > recommend :named placeholders due to query logging - surely it's better > to have a single line on this than have the docs change all the way > through. Same for permissions arrays getting the extra 'title' index etc. > > I can't think of many other things where a particular upgrade > instruction would have to change between one unstable release and > another - so IMO it's better to have one block of documentation in those > (fairly rare) cases than two contradictory and partial ones. Everything > else would still be grouped by unstable release. So far, the differences > have all be pretty minor, we could always leave a note in the earlier > documentation saying 'this change was subsequently revised, see below > and '#issue'. > > Nat > > On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright > wrote: > > > On Oct 14, 2008, at 1:00 AM, Derek Wright wrote: > > If this high-signal info is not in CHANGELOG.txt, there's not a > release node, and it's not in the upgrade docs, where do y'all > propose to put it? > > > p.s. If life swallows me whole, spits me out 3 weeks later, and I > missed an unstable, it'd sure suck if the upgrade docs have all been > "merged" again except for unstable2 => unstable3. I don't see any > value in destroying this information once we have it. If we think > the upgrade docs will get too confusing if the table of contents > (TOC) is organized by unstable, then we need a different solution. > But we need something that preserves the high-signal info about API > changes for each unstable, since we can't be sure who needs which > parts of it. > > I don't see anything wrong with keeping the TOC organized by > unstable during the entire lifecycle of unstable. Once we hit > beta1, we can move the per-unstable TOC stuff to the bottom of the > page as an appendix, and make a new merged TOC organized by > importance or subsystem or however else people think the info should > be merged for the "final" doc. > > Cheers, > -Derek (dww) > > > > From catch56 at googlemail.com Tue Oct 14 11:37:23 2008 From: catch56 at googlemail.com (Nathaniel Catchpole) Date: Tue, 14 Oct 2008 12:37:23 +0100 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: <48F47D76.4050209@webchick.net> References: <66b7c53eca0e6efa0132e07f34727da2@localhost> <7FB55BD4-A32B-4D47-8529-4808072CFEFA@dwwright.net> <7624292A-E86A-4DBB-92C3-6242630654D6@dwwright.net> <48F47D76.4050209@webchick.net> Message-ID: Yeah, that's what I meant, thanks for putting it so clearly :) Nat On Tue, Oct 14, 2008 at 12:07 PM, Angela Byron wrote: > > > Maybe I wasn't clear enough in my first response, or I'm confused by the > follow-ups. I really don't think this needs to be that complicated. > > UNSTABLE-1: > - Blah-dee-blah got a new foo thingy > ... > > UNSTABLE-2: > - Blah-dee-blah got a new bar thingy > ... > >

Blah-dee-blah has changed

> > (issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it > has a new FOO and a BAR thingy. Here's the before/after code: > > ... > > --- > > > The body of the document is written for people who are not chasing stable, > so that we don't need to make huge changes to it before release. The ToC is > organized by unstable releases so that someone chasing HEAD can get a quick > summary of the changes since the last time they updated. If they already > added a foo thingy, it's pretty easy to read the code and see that they need > a bar thingy too. > > Agreed? > > -Angie > > > Nathaniel Catchpole wrote: > >> The idea wasn't to merge everything, but it's to only keep the most recent >> version of any particular API. >> >> For example, hook_nodeapi just got split up, there's a chance the $a3 and >> $a4 arguments might get removed too. I don't see that having a single >> 'hook_nodeapi has changed' entry makes things any more confusing than having >> two separate entries with somewhat conflicting information if it's a bit >> different between two unstable versions. >> >> Similarly when dbtng was first committed, people were encouraged to use ? >> placeholders and :named placeholders interchangeably - we now only recommend >> :named placeholders due to query logging - surely it's better to have a >> single line on this than have the docs change all the way through. Same for >> permissions arrays getting the extra 'title' index etc. >> >> I can't think of many other things where a particular upgrade instruction >> would have to change between one unstable release and another - so IMO it's >> better to have one block of documentation in those (fairly rare) cases than >> two contradictory and partial ones. Everything else would still be grouped >> by unstable release. So far, the differences have all be pretty minor, we >> could always leave a note in the earlier documentation saying 'this change >> was subsequently revised, see below and '#issue'. >> > > >> Nat >> >> On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright wrote: >> >> >> On Oct 14, 2008, at 1:00 AM, Derek Wright wrote: >> >> If this high-signal info is not in CHANGELOG.txt, there's not a >> release node, and it's not in the upgrade docs, where do y'all >> propose to put it? >> >> >> p.s. If life swallows me whole, spits me out 3 weeks later, and I >> missed an unstable, it'd sure suck if the upgrade docs have all been >> "merged" again except for unstable2 => unstable3. I don't see any >> value in destroying this information once we have it. If we think >> the upgrade docs will get too confusing if the table of contents >> (TOC) is organized by unstable, then we need a different solution. >> But we need something that preserves the high-signal info about API >> changes for each unstable, since we can't be sure who needs which >> parts of it. >> >> I don't see anything wrong with keeping the TOC organized by >> unstable during the entire lifecycle of unstable. Once we hit >> beta1, we can move the per-unstable TOC stuff to the bottom of the >> page as an appendix, and make a new merged TOC organized by >> importance or subsystem or however else people think the info should >> be merged for the "final" doc. >> >> Cheers, >> -Derek (dww) >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081014/91c8fecc/attachment.htm From lynniecollins at gmail.com Tue Oct 14 16:19:33 2008 From: lynniecollins at gmail.com (lynne collins) Date: Tue, 14 Oct 2008 09:19:33 -0700 Subject: [development] Manager of Web Properties, The Linux Foundation (SF or remote/US) In-Reply-To: Message-ID: Hello, I?m sharing this search for a Manager of Web Properties for the Linux Foundation (San Francisco or *remote/US). The Linux Foundation (http://www.linuxfoundation.org) is a very prestigious nonprofit consortium dedicated to fostering the growth of Linux. It sponsors the work of Linux creator Linus Torvalds. The Linux Foundation gets millions of visitors to its Web properties every year, wants to take its Web presence to the next level of creativity and collaboration, and is evolving to become more of a media site. We?re looking for a creative, responsible leader who can: * help build sites to reach the right audiences and communicate the right message; * both develop and manage external developers; and * provide a well architected, accessible and usable web presence to facilitate collaboration for the members of the Linux and open source communities. This technical, hands-on Web designer/developer will be responsible for managing all of the Linux Foundation?s Web properties. The ideal candidate brings a passion for Linux, a solid track record for building and delivering attractive and useful Web sites (*Drupal experience is required*), and the flexibility to lead both as an individual contributor and manager of external resources. This is a high-profile opportunity that will make a big impact on the world of Linux users and developers. S/he will also gain exposure to influential supporters and developers of the Linux platform. Additional perks are exceptional benefits and the freedom/flexibility to work remotely, if desired. Required Skills: 5+ years experience and a proven portfolio of web sites you've designed and help build Content Management Systems Drupal Mediawiki CRM CiviCRM SugarCRM Bugzilla LAMP stack Usability Information Architecture Open source tools Linux development environment Image manipulation PHP Perl HTML/CSS Founded in 2007, the Linux Foundation sponsors the work of Linux creator Linus Torvalds and is supported by leading Linux and open source companies and developers from around the world. The Linux Foundation promotes, protects and standardizes Linux by providing unified resources and services needed for open source to successfully compete with closed platforms. Contact Information: Lynne Collins Senior Technology Recruiter M: (415) 306-6778 | O: (415) 785-4446 E: lynniecollins at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081014/d1d9b72e/attachment.htm From larry at garfieldtech.com Wed Oct 15 06:45:58 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Wed, 15 Oct 2008 01:45:58 -0500 Subject: [development] Announcing DRUPAL-7-0-UNSTABLE-2 In-Reply-To: References: <48F47D76.4050209@webchick.net> Message-ID: <200810150145.58365.larry@garfieldtech.com> Only in Drupal would "blah-dee-blah" be "putting it so clearly". :-) That said, what webchick says below (when she's supposed to be on vacation) makes sense. My point earlier wasn't that we shouldn't split the TOC by unstable tag, but that once unstable-2 is out, we really shouldn't expect anyone to *then* port anything to unstable-1. We want them to be going to unstable-2. Also, for the record, ? for DB placeholders was considered bad form (at least by me) even before DBTNG was committed as it is less self-documenting. Although the code does not currently forbid it, ? was not included in any of the documentation for DBTNG since, um, the original Barcelona presentation a year ago. :-) Certainly never in anything official. On Tuesday 14 October 2008 6:37:23 am Nathaniel Catchpole wrote: > Yeah, that's what I meant, thanks for putting it so clearly :) > > Nat > > On Tue, Oct 14, 2008 at 12:07 PM, Angela Byron wrote: > > Maybe I wasn't clear enough in my first response, or I'm confused by the > > follow-ups. I really don't think this needs to be that complicated. > > > > UNSTABLE-1: > > - Blah-dee-blah got a new foo thingy > > ... > > > > UNSTABLE-2: > > - Blah-dee-blah got a new bar thingy > > ... > > > >

Blah-dee-blah has changed

> > > > (issue) and (issue) Blah-dee-blah has changed since Drupal 6, in that it > > has a new FOO and a BAR thingy. Here's the before/after code: > > > > ... > > > > --- > > > > > > The body of the document is written for people who are not chasing > > stable, so that we don't need to make huge changes to it before release. > > The ToC is organized by unstable releases so that someone chasing HEAD > > can get a quick summary of the changes since the last time they updated. > > If they already added a foo thingy, it's pretty easy to read the code and > > see that they need a bar thingy too. > > > > Agreed? > > > > -Angie > > > > Nathaniel Catchpole wrote: > >> The idea wasn't to merge everything, but it's to only keep the most > >> recent version of any particular API. > >> > >> For example, hook_nodeapi just got split up, there's a chance the $a3 > >> and $a4 arguments might get removed too. I don't see that having a > >> single 'hook_nodeapi has changed' entry makes things any more confusing > >> than having two separate entries with somewhat conflicting information > >> if it's a bit different between two unstable versions. > >> > >> Similarly when dbtng was first committed, people were encouraged to use > >> ? placeholders and :named placeholders interchangeably - we now only > >> recommend > >> > >> :named placeholders due to query logging - surely it's better to have a > >> > >> single line on this than have the docs change all the way through. Same > >> for permissions arrays getting the extra 'title' index etc. > >> > >> I can't think of many other things where a particular upgrade > >> instruction would have to change between one unstable release and > >> another - so IMO it's better to have one block of documentation in those > >> (fairly rare) cases than two contradictory and partial ones. Everything > >> else would still be grouped by unstable release. So far, the differences > >> have all be pretty minor, we could always leave a note in the earlier > >> documentation saying 'this change was subsequently revised, see below > >> and '#issue'. > >> > >> > >> > >> Nat > >> > >> On Tue, Oct 14, 2008 at 9:07 AM, Derek Wright wrote: > >> > >> > >> On Oct 14, 2008, at 1:00 AM, Derek Wright wrote: > >> > >> If this high-signal info is not in CHANGELOG.txt, there's not a > >> release node, and it's not in the upgrade docs, where do y'all > >> propose to put it? > >> > >> > >> p.s. If life swallows me whole, spits me out 3 weeks later, and I > >> missed an unstable, it'd sure suck if the upgrade docs have all been > >> "merged" again except for unstable2 => unstable3. I don't see any > >> value in destroying this information once we have it. If we think > >> the upgrade docs will get too confusing if the table of contents > >> (TOC) is organized by unstable, then we need a different solution. > >> But we need something that preserves the high-signal info about API > >> changes for each unstable, since we can't be sure who needs which > >> parts of it. > >> > >> I don't see anything wrong with keeping the TOC organized by > >> unstable during the entire lifecycle of unstable. Once we hit > >> beta1, we can move the per-unstable TOC stuff to the bottom of the > >> page as an appendix, and make a new merged TOC organized by > >> importance or subsystem or however else people think the info should > >> be merged for the "final" doc. > >> > >> Cheers, > >> -Derek (dww) -- Larry Garfield larry at garfieldtech.com From victorkane at gmail.com Thu Oct 16 00:44:52 2008 From: victorkane at gmail.com (Victor Kane) Date: Wed, 15 Oct 2008 21:44:52 -0300 Subject: [development] Josh Koenig to take up the slack with the Salesforce module Message-ID: I first published the Salesforce module based on Steve McKenzie's Sandbox code due to the fact that I had a client (helpargentina.org) who needed integration with Salesforce, and naturally I thought the quality and maintainability of the software would be much better served by an open project that interested members of the community participated in. That was true then and it is true now, when it is Josh Koenig who is working on a project and has a great store of ideas and needs with which to update and stabilize the module and make it more flexible and powerful. Since due to other commitments I have been unable to give much love at all to this module in quite some time, there is no doubt in my mind that the best thing for the community and all concerned is for Josh to dive right into direct maintenance of the module, to which he has now been granted CVS access. I am sure Josh will be announcing his Road Map soon. Others have contributed a lot also, bringing to the discussion a lot of useful ideas and code, in connection with this module which is so hard to abstract from project-specific needs, notably Benjamin Melan?on and Tom Friedhof. Go Drupal! Victor Kane http://awebfactory.com.ar From josh at chapterthree.com Thu Oct 16 18:24:25 2008 From: josh at chapterthree.com (Josh Koenig) Date: Thu, 16 Oct 2008 11:24:25 -0700 Subject: [development] Maintaining Boost? In-Reply-To: References: Message-ID: <8F6F1C47-07D4-46CB-B0C4-8D32CCE273C4@chapterthree.com> As long as I'm on a roll... Since Victor mentioned I'm taking on the Salesforce module, I wanted to know if anyone knew how to contact Arto Bendekin, the maintainer of Boost? I've been using it a lot lately, and think it has huge potential to help Drupal for midrange sites that are getting a fair amount of traffic, but lack the resources to move to high-grade hosting. Basically, it's the poor man's squid, and this can help out businesses and organizations that have VPS-grade hosting but still need to withstand high sustained traffic from anonymous users. I'd like to maintain some updates and get a 6.0 release out, but Arto's contact tab is disabled. Arto: if you're out there, I wanna help! :) cheers -josh From cxjohnson at gmail.com Thu Oct 16 20:03:58 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Thu, 16 Oct 2008 15:03:58 -0500 Subject: [development] Maintaining Boost? In-Reply-To: <8F6F1C47-07D4-46CB-B0C4-8D32CCE273C4@chapterthree.com> References: <8F6F1C47-07D4-46CB-B0C4-8D32CCE273C4@chapterthree.com> Message-ID: <9ea8d6030810161303s373ba972pf441c8d940db93ad@mail.gmail.com> I forwarded your message to him. I'll make sure he gives you a reply very soon. ..chris On Thu, Oct 16, 2008 at 1:24 PM, Josh Koenig wrote: > > As long as I'm on a roll... > > Since Victor mentioned I'm taking on the Salesforce module, I wanted to > know if anyone knew how to contact Arto Bendekin, the maintainer of Boost? > > I've been using it a lot lately, and think it has huge potential to help > Drupal for midrange sites that are getting a fair amount of traffic, but > lack the resources to move to high-grade hosting. Basically, it's the poor > man's squid, and this can help out businesses and organizations that have > VPS-grade hosting but still need to withstand high sustained traffic from > anonymous users. > > I'd like to maintain some updates and get a 6.0 release out, but Arto's > contact tab is disabled. > > Arto: if you're out there, I wanna help! :) > > cheers > -josh > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081016/f5ac37ae/attachment.htm From pwgdarchive at gmail.com Fri Oct 17 08:05:04 2008 From: pwgdarchive at gmail.com (=?ISO-8859-1?Q?Benjamin_Melan=E7on?=) Date: Fri, 17 Oct 2008 04:05:04 -0400 Subject: [development] Josh Koenig to take up the slack with the Salesforce module In-Reply-To: References: Message-ID: <1406bb8f0810170105v786ae953o4dc040dc1e83f9d9@mail.gmail.com> Hi all, My Salesforce code, which I sent to Victor for review and possible release as Salesforce 2.x, isn't otherwise released, and hasn't been added to the project yet as far as I know. But Josh, it's all yours! Our (Agaric Design Collective's) client is coming back for a second Salesforce-integrated site, so we'll be able to help out some more. All Agaric's contributions involved improving the website to Salesforce direction. We didn't need to sync data from Salesforce back to Drupal, so I merely tried not to break that while refactoring the code. Main contribution: we created something of an API module for allowing other modules to provide ways of getting information to Salesforce, and an interface for mapping those fields to elements of Salesforce objects. We then developed a fieldmapping module to match any Webform field to Salesforce fields. Important caveat to anyone considering Salesforce: our integration at least relies on the Salesforce API, which costs a whole lot of money for companies to access, and I'm a bit embittered by Salesforce's complete lack of response to the point that a tool like Drupal means APIs aren't just for the big players anymore. (See http://ideas.salesforce.com/article/show/24160 ) Oh, and for free software contact management, CiviCRM and its Drupal integration http://civicrm.org are looking awesome! benjamin Agaric Design Collective Open Source Free Software Web Development http://agaricdesign.com/ 774-286-1770 From victorkane at gmail.com Fri Oct 17 08:21:10 2008 From: victorkane at gmail.com (Victor Kane) Date: Fri, 17 Oct 2008 05:21:10 -0300 Subject: [development] Josh Koenig to take up the slack with the Salesforce module In-Reply-To: <1406bb8f0810170105v786ae953o4dc040dc1e83f9d9@mail.gmail.com> References: <1406bb8f0810170105v786ae953o4dc040dc1e83f9d9@mail.gmail.com> Message-ID: On Fri, Oct 17, 2008 at 5:05 AM, Benjamin Melan?on wrote: > Hi all, > > My Salesforce code, which I sent to Victor for review and possible > release as Salesforce 2.x, isn't otherwise released, and hasn't been > added to the project yet as far as I know. But Josh, it's all yours! Awesome. Benjamin, send Josh the latest version of your code, just to be sure. I am also sending Josh a version I developed that persists Salesforce data onto the nodeprofile module instead of the core profile module, that I developed for a client but could never commit because doing so requires the more flexible API we have all been discussing which allows you to choose your form of (poison) persistence. Victor > Our (Agaric Design Collective's) client is coming back for a second > Salesforce-integrated site, so we'll be able to help out some more. > > All Agaric's contributions involved improving the website to > Salesforce direction. We didn't need to sync data from Salesforce > back to Drupal, so I merely tried not to break that while refactoring > the code. > > Main contribution: we created something of an API module for allowing > other modules to provide ways of getting information to Salesforce, > and an interface for mapping those fields to elements of Salesforce > objects. > > We then developed a fieldmapping module to match any Webform field to > Salesforce fields. > > Important caveat to anyone considering Salesforce: our integration at > least relies on the Salesforce API, which costs a whole lot of money > for companies to access, and I'm a bit embittered by Salesforce's > complete lack of response to the point that a tool like Drupal means > APIs aren't just for the big players anymore. (See > http://ideas.salesforce.com/article/show/24160 ) Oh, and for free > software contact management, CiviCRM and its Drupal integration > http://civicrm.org are looking awesome! > > benjamin > > Agaric Design Collective > Open Source Free Software Web Development > http://agaricdesign.com/ > 774-286-1770 > From drupal at dave-cohen.com Fri Oct 17 18:42:13 2008 From: drupal at dave-cohen.com (Dave Cohen) Date: Fri, 17 Oct 2008 11:42:13 -0700 Subject: [development] session questions Message-ID: <200810171142.14133.drupal@dave-cohen.com> Hi, I'm hoping someone understands sessions better than I do and can help me out. I'm noticing different behavior across browsers and I'm having trouble groking it. I'm serving a page with a form, and that form has an autocomplete field. So my drupal gets an initial request for the page, then subsequent requests for the autocomplete callback. I'm testing with Firefox and IE right now, and here's what I observe.... 1) Across all browsers and requests, the session_name() is the same. I believe this is because drupal computes a session name in conf_init(). The name depends on the URL only and not the browser. Am I correct so far? 2) From Firefox, the initial page request and subsequent autocomplete callbacks have the same session_name AND session_id. In other words the session cookie's name and value remain the same. The effect of this is that $_SESSION is shared between the normal page request and the ajax requests. 3) From IE7, the session_name remains the same across all requests, but the session_id() of the initial page request is different from the ajax callbacks. In other words the session cookie's value changes. So $_SESSION is not shared. Is this what I should be seeing? 4) Also from IE7, the session_id is new for ajax callbacks, yet drupal somehow knows which user is logged in. That is $_SESSION is not shared with the original page request, but the global $user is set correctly. How is this happening? Doesn't Drupal rely on the session_id to determine the user? Since session_id has changed shouldn't drupal think the ajax request is anonymous? Is what I'm seeing the way things are supposed to be, or have I somehow screwed up my install? Thanks, -Dave From weitzman at tejasa.com Fri Oct 17 18:47:03 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Fri, 17 Oct 2008 14:47:03 -0400 Subject: [development] session questions In-Reply-To: <200810171142.14133.drupal@dave-cohen.com> References: <200810171142.14133.drupal@dave-cohen.com> Message-ID: <6117a7500810171147p49473560p18e5a15387b3d910@mail.gmail.com> > 3) From IE7, the session_name remains the same across all requests, but the > session_id() of the initial page request is different from the ajax callbacks. > In other words the session cookie's value changes. So $_SESSION is not > shared. Is this what I should be seeing? No. Browser's have a responsibility to always send back cookies to the domain+path that sent them. So if your ajax callback is sent back to the same domain and path as the session cookie, it has to be sent back. check the domain and path of the cookie and ajax callback carefully. You can control what path/domain the cookie gets set on using settings.php (see the comments there). Note that changing that can affect existing user's and their cookies. > > 4) Also from IE7, the session_id is new for ajax callbacks, yet drupal somehow > knows which user is logged in. That is $_SESSION is not shared with the > original page request, but the global $user is set correctly. How is this > happening? Doesn't Drupal rely on the session_id to determine the user? > Since session_id has changed shouldn't drupal think the ajax request is > anonymous? > > Is what I'm seeing the way things are supposed to be, or have I somehow > screwed up my install? > Screwed up install, or browser, or other. From weitzman at tejasa.com Fri Oct 17 18:47:03 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Fri, 17 Oct 2008 14:47:03 -0400 Subject: [development] session questions In-Reply-To: <200810171142.14133.drupal@dave-cohen.com> References: <200810171142.14133.drupal@dave-cohen.com> Message-ID: <6117a7500810171147p49473560p18e5a15387b3d910@mail.gmail.com> > 3) From IE7, the session_name remains the same across all requests, but the > session_id() of the initial page request is different from the ajax callbacks. > In other words the session cookie's value changes. So $_SESSION is not > shared. Is this what I should be seeing? No. Browser's have a responsibility to always send back cookies to the domain+path that sent them. So if your ajax callback is sent back to the same domain and path as the session cookie, it has to be sent back. check the domain and path of the cookie and ajax callback carefully. You can control what path/domain the cookie gets set on using settings.php (see the comments there). Note that changing that can affect existing user's and their cookies. > > 4) Also from IE7, the session_id is new for ajax callbacks, yet drupal somehow > knows which user is logged in. That is $_SESSION is not shared with the > original page request, but the global $user is set correctly. How is this > happening? Doesn't Drupal rely on the session_id to determine the user? > Since session_id has changed shouldn't drupal think the ajax request is > anonymous? > > Is what I'm seeing the way things are supposed to be, or have I somehow > screwed up my install? > Screwed up install, or browser, or other. From drupal at dave-cohen.com Sat Oct 18 00:26:35 2008 From: drupal at dave-cohen.com (Dave Cohen) Date: Fri, 17 Oct 2008 17:26:35 -0700 Subject: [development] session questions In-Reply-To: <6117a7500810171147p49473560p18e5a15387b3d910@mail.gmail.com> References: <200810171142.14133.drupal@dave-cohen.com> <6117a7500810171147p49473560p18e5a15387b3d910@mail.gmail.com> Message-ID: <200810171726.35323.drupal@dave-cohen.com> Moshe and all, Thanks for the clarification, you're correct that's how it should behave. The truth is I was mucking with the session_name() and session_id(). I find that if I don't muck, then the cookies are consistent even in IE. However, I have a good reason to muck with these values. I'm serving pages both on a regular website, and also in Facebook canvas pages (using iframes). I don't want the Facebook iframes to share session state with the normal web pages. So I call session_name() and session_id() with custom values. I do this in settings.php, before drupal calls session_start(). According to the PHP documentation, when session_start() is called, updated cookies are supposed to be sent. On reasonable browsers like Firefox this works as advertised. On IE, a cookie is set whose name is session_name(), but its value is not session_id(). I don't know where it's getting the value from. Has anyone else encountered this? Any ideas how to debug it? I'm looking for anything here as I really don't know how to diagnose problems with IE. -Dave On Friday 17 October 2008 11:47:03 Moshe Weitzman wrote: > > 3) From IE7, the session_name remains the same across all requests, but > > the session_id() of the initial page request is different from the ajax > > callbacks. In other words the session cookie's value changes. So > > $_SESSION is not shared. Is this what I should be seeing? > > No. Browser's have a responsibility to always send back cookies to the > domain+path that sent them. So if your ajax callback is sent back to > the same domain and path as the session cookie, it has to be sent > back. check the domain and path of the cookie and ajax callback > carefully. You can control what path/domain the cookie gets set on > using settings.php (see the comments there). Note that changing that > can affect existing user's and their cookies. > [snip] > > Screwed up install, or browser, or other. From drupal at dave-cohen.com Mon Oct 20 18:48:30 2008 From: drupal at dave-cohen.com (David Cohen) Date: Mon, 20 Oct 2008 11:48:30 -0700 Subject: [development] session questions - SOLVED In-Reply-To: <200810171726.35323.drupal@dave-cohen.com> References: <200810171142.14133.drupal@dave-cohen.com> <6117a7500810171147p49473560p18e5a15387b3d910@mail.gmail.com> <200810171726.35323.drupal@dave-cohen.com> Message-ID: <1224528510.17107.1280285897@webmail.messagingengine.com> My session problem on IE... The page in question was an iframe, and apparently IE is not inclined to send back cookies to iframes. Fun! I found what appears to be a solution here: http://james.jamesandkristin.net/2005/11/18/php-session-cookie-in-frames-using-internet-explorer On Fri, 17 Oct 2008 17:26:35 -0700, "Dave Cohen" said: > Moshe and all, > > Thanks for the clarification, you're correct that's how it should behave. > The > truth is I was mucking with the session_name() and session_id(). I find > that > if I don't muck, then the cookies are consistent even in IE. > > However, I have a good reason to muck with these values. I'm serving > pages > both on a regular website, and also in Facebook canvas pages (using > iframes). > I don't want the Facebook iframes to share session state with the normal > web > pages. > ... From drupal at rocktreesky.com Mon Oct 20 23:31:16 2008 From: drupal at rocktreesky.com (Addison Berry) Date: Mon, 20 Oct 2008 19:31:16 -0400 Subject: [development] Modules free to good home Message-ID: <18D627A3-3D73-4F82-97CE-0B0ACD1363FB@rocktreesky.com> I don't have many modules under my care but now that I consider the docs queue my responsibility, I've enough queue work to keep me busy. :-) I'd like to find good caretakers for a few of my modules to lighten the load a bit. If you are interested in either being a co- maintainer or taking over maintenance altogether, please let me know off list (email or contact page http://drupal.org/user/65088/contact). I'm willing to sit in and help answer questions and guide if there are folks that feel like they want to dip into maintaining but still aren't confident - so a good opportunity to get your feet wet, if you are so inclined. I just can't carry the load of development and regular queue maintenance anymore. Modules that need good kibble and a warm, safe bed at night: Nice menus: http://drupal.org/project/nice_menus Prepopulate: http://drupal.org/project/prepopulate Comment Mail: http://drupal.org/project/commentmail - Addi (add1sun) -------------------------------------- Join us at Do It With Drupal! A large scale, curated education event December 10-12, New Orleans http://www.doitwithdrupal.com From kevin at kevincdavis.net Tue Oct 21 01:29:46 2008 From: kevin at kevincdavis.net (Kevin Davis) Date: Mon, 20 Oct 2008 18:29:46 -0700 (PDT) Subject: [development] (no subject) Message-ID: <83799.16561.qm@web1115.biz.mail.sk1.yahoo.com> Hello, I would like to know how to pass variables or information between on form in drupal to another form in drupal. Kevin From mike at mikeyp.net Tue Oct 21 03:05:29 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Mon, 20 Oct 2008 20:05:29 -0700 Subject: [development] Unsetting form values on validate Message-ID: I am building a directory listing type site and trying to keep all my listings in one node type. There are different options for the types of listings available, and I am using some javascript to show/hide forms on the node/add page. I am also doing quite a bit of validation from hook_nodeapi, of individual field formatting, and so on. One of the things I'd like to be able to do, is upon validation of the node, throw out any form values that do not match the type of listing they have chosen (so that the values won't be shown on the node preview, for example). What is the best way to go about this? I see that in my hook_nodeapi under the validate op, I am getting the node, and the $form itself, not $form_state or $form_values. The submitted data that I wish to discard is in both the $node object, and the $form array under #post among other places. Drupal 6.x btw. -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From andrewberry at sentex.net Tue Oct 21 04:29:29 2008 From: andrewberry at sentex.net (Andrew Berry) Date: Tue, 21 Oct 2008 00:29:29 -0400 Subject: [development] Unsetting form values on validate In-Reply-To: References: Message-ID: <15F76B9D-5288-49E4-93E7-1754F64A09FB@sentex.net> On 20-Oct-08, at 11:05 PM, Michael Prasuhn wrote: > I am building a directory listing type site and trying to keep all > my listings in one node type. I'm curious as to why CCK with a bunch of optional fields doesn't work for this. Could you not do a bit of custom PHP to validate fields within CCK? > One of the things I'd like to be able to do, is upon validation of > the node, throw out any form values that do not match the type of > listing they have chosen (so that the values won't be shown on the > node preview, for example). I don't think that's really the purpose of the validation hook. Typically, you should throw errors with form_set_error() to indicate why the data submitted is invalid. Even if you could make it work, I would think you'd have some pretty confused users wondering where their data went, thinking that the preview or the site was broken. > What is the best way to go about this? Perhaps presave, or prepare hooks could do it? But based on the information you've given, I really think this is a solution for multiple content types + CCK. HTH, --Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2692 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081021/ec766c6d/attachment.bin From drupal at dwwright.net Tue Oct 21 06:21:43 2008 From: drupal at dwwright.net (Derek Wright) Date: Mon, 20 Oct 2008 23:21:43 -0700 Subject: [development] Unsetting form values on validate In-Reply-To: References: Message-ID: On Oct 20, 2008, at 8:05 PM, Michael Prasuhn wrote: > I see that in my hook_nodeapi under the validate op, I am getting > the node, and the $form itself, not $form_state or $form_values. That's because of this critical bug in the D6 API: http://drupal.org/node/241364 "hook_validate() doesn't get $form_state passed to it" Sadly, since that'd be a pretty major API change in a supposedly stable release series of core, it's probably not going to be fixed. : ( But, it makes hook_nodeapi() quite useless in many cases, and has caused (and will continue to cause) all sorts of grief for a variety of modules. Tragically, no one noticed until after 6.0 was out. The current work-around is to form_alter() and add your own #validate handler, which *does* get a copy of $form_state as nature intended. Arguably, that's cleaner than using hook_nodeapi() in the first place, but then what's the point of having hook_nodeapi('validate') at all? This is yet another good anecdote to encourage contrib maintainers to make heavy use of the UNSTABLE-N tags that webchick is making from D7 core, so that we flesh out broken parts of the API before it's too late to fix them. Meanwhile, it'd be nice if Gabor and/or Dries would weigh in on #241364 and indicate if it's a D7 only issue, or if we should attempt to make a solution for D6, too. So far, none of the core maintainers (or major contributors, for that matter) have participated in that issue. Cheers, -Derek (dww) From adrian at bryght.com Tue Oct 21 06:13:10 2008 From: adrian at bryght.com (Adrian Rossouw) Date: Tue, 21 Oct 2008 08:13:10 +0200 Subject: [development] Unsetting form values on validate In-Reply-To: <15F76B9D-5288-49E4-93E7-1754F64A09FB@sentex.net> References: <15F76B9D-5288-49E4-93E7-1754F64A09FB@sentex.net> Message-ID: <61E19706-9835-47AF-969A-73C0B22099FA@bryght.com> On 21 Oct 2008, at 6:29 AM, Andrew Berry wrote: > I'm curious as to why CCK with a bunch of optional fields doesn't > work for this. Could you not do a bit of custom PHP to validate > fields within CCK? because sometimes there is a lot of overhead that comes with cck that you don't really need. and you spend more time working against what cck gives you by default than you do just writing it yourself and the dependencies for your module explode making upgrades a lot messier Anyway, to answer the question, i know in d4.7/d5 you could do form_set_value('field][field', 'value') to set fields in the validate functions, i don't know if in D6 you can just modify the $form_state. From cxjohnson at gmail.com Tue Oct 21 13:06:27 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 21 Oct 2008 08:06:27 -0500 Subject: [development] Unsetting form values on validate In-Reply-To: References: Message-ID: <9ea8d6030810210606v37ad0627x8a2a6cc126b7d91f@mail.gmail.com> Seems like the lack of functionality of hook_nodeapi('validate') should be documented in the D6 and FAPI docs in BIG BOLD LETTERS. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081021/91d57d32/attachment-0001.htm From drewish at katherinehouse.com Tue Oct 21 15:41:48 2008 From: drewish at katherinehouse.com (andrew morton) Date: Tue, 21 Oct 2008 08:41:48 -0700 Subject: [development] Unsetting form values on validate In-Reply-To: <9ea8d6030810210606v37ad0627x8a2a6cc126b7d91f@mail.gmail.com> References: <9ea8d6030810210606v37ad0627x8a2a6cc126b7d91f@mail.gmail.com> Message-ID: On Tue, Oct 21, 2008 at 6:06 AM, Chris Johnson wrote: > Seems like the lack of functionality of hook_nodeapi('validate') should be > documented in the D6 and FAPI docs in BIG BOLD LETTERS. I think you meant to say the problem with hook_validate(). I'll also throw out the reminder that anyone with a CVS account can make corrections to the docs. andrew From mike at mikeyp.net Tue Oct 21 19:45:22 2008 From: mike at mikeyp.net (Michael Prasuhn) Date: Tue, 21 Oct 2008 12:45:22 -0700 Subject: [development] Unsetting form values on validate In-Reply-To: <15F76B9D-5288-49E4-93E7-1754F64A09FB@sentex.net> References: <15F76B9D-5288-49E4-93E7-1754F64A09FB@sentex.net> Message-ID: <2E791E1E-C22E-41E0-8CF7-715E0AF2E03B@mikeyp.net> On Oct 20, 2008, at 9:29 PM, Andrew Berry wrote: > I'm curious as to why CCK with a bunch of optional fields doesn't > work for this. Could you not do a bit of custom PHP to validate > fields within CCK? I am using CCK fields. This application requires the use of conditionally required/available fields. In order to make this work reliably, I am discarding data submitted for unavailable fields on validation, instead of trying to validate a field that doesn't correspond to the listing type. On Oct 20, 2008, at 11:21 PM, Derek Wright wrote: > That's because of this critical bug in the D6 API: > > http://drupal.org/node/241364 > "hook_validate() doesn't get $form_state passed to it" > > Sadly, since that'd be a pretty major API change in a supposedly > stable release series of core, it's probably not going to be fixed. : > ( But, it makes hook_nodeapi() quite useless in many cases, and has > caused (and will continue to cause) all sorts of grief for a variety > of modules. Tragically, no one noticed until after 6.0 was out. > The current work-around is to form_alter() and add your own > #validate handler, which *does* get a copy of $form_state as nature > intended. Arguably, that's cleaner than using hook_nodeapi() in the > first place, but then what's the point of having > hook_nodeapi('validate') at all? I suppose whether or not $form_state should be in hook_nodeapi('validate') is debatable. I can see the utility of it here, yet I can see the argument that it is a misuse of hook_nodeapi, as it really has nothing to do with the node object itself, but the form. Thanks for the suggestion with the custom validation function. On Oct 20, 2008, at 11:13 PM, Adrian Rossouw wrote: > Anyway, to answer the question, i know in d4.7/d5 you could do > form_set_value('field][field', 'value') to set fields > in the validate functions, i don't know if in D6 you can just modify > the $form_state. This would be ideal, however in D6 the $form_state is a required parameter of form_set_value() and the absence of $form_state in hook_nodeapi('validate') is the problem I was running into. Derek's suggestion of adding my own validation with hook_form_alter() makes the most sense, as it will pass $form_state to my function. -Mike __________________ Michael Prasuhn mike at mikeyp.net http://mikeyp.net From sysop at scbbs.com Fri Oct 24 02:13:33 2008 From: sysop at scbbs.com (Ron Parker) Date: Thu, 23 Oct 2008 19:13:33 -0700 (PDT) Subject: [development] Has anything changed with module_invoke() recently? Message-ID: <9391720.15351224814412990.JavaMail.root@zimbra.thefiengroup.com> Regarding Drupal 6.x. Running core Drupal with og, og_user_roles and tac_lite. I am dynamically creating roles and adding them to the $user object in hook_boot and hook_user('load') (and several other places). The $user object contains the roles that the user needs to create content for the node $type in the example below (I have verified that). Theoretically, module_invoke below should not return false, but it is: roles before this is called $access = module_invoke ( $module , 'access' , 'create' , $type , $user ); // and, afterwards. They are exactly what they should be to allow this // this user access to this content ... ?> $access is FALSE. What happens in module_invoke where it would override the roles in the $user object? This same exact code worked in 5.x, so I have to believe there is something that has changed in 6.x with module_invoke() / $user . Furthermore, this code worked in the initial Drupal 6.x versions, so this change, whatever it is, is rather recent. Any ideas, whatsoever? Thanks! -ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081023/f75846b7/attachment.htm From nan_wich at bellsouth.net Fri Oct 24 03:53:02 2008 From: nan_wich at bellsouth.net (Nancy Wichmann) Date: Thu, 23 Oct 2008 23:53:02 -0400 Subject: [development] Has anything changed with module_invoke() recently? In-Reply-To: <9391720.15351224814412990.JavaMail.root@zimbra.thefiengroup.com> Message-ID: Ron Parker said: "Theoretically, module_invoke below should not return false, but it is" I have recently run into problems with hook_access. It is widely misunderstood and many module return false when they really should be returning null. I even had to change many of my modules. I know there are many out there that are still wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081023/641e0a0b/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: multipart/alternative Size: 0 bytes Desc: not available Url : http://lists.drupal.org/pipermail/development/attachments/20081023/641e0a0b/attachment.bin -------------- next part -------------- No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.2/1741 - Release Date: 10/23/2008 7:54 AM From drupal-devel at webchick.net Fri Oct 24 16:00:33 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Fri, 24 Oct 2008 12:00:33 -0400 Subject: [development] Making #access required on forms Message-ID: <4901F121.2060302@webchick.net> Gerhard brought this up on the security team list, but it seems like it's worth broader discussion: --- Hi there, as more an more people use Drupal to provide non-traditional Webpages (e.g. providing services using Ajax, Flex, ...) our traditional access permission checks in hook_menu are less than ideal. For example, you can use drupal_execute to conveniently create content or anything else. However, no check for access permissions is done since this only happens in the menu hook for node/add/whatever. I therefore propose to push for D7 that the #access parameter on forms be made mandatory. Opinions? --- My initial thought on the downside is that this has implications for people who are using drupal_execute() to perform programmatic tasks (node/block/etc. creation, etc.); they would no longer work unless the script switched to user with the proper credentials (so we should probably get a nice user switching API function in core). It is also something in the upgrade steps that, if missed, will cause forms to completely disappear which is bound to result in support requests. On the other hand, it would provide extra security and would be akin to the way we force menu callbacks to provide an access control or they don't appear for anyone. It might also help us clean up some nasty places in core (node form, I am looking at you) where we have if (user_access(...)) hard-coded. So, I echo: opinions? :) -Angie From darrel.opry at gmail.com Fri Oct 24 16:19:13 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Fri, 24 Oct 2008 12:19:13 -0400 Subject: [development] Making #access required on forms In-Reply-To: <4901F121.2060302@webchick.net> References: <4901F121.2060302@webchick.net> Message-ID: On Fri, Oct 24, 2008 at 12:00 PM, Angela Byron wrote: > Gerhard brought this up on the security team list, but it seems like it's > worth broader discussion: > > --- > > Hi there, > > as more an more people use Drupal to provide non-traditional Webpages > (e.g. providing services using Ajax, Flex, ...) our traditional access > permission checks in hook_menu are less than ideal. > > For example, you can use drupal_execute to conveniently create content > or anything else. However, no check for access permissions is done since > this only happens in the menu hook for node/add/whatever. > > I therefore propose to push for D7 that the #access parameter on forms > be made mandatory. > > Opinions? > > --- > > My initial thought on the downside is that this has implications for people > who are using drupal_execute() to perform programmatic tasks > (node/block/etc. creation, etc.); they would no longer work unless the > script switched to user with the proper credentials (so we should probably > get a nice user switching API function in core). It is also something in the > upgrade steps that, if missed, will cause forms to completely disappear > which is bound to result in support requests. > > On the other hand, it would provide extra security and would be akin to the > way we force menu callbacks to provide an access control or they don't > appear for anyone. It might also help us clean up some nasty places in core > (node form, I am looking at you) where we have if (user_access(...)) > hard-coded. > > So, I echo: opinions? :) > > -Angie I don't think that it should be a requirement or forced on developers. I do think it should be recommended. The processing, submission, and validation logic will have to be updated per form, especially if #access is used at the element level. #access is there and has been there. If someone has a good idea of a way to use it more effectively, document it and promote the approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081024/fb891cd1/attachment-0001.htm From larry at garfieldtech.com Fri Oct 24 16:31:10 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 24 Oct 2008 11:31:10 -0500 Subject: [development] Making #access required on forms In-Reply-To: <4901F121.2060302@webchick.net> References: <4901F121.2060302@webchick.net> Message-ID: <7d4c4d11b58b63f7aa99a08f0bb9f095@localhost> On Fri, 24 Oct 2008 12:00:33 -0400, Angela Byron wrote: > Gerhard brought this up on the security team list, but it seems like > it's worth broader discussion: > > --- > > Hi there, > > as more an more people use Drupal to provide non-traditional Webpages > (e.g. providing services using Ajax, Flex, ...) our traditional access > permission checks in hook_menu are less than ideal. > > For example, you can use drupal_execute to conveniently create content > or anything else. However, no check for access permissions is done since > this only happens in the menu hook for node/add/whatever. > > I therefore propose to push for D7 that the #access parameter on forms > be made mandatory. > > Opinions? > > --- > > My initial thought on the downside is that this has implications for > people who are using drupal_execute() to perform programmatic tasks > (node/block/etc. creation, etc.); they would no longer work unless the > script switched to user with the proper credentials (so we should > probably get a nice user switching API function in core). It is also > something in the upgrade steps that, if missed, will cause forms to > completely disappear which is bound to result in support requests. > > On the other hand, it would provide extra security and would be akin to > the way we force menu callbacks to provide an access control or they > don't appear for anyone. It might also help us clean up some nasty > places in core (node form, I am looking at you) where we have if > (user_access(...)) hard-coded. > > So, I echo: opinions? :) > > -Angie I have long argued that any part of a form that should only appear for some users should *always* be added, and then controlled with #access, and the validate and submit handlers must be designed to handle either case regardless of permission settings. That makes forms much easier to form_alter in useful ways. I've been bitten by modules not doing that, or not being able to handle a form value that is #access = FALSE, way too many times, especially by OG. We may need to tweak the internals of FAPI a little so that it handles #access = FALSE in a consistent manner to make the submit hooks easier. Of course, having to specify #access everywhere would be a nightmare. So I'd propose: - *All* FAPI/drupal_render() elements must support #access. A validate/submit callback that does not function properly with #access set true or false is by definition buggy. - All elements define whether #access defaults to TRUE or FALSE if not specified. - For the main form itself, #access defaults to FALSE. For everything else, it defaults to TRUE. - Establish a standard to handle conditional form adds via #access, not via an if statement. Using an if(user_access()) is treated as a bug. If that causes bugs anywhere, then the bugs get fixed per the first item. - Document the hell out of the above so that people know the Power of the #Access side. Does that sound like a reasonable balance? In the degenerate case for a typical form, it's one extra line to add an #access => TRUE or #access => user_access() to each form. Of course, one alternative is to have an #access_callback and #access_arguments property pair a la menu API, but I don't know if that's overkill. :-) --Larry Garfield From nevets at mailbag.com Fri Oct 24 16:33:36 2008 From: nevets at mailbag.com (Steve Ringwood) Date: Fri, 24 Oct 2008 11:33:36 -0500 Subject: [development] Making #access required on forms In-Reply-To: <4901F121.2060302@webchick.net> References: <4901F121.2060302@webchick.net> Message-ID: <4901F8E0.7030202@mailbag.com> Regarding > as more an more people use Drupal to provide non-traditional Webpages > (e.g. providing services using Ajax, Flex, ...) our traditional access > permission checks in hook_menu are less than ideal. > > For example, you can use drupal_execute to conveniently create content > or anything else. However, no check for access permissions is done since > this only happens in the menu hook for node/add/whatever. > > I therefore propose to push for D7 that the #access parameter on forms > be made mandatory. Sometimes I want to be able to create content for a user behind the scenes but not allow them the ability to directly create the content. One of the strong points about Drupal is it makes a great framework that I can extend as developer. If you really push this through then I think the permission to create a content type should be separate from the ability to use the form to create that content. Steve Ringwood From Greg at growingventuresolutions.com Fri Oct 24 17:46:32 2008 From: Greg at growingventuresolutions.com (Greg Knaddison - GVS) Date: Fri, 24 Oct 2008 11:46:32 -0600 Subject: [development] Making #access required on forms In-Reply-To: <4901F8E0.7030202@mailbag.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> Message-ID: <3861c6770810241046q31005362sd7d935b51edd5d1f@mail.gmail.com> On Fri, Oct 24, 2008 at 10:33 AM, Steve Ringwood wrote: > Sometimes I want to be able to create content for a user behind the scenes > but not allow them the ability to directly create the content. That would still be possible by impersonating another user[1] (i.e. uid 1) and then setting the node author name to a different user. In general, I'm in favor of requiring #access at the base level of every form. I don't have a strong feeling about it on individual fields, but I feel like Larry's proposal is pretty strong. Regards, Greg [1] http://drupal.org/node/218104 -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com From weitzman at tejasa.com Fri Oct 24 17:43:48 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Fri, 24 Oct 2008 13:43:48 -0400 Subject: [development] Making #access required on forms In-Reply-To: <4901F121.2060302@webchick.net> References: <4901F121.2060302@webchick.net> Message-ID: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> > as more an more people use Drupal to provide non-traditional Webpages > (e.g. providing services using Ajax, Flex, ...) our traditional access > permission checks in hook_menu are less than ideal. I don't see a problem here. It is up to the service that exposes the functionality to control access. It feels like this is a solution in search of a problem. Can we identify some more concrete use cases or an SA that would have been avoided had we implemented this? > For example, you can use drupal_execute to conveniently create content > or anything else. However, no check for access permissions is done since > this only happens in the menu hook for node/add/whatever. thats a feature. use reponsibly, just like the rest of our php code. @Crell - OG has problems dealing #access or other modules don't understand its use of #access? Yes, #access is incompletely implemented in core for users who have no access. see the hoops that KarenS jumped through at http://drupal.org/node/298440. So I agree that FAPI needs improving regardless of this proposal. Perhaps people would use #access more if it worked as expected. Same for #disabled (see http://drupal.org/node/227966)N From drewish at katherinehouse.com Fri Oct 24 18:02:35 2008 From: drewish at katherinehouse.com (andrew morton) Date: Fri, 24 Oct 2008 11:02:35 -0700 Subject: [development] Making #access required on forms In-Reply-To: <3861c6770810241046q31005362sd7d935b51edd5d1f@mail.gmail.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <3861c6770810241046q31005362sd7d935b51edd5d1f@mail.gmail.com> Message-ID: On Fri, Oct 24, 2008 at 10:46 AM, Greg Knaddison - GVS wrote: > On Fri, Oct 24, 2008 at 10:33 AM, Steve Ringwood wrote: >> Sometimes I want to be able to create content for a user behind the scenes >> but not allow them the ability to directly create the content. > > That would still be possible by impersonating another user[1] (i.e. > uid 1) and then setting the node author name to a different user. There's also an issue to add a core function for safely impersonating users: http://drupal.org/node/287292 From steven at digitalpulp.com Fri Oct 24 18:11:40 2008 From: steven at digitalpulp.com (Steven Surowiec) Date: Fri, 24 Oct 2008 14:11:40 -0400 Subject: [development] Drupal Test Suites Message-ID: <49020FDC.6000609@digitalpulp.com> I've been working on several Drupal projects for work and am thinking of getting an install of PHPUnderControl (http://www.phpundercontrol.org) and was wondering if there's any tests for Drupal core that are publicly available I'd be able to drop into the test suite. If not I think this would be something worth putting some time into, even as a regular project on the site. Since all the modules we write depend, in some way, on the core code, being able to include a generic core test suite in with our own would probably prove to be pretty useful. Especially for those of us that find ourselves needing to occasionally dig into core code now and then. From brad at atendesigngroup.com Fri Oct 24 18:24:36 2008 From: brad at atendesigngroup.com (Brad Bowman) Date: Fri, 24 Oct 2008 12:24:36 -0600 Subject: [development] Drupal Test Suites In-Reply-To: <49020FDC.6000609@digitalpulp.com> References: <49020FDC.6000609@digitalpulp.com> Message-ID: <1b565a00810241124k4a02448cu9625f24e000d24de@mail.gmail.com> Fantastic idea. So good we already did it :) The SimpleTest module was committed to core in June I believe, for the contrib version of the project check out http://drupal.org/project/simpletest Drupal 7 will ship with the SimpleTest module included, as well as a handful of tests. There is still work to be done though, so if you'd like to get involved you can dive into the list of issues here: http://drupal.org/project/issues?projects=3060&components=tests&states=1,16,8,13,14,15,2,4 Thanks, Brad Aten Design Group Phone: 303.831.0449 On Fri, Oct 24, 2008 at 12:11 PM, Steven Surowiec wrote: > I've been working on several Drupal projects for work and am thinking of > getting an install of PHPUnderControl (http://www.phpundercontrol.org) and > was wondering if there's any tests for Drupal core that are publicly > available I'd be able to drop into the test suite. If not I think this would > be something worth putting some time into, even as a regular project on the > site. Since all the modules we write depend, in some way, on the core code, > being able to include a generic core test suite in with our own would > probably prove to be pretty useful. Especially for those of us that find > ourselves needing to occasionally dig into core code now and then. > From steven at digitalpulp.com Fri Oct 24 18:31:05 2008 From: steven at digitalpulp.com (Steven Surowiec) Date: Fri, 24 Oct 2008 14:31:05 -0400 Subject: [development] Drupal Test Suites In-Reply-To: <1b565a00810241124k4a02448cu9625f24e000d24de@mail.gmail.com> References: <49020FDC.6000609@digitalpulp.com> <1b565a00810241124k4a02448cu9625f24e000d24de@mail.gmail.com> Message-ID: <49021469.4040804@digitalpulp.com> Ah ha, thanks for the info. I'll have to see if I can get this to integrate with PHPUnderControl at all. Will keep the list updated if I run into any problems with doing so. I notice D7 is using their own testing framework instead of using PHPUnit, which is why I'm skeptical about being able to integrate them, but I'll have to see. Where there's a nerd with determination, there's a way. Brad Bowman wrote: > Fantastic idea. So good we already did it :) The SimpleTest module was > committed to core in June I believe, for the contrib version of the > project check out http://drupal.org/project/simpletest > > Drupal 7 will ship with the SimpleTest module included, as well as a > handful of tests. There is still work to be done though, so if you'd > like to get involved you can dive into the list of issues here: > http://drupal.org/project/issues?projects=3060&components=tests&states=1,16,8,13,14,15,2,4 > > Thanks, > Brad > Aten Design Group > Phone: 303.831.0449 > > > > On Fri, Oct 24, 2008 at 12:11 PM, Steven Surowiec > wrote: > >> I've been working on several Drupal projects for work and am thinking of >> getting an install of PHPUnderControl (http://www.phpundercontrol.org) and >> was wondering if there's any tests for Drupal core that are publicly >> available I'd be able to drop into the test suite. If not I think this would >> be something worth putting some time into, even as a regular project on the >> site. Since all the modules we write depend, in some way, on the core code, >> being able to include a generic core test suite in with our own would >> probably prove to be pretty useful. Especially for those of us that find >> ourselves needing to occasionally dig into core code now and then. >> >> From gerhard at killesreiter.de Fri Oct 24 18:37:43 2008 From: gerhard at killesreiter.de (Gerhard Killesreiter) Date: Fri, 24 Oct 2008 20:37:43 +0200 Subject: [development] Making #access required on forms In-Reply-To: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> References: <4901F121.2060302@webchick.net> <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> Message-ID: <490215F7.4080708@killesreiter.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moshe Weitzman schrieb: >> as more an more people use Drupal to provide non-traditional Webpages >> (e.g. providing services using Ajax, Flex, ...) our traditional access >> permission checks in hook_menu are less than ideal. > > I don't see a problem here. It is up to the service that exposes the > functionality to control access. It feels like this is a solution in > search of a problem. I've encountered the same problem for a second time today. The problem can be summarized as "submit a form in a way that does not involve rendering a html page". > Can we identify some more concrete use cases or an SA that would > have been avoided had we implemented this? - From the fact that I needed this functionality, I infer that there are others who need it too. I've found 111 invocations of drupal_execute in CVS for D5 alone. I guess that there are 2-10 SAs in there. >> For example, you can use drupal_execute to conveniently create content >> or anything else. However, no check for access permissions is done since >> this only happens in the menu hook for node/add/whatever. > > thats a feature. use reponsibly, just like the rest of our php code. It is annoying if you want to do exactly that. To get around the problem of #access-less forms, I need to hook_form_alter #access to false for all of them and then one-by-one set permissions for the ones I need. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkCFfcACgkQfg6TFvELooQp7gCgnb7K7KEcV7wbgZmEUeXkBKTw R4AAni9wGxk5iuEj2GF9bfHaoOFT2W5Q =I9p8 -----END PGP SIGNATURE----- From kieran at acquia.com Fri Oct 24 18:40:01 2008 From: kieran at acquia.com (Kieran Lal) Date: Fri, 24 Oct 2008 11:40:01 -0700 Subject: [development] Drupal Test Suites In-Reply-To: <49021469.4040804@digitalpulp.com> References: <49020FDC.6000609@digitalpulp.com> <1b565a00810241124k4a02448cu9625f24e000d24de@mail.gmail.com> <49021469.4040804@digitalpulp.com> Message-ID: On Fri, Oct 24, 2008 at 11:31 AM, Steven Surowiec wrote: > Ah ha, thanks for the info. I'll have to see if I can get this to integrate > with PHPUnderControl at all. Will keep the list updated if I run into any > problems with doing so. I notice D7 is using their own testing framework > instead of using PHPUnit, which is why I'm skeptical about being able to > integrate them, but I'll have to see. Where there's a nerd with > determination, there's a way. To add to that we are now on our second iteration of an automated patch testing platform. Starting with a summer of code project by Rok Zlender we developed automated patch testing around the simple test framework. Rok continued his work as a mentor for the second year. In September 2007, we started building http://testing.drupal.org to do patch testing and simpletests focused on 4.7, 5, and Drupal 6. The simpletest framework for core changed pretty radically from the simpletest framework so for Drupal 7 we had to redo parts of the automated testing framework. Jimmy Berry a GHOP student moved his efforts from core tests to automated testing. Last night we complete the 2300th automated patch test from the Drupal project issue queue. Chad Phillips extended the project module on Drupal.org to send patches for automated testing and allow for report backs. Now that we are confident that automated patch testing is stable, we plan to start reporting back to the issue queue, which patches are valid, and what tests they pass and fail. For a history of this project in detail see: http://acquia.com/blog/kieran/how-test-20-000-drupal-7-core-patches We are recruiting developers to help with automated patch testing. We believe we have a thousands of hours of tests for core to be written and we can always use a hand with improving the automated testing platform. Cheers, Kieran > > Brad Bowman wrote: >> >> Fantastic idea. So good we already did it :) The SimpleTest module was >> committed to core in June I believe, for the contrib version of the >> project check out http://drupal.org/project/simpletest >> >> Drupal 7 will ship with the SimpleTest module included, as well as a >> handful of tests. There is still work to be done though, so if you'd >> like to get involved you can dive into the list of issues here: >> >> http://drupal.org/project/issues?projects=3060&components=tests&states=1,16,8,13,14,15,2,4 >> >> Thanks, >> Brad >> Aten Design Group >> Phone: 303.831.0449 >> >> >> >> On Fri, Oct 24, 2008 at 12:11 PM, Steven Surowiec >> wrote: >> >>> >>> I've been working on several Drupal projects for work and am thinking of >>> getting an install of PHPUnderControl (http://www.phpundercontrol.org) >>> and >>> was wondering if there's any tests for Drupal core that are publicly >>> available I'd be able to drop into the test suite. If not I think this >>> would >>> be something worth putting some time into, even as a regular project on >>> the >>> site. Since all the modules we write depend, in some way, on the core >>> code, >>> being able to include a generic core test suite in with our own would >>> probably prove to be pretty useful. Especially for those of us that find >>> ourselves needing to occasionally dig into core code now and then. >>> >>> > > From larry at garfieldtech.com Fri Oct 24 19:12:14 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Fri, 24 Oct 2008 14:12:14 -0500 Subject: [development] Making #access required on forms In-Reply-To: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> References: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> Message-ID: <8a0baaa81f74fde6bb21d71e26f0c0a4@localhost> On Fri, 24 Oct 2008 13:43:48 -0400, "Moshe Weitzman" wrote: > @Crell - OG has problems dealing #access or other modules don't > understand its use of #access? I'd form_alter something to hide it, and rather than passing through its value unchanged (what I'd expect) it ended up not being set at all. I ran into similar issues with CCK, which seems to have its own form element structure that doesn't map to anything else so is a huge PITA to form_alter. :-) This is under D5, though, so I don't know if it's nicer in D6. I guess this is a branch of this thread to continue in the issue queue when next I try to form_alter stuff in weird ways. --Larry Garfield From sysop at scbbs.com Fri Oct 24 19:03:05 2008 From: sysop at scbbs.com (Ron Parker) Date: Fri, 24 Oct 2008 12:03:05 -0700 (PDT) Subject: [development] Has anything changed with module_invoke() recently? In-Reply-To: <23951660.15811224874823750.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <22561143.15831224874985352.JavaMail.root@zimbra.thefiengroup.com> Ron Parker said: "This same exact code worked in 5.x, so I have to believe there is something that has changed in 6.x with module_invoke() / $user . Furthermore, this code worked in the initial Drupal 6.x versions, so this change, whatever it is, is rather recent. Theoretically, module_invoke below should not return false, but it is" Nancy Wichmann said: "I have recently run into problems with hook_access. It is widely misunderstood and many module return false when they really should be returning null. I even had to change many of my modules. I know there are many out there that are still wrong." Could someone please point me to how I begin to solve this problem? I am certain that the user object contains the correct roles that should allow permission. How do I track down what's going on with module_invoke? -ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081024/482cd852/attachment.htm From sysop at scbbs.com Sat Oct 25 00:35:31 2008 From: sysop at scbbs.com (Ron Parker) Date: Fri, 24 Oct 2008 17:35:31 -0700 (PDT) Subject: [development] The static $perm variable in user_access (was: Has anything changed with module_invoke() recently?) In-Reply-To: <22561143.15831224874985352.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <4207719.16371224894931790.JavaMail.root@zimbra.thefiengroup.com> I located the source of my problem. In the user_access() function, the static variable $perm is set to hold the permissions for a user. Issuing this command: user_access('', NULL, TRUE); ( http://api.drupal.org/api/function/user_access/6 ) will unset the $perm variable and allow it to reset with the permissions from the most current roles. My debug code indicates that it contains the correct permissions from the roles of the $user object. However, when I issue: module_invoke($module, 'access', 'create', $type, $user); which, in the case of $module = 'node_content' will itself call user_access($permission, $user) , the $perm value is now set (as it should be from my reset command), but no longer contains the all permissions from the roles in the $user object (what was originally set), but only the ones you would find for the user in the role table. Furthermore, I put debug code into user_access() to show me each time it is ran. I do not see it accessed between the time $perm is unset (by my reset command) and it is called by module_invoke(). The way this worked in 5.x: hook_init() would issue user_access('', NULL, TRUE) which would unset the $perm variable so that the next time user_access() ran, it would rebuild $perm. In 6.x appears this no longer works in the same way. So, it looks like either: a. Another module (other than the user.module) is manipulating the $perm variable, or; b. Drupal core is assuring, when module_invoke() is used, that the set $perm variable only contains roles that the user has in the roles table. My question is this: Can the $perm variable be manipulated outside of the user.module? If not, then how is b. above accomplished? Thanks for any assistance whatsoever! -ron ----- Original Message ----- From: "Ron Parker" To: development at drupal.org Sent: Friday, October 24, 2008 12:03:05 PM GMT -08:00 US/Canada Pacific Subject: Re: Has anything changed with module_invoke() recently? Ron Parker said: "This same exact code worked in 5.x, so I have to believe there is something that has changed in 6.x with module_invoke() / $user . Furthermore, this code worked in the initial Drupal 6.x versions, so this change, whatever it is, is rather recent. Theoretically, module_invoke below should not return false, but it is" Nancy Wichmann said: "I have recently run into problems with hook_access. It is widely misunderstood and many module return false when they really should be returning null. I even had to change many of my modules. I know there are many out there that are still wrong." Could someone please point me to how I begin to solve this problem? I am certain that the user object contains the correct roles that should allow permission. How do I track down what's going on with module_invoke? -ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081024/01a589e1/attachment.htm From darrel.opry at gmail.com Sat Oct 25 04:38:31 2008 From: darrel.opry at gmail.com (Darrel O'Pry) Date: Sat, 25 Oct 2008 00:38:31 -0400 Subject: [development] Making #access required on forms In-Reply-To: <8a0baaa81f74fde6bb21d71e26f0c0a4@localhost> References: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> <8a0baaa81f74fde6bb21d71e26f0c0a4@localhost> Message-ID: so maybe if #access == false, an element gets it's value set to the #default_value and it is not rendered? just to make handling the form more consistent? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081025/872db6da/attachment-0001.htm From larry at garfieldtech.com Sat Oct 25 05:12:34 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 25 Oct 2008 00:12:34 -0500 Subject: [development] Making #access required on forms In-Reply-To: References: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> <8a0baaa81f74fde6bb21d71e26f0c0a4@localhost> Message-ID: <200810250012.35482.larry@garfieldtech.com> On Friday 24 October 2008 11:38:31 pm Darrel O'Pry wrote: > so maybe if #access == false, an element gets it's value set to the > #default_value and it is not rendered? just to make handling the form more > consistent? That is what I would expect to happen, and 99% of the time is what I want to happen. :-) If that's not what happens now, uh, what does happen? -- Larry Garfield larry at garfieldtech.com From prometheus6 at gmail.com Sat Oct 25 07:33:35 2008 From: prometheus6 at gmail.com (Earl Dunovant) Date: Sat, 25 Oct 2008 03:33:35 -0400 Subject: [development] Making #access required on forms In-Reply-To: <200810250012.35482.larry@garfieldtech.com> References: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> <8a0baaa81f74fde6bb21d71e26f0c0a4@localhost> <200810250012.35482.larry@garfieldtech.com> Message-ID: I'd change #type to 'value' and #value to #default_value. It's not as automatic as using #access On Sat, Oct 25, 2008 at 1:12 AM, Larry Garfield wrote: > On Friday 24 October 2008 11:38:31 pm Darrel O'Pry wrote: > > so maybe if #access == false, an element gets it's value set to the > > #default_value and it is not rendered? just to make handling the form > more > > consistent? > > That is what I would expect to happen, and 99% of the time is what I want > to > happen. :-) > > If that's not what happens now, uh, what does happen? > > -- > Larry Garfield > larry at garfieldtech.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081025/0ef59b7e/attachment.htm From larry at garfieldtech.com Sat Oct 25 18:30:27 2008 From: larry at garfieldtech.com (Larry Garfield) Date: Sat, 25 Oct 2008 13:30:27 -0500 Subject: [development] Making #access required on forms In-Reply-To: References: <6117a7500810241043n48224ca0ha9d18ba202368d9a@mail.gmail.com> <200810250012.35482.larry@garfieldtech.com> Message-ID: <200810251330.27972.larry@garfieldtech.com> I've tried that, too. That also breaks sometimes depending on the module, especially for CCK fields. On Saturday 25 October 2008 2:33:35 am Earl Dunovant wrote: > I'd change #type to 'value' and #value to #default_value. It's not as > automatic as using #access > > On Sat, Oct 25, 2008 at 1:12 AM, Larry Garfield wrote: > > On Friday 24 October 2008 11:38:31 pm Darrel O'Pry wrote: > > > so maybe if #access == false, an element gets it's value set to the > > > #default_value and it is not rendered? just to make handling the form > > > > more > > > > > consistent? > > > > That is what I would expect to happen, and 99% of the time is what I want > > to > > happen. :-) > > > > If that's not what happens now, uh, what does happen? -- Larry Garfield larry at garfieldtech.com From earnie at users.sourceforge.net Sun Oct 26 15:45:38 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Sun, 26 Oct 2008 11:45:38 -0400 Subject: [development] Making #access required on forms In-Reply-To: <4901F8E0.7030202@mailbag.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> Message-ID: <20081026114538.vxcd0e24ql1oockg@mail.progw.org> Quoting Steve Ringwood : > I think the permission to create a content type > should be separate from the ability to use the form to create that > content. > Isn't that the case already. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From bryan at cmsreport.com Mon Oct 27 11:39:08 2008 From: bryan at cmsreport.com (Bryan Ruby) Date: Mon, 27 Oct 2008 06:39:08 -0500 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: <20081026114538.vxcd0e24ql1oockg@mail.progw.org> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> Message-ID: <4905A85C.9000609@cmsreport.com> I just visited Packt Publishing's award page and found that Earl Miles (merlinofchaos) was voted as one of the Most Valued People from Open Source Content Management Systems (try wearing that title on a T-shirt!). There are other projects besides Drupal listed. What I found interesting is that most of the MVPs for projects were the projects' lead/founder. Perhaps that says something about Drupal truly being community driven. Link at: http://www.packtpub.com/article/open-source-cms-most-valued-people-announced . PacktPub.com has been accepting MVP nominations since early July and for the majority of Content Management Systems, there were a number of candidates that received enthusiastic support. This demonstrates how many different people are key to the sucess of a CMS and how difficult it is to select an individual as the person who has contributed the most. The following list of names were put forward by members of the Content Management System's development team and community and represent the exceptional support, guidance, and sheer amount of time that the MVPs have given up to support the development and growth of the respective CMS. Congratulations to those who were selected as the first annual Open Source CMS MVPs. BryanSD From cog.rusty at gmail.com Mon Oct 27 14:19:28 2008 From: cog.rusty at gmail.com (Cog Rusty) Date: Mon, 27 Oct 2008 16:19:28 +0200 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: <4905A85C.9000609@cmsreport.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> Message-ID: On Mon, Oct 27, 2008 at 1:39 PM, Bryan Ruby wrote: > I just visited Packt Publishing's award page and found that Earl Miles > (merlinofchaos) was voted as one of the Most Valued People from Open Source > Content Management Systems (try wearing that title on a T-shirt!). There > are other projects besides Drupal listed. What I found interesting is that > most of the MVPs for projects were the projects' lead/founder. Perhaps > that says something about Drupal truly being community driven. Link at: > http://www.packtpub.com/article/open-source-cms-most-valued-people-announced ...snip... Well deserved. Earl not only pioneered some valuable modules which help tie everything together, but also has been seeing them through, with proper maintenance and releases, always keeping them as reliable as core. From pinglaura at gmail.com Mon Oct 27 14:25:25 2008 From: pinglaura at gmail.com (Laura Scott) Date: Mon, 27 Oct 2008 08:25:25 -0600 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: <4905A85C.9000609@cmsreport.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> Message-ID: Congrats to Earl! Much deserved! -Laura On Oct 27, 2008, at 5:39 AM, Bryan Ruby wrote: > I just visited Packt Publishing's award page and found that Earl > Miles (merlinofchaos) was voted as one of the Most Valued People > from Open Source Content Management Systems (try wearing that title > on a T-shirt!). There are other projects besides Drupal listed. > What I found interesting is that most of the MVPs for projects were > the projects' lead/founder. Perhaps that says something about > Drupal truly being community driven. Link at: http://www.packtpub.com/article/open-source-cms-most-valued-people-announced > . > > PacktPub.com has been accepting MVP > nominations since early July and for the majority of Content > Management Systems, there were a number of candidates that received > enthusiastic support. This demonstrates how many different people > are key to the sucess of a CMS and how difficult it is to select an > individual as the person who has contributed the most. > > The following list of names were put forward by members of the > Content Management System's development team and community and > represent the exceptional support, guidance, and sheer amount of > time that the MVPs have given up to support the development and > growth of the respective CMS. > > Congratulations to those who were selected as the first annual Open > Source CMS MVPs. > > BryanSD From drupal at ryancross.com Mon Oct 27 15:00:14 2008 From: drupal at ryancross.com (Ryan Cross) Date: Tue, 28 Oct 2008 02:00:14 +1100 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> Message-ID: <4e983be00810270800h13f91ee6s39f7164e0e837470@mail.gmail.com> There is something about the name "Earl Miles" that sounds very dignified, and with all his good work I think we should knight the MVP so I can him, Sir Earl Miles Plus, I think it would be cool to see him slaying code with a sword! Who's with me? =) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081028/8b16d992/attachment-0001.htm From victorkane at gmail.com Mon Oct 27 15:32:43 2008 From: victorkane at gmail.com (Victor Kane) Date: Mon, 27 Oct 2008 13:32:43 -0200 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: <4e983be00810270800h13f91ee6s39f7164e0e837470@mail.gmail.com> References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> <4e983be00810270800h13f91ee6s39f7164e0e837470@mail.gmail.com> Message-ID: One of the people with the highest impact on Drupal functionality, usability, one of the reasons many people stay with the Drupal CMS Framework. Gigantic. Victor Kane http://awebfactory.com.ar On Mon, Oct 27, 2008 at 1:00 PM, Ryan Cross wrote: > There is something about the name "Earl Miles" that sounds very dignified, > and with all his good work I think we should knight the MVP so I can him, > Sir Earl Miles > Plus, I think it would be cool to see him slaying code with a sword! > Who's with me? =) From cxjohnson at gmail.com Mon Oct 27 17:18:52 2008 From: cxjohnson at gmail.com (Chris Johnson) Date: Mon, 27 Oct 2008 12:18:52 -0500 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> <4e983be00810270800h13f91ee6s39f7164e0e837470@mail.gmail.com> Message-ID: <9ea8d6030810271018t3bc66599k78f4f73dc5e24f00@mail.gmail.com> Congratulations, Earl. Well deserved praise. /me now waiting for Earl to appear on the best-sellers list. *wink wink* ;-) ..chris > > On Mon, Oct 27, 2008 at 1:00 PM, Ryan Cross wrote: > > There is something about the name "Earl Miles" that sounds very > dignified, > > and with all his good work I think we should knight the MVP so I can him, > > Sir Earl Miles > > Plus, I think it would be cool to see him slaying code with a sword! > > Who's with me? =) > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081027/12c86e43/attachment.htm From amystephen at gmail.com Mon Oct 27 17:18:56 2008 From: amystephen at gmail.com (Amy Stephen) Date: Mon, 27 Oct 2008 12:18:56 -0500 Subject: [development] Earl Miles: Drupal's MVP per Packt's 2008 OS CMS Award In-Reply-To: References: <4901F121.2060302@webchick.net> <4901F8E0.7030202@mailbag.com> <20081026114538.vxcd0e24ql1oockg@mail.progw.org> <4905A85C.9000609@cmsreport.com> <4e983be00810270800h13f91ee6s39f7164e0e837470@mail.gmail.com> Message-ID: <979e7e490810271018x1059313fp23adf26378944119@mail.gmail.com> Congratulations, Earl! Amy :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081027/05a76e68/attachment.htm From steven at digitalpulp.com Wed Oct 29 14:17:16 2008 From: steven at digitalpulp.com (Steven Surowiec) Date: Wed, 29 Oct 2008 10:17:16 -0400 Subject: [development] Turning custom_url_rewrite_* into hooks? Message-ID: <4908706C.4090904@digitalpulp.com> I've working on a custom module for a project that makes use of custom_url_rewrite to open up linking shortcuts through the url() function and I was wondering if there is any specific reason this functionality isn't a regular hook? I know I could probably use URL aliases for what I'm trying to do but requires me to not have to worry about managing hundreds, possibly thousands, of URL aliases just to open up this type of functionality. Maybe I'm just mis-using this functionality but it seems like it might be worth while to consider. From john.morahan at gmail.com Wed Oct 29 14:20:10 2008 From: john.morahan at gmail.com (John Morahan) Date: Wed, 29 Oct 2008 14:20:10 +0000 Subject: [development] Turning custom_url_rewrite_* into hooks? In-Reply-To: <4908706C.4090904@digitalpulp.com> References: <4908706C.4090904@digitalpulp.com> Message-ID: <4908711A.5000404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steven Surowiec wrote: > I've working on a custom module for a project that makes use of > custom_url_rewrite to open up linking shortcuts through the url() > function and I was wondering if there is any specific reason this > functionality isn't a regular hook? I know I could probably use URL > aliases for what I'm trying to do but requires me to not have to worry > about managing hundreds, possibly thousands, of URL aliases just to open > up this type of functionality. Maybe I'm just mis-using this > functionality but it seems like it might be worth while to consider. It isn't possible right now, because those functions may be called before the module system is initialized. However, see http://drupal.org/node/320331 - -john -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCHEawX2/xQt/IP8RAjFpAJ4pPriiLJlaoX6sO80eJrfbAWkAdwCgjAuN 1WbbATqMHOcN9NBJmsMso+A= =wiIU -----END PGP SIGNATURE----- From gabor at hojtsy.hu Wed Oct 29 22:00:57 2008 From: gabor at hojtsy.hu (=?ISO-8859-1?Q?G=E1bor_Hojtsy?=) Date: Wed, 29 Oct 2008 23:00:57 +0100 Subject: [development] Turning custom_url_rewrite_* into hooks? In-Reply-To: <4908706C.4090904@digitalpulp.com> References: <4908706C.4090904@digitalpulp.com> Message-ID: <86ca3ccb0810291500k12885b37h513459dbca3a38a5@mail.gmail.com> John points out it is required before hooks are available. Also, it was deemed not as good for performance to look for hooks, and better for performance to only look for one specific function. With the code registry in Drupal 7, the modules defining hooks are pre-parsed, so we'd know a list of functions to call from that cache. That might mitigate the performance problems. Would probably need to be benchmarked (invoke hook with one implementation vs. invoke the well-known-named function). For API consistency, I agree that making this a hook would be better, if you can make it work early enough in the bootstrap :) G?bor On Wed, Oct 29, 2008 at 3:17 PM, Steven Surowiec wrote: > I've working on a custom module for a project that makes use of > custom_url_rewrite to open up linking shortcuts through the url() function > and I was wondering if there is any specific reason this functionality isn't > a regular hook? I know I could probably use URL aliases for what I'm trying > to do but requires me to not have to worry about managing hundreds, possibly > thousands, of URL aliases just to open up this type of functionality. Maybe > I'm just mis-using this functionality but it seems like it might be worth > while to consider. > From news at unleashedmind.com Thu Oct 30 13:02:40 2008 From: news at unleashedmind.com (Daniel F. Kudwien) Date: Thu, 30 Oct 2008 14:02:40 +0100 Subject: [development] Views 1.x issues need testing Message-ID: <070701c93a8f$ca4f9fc0$0200a8c0@structworks.com> I am working on getting a (hopefully final) Views 1.7 release out of the door. If you have one or more existing Drupal 5 sites using Views 1.x - preferably backups/development sites of live sites, and most preferably with highly customized Views stuff - it is most probably in your own interest to help in reviewing and testing the patches listed in http://drupal.org/node/208855#comment-1018848 If your sites make use of Taxonomy in Views, exposed filters, RSS feeds, multiple views arguments - even better. Participating is simple: Just click on 2-10 different issues on that list, download and apply the latest patch in the issue, and report back if the views on your site still work - ideally also including whether the goal of the issue has been achieved, of course. Each patch needs 2-3 confirmations to be RTBC. Some issues will require updates to the upgrade path for Views 2.x; that will be dealt with after 1.7 has been released. Thanks, Daniel From markus.kalkbrenner at arcor.de Thu Oct 30 13:00:26 2008 From: markus.kalkbrenner at arcor.de (Markus Kalkbrenner) Date: Thu, 30 Oct 2008 14:00:26 +0100 Subject: [development] How to post bug reports and patches Message-ID: <200810301400.26316.markus.kalkbrenner@arcor.de> Hi, This is my first post to this list so I will introduce myself first. My name is Markus Kalkbrenner. I'm developing software for more than 15 years and participating in open source projects since 7 years. Two years ago I started working with drupal and posted my first bug reports and patches. Currently I'm asking myself which is the right strategy to contribute patches and get them committed to CVS because most of the time I'm still working with drupal 5 and find bugs there. Just some examples: Posted 4 month ago for drupal 5.7: http://drupal.org/node/229411 node_view() incompatible to php5 I was asked to add more comments to my patch and drumm found out that the same bug still exists in drupal 6. So I added the comments but nothing happend. Neither in D5 nor in D6. Posted 3 month ago for drupal 5.8 http://drupal.org/node/287063 node_delete memory leak and wrong order of commands In a different bug I was told to post the bugs for drupal 6 to get them handled faster and finally backported to drupal 5. So I switched the version for this issue to D6 and added an additional patch for it. But no reaction. Posted 3 month ago for drupal 6.dev http://drupal.org/node/298768 Ensure that entries are written to watchdog table and http://drupal.org/node/298678 Impossible to lock two MySQL tables From my point of view these are two serious issues which are the reason for several other bug reports. I found them in drupal 5 but discovered that they still exist in D6 and D7. So I decided to post them for D6 because this is the current stable version. Unfortunately I didn't see any reaction so far. Please don't get me wrong. I really like drupal and will keep on contributing patches because I want to improve it. But maybe I'm doing something wrong or you just have no time to maintain the stable versions. So for me the current situation is like a "bad user experience". Markus From weitzman at tejasa.com Thu Oct 30 13:39:19 2008 From: weitzman at tejasa.com (Moshe Weitzman) Date: Thu, 30 Oct 2008 09:39:19 -0400 Subject: [development] How to post bug reports and patches In-Reply-To: <200810301400.26316.markus.kalkbrenner@arcor.de> References: <200810301400.26316.markus.kalkbrenner@arcor.de> Message-ID: <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> Please see http://drupal.org/node/10263. To the extent that is unclear, then ask. Note that all patches to core must be against HEAD when the bug still exists in HEAD. Thanks. On Thu, Oct 30, 2008 at 9:00 AM, Markus Kalkbrenner wrote: > Hi, > > This is my first post to this list so I will introduce myself first. > My name is Markus Kalkbrenner. I'm developing software for more than 15 years > and participating in open source projects since 7 years. > Two years ago I started working with drupal and posted my first bug reports > and patches. > > Currently I'm asking myself which is the right strategy to contribute patches > and get them committed to CVS because most of the time I'm still working with > drupal 5 and find bugs there. > > Just some examples: > > Posted 4 month ago for drupal 5.7: > http://drupal.org/node/229411 node_view() incompatible to php5 > > I was asked to add more comments to my patch and drumm found out that the same > bug still exists in drupal 6. So I added the comments but nothing happend. > Neither in D5 nor in D6. > > > Posted 3 month ago for drupal 5.8 > http://drupal.org/node/287063 node_delete memory leak and wrong order of > commands > > In a different bug I was told to post the bugs for drupal 6 to get them > handled faster and finally backported to drupal 5. So I switched the version > for this issue to D6 and added an additional patch for it. But no reaction. > > > Posted 3 month ago for drupal 6.dev > http://drupal.org/node/298768 Ensure that entries are written to watchdog > table > and > http://drupal.org/node/298678 Impossible to lock two MySQL tables > > From my point of view these are two serious issues which are the reason for > several other bug reports. I found them in drupal 5 but discovered that they > still exist in D6 and D7. So I decided to post them for D6 because this is > the current stable version. Unfortunately I didn't see any reaction so far. > > > Please don't get me wrong. I really like drupal and will keep on contributing > patches because I want to improve it. > But maybe I'm doing something wrong or you just have no time to maintain the > stable versions. So for me the current situation is like a "bad user > experience". > > Markus > From drupal-devel at webchick.net Thu Oct 30 14:14:36 2008 From: drupal-devel at webchick.net (Angela Byron) Date: Thu, 30 Oct 2008 07:14:36 -0700 Subject: [development] How to post bug reports and patches In-Reply-To: <200810301400.26316.markus.kalkbrenner@arcor.de> References: <200810301400.26316.markus.kalkbrenner@arcor.de> Message-ID: <4909C14C.3080006@webchick.net> It's a fair question. When the Drupal community is at some 385,000+ people and there are some 5,500+ issues contending for attention, it can be difficult for the issues that you think are important to gain visibility. Some tips that should help, anyway: * File issues against the latest version of Drupal to have the problem. For example, if it happens in 6.x and 7.x, file it under 7.x instead; the latest version is always where most core developers are focusing, and once they get in to a later release, it's a lot easier to make the case for it belonging in earlier ones (and easier to commit the patch too, since it's already been vetted). * Hang out on IRC in #drupal, and watch for someone asking for a patch review. Tell them you'd be happy to review their patch if they could review yours. * We are always desperately short on patch reviewers. So if you consistently do awesome patch reviews as often as you can, and you will get escalated to the very tippy-top of the community karma scale very, very quickly. There are good tips about this at http://drupal.org/patch/review. Hope that helps, I'm about to get on a plane so didn't get a chance to look at those issues in particular, but these are some general tips. -Angie Markus Kalkbrenner wrote: > Hi, > > This is my first post to this list so I will introduce myself first. > My name is Markus Kalkbrenner. I'm developing software for more than 15 years > and participating in open source projects since 7 years. > Two years ago I started working with drupal and posted my first bug reports > and patches. > > Currently I'm asking myself which is the right strategy to contribute patches > and get them committed to CVS because most of the time I'm still working with > drupal 5 and find bugs there. > > Just some examples: > > Posted 4 month ago for drupal 5.7: > http://drupal.org/node/229411 node_view() incompatible to php5 > > I was asked to add more comments to my patch and drumm found out that the same > bug still exists in drupal 6. So I added the comments but nothing happend. > Neither in D5 nor in D6. > > > Posted 3 month ago for drupal 5.8 > http://drupal.org/node/287063 node_delete memory leak and wrong order of > commands > > In a different bug I was told to post the bugs for drupal 6 to get them > handled faster and finally backported to drupal 5. So I switched the version > for this issue to D6 and added an additional patch for it. But no reaction. > > > Posted 3 month ago for drupal 6.dev > http://drupal.org/node/298768 Ensure that entries are written to watchdog > table > and > http://drupal.org/node/298678 Impossible to lock two MySQL tables > > From my point of view these are two serious issues which are the reason for > several other bug reports. I found them in drupal 5 but discovered that they > still exist in D6 and D7. So I decided to post them for D6 because this is > the current stable version. Unfortunately I didn't see any reaction so far. > > > Please don't get me wrong. I really like drupal and will keep on contributing > patches because I want to improve it. > But maybe I'm doing something wrong or you just have no time to maintain the > stable versions. So for me the current situation is like a "bad user > experience". From m.kruisselbrink at student.tue.nl Thu Oct 30 14:18:26 2008 From: m.kruisselbrink at student.tue.nl (Marijn Kruisselbrink) Date: Thu, 30 Oct 2008 15:18:26 +0100 Subject: [development] How to post bug reports and patches In-Reply-To: <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> Message-ID: <200810301518.26766.m.kruisselbrink@student.tue.nl> On Thursday 30 October 2008 14:39:19 Moshe Weitzman wrote: > Please see http://drupal.org/node/10263. To the extent that is > unclear, then ask. Note that all patches to core must be against HEAD > when the bug still exists in HEAD. Thanks. That page doesn't address the biggest problem I have trying to contribute; it literally takes months to get any reply whatsoever to a patch (I think in one case there was 6 months between reporting an issue with a patch and the first reply other than me updating the patch to keep working against HEAD (which I gave up doing after a couple of months)). So what is wrong with the current system that it can take this long? Marijn From markus.kalkbrenner at arcor.de Thu Oct 30 14:29:01 2008 From: markus.kalkbrenner at arcor.de (Markus Kalkbrenner) Date: Thu, 30 Oct 2008 15:29:01 +0100 Subject: [development] How to post bug reports and patches In-Reply-To: <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> Message-ID: <200810301529.02143.markus.kalkbrenner@arcor.de> Thanks for your quick answer. > Please see http://drupal.org/node/10263. Quote: Be persistent. If you don't get any response right away, don't necessarily give up. If you're still convinced your idea has merit, find another way to present it That's what I'm doing now ;-) > Note that all patches to core must be against HEAD > when the bug still exists in HEAD. OK, I wasn't aware of this fact. I'll keep this in mind. But how could a serious issue be escalated if it only exists in a release branch and nobody reacts on a bug report for months. Should I use this list? Markus From Greg at growingventuresolutions.com Thu Oct 30 14:37:40 2008 From: Greg at growingventuresolutions.com (Greg Knaddison - GVS) Date: Thu, 30 Oct 2008 08:37:40 -0600 Subject: [development] How to post bug reports and patches In-Reply-To: <200810301518.26766.m.kruisselbrink@student.tue.nl> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> <200810301518.26766.m.kruisselbrink@student.tue.nl> Message-ID: <3861c6770810300737p2f4e3e7j54872c378df773b8@mail.gmail.com> On Thu, Oct 30, 2008 at 8:18 AM, Marijn Kruisselbrink wrote: > gave up doing after a couple of months)). So what is wrong with the current > system that it can take this long? The problem is that there is a very small set of people to commit patches. Those people are busy. So, they rely on reviews from other people to help them decide what to commit. Since there are not enough people who do reviews, the people who review code get wide respect from the community including the people that they help the most: the core committers. When the core committers see a patch by someone they respect (like a patch reviewer) the patch is more likely to get committed because of the respect and trust. So, it's very simple: 1. To get your patch committed quickly, you build trust and respect with the committers 2. To build trust and respect with the committers you review other people's patches 3. Repeat until there are no more bugs Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com From darrenoh at sidepotsinternational.com Thu Oct 30 14:42:04 2008 From: darrenoh at sidepotsinternational.com (Darren Oh) Date: Thu, 30 Oct 2008 10:42:04 -0400 Subject: [development] How to post bug reports and patches In-Reply-To: <200810301518.26766.m.kruisselbrink@student.tue.nl> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> <200810301518.26766.m.kruisselbrink@student.tue.nl> Message-ID: <7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com> Most often patches are ignored when they are not relevant to the development version of Drupal. Bugs are sometimes labeled feature requests by maintainers who are not interested in fixes that only apply to older versions. In effect they're saying, This doesn't need to be fixed. You got it to work for you, and other people can wait for the next version of Drupal. Only a few core maintainers behave this way, probably because they are trying to shorten the patch queue, but their comments discourage other developers from getting involved. On Oct 30, 2008, at 10:18 AM, Marijn Kruisselbrink wrote: > That page doesn't address the biggest problem I have trying to > contribute; it > literally takes months to get any reply whatsoever to a patch (I > think in one > case there was 6 months between reporting an issue with a patch and > the first > reply other than me updating the patch to keep working against HEAD > (which I > gave up doing after a couple of months)). So what is wrong with the > current > system that it can take this long? > > Marijn From darrenoh at sidepotsinternational.com Thu Oct 30 15:07:10 2008 From: darrenoh at sidepotsinternational.com (Darren Oh) Date: Thu, 30 Oct 2008 11:07:10 -0400 Subject: [development] How to post bug reports and patches In-Reply-To: <7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <6117a7500810300639t488f3b20mbb6a4bca6a8913aa@mail.gmail.com> <200810301518.26766.m.kruisselbrink@student.tue.nl> <7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com> Message-ID: <1AE9533B-4E76-415D-8D3B-2CE4782064B0@sidepotsinternational.com> After chatting with greggles, I should make clear that I can guess why core maintainers would do this because as a project maintainer I have been guilty of exactly the same thing. There are four bottlenecks in project maintenance: 1. People who complain outnumber people to read complaints. 2. People who read complaints outnumber people who provide patches. 3. People who provide patches outnumber people who review patches. 4. People who review patches outnumber people who commit patches. This means a maintainer spends a lot of time sifting through issues and trying to consolidate them to the few that are helpful. A maintainer's frustration is that most users focus on bottleneck 4 when the other three are just as important. On Oct 30, 2008, at 10:42 AM, Darren Oh wrote: > Most often patches are ignored when they are not relevant to the > development version of Drupal. Bugs are sometimes labeled feature > requests by maintainers who are not interested in fixes that only > apply to older versions. In effect they're saying, This doesn't need > to be fixed. You got it to work for you, and other people can wait > for the next version of Drupal. > > Only a few core maintainers behave this way, probably because they > are trying to shorten the patch queue, but their comments discourage > other developers from getting involved. From markus.kalkbrenner at arcor.de Thu Oct 30 15:11:11 2008 From: markus.kalkbrenner at arcor.de (Markus Kalkbrenner) Date: Thu, 30 Oct 2008 16:11:11 +0100 Subject: [development] How to post bug reports and patches In-Reply-To: <7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com> References: <200810301400.26316.markus.kalkbrenner@arcor.de> <200810301518.26766.m.kruisselbrink@student.tue.nl> <7FD2DE06-838D-4518-A498-7791F967004A@sidepotsinternational.com> Message-ID: <200810301611.11732.markus.kalkbrenner@arcor.de> Am Donnerstag, 30. Oktober 2008 15:42:04 schrieb Darren Oh: > Most often patches are ignored when they are not relevant to the > development version of Drupal. Bugs are sometimes labeled feature > requests by maintainers who are not interested in fixes that only > apply to older versions. In effect they're saying, This doesn't need > to be fixed. You got it to work for you, and other people can wait for > the next version of Drupal. I second that. I made the same experience. In my company we're 10 developers working with drupal. But not anybody is using an unpatched version of drupal in his projects. In our repository we maintain different patches only for bugfixes for drupal's "stable" versions. And it's hard work to merge everthing every time a new drupal security/bugfix release comes out. From my point of such a popular project like drupal should better care about it's stable versions or branches. On the other hand I understand that in a open source project nobody could be forced to do something ... Markus From Kevin.Sookocheff at cbsa-asfc.gc.ca Thu Oct 30 17:16:11 2008 From: Kevin.Sookocheff at cbsa-asfc.gc.ca (Sookocheff, Kevin) Date: Thu, 30 Oct 2008 13:16:11 -0400 Subject: [development] Error running SimpleTest on new installation Message-ID: <1B49F1E3B3E5CE4C8CAD37EB15E549AF0110823C@SD01ITMP02.PROD.NET> Hello, I had checked out a fresh version of Drupal from CVS this morning and each time I run some SimpleTest test cases I receive the following error: Undefined index: test_id in _simpletest_batch_finished() (line 423 of E:\xampp\htdocs\drupal_test\modules\simpletest\simpletest.module). I am new to Drupal development and want to get started by writing some tests and reviewing patches. Does anyone have an idea about fixing the above problem so that I can get started? Thanks, Kevin From sysop at scbbs.com Thu Oct 30 17:32:07 2008 From: sysop at scbbs.com (Ron Parker) Date: Thu, 30 Oct 2008 10:32:07 -0700 (PDT) Subject: [development] The static $perm variable in user_access Message-ID: <24835437.22231225387927457.JavaMail.root@zimbra.thefiengroup.com> The static $perm variable in user_access() contains the permissions that users have. When user_access('ClearCache', NULL, TRUE) is executed, the static $perm value is emptied and re-filled with permissions from the current roles in the $user object . Theorectically, when user_access() is next called, assuming the $ user object contains the same roles, the $perm variable should contain the same permissions which were cached in the first call. This is what happened in Drupal 5.x and the earlier versions of 6.x. This is NOT happening (at least consistently) in the most recent versions of the user.module . I've written a bunch of debug code in the user, node and ogur modules and now have more details. I am printing the output of user_access () every time it is called. When I issue: user_access('ClearCache', NULL, TRUE) Static $perm variable is cleared and re-filled with permissions from current $user object. This is correct. When module_invoke () is immediately executed next: module_invoke('node_content', 'access', 'create', 'story', $user) It will now make another call to user_access() : user_access('create story content', $user) The $user object still contains the same roles. The $perm variable now contains values. This is correct. But the values in $perm are NOT the same as those inserted during the ClearCache call above! They have changed, and NOT from the user_access() function (which I am monitoring)! So the question is: Why has this $perm value changed? So far, I've found this behaviour occurs with OGUR when one of the following modules is installed: ? taxonomy_access ? tac_lite ? menu_breadcrumb ? admin_menu I so far am unable to discover what it is about these modules which is causing this problem. This did not occur in 5.x and earlier 6.x versions of Drupal. Please, please, please help! -ron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081030/c01a5fd9/attachment-0001.htm From karoly at negyesi.net Thu Oct 30 18:15:37 2008 From: karoly at negyesi.net (Karoly Negyesi) Date: Thu, 30 Oct 2008 19:15:37 +0100 (CET) Subject: [development] Turning custom_url_rewrite_* into hooks? In-Reply-To: <86ca3ccb0810291500k12885b37h513459dbca3a38a5@mail.gmail.com> References: <4908706C.4090904@digitalpulp.com> <86ca3ccb0810291500k12885b37h513459dbca3a38a5@mail.gmail.com> Message-ID: The patch you want to help with is http://drupal.org/node/298600 From slc at publicus.net Thu Oct 30 19:34:09 2008 From: slc at publicus.net (Steven Clift) Date: Thu, 30 Oct 2008 14:34:09 -0500 Subject: [development] Looking for local gov, neighborhood association uses of Drupal Message-ID: <490A0C31.6060302@publicus.net> Noting the discussion of Federal government uses of Drupal, are any of you aware of any good examples of local government or neighborhood association uses of Drupal? I am in particular interested in examples which make public meetings more accessible (perhaps allowing comments on agenda items/documents), host active community calendars, or have set up personalized "what's new" e-mail update options. Also reply to: clift at publicus.net Thanks, Steven Clift http://stevenclift.com From killshot91 at comcast.net Thu Oct 30 20:00:02 2008 From: killshot91 at comcast.net (Steve Edwards) Date: Thu, 30 Oct 2008 13:00:02 -0700 Subject: [development] Looking for local gov, neighborhood association uses of Drupal In-Reply-To: <490A0C31.6060302@publicus.net> References: <490A0C31.6060302@publicus.net> Message-ID: <490A1242.6080101@comcast.net> I site I helped on (but was not the primary developer) is for the city of West Linn, OR. The site is http://www.westlinnoregon.gov. I know Brian and Todd at aHa Consulting are also working with other municipalities. Steve Steven Clift wrote: > Noting the discussion of Federal government uses of Drupal, are any of > you aware of any good examples of local government or neighborhood > association uses of Drupal? > > I am in particular interested in examples which make public meetings > more accessible (perhaps allowing comments on agenda items/documents), > host active community calendars, or have set up personalized "what's > new" e-mail update options. > > Also reply to: clift at publicus.net > > Thanks, > Steven Clift > http://stevenclift.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081030/bf4e284e/attachment.htm From darrenoh at sidepotsinternational.com Thu Oct 30 13:50:37 2008 From: darrenoh at sidepotsinternational.com (Darren Oh) Date: Thu, 30 Oct 2008 09:50:37 -0400 Subject: [development] How to post bug reports and patches In-Reply-To: <200810301400.26316.markus.kalkbrenner@arcor.de> References: <200810301400.26316.markus.kalkbrenner@arcor.de> Message-ID: I've experienced the problem you describe many times. It depends on the maintainer for the version of Drupal. killes has been quick to apply fixes to Drupal 4.7. drumm seems to hope people that people will just stop using Drupal 5. Other core maintainers criticize patches for problems they are not interested in, then ignore the patches when they are fixed, apparently hoping the contributor will give up. The most common reason maintainers are not interested in a patch is that they are working on a new version of Drupal which makes the patch obsolete. From metzlerd at metzlerd.com Fri Oct 31 04:27:44 2008 From: metzlerd at metzlerd.com (David Metzler) Date: Thu, 30 Oct 2008 21:27:44 -0700 Subject: [development] The static $perm variable in user_access In-Reply-To: <24835437.22231225387927457.JavaMail.root@zimbra.thefiengroup.com> References: <24835437.22231225387927457.JavaMail.root@zimbra.thefiengroup.com> Message-ID: <93852E0F-BDDB-4914-8216-13292059DC28@metzlerd.com> It sounds like you're suggesting that $perm, a static variable within user_access() is being modified without user_access being called, but within a single page load. That doesn't seem possible in PHP, unless there is a PHP bug. Static variables are supposed to be local in scope to the functions that create them. To prove beyond a shadow of doubt, put a $debug statement in at the very beginning of the function user_access and another at the very end of the function. (just before the return). If what you're saying is true, there will be evidence in the "begin" value being different than the "end" value prior to it. What I suspect is that another module is calling user_access, (perhaps with a different user, or modified roles in between) in between. If you serialize the $user and $perm variables within user_access, you ought to be able to tell. Myself I'd be greping for calls in the modules you suspect. Dave On Oct 30, 2008, at 10:32 AM, Ron Parker wrote: > The static $perm variable in user_access() contains the permissions > that users have. When user_access('ClearCache', NULL, TRUE) is > executed, the static $perm value is emptied and re-filled with > permissions from the current roles in the $user object. > Theorectically, when user_access() is next called, assuming the > $user object contains the same roles, the$perm variable should > contain the same permissions which were cached in the first call. > This is what happened in Drupal 5.x and the earlier versions of > 6.x. This is NOT happening (at least consistently) in the most > recent versions of the user.module. > > I've written a bunch of debug code in the user, node and ogur > modules and now have more details. I am printing the output of > user_access() every time it is called. > > When I issue: > user_access('ClearCache', NULL, TRUE) > > Static $perm variable is cleared and re-filled with permissions > from current $user object. This is correct. > > When module_invoke() is immediately executed next: > module_invoke('node_content', 'access', 'create', 'story', $user) > > It will now make another call to user_access(): > user_access('create story content', $user) > > The $user object still contains the same roles. The $perm variable > now contains values. This is correct. But the values in $perm are > NOT the same as those inserted during theClearCache call above! > They have changed, and NOT from the user_access() function (which I > am monitoring)! So the question is: Why has this $perm value changed? > > So far, I've found this behaviour occurs with OGUR when one of the > following modules is installed: > taxonomy_access > tac_lite > menu_breadcrumb > admin_menu > I so far am unable to discover what it is about these modules which > is causing this problem. This did not occur in 5.x and earlier 6.x > versions of Drupal. > > Please, please, please help! > > -ron > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081030/103e349e/attachment.htm From tomi at vacilando.org Fri Oct 31 12:10:27 2008 From: tomi at vacilando.org (Tomas Fulopp) Date: Fri, 31 Oct 2008 13:10:27 +0100 Subject: [development] How to post bug reports and patches In-Reply-To: References: <200810301400.26316.markus.kalkbrenner@arcor.de> Message-ID: <593475f90810310510w228803berc6c0ba391cd064@mail.gmail.com> Just my two cents - while there are systemic reasons why this happens, the community needs to be able to see the issue purely from Markus's point of view. He seems to be a devoted Drupal developer who has put a lot of his time into developing patches only to see that they are not checked and not committed. That is to say, he has provided what he believes are solutions for various problems in several versions of Drupal, but there is nobody to actually apply them for the benefit of others. I am amazed he wrote such a polite and friendly message, asking what did he do wrong. I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to check other people's patches and they might check yours (I know it works that way, but I think it is not healthy; he already provided a service), or provide statistics on how many people complain and don't review (it is a fact it is easier and faster to spot problems than to solve them). I would be surprised if developers like Markus became a trifle discouraged from providing new patches. To summarize: this is just to show that the answers provided in this thread are unlikely to provide an efficient solution for developers like Markus. We must not be satisfied with such answers and keep searching more effective methods of recognizing and applying results of good coding. And I am sure we'll manage, for this is a marvellous community. Tom?? On Thu, Oct 30, 2008 at 2:50 PM, Darren Oh < darrenoh at sidepotsinternational.com> wrote: > I've experienced the problem you describe many times. It depends on the > maintainer for the version of Drupal. killes has been quick to apply fixes > to Drupal 4.7. drumm seems to hope people that people will just stop using > Drupal 5. Other core maintainers criticize patches for problems they are not > interested in, then ignore the patches when they are fixed, apparently > hoping the contributor will give up. The most common reason maintainers are > not interested in a patch is that they are working on a new version of > Drupal which makes the patch obsolete. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081031/9560b253/attachment-0001.htm From aldo at caonao.cu Fri Oct 31 12:21:16 2008 From: aldo at caonao.cu (Aldo Martinez Selleras) Date: Fri, 31 Oct 2008 07:21:16 -0500 Subject: [development] adding objects and submit data in a node_form() Message-ID: <200810310721.16298.aldo@caonao.cu> hi! i want modify a node_form() function, but, i need to a direct relation between a node and a term in the taxonomy vocabulary, them, i want to add fieldset with a checkbox relation of the terms in the category, now, my question is it, how i add the information in the term_node table when submit the form ?? i hope u understand me. -- ---------------------- Aldo Martinez Selleras Administrador del Nodo CITMATEL GND Camaguey Tel: 32-291661 E-mail: aldo at caonao.cu Linux User #364356 From kaos777 at gmail.com Fri Oct 31 13:15:07 2008 From: kaos777 at gmail.com (Alex Urevick-Ackelsberg) Date: Fri, 31 Oct 2008 09:15:07 -0400 Subject: [development] Looking for local gov, neighborhood association uses of Drupal Message-ID: <37b3830e0810310615j12d40997pe15618e966d07542@mail.gmail.com> We helped to build, and currently maintain, a site for the Town and Village of Rhinebeck, NY. http://rhinebeck-ny.gov -- Alex Urevick-Ackelsberg Partner ZivTech, LLC http://zivtech.com alex at zivtech.com (917) 407-9086 > ---------- Forwarded message ---------- > From: Steven Clift > To: development at drupal.org > Date: Thu, 30 Oct 2008 14:34:09 -0500 > Subject: [development] Looking for local gov, neighborhood association uses > of Drupal > Noting the discussion of Federal government uses of Drupal, are any of you > aware of any good examples of local government or neighborhood association > uses of Drupal? > > I am in particular interested in examples which make public meetings more > accessible (perhaps allowing comments on agenda items/documents), host > active community calendars, or have set up personalized "what's new" e-mail > update options. > > Also reply to: clift at publicus.net > > Thanks, > Steven Clift > http://stevenclift.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.drupal.org/pipermail/development/attachments/20081031/2a0cbb1b/attachment.htm From earnie at users.sourceforge.net Fri Oct 31 13:22:58 2008 From: earnie at users.sourceforge.net (Earnie Boyd) Date: Fri, 31 Oct 2008 09:22:58 -0400 Subject: [development] Looking for local gov, neighborhood association uses of Drupal In-Reply-To: <490A0C31.6060302@publicus.net> References: <490A0C31.6060302@publicus.net> Message-ID: <20081031092258.jpe9tu8k9y0wso8w@mail.progw.org> Quoting Steven Clift : > Noting the discussion of Federal government uses of Drupal, are any > of you aware of any good examples of local government or neighborhood > association uses of Drupal? > > I am in particular interested in examples which make public meetings > more accessible (perhaps allowing comments on agenda > items/documents), host active community calendars, or have set up > personalized "what's new" e-mail update options. > Try a google for ``includes/bootstrap.inc government'' and you'll find a few. http://www.norweld.org/ http://www.npc.edu/ http://www.centerforunreform.org/ Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/ From rob at robshouse.net Fri Oct 31 13:27:06 2008 From: rob at robshouse.net (Robert Douglass) Date: Fri, 31 Oct 2008 14:27:06 +0100 Subject: [development] Digg widget for Drupal.org Packt award story Message-ID: <885F358B-8AF5-4F47-ADC4-6BF5D9C51205@acquia.com> Hi everyone, congrats to all on our sweep of the Packt Open Source CMS awards. Really gerat news. Here's the code for the Digg widget to the Drupal.org story. Let's work together to get this onto the front page of Digg: