Preview: Joomla! Developer - OpenSocial
Joomla! Developer Network - Joomla! Developer NetworkJoomla! - the dynamic portal engine and content management systemLast Build Date: Fri, 10 Feb 2012 11:28:16 +0000
Security Center Thu, 30 Sep 2010 01:57:31 +0000 The Joomla! Project takes security vulnerabilities very seriously. As a member of oCert we follow some specific procedures when dealing with security issues. If you find a possible vulnerability, please report it to the Joomla Security Strike Team first. You can contact the team via email at security@joomla.org. Also let us know via email if you find a reported vulnerability (reported elsewhere). Please include where you saw the report. You can provide patches for any issues that you find when emailing the team. If you want to join the team send an email to security@joomla.org and ask for more details. Due to the sensitive nature of security work the team's membership is restricted, but we welcome anyone who is qualified to contact us about membership. Joomla! Security Strike Team In wild land firefighting, the term "Strike Team" is used to describe a collection of similar resources, which used for a specific purpose (http://en.wikipedia.org/wiki/Strike_Team). The JSST is called a strike team because it's a collection of developers and security experts tasked with improving and managing security for Joomla. Goals Investigate and respond to reported core vulnerabilities. Execute code reviews prior to release to identify new vulnerabilities. Provide public presence regarding security issues. Help the community understand Joomla security. Security Announcement Policy Verified vulnerabilities will only be publicly announced AFTER a release is issued which fixes the vulnerability. All announcements will contain as much information as possible, but will NOT contain step-by-step instructions for the vulnerability. Public Responses Policy Articles are written about Joomla all the time. In many circumstances, these articles (even from reputable sources) contain a significant amount of misinformation. The JSST will assess and address articles written about security issues. If the article contains valid information about a vulnerability not yet fixed, we will ask the publisher to suspend the article until we can fix the issue. If the article contains invalid information, we will note what is invalid, and ask the publisher to either fix or remove the article. The JSST will be available to answer questions/validate any Joomla security-related articles on the publisher's request. Security Release Policy Critical and high-level vulnerabilities trigger an immediate release cycle. Moderate vulnerabilities may trigger a release cycle depending on the specific issue. Low and very low vulnerabilities (and moderates which do not trigger a release cycle) will be included with the next scheduled maintenance release. All security releases will be accompanied by one (or more) appropriate security announcements. Vulnerability Threat Levels There are two main details that contribute to a vulnerabilities priority or "threat level": Impact Critical - "0-day" attacks, and attacks where site control is compromised (allows attacker to take control over site). High - SQL injection attacks, remote file include attacks, and other attack vectors where site data is compromised. Moderate - XSS attacks, write ACL violations (editing or creating of content where not allowed). Low - read ACL violations (reading of content where not allowed). Severity Critical - VERY easy to perform. Relies on no outside information (TRUE 0-day attack). High - Moderately easy to perform. May rely on readily available outside information. Moderate - Not easy to perform. May rely on sensitive information. Low - Difficult to perform. Relies on sensitive information or requires special circumstances to perform. * NOTE: The descriptions are just generic guidelines. Each vulnerability will be assessed for damage potential and will be ranked accordingly. Supported Versions All currently developed and supported versions of Joomla will be actively monitored by the JSST. Currently active versions include: Joomla 2.5.x (until December 2013) Joomla 1.5.x (until April 2012) Joom[...]
Improving Joomla! Mon, 21 Jun 2010 09:31:39 +0000 There are many ways to help with the on-going effort to improve Joomla. Volunteer Your TimeMost of the work for the Joomla! project is done by unpaid volunteers. The major areas where volunteers can get involved are listed below.
Joomla! Student Outreach Program (JSOP)JSOP allows allows students to gain real-world software development experience working with world-class mentors on projects of value to the Joomla! community. This is an all-volunteer program. Students, mentors, and administrators work on a volunteer basis, although there will be cool prizes and achievement certificates for students who successfully complete the program. See the JSOP page for more information. Dedicate Staff TimeOrganizations can participate in the Joomla! community as sponsors, either by donating money or developer time to the project. See the Sponsorship page for more information. Donate MoneyDonations of money to the project are always appreciated. See the Donations page for more information.
Joomla Bug Squad Mon, 21 Jun 2010 09:38:00 +0000 Landing page for the JBS. Should be roughly based on http://docs.joomla.org/Bug_Squad Introduce a summary of what the JBS is. For newbies the next step is to align themselves with one or more teams. In each team page there should be a list of resources (links to tutorials on how to get started, etc). Include a loadposition module of the articles in the Teams/JBS category you can join. Include a link to the most basic common information like setting up a Joomla site from SVN, how to apply a patch, etc.
Joomla! Developer Network Sun, 13 Jun 2010 04:15:11 +0000 Welcome to the shiny new Joomla Developer Network site. Just as our software goes through phases from design through alpha and beta releases and eventually going stable, this site is also going through a similar cycle. Currently we consider it to be at the beta stage of its evolution. In other words, we know there are things missing and some stuff might even be broken, but we'd like people to see it now so we can gather feedback and fix any problems you might find. Please let us know what you think on the developer general mailing list. We look forward to hearing your views. There is always a great deal of activity underway and communicating with other developers in the community is essential. This site is a resource for anyone looking to build or maintain software based on the Joomla platform. There are two main focuses of this site:
Talk with Joomla! DevelopersIf you want to talk Joomla code, come join us on the discussion lists. Joomla! developers can also be found on IRC in the #joomla-dev channel on freenode.net. {loadposition frontpage1}
{loadposition frontpage2}
{loadposition frontpage3}
Getting Started Sun, 13 Jun 2010 04:15:55 +0000 How do you get started with Joomla! development? The answer is organized into three areas below. {loadmodule resources} Reporting and Fixing Issues Anyone is welcome to report issues or bugs in the Joomla! CMS or Joomla! Platform. For the Joomla CMS versions 1.6 and up and Joomla Platform 11.1 and up, report issues on the CMS tracker (for platform issues please use the category "Joomla Libraries"). For the Joomla CMS version 1.5 use the Joomla 1.5 tracker. You will need to register for an account on joomlacode.org to report an issue. The Joomla! Bug Squad (also known as JBS) is the group responsible for sorting out and fixing Joomla! bugs and issues. Who can join the Bug Squad? Anyone who knows how to use Joomla! and is willing to learn how to use our version control software can join the Bug Squad. You do NOT need to be a PHP programmer, although it is a great way to learn and improve your programming skills. How do I get more information? See the Bug Squad article and Bug Squad Portal in the Wiki. How do I join the Bug Squad? Sign up for an account on joomlacode.org, fill out this form, and e-mail a Bug Squad coordinator and ask to join. Writing Joomla! Extensions One of great things about Joomla! is how easy it is to write extensions for. It is designed to be extended, and there is a large and active community of extension developers. For example, the Joomla! Extensions Directory lists over 5,000 extensions available to Joomla! users. Extensions allow Joomla! to be used for just about anything that you can imagine doing with a website. Extensions are developed by individuals, large companies, and everything in between. How do I get started writing Joomla! extensions? There are a number of useful articles in the Wiki to help you get started. Here are a few: Different extension types: http://docs.joomla.org/Tutorial:What_Are_Extensions http://docs.joomla.org/Joomla!_Extensions_Defined Overall index to developer articles: http://docs.joomla.org/Developers Tutorials for different extension types: http://docs.joomla.org/Tutorial:Plugins http://docs.joomla.org/Tutorial:Creating_a_Hello_World_Module_for_Joomla_1.5 http://docs.joomla.org/Developing_a_Model-View-Controller_%28MVC%29_Component_for_Joomla!1.6 Contributing New Features Anyone can contribute new features to Joomla. The Production Leadership Team (PLT) is responsible for deciding which features are included into each version. The general steps for submitting code to the Joomla! CMS are as follows: Sign the Joomla! Contributor Agreement (JCA). This is required so that your code can be included into Joomla! under the GPL license. Click here to sign the agreement on line. Communicate on the CMS list what you are working on and make sure it is consistent with the goals for the upcoming release. Post a description of your project in the CMS Feature Tracker with a status of Open. Request a Subversion branch for your coding and keep the branch up to date with the latest trunk version. You can request a branch by emailing the CMS list. Indicate what your branch is for and whether you would like others to help you with the coding. Someone on the PLT will respond and set up a branch for your work. Working from a branch is not required but is recommended for complex features. Follow the Joomla! Coding Standards and write unit and system tests to document your code and test that it works correctly. Keep other developers and the PLT advised of your project status and invite them to review and comment on your work. When you have work ready for testing, change the feature status on the tracker to Pending. Once it is successfully tested, it will be changed to Ready for Review at which point senior developers will review it. You may also post patches directly to the feature tracker without using a SVN branch. If your code is accepted, your branch or patch will be merged with the SVN trunk during[...]
How New Features are Added to Joomla Thu, 18 Nov 2010 01:59:05 +0000 New ideas come from many places and anyone in the community. We prefer to use the Google Group mailing list for the CMS since it's a great places to brainstorm, but the Joomla People site also works well—or even anywhere Joomla folks congregate. The Production Leadership Team (otherwise known as the PLT) have set up two ways to help manage all the great ideas coming from the community; the Joomla Idea Pool (based on UserVoice) and the Joomla Feature Tracker. The Joomla Idea Pool (JIP) The JIP (located at ideas.joomla.org) is a great way for anyone in the community to make their voice heard and set priorities. Users have up to 10 votes to cast on the various ideas, which will help make clear what future features the community really wants. It is important to understand that not all of these features will be added to Joomla. This may happen for a number of reasons. For example, there may be a great feature proposed but either nobody volunteers to take it on or the PLT concludes it should be a separate extension from the core CMS or platform. Our hope is that many or all of the most popular features on the JIP will have a strong chance of attracting energetic development talent to complete them. Once a feature has moved to the implementation stage, it gets added to the Joomla Feature Tracker. The Joomla Feature Tracker (JFT) The JFT is the team’s way to track the progress of a feature and allows for better collaboration during development. The status of an item in the tracker is gauged according to the following: The feature tracker is used when there is clear intent to provide code to implement the feature. Feature requests should be posted at ideas.joomla.org. Open: All new features start as Open. An open feature could just be an idea. Open features can move to either In Progress if there is code that is available but not ready for testing, Pending if it is ready for tests, or Ready for Review when testing is completed. Pending: A feature is worked on until the owners are satisfied enough that code is ready for testing. At that point move it to Pending. You may wish to announce this on mailing lists or elsewhere. Ready for Review: At this point the owner(s) put the feature in the hands of the PLT (or authorized delegates) to review the feature. The feature can be moved to Approved, Closed or be moved back to In Progress. Closed: If an issue is set to Closed, a reason should be given. For example, it might be that the feature is better suited for a separate extension, it conflicts with another feature, or that the PLT determines it isn’t a good fit. Approved: This is a holding state for all features. Approved is also a holding area for when merging is closed in the trunk. Ready to Commit: When the feature is complete, tested, approved and is ready to commit, whether it’s done in a branch or as a patch, it will be added to the trunk during the feature merge phase of the release cycle. Committed to Github/SVN: This is the final implementation status in the process. The new feature is in the next version of Joomla. FAQ's How do I suggest a new feature for Joomla? One of the key factors in determining future features is how strong the community support is for that idea. The voting system at ideas.joomla.org helps build that support so we recommend you start there. If you have the skills to develop the feature yourself, you can also go straight to the JFT, add a suggested feature, and immediately begin working on your project. Make sure you check the tracker first to make sure your idea isn’t already there. We encourage people with ideas that are very similar or overlap to join forces and work together. Where can I discuss ideas for new Joomla features? Ideas for new features can be discussed anywhere, but the best place to get constructive feedback and increase your chances of getting a feature added to a future rele[...]
Joomla Development Strategy Mon, 21 Jun 2010 09:18:20 +0000 Introduction From its very core, Joomla is designed and built to help bring people together. It is centered on simplicity and ease of use. For these reasons we have a certain way of thinking as we approach Joomla development. Objectives To continue to offer a stable and reliable platform for our current and future user base. To make innovation available to users and developers on a more timely basis. To make it easy for developers to contribute code to the project at any time. There are five major principles to the Joomla development strategy aimed at achieving those objectives: maintain a stable trunk; predictable, incremental software releases; strong backward compatibility support; a sound security policy; and an open development process. Maintain a Stable Trunk It is critical to our mission that the trunk must always contain a stable and tested version of the code base that can be made ready for a release within a short time. To ensure that the trunk is always stable write access is only granted to a limited number of disciplined and trusted people. Trunk represents the current development build, or the most current functioning version of the software. When features or issues are being “worked on” that should happen in a branch or in a separate system altogether until completion. Changes should only be committed to the trunk when they are complete, working, and all automated tests pass. This can be done via a merge back from a branch or via a patch file, depending on the extent of the change. Requirements for inclusion into trunk. There are a few requirements that must be met before changes are considered for inclusion into the trunk. These measures help to ensure that the trunk is always in a stable state. Satisfy the Joomla! Coding Standards. Coding standards exist to keep code consistent, easily readable, and maintainable. Before any code contributions are included into the trunk they should meet the Joomla Coding Standards which are described in detail in the documentation wiki. Pass all automated tests. Automated tests are used to isolate specific parts or features of the software and ensure that they behave correctly. The Joomla project maintains Unit Tests for API classes and methods as well as System Tests for various application functionality. Before code contributions are included into the trunk all the automated tests should pass so that we can be reasonably assured that the trunk remains stable and reliable. Provide automated tests for all new API classes and methods. Any new methods or classes added to the Joomla platform API must be accompanied by working Unit Tests to verify their correct behavior. This serves to help guarantee that not only the current code works, but that future changes do not cause an unstable trunk. Where appropriate system tests should be created to verify expected behavior. Provide basic documentation for all new additions to the code base. To maintain features and systems added to the code base, as well as to help ensure an ability to uphold our principle of backward compatibility some basic documentation is required for new API classes and methods or new application logic when it is added to the trunk. If you are writing a new class or method, describe what it is supposed to be used for and why it exists and a couple of brief examples of its use. For application features, describe the addition or describe each layout and their intended purpose. Predictable, Incremental Software Releases A software release is the distribution of software code, documentation, and support materials. The Joomla project strategy for software releases borrows heavily from the Ubuntu project's time-based release process, which likewise borrowed heavily from the GNOME project. Version Strategy The version identifiers for Joomla follow a three level numerical convention where the leve[...]
Joomla Development Strategy Mon, 21 Jun 2010 09:18:20 +0000 Introduction From its very core, Joomla is designed and built to help bring people together. It is centered on simplicity and ease of use. For these reasons we have a certain way of thinking as we approach Joomla development. Objectives To continue to offer a stable and reliable platform for our current and future user base. To make innovation available to users and developers on a more timely basis. To make it easy for developers to contribute code to the project at any time. There are five major principles to the Joomla development strategy aimed at achieving those objectives: maintain a stable trunk; predictable, incremental software releases; strong backward compatibility support; a sound security policy; and an open development process. Maintain a Stable Trunk ↑ It is critical to our mission that the trunk must always contain a stable and tested version of the code base that can be made ready for a release within a short time. To ensure that the trunk is always stable write access is only granted to a limited number of disciplined and trusted people. Trunk represents the current development build, or the most current functioning version of the software. When features or issues are being “worked on” that should happen in a branch or in a separate system altogether until completion. Changes should only be committed to the trunk when they are complete, working, and all automated tests pass. This can be done via a merge back from a branch or via a patch file, depending on the extent of the change. Requirements for inclusion into trunk. There are a few requirements that must be met before changes are considered for inclusion into the trunk. These measures help to ensure that the trunk is always in a stable state. Satisfy the Joomla! Coding Standards. Coding standards exist to keep code consistent, easily readable, and maintainable. Before any code contributions are included into the trunk they should meet the Joomla Coding Standards which are described in detail in the documentation wiki. Pass all automated tests. Automated tests are used to isolate specific parts or features of the software and ensure that they behave correctly. The Joomla project maintains Unit Tests for API classes and methods as well as System Tests for various application functionality. Before code contributions are included into the trunk all the automated tests should pass so that we can be reasonably assured that the trunk remains stable and reliable. Provide automated tests for all new API classes and methods. Any new methods or classes added to the Joomla platform API must be accompanied by working Unit Tests to verify their correct behavior. This serves to help guarantee that not only the current code works, but that future changes do not cause an unstable trunk. Where appropriate system tests should be created to verify expected behavior. Provide basic documentation for all new additions to the code base. To maintain features and systems added to the code base, as well as to help ensure an ability to uphold our principle of backward compatibility some basic documentation is required for new API classes and methods or new application logic when it is added to the trunk. If you are writing a new class or method, describe what it is supposed to be used for and why it exists and a couple of brief examples of its use. For application features, describe the addition or describe each layout and their intended purpose. Predictable, Incremental Software Releases ↑ A software release is the distribution of software code, documentation, and support materials. The Joomla project strategy for software releases borrows heavily from the Ubuntu project's time-based release process, which likewise borrowed heavily from the GNOME project. Version Strategy The version identifiers for Joomla follo[...]
Backward Compatibility Policy Fri, 20 Aug 2010 08:24:52 +0000 Backward compatibility for any software platform is a high priority. Clean, maintainable code is also a high priority for any software platform. Sadly, in practice, these two ideals are often at odds. Providing backward compatibility support makes software more complex and less maintainable. The Joomla project's policy for addressing these conflicting ideals is as follows: Backward compatibility support is important. During development, alpha testing, and beta testing of new releases, backward-incompatible changes will be considered issues to be resolved. Every effort will be made to make sure that each release of Joomla is backward compatible with the previous minor release. Backward compatibility support will be limited. When a documented API method is removed or changed, the previously documented method will be retained and deprecated. Deprecated methods will have added code to generate deprecation notices when they are used. The deprecation notices will state specifically when the backward-compatibility support for the method will expire. This expiration will be expressed as a release number which could be as early as the next minor release. In this way old API methods will not have to be maintained longer than necessary, but plenty of warning will be given before their removal. When data changes are involved, we will provide data conversion tools that will be available before the GA milestone. It is often very hard to determine if any applications are relying on or extending a subtle feature. Because of this it is difficult to assess whether or not backward-compatibility support needs to be provided for that feature and judgement calls will be made. In these cases if the judgement is wrong it will need to be caught during testing and reported. Backward compatibility support is the responsibility of everyone. It is very important to catch backward compatibility problems during development of new releases. In particular, it is important to test new Joomla releases before they are released in final form. If a backward-compatibility problem is found before the final release, it will be considered an issue and will generally be fixed (by adding backward compatibility support where it is reasonable to do so) if at all possible before the final release. After the final release, we may elect not to fix outstanding or new backward-compatibility problems. Consumers of Joomla have a right to backward compatibility, but they also have a responsibility to test Joomla against their applications during the beta release cycle (or sooner) to make sure their applications work. Commentary Developer API The developer API is the code that a developer uses to write extensions for the Joomla CMS and applications on the Joomla Platform. Where reasonable, new minor releases will be backward compatabie with at least the previous minor release. For example, API not marked as deprecated in version 1.5 will be backward compatible with version 1.6. Unavoidable exceptions can arise (hopefully infrequently). For example, the permission codes in 1.6 are not backward compatible with 1.5 but the goal is for such circumstances to be rare. Contributors will make their best effort to document potential backward compatibility issues. Compatibility between major versions, for example 1.x and 2.x, is desirable but not mandatory nor expected. Data Model Changes to the data model are inevitable in every release. When data model changes occur, they will be documented and an SQL patch will be provided. Where complex transformations are required then code based solutions (for example, upgrade code in the installation or a separate component) will be provided. User Interface and Site Behaviour Changes in the UI between minor r[...]
Joomla Coding Standards Mon, 21 Jun 2010 05:34:59 +0000 The Joomla Coding Standards are based on the PEAR Coding Standards with some small variations as outlined below.
Joomla! Contributors Agreement - Minors Tue, 08 Feb 2011 09:04:32 +0000 This agreement is for individuals who are under 18 years old. Please follow the instructions below. Thanks!
Joomla! Contributors Agreement - Corporations Wed, 09 Feb 2011 05:04:32 +0000 This agreement is for people who work for an organization where the organization owns the copyright of the contributed programming code. Please follow the instructions below. Thanks!
Joomla! Contributors Agreement - Individuals Thu, 10 Feb 2011 04:04:32 +0000 This agreement is for individuals who are at least 18 years old. Please follow the instructions below. Thanks!
Joomla Bug Squad Coding Team Mon, 21 Jun 2010 09:28:33 +0000 The "Golden Path" for any issue (which are usually bugs but can sometimes be other things) in any Joomla release is that it moves through the following statii: Open → Confirmed → Pending → Ready to Commit → Fixed in SVN The Coding Team is responsible for the part of the process that moves issues from Confirmed to Pending. If the bug squad was run like a hospital, then the coding team is like the doctors and specialist that perform surgery on patients that have come up from the emergency room triage.
JSOP 2010 Student Application Template
Wed, 22 Sep 2010 05:41:35 +0000 IntroductionBelow is the application template for students to use when applying for JSOP positions with Joomla! for 2010. To apply, just copy the application into a text document, fill it in, and then email it to jsop@joomla.org.
JSOP 2010 Timeline Wed, 22 Sep 2010 05:39:52 +0000
Introducing the Joomla! Student Outreach Program (JSOP) Wed, 22 Sep 2021 05:34:00 +0000 We are very pleased to announce the first version of the Joomla! Student Outreach Program, or JSOP. The purpose of this program is to provide a structure that allows students to gain real-world software development experience working with world-class mentors on projects of value to the Joomla! community. This is an all-volunteer program. Students, mentors, and administrators work on a volunteer basis, although there will be cool t-shirts and achievement certificates for students who successfully complete one or more projects. Here are some questions and answers about the program.
[20120201] - Core - Information Disclosure Thu, 02 Feb 2012 05:25:21 +0000
DescriptionInadequate validation leads to information disclosure in administrator. Affected InstallsJoomla! version 2.5.0, 1.7.4, and all earlier 1.7.x versions SolutionUpgrade to version 1.7.5 or 2.5.1 or higher Reported by Jakub Galczyk ContactThe JSST at the Joomla! Security Center.
[20120202] - Core - Information Disclosure Thu, 02 Feb 2012 05:25:21 +0000
DescriptionOn some servers the error log could be read by unauthorised users. Affected InstallsJoomla! version 1.7.4 and all earlier 1.7.x versions SolutionUpgrade to version 2.5.1 or 1.7.5 or higher Reported by Alain Rivest ContactThe JSST at the Joomla! Security Center. |
|||||||||||||||||||||||||||||||||||||||||
http://developer.joomla.org/gsoc2008/opensocial.feed?type=rss
Copyright 2006-2012 Feedage.com LLC
Privacy policy - Sitemap - Press - Terms of Service - Copyright information
Contact Us - About Us - Feedage - Search Engine Consulting
Language Detection Powered by
Privacy policy - Sitemap - Press - Terms of Service - Copyright information
Contact Us - About Us - Feedage - Search Engine Consulting
Language Detection Powered by