Joomla! Documentation - User contributions [en]

Talk:Joomla CodeSniffer

2012-12-09T12:32:41Z

Masterchief: /* PSR's */ new section

==Installation ? ==
Is there any reason for not using the "Easy Install method" ? i mean

<code>pear install PHP_CodeSniffer-1.3.0RC1</code>

as described in [http://pear.php.net/package/PHP_CodeSniffer/download/ Installation]

?

--[[User:Elkuku|Elkuku]] 01:26, 19 October 2010 (UTC)

== PSR's ==

I have no idea why PSR-0, 1 and 2 are referenced on this page at all. The Platform doesn't meet PSR-0 nor PSR-1 and deliberately ignores many of the requirements in PSR-2. People submitting code to the Platform or the CMS should be using https://github.com/joomla/coding-standards.

Archived:GSOC 2012 Project Ideas

2012-03-05T03:04:13Z

Masterchief: Reworked format in line with KDE's page.

==Welcome!==
Welcome to the Joomla! Google Summer of Code (GSoC) 2012 project ideas page. As we move forward with the 2012 version of the Joomla! GSoC, we will use this page to develop possible project ideas. Please note that anyone who is interested can participate in this process. You do not have to be a GSoC student or mentor to suggest possible project ideas. Thanks!

Discussion of ideas and other GSoC related items is welcome on our Google Group: https://groups.google.com/forum/?fromgroups#!forum/joomla-gsoc-2012

==Ideas==

Opportunities exist for students to work with projects from either the Joomla CMS, the Joomla Platform or in some cases a combination of both.

In addition to this ideas list, the Joomla! Community is able to voice their opinion on features they would like to see via the [http://ideas.joomla.org/ Joomla! Idea Pool]. Those wishing to add ideas to this listing are encouraged to review the Idea Pool and base their idea on the input received there.

===Joomla CMS===

[http://github.com/joomla/joomla-cms Source Code] [http://groups.google.com/d/forum/joomla-dev-cms Developer Mailing List]

====Project: Social Package====

:'''Brief explanation:''' Over the last several years, social media has become a dominant force in online media. Based on the number of extensions interacting with various social media APIs, it would be logical to build a Social package for the Joomla! Platform that provides a common and simplified interface to post and retrieve data from various social media networks.

:'''Knowledge Prerequisite:''' Joomla Platform, familiarity with social media APIs (Facebook, Twitter, Google+, etc.), OAuth

:'''Difficulty:''' Medium to Hard

:'''Mentor:''' Michael Babker

====Project: New document types====

:'''Brief explanation:''' Create JCard, JCal, JCSV and other extensible classes that will produce standards compliant documents of specific types (e.g. vCard,iCal).

:'''Knowledge Prerequisite:''' Joomla Platform, XML, web standards,

:'''Difficulty:''' Medium to Hard

:'''Mentor:'''

====Project: Language Installation====

Create an interface to install language packs from a generated list of accredited language packs during Joomla installation and subsequently from the administrator interface, either the installer or the language manager.

:'''Knowledge Prerequisite:''' Joomla Platform, JSON

:'''Difficulty:''' Medium to Hard

:'''Mentor:'''

====Project: Joomla Translations====

:'''Brief explanation:''' Create a centralized translation tool, which will be a kind of Facebook Self-Translation App for Joomla! communities to have better translation.

:'''Expected Results:''' The centralized website will make better translations for Joomla! It will help non-English speaking translation teams to get feedback about translation quality from people, who speak the same language. So translation teams can involve more volunteers in translation process. It will help also extension developers to translate their software. It will enable ability to submit a new extension translation INI file in English and get the translated version from the translation teams.

:See
:*[http://www.facebook.com/translations/ Facebook Self-Translation]
:*[http://localize.drupal.org]

:'''Knowledge Prerequisite:''' PHP, JavaScript, MySQL, Joomla! Framework

:'''Difficulty:''' Medium

:'''Mentor:''' Edvard Ananyan

====Project: CMS Unit Testing====

:'''Brief explanation:''' The Joomla CMS has its own set of classes that augment the Joomla platform but these are not well tested. The goal of this project is to improve the code coverage by writing unit tests for library classes specific to the Joomla CMS.

:'''Expected Results:''' The student will be expected to review the current code coverage for the Joomla CMS libraries (/libraries/cms) and write and agreed-upon number of unit tests with particular attention to packages and classes that are below 50% coverage.

:'''Knowledge Prerequisite:''' PHP, PHPUnit

:'''Difficulty:''' Medium

:'''Mentor:'''

===Joomla Platform===

The Joomla Platform allows for ideas that can work within the Joomla CMS, or could be completely separate applications that have no connection at all. The Joomla Platform allows for applications to be built for the command line, process daemons and web services. The follow list outlines some ideas that will be immediately useful for the Joomla Platform project that a student may consider taking on. In addition to PHP libraries, the Joomla Platform also ships with Mootools and project ideas can be related to client-side operations as well as server-side.

[http://github.com/joomla/joomla-platform github Source Code] [http://groups.google.com/d/forum/joomla-dev-platform Developer Mailing List]

====Project: Platform Unit Testing====

:'''Brief explanation:''' The Joomla Platform has a good suite of automated Unit Tests, but code coverage is lacking in some areas. The goal of this project is to improve the code coverage by writing unit tests for the Joomla Platform.

:'''Expected Results:''' The student will be expected to review the current [http://developer.joomla.org/coverage/ code coverage report] for the Joomla Platform and write and agreed-upon number of unit tests with particular attention to packages that are below 50% coverage. Preference should be given to non-deprecated classes but the student may choose from either the core tree (/libraries/joomla) or the legacy tree (/libraries/legacy).

:'''Knowledge Prerequisite:''' PHP, PHPUnit

:'''Difficulty:''' Medium

:'''Mentor:'''

====Project: Joomla Platform Application Directory====

:'''Brief explanation:''' The Joomla project has several directory sites dedicated to extensions for the Joomla CMS (the [http://extensions.joomla.org JED]) and free and commercial resources (the [http://resources.joomla.org JRD]). With the release of the Joomla Platform, and it's particular attention to allowing other types of applications (not just the CMS), there is a need for a new website to act as a directory for these applications. The goal of this project is to build a new Joomla Platform application (not a Joomla component but a full application) to serve as this directory.

:'''Expected Results:''' The student will be expected to build a new web application based on JApplicationWeb and the new Universal Content Model (UCM) package loosely inline with the other Joomla directory sites (the JED and the JRD). This is expected to be a "phase 1" project where the features will include user registration (agreeing to terms) and login, simple information pages (like Joomla articles) and listing pages for Joomla Platform applications. Suitable fields will be required and should include such things as application type (command line application, daemon, web application, web service, etc), what the application does, how to get it and so forth. The student is not expected to design the final template but should look to [http://twitter.github.com/bootstrap/ Bootstrap] for basic inspiration. Simple categorization will also be required. Global search can be added if time permits.

:'''Knowledge Prerequisite:''' PHP, OOP

:'''Difficulty:''' Hard but very rewarding

:'''Mentor:''' Andrew Eddie

Potential backward compatibility issues in Joomla 1.7 and Joomla Platform 11.2

2011-06-03T01:49:38Z

Masterchief:

= Platform =
*JPATH_PLATFORM is now used instead of JPATH_LIBRARIES

== JDatabaseQuery ==

JDatabaseQuery is now abstract due of the work done to support new database engines (Windows Azure and Microsoft SQL Server). This means you '''must''' use <code>$db->getQuery(true);</code> to instantiate a query as is the '''correct''' practice in Joomla 1.6.

== JDocument ==
*getHeadData(), setHeadData() and mergeHeadData() are from now on only present in JDocumentHTML. They have been removed from JDocument and JDocumentXML.<ref>[https://github.com/joomla/joomla-platform/commit/2a72ba9e73dbd4ef1484ef0af29249aa3e0c6067 Remove getHeadData(), setHeadData() and mergeHeadData() from JDocument since it only applies to JDocumentHTML. (GitHub)]</ref>

=== JDocumentHTML ===
*JDocumentHTML::$_links has changed to a multidimensional array. Also the rendering of the link elements has been moved from JDocumentHTML to JDocumentRenderHead.<ref>[https://github.com/joomla/joomla-platform/commit/7884e7d9456afac17558f6e90a0e7e86be8b14f2 Move the rendering of HTML link elements to JDocumentRendererHead. (GitHub)]</ref>

=== JDocumentRendererMessage ===
*A div element with the ID "system-message-container" is always rendered, whether there are messages or not. This ID should not be used in any extension or template.<ref>[https://github.com/joomla/joomla-platform/commit/bade3acf0f5ea588be92cb24d4237228c043a3c7 Modify JDocumentRendererMessage to always render <div id="system-message-container"></div>. This makes it possible to render messages via JavaScript. (GitHub)]</ref>

== JURI ==
*The unused parameter $akey has been removed from JURI::buildQuery().<ref>[https://github.com/joomla/joomla-platform/commit/14ebbbd702c2d79098057647fcc4603157896509 Remove an unused paramet in JURI::buildQuery(). (GitHub)]</ref>

== JLoader ==
*JLoader can't load files multiple times anymore.<ref>[https://github.com/joomla/joomla-platform/commit/bfef02de71db7aa5cb46ffdff92778fd6f14f621 Use include_once instead of include in JLoader (GitHub)]</ref>

= CMS =

== General Coding Principles ==

Within the new Joomla release cycle, developers need to be conscious of more frequent changes to version numbers. If you are doing hard checks against, for example, a version number exactly equal to "1.6" then as we move to 1.7, those checks may fail with unexpected results. You should ensure that version checks appropriately allow for future increments like 1.7, 1.8, 2.0, 3.0, and so on.

= References =
<references />

Potential backward compatibility issues in Joomla 1.7 and Joomla Platform 11.2

2011-06-03T01:39:09Z

Masterchief: Added note for JDatabaseQuery

Archived:GCI 2010-11

2010-10-29T23:42:47Z

Masterchief: /* Intermediate */

== Google Code-in 2010-2011 ==

=== Introduction ===

[http://code.google.com/gci Google Code-in] (GCI) is a contest for pre-university (13-18 year old) students, that aims at helping students get involved in Open Source projects.

[http://code.google.com/opensource/gci/2010-11/faqs.html Google Code-in Frequently Asked Questions]

This list is a work in progress. The final listing for each task that is offered to students must include:

# A specific work product, whether a piece of code, a written report, a piece of writing, a website or an image.
# Evaluation criteria which will be used for determining whether the task has been successfully completed.
# A list of any resources that would be useful for the student doing the project. These will usually be links to information but could something else.
# A difficulty rating (we are using challenging, intermediate, basic).

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

====== Challenging ======
# Add the ability for the Mass Mail feature in Joomla 1.6 to be able to send HTML messages.
# Add a batch update facility to the Joomla 1.6 user manager to be able to batch add, remove or set the user groups for users in a list.
# Create a bulk import utility for the Joomla! user manager to create from a csv file and optionally notify users of their account details via email.
# Create a plugin to allow users to delete their accounts.
# Create a new component syndicate a combined feed from two separate components.
# Create a new document type: vcalendar.
# Create a new document type: ical.
# Create a new document type: rdf.
# Create a new document type: hcard.
# Create a new document type: csv.
# Create a new document type: vcard.
# Implement frontend editing for com_contact.
# Implement frontend editing for com_newsfeeds.
# Implement a method for Apply in the front end for com_content or com_weblinks.
# Create a component that would allow a backend user to change his or her password and other account settings in the backend without having access to the com_users user interface.
# Create a Debian package for Joomla! 1.6. Document the process.
# Create a Debian package for the Joomla! Framework. Document the process.
# Create a RPM package for Joomla! 1.6. Document the process.
Resources: http://en.wikipedia.org/wiki/RPM_Package_Manager
http://www.rpm.org/
# Create a RPM package for Joomla! 1.6. Document the process.
Resources: http://en.wikipedia.org/wiki/RPM_Package_Manager
http://www.rpm.org/

====== Intermediate ======

#Create a custom document type to download vcard information in RDF format.
#Create a Google Map user plugin for display based on address information in com_contact.
#Create a plugin that stores information from specific fields in a profile plugin in the jos_contact_details table
#Create a plugin that parses actions from Mosets Tree and stores them in Scout (directory monitoring)
#Create an administrator module for quick article create that could replace Quick Icons.

====== Basic ======
#Create a module to display a list of contacts in a category
#Create a module to display a list of newsfeeds in a category.
#Create user plugin to display a Twitter feed.
#Create a user plugin to display a Facebook feed.

==== Documentation ====

====== Challenging ======
#Document a complete class of the Joomla! Framework including appropriate code examples from the Joomla! core or elsewhere. (This task can be repeated for each framework class).
#Create a document describing the observer design pattern and how it is implemented in Joomla! plugins.
#Consult with the Joomla! development community and draft proposed code style standards for XML.

====== Intermediate ======
#Document the use of alternative component layouts and provide a detailed commented example for each of the core components.
#Document the use of alternative module layouts and provide detailed commented examples for at least 5 core modules.
#Document how to create a custom document type, using a core component as an example (document types might be rdf, csv, hcard, ical, hcal etc).

====== Basic ======

For each of these create a page in docs.joomla.org
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.
# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.
# Describe how a template designer can create a template parameter to for the site owner to include their Google Analytics code in the template automatically.
# Describe how to restore the default ACL settings.

==== Outreach ====

====== Challenging ======

# Do a presentation for a local club, school or group on how to create a Joomla! Website. Write a brief report about the experience. (Can be done by several people)
# Create a Joomla! website for a non profit organization. Write a report about the experience. (Can be done by several people)
# Create a survey of third party developers to learn how closely they follow Joomla! core development and what forms of communication about core development they would find most useful.
# Organize an Install Fest where a group of students in your school can install and start creating a Joomla! website.

====== Intermediate ======

# Translate the Evaluators Persona (http://docs.joomla.org/Evaluators) into a language other than English.
# Write an article for the Joomla! Community Magazine
# Write an article about Joomla! or the Joomla! Project for your school newspaper or a local newspaper.
# Meet with the team working on the redesign of joomla.org and write an article about the current status. (Can be repeated every 2 weeks)
# Staff or help staff a Joomla! table or booth at a local IT Expo or event (To do this you must submit information about the specific event before hand and write a short report about it afterwards.)
# Design and create a media resource pack (PSD's or similar, logo's, etc) that a Joomla! Day can use to promote their event on web sites or using printed material.
# Design and create a media resource pack (PSD's or similar, logo's, etc) that a Joomla User Group can use to promote their group on web sites or using printed material.
# Design a logo or badge for one of the official groups (Joomla Bug Squad, Joomla Extension Directory) on the people.joomla.org site. (Can be repeated)

====== Basic ======

# Create a standard "Download Joomla!" module that Joomla! fans can use on their sites.
# Create list of online media outlets for distribution of Joomla! announcements
# Create a document on ways to leverage participation in the Joomla! Project to promote your Joomla! Business (ideas like putting a link in your forum signature, listing on the Resources Directory and so on).
# Create contributing author badge for the Joomla! Community Magazine
# Update Author Resources content for the Joomla! Community Magazine
# Create a powerpoint presentation (or similar) on the new user features in Joomla 1.6 that could be used at conference presentations (including good slide notes).
# Create an information PDF about how to run a Joomla Day, how to register the event with Joomla, and include links to key and useful resources.
# Create an information PDF about how to set up a Joomla User Group in your area, how to register the group with Joomla, and include links to key and useful resources.

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

====== Challenging ======
# Write a PHPUnit test for a package or sub-package in the Joomla Libraries.(multiple opportunities exist for this task).
# Write a Selenium System test to cover a unit of the CMS functionality.(multiple opportunities exist for this task).

====== Intermediate ======
# Take a package or sub-package from the Joomla Libraries and ensure that the code formatting complies with our standards, and make corrections as appropriate (multiple opportunities exist for this task).

====== Basic ======

#Review 24 hours of posts in the New to Joomla! forums and report on the most common problems reported.
#Review 24 hours of posts in the Administration forums and report on the most common problems reported.

==== Research ====

Tasks related to studying a problem and recommending solutions

====== Challenging ======

# Research how to read/write video metadata in MP4 and webm containers. Write a report summarizing what you learn for the development team.
# Research the best server side tools/methods to transcode video from various formats to those MP4 and webm containers including various compression schemes and settings for different screen formats (for Example transcoding to an iOS device like iPhone/Pod/Pad vs the full TV experience. Write a report summarizing what you learn for the development team.
# Research various online resources for video metadata along with the strengths and weaknesses of their API's, access rules and licensing restrictions. Write a report summarizing what you learn for the development team.
# Research what it would take to start using PHAR packages for distributing the framework
(See http://www.php.net/manual/en/intro.phar.php). Write a report for the development team.

# Review the W3C Authoring Tool Accessibility Guidelines (ATAG) 1.0 checkpoints and document where Joomla! does and does not meet them.
# Review the W3C Authoring Tool Accessibility Guidelines 2.0 (http://www.w3.org/TR/ATAG20/) and write a report on what would be needed for Joomla! 1.7 to meet them.

====== Intermediate ======

# With Joomla's Google Analytics data, analyse the data for the past six months and make comments about how people are using www.joomla.org (entry points, exist points, etc).

====== Basic ======

# Analyze usage statistics for Joomla! Community Magazine and recommend changes to increase traffic
# Write a report on how you would improve one of the www.joomla.org sites to make it easier for people who don't know anything about Joomla to find information.

==== Training ====

Tasks related to helping others learn more

====== Challenging ======

# Suppose a teacher in your school was going to spend a month teaching his or her students to use Joomla! to make a website. Interview a teacher in your school about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.
# Suppose a teacher in your school was going to spend a month teaching his or her students to develop a simple Joomla! component. Interview a teacher in your school about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.
# Suppose a teacher in your school was going to spend a month teaching his or her students to create a Joomla! template. Interview a teacher in your school (this might be an art teacher) about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.

====== Intermediate ======

# Create a guide to Joomla! resources, documents and sites for someone who has "inherited" a Joomla! site from somebody else and has never used Joomla! before. Create a persona for this profile in docs.joomla.org and link all resources to the persona page.

====== Basic ======
# Create a "HTML Basics" document aimed at someone who has a Joomla! site but has only used a WYSIWYG editor.
# Create a "CSS Basics" document aimed at someone with no web background.

==== Translation ====

Tasks related to localization

(Multiple opportunities exist for each of these but may be limited by the availability of mentors in a specific language. Limit of one instance of each task per distinct language.)

====== Challenging ======
# For a language that does not have an accredited translation team, begin the process of organizing a team. Completion of this task will involve contacting the translation coordinators, using resources such as local JUGs and the Joomla! Forums and People site to find collaborators, learning to use com_localise, and beginning the translation process.
# For a language that does not have an accredited translation team, provide a translation of core strings.

====== Intermediate ======
# Translate the Absolute Beginner's Guide (http://docs.joomla.org/Beginners) into a language besides English.
# Translate the documentation on creating translations and becoming an accredited translation team into a language besides English.
# Translate the security documentation into a language other than English. (http://docs.joomla.org/Security)

====== Basic ======
# Provide an accredited translation team with translation of sample data.
# Provide an accredited translation team with the translation of the help screens for one complete component.
# Provide an accredited translation team with translation of 100 strings.

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

====== Challenging ======

# Card sorting studies are a basic approach to usability testing (http://www.deyalexander.com.au/resources/uxd/card-sorting.html ). Research card sorting and design a set of cards that could be used for analyzing usability in the Joomla! Administrator. Have at least one user try the card sorting task. Document your work and the results of the test case so that others know how to use the cards to test usability.
# Card sorting studies are a basic approach to usability testing (http://www.deyalexander.com.au/resources/uxd/card-sorting.html). Research card sorting and design a set of cards that could be used for analyzing usability of the docs.joomla.org. Have at least one user try the card sorting task. Document your work and the results of the test case so that others know how to use the cards to test usability.

# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Creating an article in the administrator.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Installing an extension.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Updating Joomla!.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Creating a menu item.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks and document a think out loud procedure for it and carry out a test with at least 3 users: Configuring permissions to achieve a specific goal.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks and document a think out loud procedure for it and carry out a test with at least 3 users: Creating an new action permissions user group.

====== Intermediate ======

# Create a document about techniques for usability testing for developers.
# Check a standard installation of Joomla with the default template against a colour-blind checking site, then install a freely available template and do the same. Report any interesting results.

====== Basic ======

# Check a standard installation of Joomla 1.6 against a HTML and CSS validation site. Report back any errors that you find.
# Identify 10 common tasks in the Joomla! administrator and record step by step the number of clicks it takes to completion.

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-29T23:38:15Z

Masterchief: /* Basic */

== Google Code-in 2010-2011 ==

=== Introduction ===

[http://code.google.com/gci Google Code-in] (GCI) is a contest for pre-university (13-18 year old) students, that aims at helping students get involved in Open Source projects.

[http://code.google.com/opensource/gci/2010-11/faqs.html Google Code-in Frequently Asked Questions]

This list is a work in progress. The final listing for each task that is offered to students must include:

# A specific work product, whether a piece of code, a written report, a piece of writing, a website or an image.
# Evaluation criteria which will be used for determining whether the task has been successfully completed.
# A list of any resources that would be useful for the student doing the project. These will usually be links to information but could something else.
# A difficultly rating (we are using challenging, intermediate, basic).

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

====== Challenging ======
# Add the ability for the Mass Mail feature in Joomla 1.6 to be able to send HTML messages.
# Add a batch update facility to the Joomla 1.6 user manager to be able to batch add, remove or set the user groups for users in a list.
# Create a bulk import utility for the Joomla! user manager to create from a csv file and optionally notify users of their account details via email.
# Create a plugin to allow users to delete their accounts.
# Create a new component syndicate a combined feed from two separate components.
# Create a new document type: vcalendar.
# Create a new document type: ical.
# Create a new document type: rdf.
# Create a new document type: hcard.
# Create a new document type: csv.
# Create a new document type: vcard.
# Implement frontend editing for com_contact.
# Implement frontend editing for com_newsfeeds.
# Implement a method for Apply in the front end for com_content or com_weblinks.
# Create a component that would allow a backend user to change his or her password and other account settings in the backend without having access to the com_users user interface.
# Create a Debian package for Joomla! 1.6. Document the process.
# Create a Debian package for the Joomla! Framework. Document the process.
# Create a RPM package for Joomla! 1.6. Document the process.
Resources: http://en.wikipedia.org/wiki/RPM_Package_Manager
http://www.rpm.org/
# Create a RPM package for Joomla! 1.6. Document the process.
Resources: http://en.wikipedia.org/wiki/RPM_Package_Manager
http://www.rpm.org/

====== Intermediate ======

#Create a custom document type to download vcard information in RDF format.
#Create a Google Map user plugin for display based on address information in com_contact.
#Create a plugin that stores information from specific fields in a profile plugin in the jos_contact_details table
#Create a plugin that parses actions from Mosets Tree and stores them in Scout (directory monitoring)
#Create an administrator module for quick article create that could replace Quick Icons.

====== Basic ======
#Create a module to display a list of contacts in a category
#Create a module to display a list of newsfeeds in a category.
#Create user plugin to display a Twitter feed.
#Create a user plugin to display a Facebook feed.

==== Documentation ====

====== Challenging ======
#Document a complete class of the Joomla! Framework including appropriate code examples from the Joomla! core or elsewhere. (This task can be repeated for each framework class).
#Create a document describing the observer design pattern and how it is implemented in Joomla! plugins.
#Consult with the Joomla! development community and draft proposed code style standards for XML.

====== Intermediate ======
#Document the use of alternative component layouts and provide a detailed commented example for each of the core components.
#Document the use of alternative module layouts and provide detailed commented examples for at least 5 core modules.
#Document how to create a custom document type, using a core component as an example (document types might be rdf, csv, hcard, ical, hcal etc).

====== Basic ======

For each of these create a page in docs.joomla.org
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.
# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.
# Describe how a template designer can create a template parameter to for the site owner to include their Google Analytics code in the template automatically.
# Describe how to restore the default ACL settings.

==== Outreach ====

====== Challenging ======

# Do a presentation for a local club, school or group on how to create a Joomla! Website. Write a brief report about the experience. (Can be done by several people)
# Create a Joomla! website for a non profit organization. Write a report about the experience. (Can be done by several people)
# Create a survey of third party developers to learn how closely they follow Joomla! core development and what forms of communication about core development they would find most useful.
# Organize an Install Fest where a group of students in your school can install and start creating a Joomla! website.

====== Intermediate ======

# Translate the Evaluators Persona (http://docs.joomla.org/Evaluators) into a language other than English.
# Write an article for the Joomla! Community Magazine
# Write an article about Joomla! or the Joomla! Project for your school newspaper or a local newspaper.
# Meet with the team working on the redesign of joomla.org and write an article about the current status. (Can be repeated every 2 weeks)
# Staff or help staff a Joomla! table or booth at a local IT Expo or event (To do this you must submit information about the specific event before hand and write a short report about it afterwards.)

====== Basic ======

# Create a standard "Download Joomla!" module that Joomla! fans can use on their sites.
# Create list of online media outlets for distribution of Joomla! announcements
# Create a document on ways to leverage participation in the Joomla! Project to promote your Joomla! Business (ideas like putting a link in your forum signature, listing on the Resources Directory and so on).
# Create contributing author badge for the Joomla! Community Magazine
# Update Author Resources content for the Joomla! Community Magazine
# Create a powerpoint presentation (or similar) on the new user features in Joomla 1.6 that could be used at conference presentations (including good slide notes).
# Create an information PDF about how to run a Joomla Day, how to register the event with Joomla, and include links to key and useful resources.
# Create an information PDF about how to set up a Joomla User Group in your area, how to register the group with Joomla, and include links to key and useful resources.

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

====== Challenging ======
# Write a PHPUnit test for a package or sub-package in the Joomla Libraries.(multiple opportunities exist for this task).
# Write a Selenium System test to cover a unit of the CMS functionality.(multiple opportunities exist for this task).

====== Intermediate ======
# Take a package or sub-package from the Joomla Libraries and ensure that the code formatting complies with our standards, and make corrections as appropriate (multiple opportunities exist for this task).

====== Basic ======

#Review 24 hours of posts in the New to Joomla! forums and report on the most common problems reported.
#Review 24 hours of posts in the Administration forums and report on the most common problems reported.

==== Research ====

Tasks related to studying a problem and recommending solutions

====== Challenging ======

# Research how to read/write video metadata in MP4 and webm containers. Write a report summarizing what you learn for the development team.
# Research the best server side tools/methods to transcode video from various formats to those MP4 and webm containers including various compression schemes and settings for different screen formats (for Example transcoding to an iOS device like iPhone/Pod/Pad vs the full TV experience. Write a report summarizing what you learn for the development team.
# Research various online resources for video metadata along with the strengths and weaknesses of their API's, access rules and licensing restrictions. Write a report summarizing what you learn for the development team.
# Research what it would take to start using PHAR packages for distributing the framework
(See http://www.php.net/manual/en/intro.phar.php). Write a report for the development team.

# Review the W3C Authoring Tool Accessibility Guidelines (ATAG) 1.0 checkpoints and document where Joomla! does and does not meet them.
# Review the W3C Authoring Tool Accessibility Guidelines 2.0 (http://www.w3.org/TR/ATAG20/) and write a report on what would be needed for Joomla! 1.7 to meet them.

====== Intermediate ======

# With Joomla's Google Analytics data, analyse the data for the past six months and make comments about how people are using www.joomla.org (entry points, exist points, etc).

====== Basic ======

# Analyze usage statistics for Joomla! Community Magazine and recommend changes to increase traffic
# Write a report on how you would improve one of the www.joomla.org sites to make it easier for people who don't know anything about Joomla to find information.

==== Training ====

Tasks related to helping others learn more

====== Challenging ======

# Suppose a teacher in your school was going to spend a month teaching his or her students to use Joomla! to make a website. Interview a teacher in your school about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.
# Suppose a teacher in your school was going to spend a month teaching his or her students to develop a simple Joomla! component. Interview a teacher in your school about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.
# Suppose a teacher in your school was going to spend a month teaching his or her students to create a Joomla! template. Interview a teacher in your school (this might be an art teacher) about what resources would be useful for that and create a resource portal of links and materials on docs.joomla.org.

====== Intermediate ======

# Create a guide to Joomla! resources, documents and sites for someone who has "inherited" a Joomla! site from somebody else and has never used Joomla! before. Create a persona for this profile in docs.joomla.org and link all resources to the persona page.

====== Basic ======
# Create a "HTML Basics" document aimed at someone who has a Joomla! site but has only used a WYSIWYG editor.
# Create a "CSS Basics" document aimed at someone with no web background.

==== Translation ====

Tasks related to localization

(Multiple opportunities exist for each of these but may be limited by the availability of mentors in a specific language. Limit of one instance of each task per distinct language.)

====== Challenging ======
# For a language that does not have an accredited translation team, begin the process of organizing a team. Completion of this task will involve contacting the translation coordinators, using resources such as local JUGs and the Joomla! Forums and People site to find collaborators, learning to use com_localise, and beginning the translation process.
# For a language that does not have an accredited translation team, provide a translation of core strings.

====== Intermediate ======
# Translate the Absolute Beginner's Guide (http://docs.joomla.org/Beginners) into a language besides English.
# Translate the documentation on creating translations and becoming an accredited translation team into a language besides English.
# Translate the security documentation into a language other than English. (http://docs.joomla.org/Security)

====== Basic ======
# Provide an accredited translation team with translation of sample data.
# Provide an accredited translation team with the translation of the help screens for one complete component.
# Provide an accredited translation team with translation of 100 strings.

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

====== Challenging ======

# Card sorting studies are a basic approach to usability testing (http://www.deyalexander.com.au/resources/uxd/card-sorting.html ). Research card sorting and design a set of cards that could be used for analyzing usability in the Joomla! Administrator. Have at least one user try the card sorting task. Document your work and the results of the test case so that others know how to use the cards to test usability.
# Card sorting studies are a basic approach to usability testing (http://www.deyalexander.com.au/resources/uxd/card-sorting.html). Research card sorting and design a set of cards that could be used for analyzing usability of the docs.joomla.org. Have at least one user try the card sorting task. Document your work and the results of the test case so that others know how to use the cards to test usability.

# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Creating an article in the administrator.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Installing an extension.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Updating Joomla!.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks create and document a think out loud procedure and carry out a test with at least 3 users: Creating a menu item.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks and document a think out loud procedure for it and carry out a test with at least 3 users: Configuring permissions to achieve a specific goal.
# Think out loud studies are another basic type of usability research (http://en.wikipedia.org/wiki/Think_aloud_protocol). For the following tasks and document a think out loud procedure for it and carry out a test with at least 3 users: Creating an new action permissions user group.

====== Intermediate ======

# Create a document about techniques for usability testing for developers.
# Check a standard installation of Joomla with the default template against a colour-blind checking site, then install a freely available template and do the same. Report any interesting results.

====== Basic ======

# Check a standard installation of Joomla 1.6 against a HTML and CSS validation site. Report back any errors that you find.
# Identify 10 common tasks in the Joomla! administrator and record step by step the number of clicks it takes to completion.

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-29T04:44:41Z

Masterchief: /* Research */

Archived:GCI 2010-11

2010-10-29T04:39:56Z

Masterchief: /* User Interface */

Archived:GCI 2010-11

2010-10-29T00:23:40Z

Masterchief: /* Documentation */

== Google Code-in 2010-2011 ==

=== Introduction ===

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

# Add the ability for the Mass Mail feature in Joomla 1.6 to be able to send HTML messages.
# Add a batch update facility to the Joomla 1.6 user manager to be able to batch add, remove or set the user groups for users in a list.

==== Documentation ====

Tasks related to creating/editing documents
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.
# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.
# Describe how a template designer can create a template parameter to for the site owner to include their Google Analytics code in the template automatically.

==== Outreach ====

Tasks related to community management and outreach/marketing
# Write an article for the Joomla! Community Magazine
# Recruit new authors for the Joomla! Community Magazine
# Create contributing author badge for the Joomla! Community Magazine
# Create list of online media outlets for distribution of Joomla! announcements

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

# Take a package or sub-package from the Joomla Libraries and ensure that the code formatting complies with our standards, and make corrections as appropriate (multiple opportunities exist for this task).

==== Research ====

Tasks related to studying a problem and recommending solutions

==== Training ====

Tasks related to helping others learn more
# Create instructional videos for new Joomla! Community Magazine authors
# Update Author Resources content for the Joomla! Community Magazine

==== Translation ====

Tasks related to localization
# Recruit new non-english language contributions to the Joomla! Community Magazine

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-29T00:14:08Z

Masterchief: /* Quality Assurance */

== Google Code-in 2010-2011 ==

=== Introduction ===

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

# Add the ability for the Mass Mail feature in Joomla 1.6 to be able to send HTML messages.
# Add a batch update facility to the Joomla 1.6 user manager to be able to batch add, remove or set the user groups for users in a list.

==== Documentation ====

Tasks related to creating/editing documents
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.
# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.

==== Outreach ====

Tasks related to community management and outreach/marketing

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

# Take a package or sub-package from the Joomla Libraries and ensure that the code formatting complies with our standards, and make corrections as appropriate (multiple opportunities exist for this task).

==== Research ====

Tasks related to studying a problem and recommending solutions

==== Training ====

Tasks related to helping others learn more

==== Translation ====

Tasks related to localization

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-29T00:11:39Z

Masterchief: /* Code */

Archived:GCI 2010-11

2010-10-28T23:59:49Z

Masterchief: /* Documentation */

== Google Code-in 2010-2011 ==

=== Introduction ===

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

==== Documentation ====

Tasks related to creating/editing documents
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.
# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.

==== Outreach ====

Tasks related to community management and outreach/marketing

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

==== Research ====

Tasks related to studying a problem and recommending solutions

==== Training ====

Tasks related to helping others learn more

==== Translation ====

Tasks related to localization

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-28T23:56:00Z

Masterchief:

== Google Code-in 2010-2011 ==

=== Introduction ===

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

==== Documentation ====

Tasks related to creating/editing documents
# Describe the way view access levels can be expanded in Joomla 1.6 and how a site owner would use them to control the visible access to site content.

# Describe the meanings of the core permissions in Joomla 1.6 and the four levels over which they can be applied.
# Describe the Global Level of permissions in Joomla 1.6 and how a site owner might use them to broadly control site access.
# Describe the Component Level of permissions in Joomla 1.6 and how a site owner can restrict users in groups to certain components.
# Describe the Category Level permissions in Joomla 1.6 and how a site owner can restrict content providers to create, edit and delete content in those categories.
# Describe the Article Level permissions in Joomla 1.6 and how a site owner can restrict content providers to edit and delete their articles.
# Describe how site owners can use the Edit Own permission effectively in Joomla 1.6.

==== Outreach ====

Tasks related to community management and outreach/marketing

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

==== Research ====

Tasks related to studying a problem and recommending solutions

==== Training ====

Tasks related to helping others learn more

==== Translation ====

Tasks related to localization

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

[[Category:GCI]]

Archived:GCI 2010-11

2010-10-28T23:45:48Z

Masterchief: New page: == Google Code-in 2010-2011 == === Introduction === === Proposed Tasks === ==== Code ==== Tasks related to writing or refactoring code ==== Documentation ==== Tasks related to cre...

== Google Code-in 2010-2011 ==

=== Introduction ===

=== Proposed Tasks ===

==== Code ====

Tasks related to writing or refactoring code

==== Documentation ====

Tasks related to creating/editing documents

==== Outreach ====

Tasks related to community management and outreach/marketing

==== Quality Assurance ====

Tasks related to testing and ensuring code is of high quality

==== Research ====

Tasks related to studying a problem and recommending solutions

==== Training ====

Tasks related to helping others learn more

==== Translation ====

Tasks related to localization

==== User Interface ====

Tasks related to user experience research or user interface design and interaction

[[Category:GCI]]

Bug Squad

2010-08-12T10:48:32Z

Masterchief:

[[Image:workgroups_bugsquad.jpg|right]]

The Joomla! Bug Squad (JBS) is a team within the production working group. Their job is to identify and fix bugs in Joomla. This includes the following:

* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] and [http://forum.joomla.org/viewforum.php?f=579 Joomla! 1.6 Beta Bug Reporting Forum] for reported issues and help community members with solving these issues.
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Version 1.5 Bug Tracker]] and [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Version 1.6 Issue Tracker]] .
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].

The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!

The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:
* Tracker Team - monitors the forums and trackers
* Coding Team - creates patches for Confirmed Issues
* Testing Team - tests Pending issues
* Automated Testing Team - creates automated system and unit tests for tracker issues
* Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.

These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.

If you are a member of the JBS, you might also like to join the JBS group at [http://people.joomla.org/groups/viewgroup/95-Joomla+Bug+Squad.html people.joomla.org].

===Tracker Team===
This team has the very important and sometimes difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.

Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.

The Tracker Team should also make sure the issue has the correct Type and Priority. Remember, many users reporting bugs are not familiar with all of the fields and terminology. In many cases, this could be the user's first contribution or interaction with the project.

It is critically important that all JBS members follow the Code of Conduct and show courtesy and respect in all tracker comments. Remember, we are the ambassadors of the Joomla! project, and the way we behave reflects on the whole project. People will naturally be unhappy if an issue they report is not taken seriously or if they feel that it was closed improperly. So we need to be sensitive to that fact, while of course making the what we believe to be the correct decision. For example, if you close an issue as Not a Bug, please put a comment in telling the reporter why in a nice way.

Also, if someone is not following the Code of Conduct in a tracker comment, please point this out in a respectful way and remind the person that we need to follow the CoC at all times. If there is a persistent problem, please let your Team Leader or a JBS Coordinator know so we can take action. We absolutely do not want to tolerate rude or disrespectful behavior in the tracker or forum.

For more information see the [[Tracker Team]] page.

===Coding Team===
The coding team works with Confirmed issues and creates patches to correct these issues if they haven't already been provided. When a patch is completed, and when a test plan has been added that tells the testers how to test the patch, the issue is changed to Pending status.

Many times the first patch submitted for an issue will not be the actual patch that is committed to the SVN. There are many reasons for this. Someone else may have a different approach to the solving the issue, a tester might find a problem, or the person who submitted the patch will think of a better way to do it.

It is important to be positive and flexible and not expect that every patch you submit will go straight into the SVN. That does not mean the work is not helpful or valuable. In many cases, it is not possible to get to the end result without going through one or more tries.

For more information see the [[Bug Squad Coding Team]] page.

===Testing Team===
This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.

Over time, we plan to include more automated testing into the process. Eventually, we would like every Ready to Commit issue have both a code patch and an automated system or unit test. Accordingly, it will be important for members of the testing team to be learning how to write and use system tests.

There are some tips for testing in the wiki in the [[Testing Checklists]] article.

===Automated Testing Team===
Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.

For more information see the [[Automated Testing Team]] page.

===Migration / Upgrade Team===
This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Tracking Process

2010-08-12T10:45:40Z

Masterchief: /* Issue Priorities */

=Overview=
The [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Joomla! Bug Tracker] is the place where all Joomla! bugs are tracked. This article documents the current Joomla! bug tracking process from the time a new bug is reported to the time it is closed.

=Reporting Issues=

[[Image:ReportingIssues.jpg|1024 px]]

The process is normally started in one of two ways: the bug is added to the tracker, or a user reports the bug in the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Forum] for the given maintenance release.

== Issues reported on the forum ==

JBS members scan the forums to determine when issues need to be put into the tracker. If the issue can be reproduced, is clearly a bug, and there are step-by-step instructions for how to reproduce it, it can be entered into the tracker with a status of Confirmed. If it is not as clear-cut, it can be entered with a status of Open, so that other JBS members will know it needs further investigation.

== Issues directly reported to the tracker ==

When an issue is added to the tracker, the status will be either
1. Open
2. Confirmed
3. or Pending
depending on the situation. If the issue needs more investigation, then it should be set to Open. If the issue (1) is a bug and (2) can be reproduced and (3) has good test instructions, it should be set to Confirmed. If it meets the three Confirmed criteria and also has a good patch attached, it should be set to Pending. See below for more information about the status codes.

== Issue Priorities ==

Most issues are priority 3, or Normal. The artifacts are prioritized according to the following characteristics:

'''Critical (1):'''
The trunk is not working at all. Significant parts of the source are broken preventing key operations. Examples would be login, installation, extension installers, javascript errors that prevent you from moving a save or similar action, etc. Also includes the generation of Fatal PHP errors.

'''Major (2):'''
Parts of the source are obstructing operation in a serious way or causing a major loss in advertised function. Examples would includes PHP notices and warnings and reported javascript errors. Major issues will also typically prevent the release cycle from moving from Beta to Release Candidate (RC), or Release Candidate to General Availability (GA).

'''Normal: (3)'''
Issues that are hindering advertised behavior but the application is still workable. Examples would include parameters not working as advertised, language files not loading as expected, etc.

'''Minor (4):'''
Minor loss of function and generally annoying behavior. May include less common platform or browser specific problems that while they may be technically major in those environments, they represent a minority. Also include missing translation strings.

'''Trivial (5):'''
Cosmetic problems, misspelled words, graphically misaligned object, less common issues with parameters, etc.

= Resolving Issues =

The bug squad takes care of the 1.5 release which is now in maintenance mode. That means getting the 1.5.1, 1.5.2, 1.5.3, 1.5.4 etc releases ready by fixing problems that come up. The idea is to make the release increasingly stable and take care of issues that come up. At the same time, it is vitally important not to break anything that is working. That's called software regression and it's not something you want at this stage.

In the 1.5 tracker there are several common statuses, mainly: open, confirmed, pending, ready to commit.

* '''Open''' means it's reported, but it hasn't been determined for sure whether it is a real bug or not. Many Open issues are not actually bugs. If the issue fits into one of the categories below, then the status is changed as indicated and the bug is closed:
** Cannot be reproduced. We have tried the same thing the reported did but the software appears to work correctly. (In many cases, more information is needed to be able to reproduce a bug. See "Information Required" below.) Change status to '''Unable to confirm'''.
** Has already been reported in a different issue number. Change status to '''Duplicate report''' and add the number on the duplicates tab.
** Is a known limitation of the software. Change status to '''Known issue'''.
** Is a feature request, a mistake made by a user, or is the way the software is intended to work. Change status to '''Not a bug'''.
** Is a bug with an extension or some other external program. Change status to '''Not Joomla! core'''.
* '''Information Required''' is used if we need more information ''from the person who reported the issue'' to decide about the issue. For example, there are questions about how to reproduce the problem or other questions about the issue. If we get the information we need, then we can continue processing the issue. If we don't get the information within two weeks, then we can change the status to Unable to confirm (or another of the closed status codes if that is more applicable).
* '''Needs Review''' is used if we need a JBS Coordinator, Development Coordinator, or other experienced developer to review the issue. This is different from Information Required, which means that we need more information from the person who reported the issue.
* '''Confirmed''' means that JBS has confirmed that this issue is a bug in Joomla! that should be fixed. That's when the JBS tries to solve it or consults with the development team about a solution. ''At this point there should be clear step-by-step test instructions that indicate how to reproduce the problem.''
* '''Pending''' means that a patch has been submitted that a JBS member or development coordinator or appropriate leadership team member believes fixes the bug. If needed, additional test instructions are entered for the issue. Every Pending issue should have instructions that tell the tester how to reproduce the problem and make sure the patch fixes the problem.
* '''Ready to commit''' means that two separate people have successfully tested the same patch file, and it works correctly with the patch. Note that, for some issues that are more complex or higher impact, we may need more than two people to test or may need to test on multiple platforms.
* '''Fixed in SVN''' means that, after reviewing the code, the JBS commit coordinators have determined that the patch is good and the change has been committed to the Joomla! codebase. At this point, it will be part of the next Joomla! maintenance release.

The flowchart below provides a visual guide to how the process for resolving bugs works.

[[Image:ResolvingIssues.jpg|1024 px]]

You do ''not'' need to be a member of the JBS to help fix bugs in Joomla. Anyone can report bugs, test patches, or submit patches. If you want to help with resolving bugs, go to the [http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Tracker]. You can help resolve Open issues as outlined above. You can create and submit patches for Confirmed issues. Or you can help test Pending issues. To report about what you have done, login to joomlacode and add a comment. You'll be amazed at how much impact you can have and how good it feels to contribute to the Joomla! project.

If you have any questions, or are interested in joining the JBS, please contact the [http://community.joomla.org/magazine/author/75-mark-dexter.html JBS Coordinator].

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Squad

2010-08-12T10:41:59Z

Masterchief: /* Tracker Team */

[[Image:workgroups_bugsquad.jpg|right]]

The Joomla! Bug Squad (JBS) is a team within the production working group. Their job is to identify and fix bugs in Joomla. This includes the following:

* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] and [http://forum.joomla.org/viewforum.php?f=579 Joomla! 1.6 Beta Bug Reporting Forum] for reported issues and help community members with solving these issues.
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Version 1.5 Bug Tracker]] and [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Version 1.6 Issue Tracker]] .
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].

The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!

The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:
* Tracker Team - monitors the forums and trackers
* Coding Team - creates patches for Confirmed Issues
* Testing Team - tests Pending issues
* Automated Testing Team - creates automated system and unit tests for tracker issues
* Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.

These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.

===Tracker Team===
This team has the very important and sometimes difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.

Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.

The Tracker Team should also make sure the issue has the correct Type and Priority. Remember, many users reporting bugs are not familiar with all of the fields and terminology. In many cases, this could be the user's first contribution or interaction with the project.

It is critically important that all JBS members follow the Code of Conduct and show courtesy and respect in all tracker comments. Remember, we are the ambassadors of the Joomla! project, and the way we behave reflects on the whole project. People will naturally be unhappy if an issue they report is not taken seriously or if they feel that it was closed improperly. So we need to be sensitive to that fact, while of course making the what we believe to be the correct decision. For example, if you close an issue as Not a Bug, please put a comment in telling the reporter why in a nice way.

Also, if someone is not following the Code of Conduct in a tracker comment, please point this out in a respectful way and remind the person that we need to follow the CoC at all times. If there is a persistent problem, please let your Team Leader or a JBS Coordinator know so we can take action. We absolutely do not want to tolerate rude or disrespectful behavior in the tracker or forum.

For more information see the [[Tracker Team]] page.

===Coding Team===
The coding team works with Confirmed issues and creates patches to correct these issues if they haven't already been provided. When a patch is completed, and when a test plan has been added that tells the testers how to test the patch, the issue is changed to Pending status.

Many times the first patch submitted for an issue will not be the actual patch that is committed to the SVN. There are many reasons for this. Someone else may have a different approach to the solving the issue, a tester might find a problem, or the person who submitted the patch will think of a better way to do it.

It is important to be positive and flexible and not expect that every patch you submit will go straight into the SVN. That does not mean the work is not helpful or valuable. In many cases, it is not possible to get to the end result without going through one or more tries.

For more information see the [[Bug Squad Coding Team]] page.

===Testing Team===
This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.

Over time, we plan to include more automated testing into the process. Eventually, we would like every Ready to Commit issue have both a code patch and an automated system or unit test. Accordingly, it will be important for members of the testing team to be learning how to write and use system tests.

There are some tips for testing in the wiki in the [[Testing Checklists]] article.

===Automated Testing Team===
Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.

For more information see the [[Automated Testing Team]] page.

===Migration / Upgrade Team===
This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Squad

2010-08-12T10:35:41Z

Masterchief: /* Automated Testing Team */

[[Image:workgroups_bugsquad.jpg|right]]

The Joomla! Bug Squad (JBS) is a team within the production working group. Their job is to identify and fix bugs in Joomla. This includes the following:

* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] and [http://forum.joomla.org/viewforum.php?f=579 Joomla! 1.6 Beta Bug Reporting Forum] for reported issues and help community members with solving these issues.
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Version 1.5 Bug Tracker]] and [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Version 1.6 Issue Tracker]] .
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].

The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!

The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:
* Tracker Team - monitors the forums and trackers
* Coding Team - creates patches for Confirmed Issues
* Testing Team - tests Pending issues
* Automated Testing Team - creates automated system and unit tests for tracker issues
* Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.

These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.

===Tracker Team===
This team has the very important and difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.

Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.

The Tracker Team should also make sure the issue has the correct Type and Priority. Remember, many users reporting bugs are not familiar with all of the fields and terminology. In many cases, this could be the user's first contribution or interaction with the project.

It is critically important that all JBS members follow the code of conduct and show courtesy and respect in all tracker comments. Remember, we are the ambassadors of the Joomla! project, and the way we behave reflects on the whole project. People will naturally be unhappy if an issue they report is not taken seriously or if they feel that it was closed improperly. So we need to be sensitive to that fact, while of course making the what we believe to be the correct decision. So, for example, if you close an issue as Not a Bug, please put a comment in telling the reporter why in a nice way.

Also, if someone is not following the Code of Conduct in a tracker comment, please point this out in a respectful way and remind the person that we need to follow the CoC at all times. If there is a persistent problem, please let your Team Leader or a JBS Coordinator know so we can take action. We absolutely do not want to tolerate rude or disrespectful behavior in the tracker or forum.

===Coding Team===
The coding team works with Confirmed issues and creates patches to correct these issues if they haven't already been provided. When a patch is completed, and when a test plan has been added that tells the testers how to test the patch, the issue is changed to Pending status.

Many times the first patch submitted for an issue will not be the actual patch that is committed to the SVN. There are many reasons for this. Someone else may have a different approach to the solving the issue, a tester might find a problem, or the person who submitted the patch will think of a better way to do it.

It is important to be positive and flexible and not expect that every patch you submit will go straight into the SVN. That does not mean the work is not helpful or valuable. In many cases, it is not possible to get to the end result without going through one or more tries.

For more information see the [[Bug Squad Coding Team]] page.

===Testing Team===
This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.

Over time, we plan to include more automated testing into the process. Eventually, we would like every Ready to Commit issue have both a code patch and an automated system or unit test. Accordingly, it will be important for members of the testing team to be learning how to write and use system tests.

There are some tips for testing in the wiki in the [[Testing Checklists]] article.

===Automated Testing Team===
Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.

For more information see the [[Automated Testing Team]] page.

===Migration / Upgrade Team===
This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Squad

2010-08-12T10:34:14Z

Masterchief: /* Coding Team */

[[Image:workgroups_bugsquad.jpg|right]]

The Joomla! Bug Squad (JBS) is a team within the production working group. Their job is to identify and fix bugs in Joomla. This includes the following:

* Scan the [http://forum.joomla.org/viewforum.php?f=199 Joomla! Bug Reporting Forum] and [http://forum.joomla.org/viewforum.php?f=579 Joomla! 1.6 Beta Bug Reporting Forum] for reported issues and help community members with solving these issues.
* Maintaining the [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Version 1.5 Bug Tracker]] and [[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Version 1.6 Issue Tracker]] .
* Fix reported bugs and resolve reported issues according to the [[Bug Tracking Process]].

The Bug Squad is also supporting with testing and quality assurance when a new major or minor version is developed. Generally speaking the bug-squad is in the lead when a version switches from beta-stage to the stable-stage within the development cycle of Joomla!

The Bug Squad was created in December 2007. As of May 2010, JBS has been organised into the following teams:
* Tracker Team - monitors the forums and trackers
* Coding Team - creates patches for Confirmed Issues
* Testing Team - tests Pending issues
* Automated Testing Team - creates automated system and unit tests for tracker issues
* Migration / Upgrade Team - responsible for supporting migration and upgrading from the prior version to the current version.

These teams are not rigid, and JBS members can participate in whatever activities they wish. The purpose of the teams is to make it easier for JBS members to focus their efforts and learn the skills required to successfully contribute to the project.

===Tracker Team===
This team has the very important and difficult job of filtering all of the forum posts and bug reports and sorting out which ones are real bugs that are ready to be worked on. From the standpoint of the tracker, their job is to move issues from Open status to Confirmed status. Of course, many issues will also be put into other status codes, including Information Required, Needs Review, Duplicate, Not a Bug, and so on.

Before an issue is marked Confirmed, it needs to be reproduced and documented so that others can reproduce the problem.

The Tracker Team should also make sure the issue has the correct Type and Priority. Remember, many users reporting bugs are not familiar with all of the fields and terminology. In many cases, this could be the user's first contribution or interaction with the project.

It is critically important that all JBS members follow the code of conduct and show courtesy and respect in all tracker comments. Remember, we are the ambassadors of the Joomla! project, and the way we behave reflects on the whole project. People will naturally be unhappy if an issue they report is not taken seriously or if they feel that it was closed improperly. So we need to be sensitive to that fact, while of course making the what we believe to be the correct decision. So, for example, if you close an issue as Not a Bug, please put a comment in telling the reporter why in a nice way.

Also, if someone is not following the Code of Conduct in a tracker comment, please point this out in a respectful way and remind the person that we need to follow the CoC at all times. If there is a persistent problem, please let your Team Leader or a JBS Coordinator know so we can take action. We absolutely do not want to tolerate rude or disrespectful behavior in the tracker or forum.

===Coding Team===
The coding team works with Confirmed issues and creates patches to correct these issues if they haven't already been provided. When a patch is completed, and when a test plan has been added that tells the testers how to test the patch, the issue is changed to Pending status.

Many times the first patch submitted for an issue will not be the actual patch that is committed to the SVN. There are many reasons for this. Someone else may have a different approach to the solving the issue, a tester might find a problem, or the person who submitted the patch will think of a better way to do it.

It is important to be positive and flexible and not expect that every patch you submit will go straight into the SVN. That does not mean the work is not helpful or valuable. In many cases, it is not possible to get to the end result without going through one or more tries.

For more information see the [[Bug Squad Coding Team]] page.

===Testing Team===
This team tests Pending issues and, when tests are successful, documents this and moves the issue to Ready to Commit status. At this point, one of the JBS coordinators will commit the patch to the SVN.

Over time, we plan to include more automated testing into the process. Eventually, we would like every Ready to Commit issue have both a code patch and an automated system or unit test. Accordingly, it will be important for members of the testing team to be learning how to write and use system tests.

There are some tips for testing in the wiki in the [[Testing Checklists]] article.

===Automated Testing Team===
Automated testing is a key technology that we will incorporate into the workings of JBS. At the present, this is a somewhat specialized skill, so we will start by developing a separate team of people who are familiar with this and can help write automated tests and train other JBS members on automated testing. Our aim is to eventually make automated testing a routine part of fixing issues.

===Migration / Upgrade Team===
This team is responsible for coding and documenting the upgrade process for users migrating sites or extensions from one version to the next (for example, from version 1.5 to 1.6). They will be responsible for creating and fixing issues in this area of the code.

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Squad Coding Team

2010-05-27T21:50:40Z

Masterchief:

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.

To be involved in the Coding Team you should either know, or be prepared to learn, the following:

* The PHP programming language;
* SQL syntax;
* How to checkout and update a Subversion (SVN) source code repository;
* How to create, apply and analyse a "patch file"; and
* The basic principles of Object Oriented Programming (OOP for short).

Does that sound a bit scary? If it does, it basically boils down to if you want to be a part of the coding team, you need to have some programming skills. If you are a beginner programmer, then the Coding Team is going to be like going to the gym regularly. You'll start out very sore and your brain will probably hurt, but after a while those bugs are going to be no match for you. Stick with it and you'll come out of your tour of duty with some pretty serious programming punch, not to mention a wealth of experience passed down from other Joomla Jedi masters.

The '''Testing Team''' has gone before you ensuring that issues move to Confirmed are the real deal (as far as they can tell). As a member of the Coding Team, 99% of your work will be to devise a code patch to rectify the issue that has been raised. You also need to include a test plan so that the people that follow you actually know how to work out whether the issue has been fixed. Once you do this, you'll upload the patch to the issue and then set the status to '''Pending'''. When this happens the '''Testing Team''' will pick up you patch and make sure that it applies without any conflicts, and then follow your test plan to verify the patch does the job. All going well, the Testing Team will then promote the issuse to '''Ready to Commit''' and you can start to relax and think about shore leave ... after you've finished all the other issues of course.

It's entirely possible that things will go this smoothly, but just as often they don't.

Sometimes you will need to ask for more information from the person that raised the issue if the root cause of the problem is not immediately obvious. This could be a very short conversation, or it could go on for quite some time depending on the complexity of the issue. If you begin to enter into a long dialogue, it is advisable to change the status to '''In Progress'''.

Sometimes an issue just seems impossible to work out, or you might be concerned that your patch is going to have side effects on other parts of the framework. In this case, change the status to '''Needs review''' and one of the Joomla Jedi's will take a look and see if they can assist with the problem.

Whenever a problem is being solved in the framework (those are all the files under the <code>/libraries/</code> folder), you are encouraged to write or update the Unit Tests for the part of the code you are fixing. This is not always possible but should always be attempted as a general rule.

When you are making changes to layouts, you need to be mindful that both frontend and backend templates use layout overrides. In Joomla 1.6, Beez2 on the frontend uses layout overrides to provide HTML5 support and Hathor in the backend uses layout overrides extensively to provide accessibility support. When you make patches to layouts make sure that you do any related layouts in the core templates as well.

Members of the Coding Team also need to be very disciplined and have good attention to detail. Joomla has a strong tradition of following a published coding style, and it is your job to ensure it is upheld at all times. Beautiful code is easier to read and easier to debug. Always be mindful that you are in a team, and that team involves the future generations of Joomla developers that you haven't even met yet (and sometimes even your future self).

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Bug Squad Coding Team

2010-05-27T08:19:22Z

Masterchief: New page: The "Gloden 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 &rarr...

The "Gloden 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.

To be involved in the Coding Team you should either know, or be prepared to learn, the following:

* The PHP programming language;
* SQL syntax;
* How to checkout and update a Subversion (SVN) source code repository;
* How to create, apply and analyse a "patch file"; and
* The basic principles of Object Oriented Programming (OOP for short).

Does that sound a bit scary? If it does, it basically boils down to if you want to be a part of the coding team, you need to have some programming skills. If you are a beginner programmer, then the Coding Team is going to be like going to the gym regularly. You'll start out very sore and your brain will probably hurt, but after a while those bugs are going to be no match for you. Stick with it and you'll come out of your tour of duty with some pretty serious programming punch, not to mention a wealth of experience passed down from other Joomla Jedi masters.

The '''Testing Team''' has gone before you ensuring that issues move to Confirmed are the real deal (as far as they can tell). As a member of the Coding Team, 99% of your work will be to devise a code patch to rectify the issue that has been raised. You also need to include a test plan so that the people that follow you actually know how to work out whether the issue has been fixed. Once you do this, you'll upload the patch to the issue and then set the status to '''Pending'''. When this happens the '''Testing Team''' will pick up you patch and make sure that it applies without any conflicts, and then follow your test plan to verify the patch does the job. All going well, the Testing Team will then promote the issuse to '''Ready to Commit''' and you can start to relax and think about shore leave ... after you've finished all the other issues of course.

It's entirely possible that things will go this smoothly, but just as often they don't.

Sometimes you will need to ask for more information from the person that raised the issue if the root cause of the problem is not immediately obvious. This could be a very short conversation, or it could go on for quite some time depending on the complexity of the issue. If you begin to enter into a long dialogue, it is advisable to change the status to '''In Progress'''.

Sometimes an issue just seems impossible to work out, or you might be concerned that your patch is going to have side effects on other parts of the framework. In this case, change the status to '''Needs review''' and one of the Joomla Jedi's will take a look and see if they can assist with the problem.

Whenever a problem is being solved in the framework (those are all the files under the <code>/libraries/</code> folder), you are encouraged to write or update the Unit Tests for the part of the code you are fixing. This is not always possible but should always be attempted as a general rule.

When you are making changes to layouts, you need to be mindful that both frontend and backend templates use layout overrides. In Joomla 1.6, Beez2 on the frontend uses layout overrides to provide HTML5 support and Hathor in the backend uses layout overrides extensively to provide accessibility support. When you make patches to layouts make sure that you do any related layouts in the core templates as well.

Members of the Coding Team also need to be very disciplined and have good attention to detail. Joomla has a strong tradition of following a published coding style, and it is your job to ensure it is upheld at all times. Beautiful code is easier to read and easier to debug. Always be mindful that you are in a team, and that team involves the future generations of Joomla developers that you haven't even met yet (and sometimes even your future self).

<noinclude>[[Category:Development Working Group]][[Category:Bug Squad]]</noinclude>

Filing bugs and issues

2010-05-18T04:06:42Z

Masterchief: /* Access the Joomla! development bug tracker. */

== Reporting bugs ==

To report a bug in the Joomla! bug trackers, you need to create an "artefact" (''Editor's note: joomlacode.org uses the American spelling "artifact", but our policy is to use British/Australian spellings throughout the documentation.''). Once the artefact is created, the developers will check the validity of it and act accordingly.

=== Register an Account at joomlacode.org ===
[http://joomlacode.org/gf/account/?action=UserAdd Register]

=== Access the Joomla! development bug tracker. ===

*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=8103 Joomla! 1.6 Issue Tracker] - Active
*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Joomla! 1.5 Bug Tracker] - Active
*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=5782 Joomla! 1.0 Bug Tracker] - Closed

=== Check to see if the bug you want to report is already reported. ===

A series of filters display the artefacts. Make sure Priority is set to "Any", Assignee to "Any" and Status to "Any", other filters to nothing. Mouse over the title of the artefacts to check their contents. If the issue you are experiencing is not already reported, click on the bottom-right Button "Add new Tracker Item".

A new screen will display and there, the more information you give, the easier it is for the developers.

Fill as many fields as you can.

* [[Priority]] : Use the default "Medium" except if you know the code enough to make another choice.
* PHP : Choose the version you are testing on. You can find this information by clicking the Menu "Help"->"System Info" in the Administrator back-end of Joomla!.
* Estimated Time : Leave this blank.
* Build : Type here the #SVN number if you know it, or Nightly Build date, or Version used if using a Released version.
* Browser : Self-explanatory.
* Database : The version of MySQL is also available in "Help" -> "System Info".
* Status : Leave this to "Open".
* Percent Complete : Leave this blank.
* Category : This one is more tricky. Use "Administration" if you do not know better.
* Customer : Use "User" if the issue is in front-end, "Developer" if the issue concerns an extension you are developing, "Administrator" in other cases.
* Web Server : The version/server type is also available in "Help" -> "System Info".

=== Provide a summary ===

Describe in a few words the issues you are having. It is generally a good idea to use existing artefacts as examples if this is your first time reporting a bug.

Examples:

* Front-end: Warning such and such.
* Back-end: Unable to save article when "nameofplugin" is published.

Note: Take care to be descriptive in your summary as this is the first thing the developers will see when they are perusing the tracker for something to fix.

=== Provide details about the bug ===

This is the most important part of reporting the bug. Describe here step by step how you got the error you are noticing. Include all of the information that someone will need to re-trace your steps and see the problem. Remember: Your bug will not be fixed unless others can see the problem, so you want to be as clear and detailed as possible. You do not need to know anything about programming to write a great bug report. But if you do understand the code and think you know how to fix the bug, please include this in the report.

The general format should be something like:
# "Here is ''exactly'' what I did."
# "This is what happened."
# "This is what I think should have happened."
# "Other information, possible solution, proposed code patch."

The more details, the better. Also, it is important to reproduce the bug using the sample Joomla! website or with easy, clear instructions for how to set it up. Remember that others will not have access to your site's database, so you will need to be able to tell someone how to see the bug with data that is readily available -- the sample site.

'''Example A'''

; What I did : Started with sample website. Everything was ok. I enabled "nameofplugin". Try to save any article from back end.
; What happened : I get a blank screen and article is not saved.
; What should have happened : Articles should save correctly.
; Other information : These are the plugins enabled at the same time. SEF is on (or Off). My site is in a sub-folder. I also remark that... etc. Files such and such are the issues IMHO (if you know what you are talking about).

'''Example B'''

; What I did : Navigate to Back-end. Click on "menu_name" Menu.
; What happened: Page opened is blank.
; What should have happened : Menu should have opened correctly.
; Other information : Any other menu works OK. etc.

'''Real-Life Example'''
; What I did
: Started with the sample website.
: Added an unpublished article from the back end, with Section=FAQ, Category=General.
: In the advanced parameters for the article, set Show Title to "No" and Print, PDF, and Email Icons to "Hide".
: Save the article and navigate to front end. Login to the front end as admin and navigate to the Example Pages -> Category Blog menu item.
; What happened : The newly added article shows but there is no edit icon for the front-end user to click on.
; What should have happened : The edit icon should show, allowing a front end user to edit this article.
; Other information : This only happens with the rhuk_milkyway template. By changing this code [code proposed] in file [name and hierarchy of file], line(s) #, the issue looks solved on my settings.

=== Add an attachment to your report ===

To better describe the issue or/and propose a fix, you can add attachments to the artefact you are creating by using the "Browse" buttons at the bottom of the screen.
A screen capture of the page(s) concerned helps a lot. If you can, try to optimise the size of the image through an image editor.
If you know what part(s) of the code base to change, a patch [patches] or a full file where your changes are WELL shown will help the developers to solve the problem quicker.

=== Finish and send in the report ===

You will receive an e-mail confirming that you posted the artefact. When someone comments or asks for supplementary details or solves the issue, you will receive a notification e-mail and may reply if needed.

=== Extra tips and tricks ===

Well-written bug reports are incredibly helpful. However, there's a certain amount of overhead involved in working with any bug tracking system, so your help in keeping our ticket tracker as useful as possible is appreciated. In particular:

* Do read the [http://docs.joomla.org/FAQs FAQ] to see if your issue might be a well-known question.
* Do search [http://joomlacode.org/gf/project/joomla/tracker/ the tracker] to see if your issue has already been filed.
* Do ask on [http://forum.joomla.org/index.php/board,199.0.html testing forums] first if you're not sure if what you're seeing is a bug.
* Do write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test cases, etc. A minimal example that illustrates the bug in a nice small test case is the best possible bug report.
* Don't use the tracker system to ask support questions. Use the [http://forum.joomla.org/ Joomla! forums], or the [irc://irc.freenode.net/joomla #joomla] IRC channel on freenode for that.
* Don't use the trackers to make large-scale feature requests. We like to discuss any big changes to Joomla!'s core on the [http://forum.joomla.org/index.php#6 developers forums] before actually working on them.
* Don't reopen issues that have been marked "not a bug". This mark means that the decision has been made that we can't or won't fix this particular issue. If you're not sure why, please ask on developer forums.
* Don't use the tracker for lengthy discussions, because they're likely to get lost. If a particular artefact is controversial, please move discussion to [http://forum.joomla.org/index.php#6 developer forums].

== Reporting security issues ==

Report security issues to security [at] joomla [dot] org. This is a private list only open to long-time, highly trusted Joomla! developers, and its archives are not publicly readable.

In the event of a confirmed vulnerability in Joomla! itself, we will take the following actions:

* Acknowledge to the reporter that we've received the report and that a fix is forthcoming. We'll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
* Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases.
* Determine a go-public date for announcing the vulnerability and the fix. To try to mitigate a possible "arms race" between those applying the patch and those trying to exploit the hole, we will not announce security problems immediately.
* Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of Joomla! but in some cases it may simply be patches against current releases.

[[Category:Bug Squad]]
[[Category:Development]]

J2.5:What's new in Joomla 2.5

2010-05-17T23:03:52Z

Masterchief: New page: Lots of things.

Lots of things.

Summer of Code 2010 Project Ideas

2010-02-18T23:44:40Z

Masterchief: /* Welcome! */

===Welcome!===
Welcome to the Joomla! Google Summer of Code (GSoC) 2010 project ideas page. As we move forward with the 2010 version of the Joomla! GSoC, we will use this page to develop possible project ideas. Please note that anyone who is interested can participate in this process. You do not have to be a GSoC student or mentor to suggest possible project ideas. Thanks!

===Ideas===

=====Improve Image Presentation Capabilities=====

This project could include:

* Expand the JHtml modal behaviour to support groups of images (eg Litebox or similar).
* A content plugin to support modal gallery displays or inline image sliders.
* A module to support galleries of images.

=====Audio/Video Support=====

This project could include:

* Sourcing or creating a FOSS flash audio (see http://flash-mp3-player.net/) and video player.
* A content plugin to support embedding different types of audio files easily in content.
* A content plugin to support embedding different types of video files (both local and hosted, eg vimeo) easily in content.

=====Google Map Support=====

This project could include:

* An editor-xtd plugin that allows you to insert "map code" for a content plugin.
* A content plugin to display a map with content.
* A module to display a map.
* Support for finding directions.

=====Simple User Subscription and User Utilities=====

This project would be suite of extensions that would provide enhanced user features such as:

* Allow you to manage user account expiry.
* Allow you to manage password expiry.
* Allow for configurable email messages.
* Allow for user registration approval.
* Clean up bad user records.
* Run simple reports on user registration data.

=====Extension Builder=====

This project would involve a component that builds other components, modules, plugins, languages and templates in skeletal form. It could also be used to create/edit new component and module layout overrides in templates.

Archived:Database schema standards

2009-11-02T01:22:21Z

Masterchief: New page: == Table Naming Conventions == == Field Naming Conventions == == Field Type Recommendations ==

== Table Naming Conventions ==

== Field Naming Conventions ==

== Field Type Recommendations ==

Coding style and standards

2008-10-23T10:06:46Z

Masterchief: /* Added condensed version for layout files */

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgement based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utitilies/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Layout files do not need full DocBlocks. However, they do require and Id tag and direct access block as follows:

<source lang="php"><?php /** $Id$ */ defined('_JEXEC') or die('Restricted access'); ?></source>

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using tradationally uppercase acryonyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source lang="php"><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source lang="php">
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source lang="php">
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source lang="php"><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source lang="php">MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

If more than one dynamic string is used in a phrase, the printf markers should employ order placement as other languages might change the position of the strings. This is done via %[number]$[printf_type] as follows:

Left to right language:

<source lang="php">PAGE X OF Y=Page %1$d of %2$d</source>

Right to left language:

<source lang="php">PAGE X OF Y=%2$d of %1$d egaP</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Plugins ===

The naming convention is ''[Folder]View[Element]''.

<source lang="php">
class ContentPluginPagebreak extends JPlugin
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Coding style and standards

2008-10-23T08:06:30Z

Masterchief: /* Language Keys */

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgement based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utitilies/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Example URLs

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using tradationally uppercase acryonyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source lang="php"><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source lang="php">
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source lang="php">
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source lang="php"><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source lang="php">MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

If more than one dynamic string is used in a phrase, the printf markers should employ order placement as other languages might change the position of the strings. This is done via %[number]$[printf_type] as follows:

Left to right language:

<source lang="php">PAGE X OF Y=Page %1$d of %2$d</source>

Right to left language:

<source lang="php">PAGE X OF Y=%2$d of %1$d egaP</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Plugins ===

The naming convention is ''[Folder]View[Element]''.

<source lang="php">
class ContentPluginPagebreak extends JPlugin
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Coding style and standards

2008-10-21T09:31:13Z

Masterchief: Bug fixes

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgement based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utitilies/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Example URLs

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using tradationally uppercase acryonyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source lang="php"><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source lang="php">
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source lang="php">
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source lang="php"><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source lang="php">MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Plugins ===

The naming convention is ''[Folder]View[Element]''.

<source>
class ContentPluginPagebreak extends JPlugin
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Coding style and standards

2008-10-21T09:29:31Z

Masterchief: Language additions, merge changes and suggestions

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions are permitted, for example where common programming names are used that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length. Use your judgement based on the nature of the line and readability.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) || (condition2)) {
action1();
} else if ((condition3) && (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) || (condition2)) {
action1();
}
else if ((condition3) && (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

Please note - commented code is not to be committed to trunk or release repositories.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Doc Blocks ===

All source code files in the core Joomla distribution must contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

The <code>@package</code> in the header is not required for class-only files.

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @subpackage SubPackageName
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class JFooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

The following package names are to be used in the core stack:

* Joomla.Administrator - all files that belong only to the administrator or backend application
* Joomla.Installation - all files that belong to the installation application
* Joomla.Plugin - all plugin files
* Joomla.Site - all files that pertain only to the site or frontend application
* Joomla.XML-RPC - all files that belong to the XML-RPC server application

The sub-package name will vary according to the extension type:

* Components - the component folder, eg <code>com_content</code>
* Modules - the module folder, eg <code>mod_latest_news</code>
* Plugins - the folder.element, eg <code>content.pagebreak</code>
* Templates - the template folder, eg <code>rhuk_milkyway</code>
* Framework - nothing for top level files (such as <code>factory.php</code>), the first level folder or the first.second level folders as appropriate, eg <code>utilities</code> for <code>joomla/utitilies/date.php</code>, <code>html.html</code> for <code>joomla/html/html/email.php</code>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Example URLs

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase even if using tradationally uppercase acryonyms (such as XML, HTML). One exception is for Joomla framework classes which must begin with an uppercase 'J' with the next letter also being uppercase. For example:

* JHtmlHelper
* JXmlParser
* JModel

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Function in the Joomla framework must begin with a lowercase 'j'. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
jImport();
jDoSomething();
</source>

Private class members (meaning class members that are intended to be used only from within the same class in which they are declared; are preceded by a single underscore. Properties are to be written in underscore format (that is, logical words separated by underscores) and should be all lowercase. For example:

<source lang="php">
class JFooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected $field_name = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Language Keys ===

Except for the most common of words, such as "Yes", "No", "Show", "Hide" all language keys should be namespaced to reflect the type of string they represent. Always consider that if two extensions use the same key, the one loaded last will be the one that displays. Namespacing should generally relate to the extension displaying the text. For example:

<source><?php
echo JText::_('Weblink Link');
echo JText::_('Weblink Title');
echo JText::_('Weblink Description');

echo JText::_('Exception An error occurred while saving');
?></source>

TODO: Link to page with "common" strings that can be used for typical actions in components, such a "Save"

Where the same English word is used in two different locations, two different language keys should be used to allow for cases where the translation results in different words or phrases.

<source>
// A table column title
<th><?php echo JText::_('Weblink Column Title');?></th>
<th><?php echo JText::_('Weblink Column Link');?></th>

// In the form
<?php echo JText::_('Weblink Title');?><input name="title" />
<?php echo JText::_('Weblink Link');?><input name="link" />
</source>

Toolbar and Linkbar text should be prefixed Toolbar and Linkbar respectively.

The language keys should be written as naturally as possible with spaces, not underscores separating words. Long phrases can be condensed to reduce keys to a sensible length. For example, tooltips for an edit field can be written like this:

<source>
<?php echo JText::_('Weblink Title');?><input name="title" title="<?php echo JText::_('Weblink Title Desc');?>" />
</source>

The convention used should be governed by common sense, but must be consistent. In general consider how the language file will look with all keys sorted alphabetically. Prefixes should be used to group text within a common context (such as column headings). Suffixes should be used to group elements that logically go together (such as a field name and its description).

Phrases must never be assembled by string concatenation. Each phrase must be represented by a single language key, using sprintf as appropriate to replace dynamic words in the phrase. Where replacements are made, the word used should be as descriptive as possible and all-uppercase. This assists the translators to determine the context of the replacement.

<source><?php
// Not permitted
echo JText::_('Deleted ').$n.JText::_(' items');

// Permitted
echo JText::sprintf('Message Deleted NUMBER items', $n);
?></source>

The reference in the language file would look like this:

<source>MESSAGE DELETED NUMBER ITEMS=Deleted %d Item(s)</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Plugins ===

The naming convention is ''[Folder]View[Element]''.

<source>
class ContentPluginPagebreak extends JPlugin
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Archived:Version 1.6 Developer Notes

2008-10-18T22:27:51Z

Masterchief:

{{incomplete}}
{{RightTOC}}
[[Category:Development]]

Compilation of developer notes on changes in 1.6.

== Schema ==

Added ACL tables (todo - list them)
Removed jos_groups table

== Framework ==

=== JAuthorization ===

Remove <code>JAuthorization::_mos_add_acl</code>.

Added <code>JAuthorization::getUserAccessLevels( $section [, $action = 'view'] )</code>.

=== JDatabase ===

JDatabase::setQuery casts the sql variable to a string. This allows you to pass an object that implements the __toString magic method.

=== JFile ===

Both JFile::write and JFTP::write now use a reference for its second argument. Code like ''JFile::write($filename,'string');'' will fail, however ''$data = 'string'; JFile::write($filename, $data);'' will work for both 1.5 and 1.6

=== JModel ===

JModel::getState will now take an optional second argument to set the default.
$value = $model->getState( 'foo', 'bar' );

JModel has an addition contruction option and internal variable <code>__state_set</code>. This is used to lazy-load model initialisation.

=== New API ===

Added <code>JTableTree</code> as an abstract class for tree-based tables.

Made JObject abstract. It can no longer be directly instantiated. Use JStdClass instead.

== Components ==

=== Join for access level ===

Before:
<pre>LEFT JOIN #__groups AS g ON g.id = c.access</pre>

After:
<pre>LEFT JOIN #__core_acl_axo_groups AS g ON g.value = a.access</pre>

=== Administrator:Users ===

== Legacy Mode ==

Only available in legacy mode (to be dropped in future versions):

* <code>global $mainframe</code> - Use <code>$app = &JFactory::getApplication()</code> instead.
* JTemplate (patTemplate completely deprecated)

== Files/Features Dropped ==

== TODO ==

Don't forget to do this:

* Access Level links in backend lists need to be refactored to support the new levels available in the jos_core_acl_axo_groups table.

Coding style and standards

2008-10-16T21:30:50Z

Masterchief: Add spelling note

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

First rule, if in doubt, ask.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== Spelling ===

Spelling of class, function, variable and constant names should generally be in accordance with British English rules (en_GB). However, some exceptions to this are common programming names that align with the PHP API such as <code>$color</code>.

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length 75-85 characters is a good target. Use your judgement based on the nature of the line and readability. Line lengths in mixed HTML+PHP code will often be blow out so that the generated source remains reabable.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) OR (condition2)) {
action1();
} else if ((condition3) AND (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) OR (condition2)) {
action1();
}
else if ((condition3) AND (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Comment Blocks ===

All source code files in the core PEAR distribution should contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @version Release: @package_version@
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class fooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Example URLs

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase.

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
</source>

Private class members (meaning class members that are intented to be used only from within the same class in which they are declared; are preceded by a single underscore. For example:

<source lang="php">
class fooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Coding style and standards

2008-10-16T06:52:07Z

Masterchief: Major revision bringing in new standard for 1.6

{{review}}
{{RightTOC}}
remark: The following information has been copied from the old WIKI archive has not yet been reviewed.
See: http://dev.joomla.org/component/option,com_jd-wiki/Itemid,/id,standards:coding/

Good coding standards are important in any development project, but particularly when multiple developers are working on the same project. Having coding standards helps ensure that the code is of high quality, has fewer bugs, and is easily maintained.

== File Format ==
All files contributed to Joomla must:

* Be stored as ASCII text
* Use UTF-8 character encoding
* Be Unix formatted
** Lines must end only with a line feed (LF). Line feeds are represented as ordinal 10, octal 012 and hex 0A. Do not use carriage returns (CR) like Macintosh computers do or the carriage return/line feed combination (CRLF) like Windows computers do.

== Coding Standards ==

=== E_STRICT-compatible code ===

As of version 1.6, all new code that is suggested for inclusion into Joomla must be E_STRICT-compatible. This means that it must not produce any warnings or errors when PHP's error reporting level is set to E_ALL | E_STRICT.

=== Indenting and Line Length ===

Use tabs to indent, not spaces. Make sure that the tab-stops are set to only 4 spaces in length.

There is no set limit for line length 75-85 characters is a good target. Use your judgement based on the nature of the line and readability. Line lengths in mixed HTML+PHP code will often be blow out so that the generated source remains reabable.

=== Control Structures ===

These include if, for, while, switch, etc. Here is an example of an if statement, as it is the most complicated of the control structures:

<source lang="php">
<?php
if ((condition1) OR (condition2)) {
action1();
} else if ((condition3) AND (condition4)) {
action2();
} else
{
// Use one true brace in control structures
// when the block is longer than one line
defaultAction();
anotherAction();
}

// optional formatting if it improves readability
if ((condition1) OR (condition2)) {
action1();
}
else if ((condition3) AND (condition4)) {
action2();
}
else {
defaultAction();
anotherAction();
}
</source>

Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.

In '''layouts''', the alternative named notation should be used:

<source lang="php">
<?php
if ((condition1) OR (condition2)) :
action1();
elseif ((condition3) AND (condition4)) :
action2();
else :
defaultAction();
anotherAction();
endif;

foreach ($array as $element) :
echo $element;
endforeach;
</source>

Logical operators in condition statements should use uppercase words (<code>AND</code>, <code>OR</code>, etc) rather than programmatic notation (<code>&&</code>, <code>||</code>, etc).

With the exception of <code>case</code> statements, curly braces must always be included even though they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.

For switch statements:

<source lang="php">
<?php
switch (condition)
{
case 1:
doAction1();
break;

case 2:
doAction2();
break;

default:
doDefaultAction();
break;
}
</source>

Use indenting and line-breaks rather than curly braces in the <code>case</code> statements to increase readability. There should be no space between the condition and the colon in the <code>case</code> statement.

=== Function Calls ===

Functions should be called with no spaces between the function name and the opening parenthesis, and no space between this and the first parameter; a space after the comma between each parameter (if they are present), and no space between the last parameter and the closing parenthesis, and the semicolon. Here's an example:

<source lang="php">
<?php
$var = foo($bar, $baz, $quux);
</source>

As displayed above, there should be space before and one space after the equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, tabs (not spaces) may be inserted to promote readability:

<source lang="php">
<?php
$short = foo($bar);
$long_variable = foo($baz);
</source>

=== Function Definitions ===

Class and function declarations follow the "one true brace" convention:

<source lang="php">
<?php
function fooFunction( $arg1, $arg2 = '' )
{
if (condition) {
statement;
}
return $val;
}

class fooClass
{
function fooMethod($arg1)
{
if ($arg) {
$result = true;
} else {
$result = false;
}
return $result;
}
}
</source>

Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate. Here is a slightly longer example:

<source lang="php">
<?php
function connect(&$dsn, $persistent = false)
{
if (is_array($dsn)) {
$dsninfo = &$dsn;
} else {
$dsninfo = DB::parseDSN($dsn);
}

if (!$dsninfo OR !$dsninfo['phptype']) {
return $this->raiseError();
}

return true;
}
</source>

=== Comments ===

Inline documentation for classes should follow the PHPDoc convention, similar to Javadoc. More information about PHPDoc can be found here: http://www.phpdoc.org/

See also [[Adding phpDocumentor comments]]

Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.

C style comments (<tt>/* */</tt>) and standard C++ comments (<tt>//</tt>) are both satisfactory. Use of Perl/shell style comments (<tt>#</tt>) is not permitted.

=== Including Code ===

Anywhere you are unconditionally including a class file, use <code>require_once</code>. Anywhere you are conditionally including a class file (for example, factory methods), use <code>include_once</code>. Either of these will ensure that class files are included only once. They share the same file list, so you don't need to worry about mixing them -- a file included with <code>require_once</code> will not be included again by </code>include_once</code>.

;Note: [[php:include_once|include_once]] and [[php:require_once|require_once]] are PHP ''language statements'', not functions. You don't need parentheses around the filename to be included.

=== PHP Code Tags ===

Always use <tt><?php ?></tt> to delimit PHP code, not the <tt><? ?></tt> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

For files that contain only PHP code, the closing tag (<tt>?></tt>) is never permitted. It is not required by PHP. Not including it prevents trailing whitespace from being accidentally injected into the output.

=== SQL Queries ===

SQL keywords are to be written in uppercase, while all other identifiers (which the exception of quoted text obviously) is to be in lowercase. Carriage returns should not be used as [[JDatabase]]::getQuery provides for formatted output. However, indenting with spaces to improve readability is desireable.

Queries should be wrapped in single quotes (as these text blocks are parsed faster by php).

All quoted string must using the ''Quote'' method to facilitate future compatibility with other database engines.

All table names should use the '''<tt>#_</tt>''' prefix rather than <tt>jos_</tt> to access Joomla! contents and allow for the [[screen.config.15#Database_Settings|user defined database prefix]] to be applied.

All expected integer or floating-point variable must be [http://php.net/manual/language.types.type-juggling.php cast] with <tt>(int)</tt>, <tt>(float)</tt> or <tt>(double)</tt> as appropriate.

<source lang="php">
$state = 1;
$name = 'bill';
$db = &JFactory::getDBO();
$query = 'SELECT COUNT( c.id ) AS num_articles, u.id, u.username'.
' FROM #__content AS c'.
' LEFT JOIN #__users AS u ON u.id = c.created_by'.
' WHERE c.state = '.(int) $state
' AND u.id IS NOT NULL'.
' AND u.username <> '.$db->Quote( $name ).
' GROUP BY u.id'.
' HAVING COUNT( c.id ) > 0';
$db->setQuery();
// Output formated query:
if ($debug) {
echo $db->getQuery();
}
$stats = $db->loadObjectList();
</source>

=== Comment Blocks ===

All source code files in the core PEAR distribution should contain the following comment block as the header:

<source lang="php">
<?php
/**
* @version $Id$
* @package Joomla
* @copyright Copyright (C) 2005 - 2008 Open Source Matters. All rights reserved.
* @license GNU/GPL, see LICENSE.php
*/
</source>

Classes, functions, constants, class properties and class methods should all be supplied with appropriate DocBlocks.

<source lang="php">
/**
* Short description for class
*
* Long description for class (if any)...
*
* @package PackageName
* @version Release: @package_version@
* @link http://pear.php.net/package/PackageName
* @see NetOther, Net_Sample::Net_Sample()
* @since Class available since Release 1.2.0
* @deprecated Class deprecated in Release 2.0.0
*/
class fooBar
{
/**
* @var int $id Primary key
*/
public $id = null;
}
</source>

Please note that code contributed to the Joomla stack that will become the copyright of the project is not allowed to include <code>@author</code> tags. You should update the contribution log in <tt>CREDITS.php</tt>. Joomla's philosophy is that the code is written "all together" and there is no notion of any one person 'owning' any sectino of code.

Files included from third party sources must leave DocBlocks intact.

Example URLs

== Naming Conventions ==

=== Classes ===

Classes should be given descriptive names. Avoid using abbreviations where possible. Class names should always begin with an uppercase letter and be written in CamelCase.

Third-party developers are advised to namespace their functions with a unique prefix.

=== Functions and Methods ===

Functions and methods should be named using the "studly caps" style (also referred to as "bumpy case" or "camel caps"). The initial letter of the name is lowercase, and each letter that starts a new "word" is capitalized. Some examples:

<source lang="php">
connect();
getData();
buildSomeWidget();
</source>

Private class members (meaning class members that are intented to be used only from within the same class in which they are declared; are preceded by a single underscore. For example:

<source lang="php">
class fooBar
{
// Joomla 1.5 and earlier format
var $_status = null;

function _sort()
{
}

// Joomla 1.6 format
private $_status = null;

protected function _sort()
{
}
}
</source>

=== Constants ===

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the [[JError]] class all begin with "JERROR_".

=== Global Variables ===

If your package needs to define global variables, their name should start with a single underscore followed by the uppsercase class/package name and another underscore. For example, the JError class uses a global variable called $_JERROR_LEVELS.

With PHP5 and later you may use static class properties or constants instead of globals.
<source lang="php">
<?php
class JWhatever
{
public static $instance = null;
const SUCCESS = 1;
const FAILURE = 0;
// Methods...
}
</source>

=== Regular and Class Variables ===

Regular variables, follow the same conventions as function.

Class variables should be set to null or some other appropriate default value. Lining up the default values with tabs should only be used if particularly warranted for readability.

=== References ===

When using references, there should be a space before the reference operator and no space between it and the function or variable name. For example:

<source lang="php">
<?php
$ref1 = &$this->_sql;
$db = &JFactory::getDBO();
</source>

=== Controllers ===

For single controller components, the naming convention is ''[Name]Controller''.

<source lang="php">
<?php
/**
* Content Controller
* @package Joomla
*/
class ContentController extends JController
{
// Methods
}
?>
</source>
The file name will generally be ''controller.php'' and is located in the component folder.
<source lang="text">
com_content
/ controller.php
</source>

For a multi-controller components, such as the Banners in the Administrator, the convention is ''[Component]Controller[Name]''.

<source lang="php">
<?php
/**
* Banner Client Controller
* @package Joomla
*/
class BannerControllerClient extends JController
{
// Methods
}
?>
</source>

The files will be located in a <tt>/controllers/</tt> folder under the component folder. The file names will reflect the name of the controller.
<source lang="text">
com_banner
/controllers/
/ banner.php
/ client.php
</source>

=== Models===

The naming convention is ''[Component]Model[Name]''.

<source lang="php">
<?php
/**
* Banner Client Model
* @package Joomla
*/
class BannerModelClient extends JModel
{
// Methods
}
?>
</source>

The files will be located in a <tt>/models/</tt> folder under the component folder. The file names will reflect the name of the model.

<source lang="text">
com_banner
/models/
/ banner.php
/ client.php
</source>

=== Views ===
The naming convention is ''[Component]View[Name]''.
<source lang="php">
<?php
/**
* Contact Category View
* @package Joomla
*/
class ContactViewCategory extends JView
{
// Methods
}
?>
</source>
The files will be located in a <tt>/view/</tt> folder under the component folder. The subfolder names will reflect the name of a View.

com_contact
/views/
/''view name 1''/
/ view.html.php
/''view name 2''/
/ view.html.php

Multi-view components such as com_content may provide an optional "master" view class the specialised views extend from. It is located in the component folder and typically called ''view.php''. The naming convention is ''[Component]View''.

com_content
/views/
<span style="color:#999">/archive/</span>
/ view.html.php
<span style="color:#999">/article/</span>
/ view.php

<source lang="php">
view.php
<?php
/**
* Content View
* @package Joomla
*/
class ContentView extends JView
{
// Helper Methods
}
?>

views/archive/view.html.php
<?php
/**
* Content Archive View
* @package Joomla
*/
class ContactViewArchive extends ContentView
{
// Methods
}
?>
</source>

=== Layouts ===
Components may support different Layouts to render the data supplied by a [[#Views|View]] and its [[#Models|Models]]. A Layout file usually contains markup and some PHP code for ''display logic only'': no functions, no classes.

A Layout consists of at least one .php file and an equally named [[Creating a basic layout.xml file|.xml manifest file]] located in the <tt>/tmpl/</tt> folder of a View, both reflect the internal name of the Layout. The standard Layout is called ''default''.

<span style="color:#999">com_content
/views/
/article/</span><span style="color:#000">
/tmpl/
/ default.php
/ default.xml
/ form.php
/ form.xml
/ pagebreak.php
/ pagebreak.xml </span>

The Layout may use supplemental .php files to provide more granual control in order to render individual parts or repetitive items of the data.

Users may customise the Layout output via [[#Template Layout Overrides|Template Layout Overrides]].

=== Templates ===

=== Template Layout Overrides ===

Archived:Version 1.6 Developer Notes

2008-10-11T11:45:33Z

Masterchief:

{{incomplete}}
{{RightTOC}}
[[Category:Development]]

Compilation of developer notes on changes in 1.6.

== Schema ==

Added ACL tables (todo - list them)
Removed jos_groups table

== Framework ==

JDatabase::setQuery casts the sql variable to a string. This allows you to pass an object that implements the __toString magic method.

JModel::getState will now take an optional second argument to set the default.
$value = $model->getState( 'foo', 'bar' );

Both JFile::write and JFTP::write now use a reference for its second argument. Code like ''JFile::write($filename,'string');'' will fail, however ''$data = 'string'; JFile::write($filename, $data);'' will work for both 1.5 and 1.6

Remove <code>JAuthorization::_mos_add_acl</code>.

Added <code>JAuthorization::getUserAccessLevels( $section [, $action = 'view'] )</code>.

Added <code>JTableTree</code> as an abstract class for tree-based tables.

JModel has an addition contruction option and internal variable <code>__state_set</code>. This is used to lazy-load model initialisation.

== Components ==

=== Join for access level ===

Before:
<pre>LEFT JOIN #__groups AS g ON g.id = c.access</pre>

After:
<pre>LEFT JOIN #__core_acl_axo_groups AS g ON g.value = a.access</pre>

=== Administrator:Users ===

== Legacy Mode ==

Only available in legacy mode (to be dropped in future versions):

* <code>global $mainframe</code> - Use <code>$app = &JFactory::getApplication()</code> instead.
* JTemplate (patTemplate completely deprecated)

== Files/Features Dropped ==

== TODO ==

Don't forget to do this:

* Access Level links in backend lists need to be refactored to support the new levels available in the jos_core_acl_axo_groups table.

Archived:Version 1.6 Developer Notes

2008-10-10T02:43:58Z

Masterchief:

{{incomplete}}
{{RightTOC}}
[[Category:Development]]

Compilation of developer notes on changes in 1.6.

== Schema ==

Added ACL tables (todo - list them)
Removed jos_groups table

== Framework ==

JDatabase::setQuery casts the sql variable to a string. This allows you to pass an object that implements the __toString magic method.

JModel::getState will now take an optional second argument to set the default.
$value = $model->getState( 'foo', 'bar' );

Both JFile::write and JFTP::write now use a reference for its second argument. Code like ''JFile::write($filename,'string');'' will fail, however ''$data = 'string'; JFile::write($filename, $data);'' will work for both 1.5 and 1.6

Remove <code>JAuthorization::_mos_add_acl</code>.

Added <code>JAuthorization::getUserAccessLevels( $section [, $action = 'view'] )</code>.

== Components ==

=== Join for access level ===

Before:
<pre>LEFT JOIN #__groups AS g ON g.id = c.access</pre>

After:
<pre>LEFT JOIN #__core_acl_axo_groups AS g ON g.value = a.access</pre>

=== Administrator:Users ===

== Legacy Mode ==

Only available in legacy mode (to be dropped in future versions):

* <code>global $mainframe</code> - Use <code>$app = &JFactory::getApplication()</code> instead.
* JTemplate (patTemplate completely deprecated)

== Files/Features Dropped ==

== TODO ==

Don't forget to do this:

* Access Level links in backend lists need to be refactored to support the new levels available in the jos_core_acl_axo_groups table.

Archived:Version 1.6 Developer Notes

2008-10-10T02:31:25Z

Masterchief:

{{incomplete}}
{{RightTOC}}
[[Category:Development]]

Compilation of developer notes on changes in 1.6.

== Schema ==

Added ACL tables (todo - list them)
Removed jos_groups table

== Framework ==

JDatabase::setQuery casts the sql variable to a string. This allows you to pass an object that implements the __toString magic method.

JModel::getState will now take an optional second argument to set the default.
$value = $model->getState( 'foo', 'bar' );

Both JFile::write and JFTP::write now use a reference for its second argument. Code like ''JFile::write($filename,'string');'' will fail, however ''$data = 'string'; JFile::write($filename, $data);'' will work for both 1.5 and 1.6

== Components ==

=== Join for access level ===

Before:
<pre>LEFT JOIN #__groups AS g ON g.id = c.access</pre>

After:
<pre>LEFT JOIN #__core_acl_axo_groups AS g ON g.value = a.access</pre>

=== Administrator:Users ===

== Legacy Mode ==

Only available in legacy mode (to be dropped in future versions):

* <code>global $mainframe</code> - Use <code>$app = &JFactory::getApplication()</code> instead.
* JTemplate (patTemplate completely deprecated)

== Files/Features Dropped ==

== TODO ==

Don't forget to do this:

* Access Level links in backend lists need to be refactored to support the new levels available in the jos_core_acl_axo_groups table.

Archived:Version 1.6 Developer Notes

2008-10-10T02:21:16Z

Masterchief:

{{incomplete}}
{{RightTOC}}
[[Category:Development]]

Compilation of developer notes on changes in 1.6.

== Schema ==

Added ACL tables (todo - list them)
Removed jos_groups table

== Framework ==

JDatabase::setQuery casts the sql variable to a string. This allows you to pass an object that implements the __toString magic method.

JModel::getState will now take an optional second argument to set the default.
$value = $model->getState( 'foo', 'bar' );

Both JFile::write and JFTP::write now use a reference for its second argument. Code like ''JFile::write($filename,'string');'' will fail, however ''$data = 'string'; JFile::write($filename, $data);'' will work for both 1.5 and 1.6

== Components ==

=== Join for access level ===

Before:
<pre>LEFT JOIN #__groups AS g ON g.id = c.access</pre>

After:
<pre>LEFT JOIN #__core_acl_axo_groups AS g ON g.value = a.access</pre>

=== Administrator:Users ===

== Legacy Mode ==

Only available in legacy mode (to be dropped in future versions):

* <code>global $mainframe</code> - Use <code>$app = &JFactory::getApplication()</code> instead.
* JTemplate (patTemplate completely deprecated)

== Files/Features Dropped ==

Pizza Bugs and Fun 2

2008-09-04T07:18:36Z

Masterchief:

[[Category:Bug Squad]]
[[Category:Development]]
[[Image:pbf.png|right]]
{{RightTOC}}

We eagerly announce the second Joomla! Pizza Bug and Fun event scheduled for the weekends of '''June 21 and 22''' and '''June 28 and 29'''. It's hard to believe that six months have passed since the first Joomla! Pizza Bug and Fun event. The first PBF helped finalize Joomla! 1.5 and, if all goes as planned, this second event will help prepare Joomla! 1.5.4 for release early in July.

This wiki will be used as the central resource for coordinating efforts and accumulating results from this event.

== Goals ==

* '''Bugs''' : For our first PBF event, we targeted priority 1 and 2 bugs and tested the entire application. Since it's release, Joomla! 1.5 has been very stable and there are no serious bugs to fix. But, there are a number of medium priority items that require patches and testing. If we are able to empty the tracker during the weekend, it would be an important accomplishment for the community.

* '''Documentation''' : since the last [[Doc Camp 1|Doc Camp]] a lot of documentation has been written, but we need more of it. If you want to help out writing documentation, you're also more than welcome.

* '''Unit testing''' : we have started writing unit tests for Joomla! This is documented in the wiki, see [[Unit Testing]] for details. This is a very important part to improve the overall quality of Joomla! and increase development speed. If you have experience in this area, we challenge you to come help us.

== FAQ ==
Below you will find as much as possible information we can share on how this events is organized. If you don't find what you are looking for, you can check out the [[PBF FAQ]].

== Organization, logistics and communications ==

Managing this event will be a challenge. The team of [[Pizza couriers]] is working on the organization of this event, taking care of all logistics, infrastructure and communications.

'''Read this blog for information on how to get started when you arrive for the Pizza, Bugs and Fun event:'''
see http://developer.joomla.org/home/26-coordinator-blog/147-the-best-ingredients-for-a-nice-pizza.html

== Locations ==

If you want to get people together and have a venue to share, please add it below. Share as much as possible details like exact location, url for more information about the venue, ways to register, date and time the venue is available etc. If you have any questions regarding this, feel free to contact Wilco Jansen (wilco.jansen@joomla.org).

=== Europe ===
Hotel La Meridiana
Viale Italia 198 - Marina Romea 48010 Ravenna (Ra) Italy
28 June 2008
Additional information [http://www.joomladay.it/ www.joomladay.it]
To register post [http://forum.joomla.it/index.php/topic,44604.0.html here]
[http://www.joomladay.it/component/option,com_contact/task,view/contact_id,1/Itemid,2 Contacts]

JUG Catalan Countries
June 21. Can Domenge Centre Tecnologic. Soldat Arrom quart, 1. Palma de Mallorca Spain
[http://www.joomla.cat JUG Catalan Countries Website]

There will also be a location in the Netherlands (Amsterdam, Rotterdam or Eindhoven, most likely it will be Rotterdam)
If you are interested please send a mail to wilco.jansen@joomla.org

=== North America ===

Webimagery, LLC
843 Carondelet St. Suite 6
New Orleans, LA 70130
USA
[http://jpbf2nola1.eventbrite.com June 21 Registration]
[http://jpbf2nola2.eventbrite.com June 22 Registration]

PICnet, Inc. (DC)
1341 G St, NW, Suite 1100
Washington DC, 20005
[http://www.joomladayusa.org/index.php?option=com_events&type=event&task=details&id=6&Itemid=11 Registration Page]

New York City JUG
WinterGarden
World Financial Center (By the Gap)
[http://www.joomlanyc.org Joomla NYC Website]

Vancouver, BC, Canada
822 Homer (at Robson)
Across from where the JoomlaDay event was held.
Call Mike Hamanaka or Amir Sharifnejad at +1-604-626-9225 and we will buzz you in.
[website to be announced]

Georgia Institute of Technology
Library, East Commons
Performance Space ([http://librarycommons.gatech.edu/lec/index.php Zone 1])
Atlanta, GA 30332
[http://maps.google.com/maps?f=q&hl=en&geocode=&q=georgia+tech+library&jsv=117&sll=37.0625,-95.677068&sspn=31.013085,70.576172&ie=UTF8&latlng=33784533,-84408802,8904700088832885237&ei=ZS5lSPWvGZ2WqgL5lqGLDg&cd=1 Map]

=== South America ===
No venue registered

=== Asia/Pacific ===

Spike Systems Pty Ltd
Level 6, 99 York Street
Sydney.
Map here: http://tinyurl.com/4gwatl
URL with additional information will follow soon (including registration option).

=== Africa ===
No venue registered

===Cyberspace===
====Internet Relay Chat (IRC)====
Freenode channel [irc://irc.freenode.net/joomlapbf #joomlapbf] from 21 to 22 June 2008, all times, all timezones.

If you don't have an IRC client installed, use this link: [http://www.joomlanyc.org/index.php?option=com_wrapper&Itemid=23 #joomlapbf]. This is a web-based IRC client.

This channel is available now and throughout the event. We might set up additional channels, if we do they will be listed above.

== Registration ==
=== For write access to this wiki ===
To get write access to this wiki you will need to [[Special:Userlogin|register here first]]. Please be aware that the registration process requires a valid email address. If you are traveling to one of the physical locations you are advised to ensure that you have registered on this wiki and have a valid login before you travel. You don't need access to your email account after registration.

=== At a physical location ===
If you wish to be present at one of the physical locations listed above then you must register in advance because space most likely is limited. Registrations are the responsibility of the individual location organizers and you should click on the appropriate link above for more information.

=== Taking bugs, tasks and pizza ===
Pizza can be ordered at a shop near by :-)

Please check the [http://docs.joomla.org/Pizza_Bugs_and_Fun_2#Organization.2C_logistics_and_communications Organization, logistics and communications section] for detail on how to get involved in working on tasks.

==Requirements==
* All code must be made available under the [http://www.gnu.org/licenses/gpl-2.0.html General Public Licence version 2].
* All documentation contributions must be made available under the [[JEDL|Joomla! Electronic Documentation License]]. Further information on the JEDL is available in the [[JEDL/FAQ|JEDL Frequently Asked Questions]]
* No advertising or self-promotion will be allowed. This includes back links to your website or anyone else's. The one exception is that if you have made a contribution then feel free to add your name and an optional link to your website to the [[PBF Contributors List]]
* All contributions must be in English. Note that the official language of the Joomla! project is British/Australian English.
{{:PBF_Contributors_List}}

Archived:Learn more about patch files

2008-09-04T07:17:19Z

Masterchief:

[[Category:Bug Squad]]

Test this patch, make a patch, are things you hear when you report an issue or when you're working on bugs. What exactly is a patch?

A patch is a file that indicates which exact lines in which exact files should be changed.

Here's a recent patch from issue 11354 which corrected a simple typo.

<code>
Index: plugins/authentication/gmail.php
===================================================================
--- plugins/authentication/gmail.php (revision 10386)
+++ plugins/authentication/gmail.php (working copy)
@@ -87,7 +87,7 @@
}
}
else {
- $message = 'curl isn\'t insalled';
+ $message = 'curl isn\'t installed';
}
if ($success)

</code>
Looking more closely, we see that the patch always starts with the name of the changed file relatiive to the Joomla! root. In this case it is the file gmail.php in the plugins/authenticaion folder.

Next we see the file named again in two lines. The number in the first line represents the version of the code base or build on which the patch was created, The working copy is the copy that is changed. What do I mean by build? Every time a change is made to he codebase, that creates a new revision or build. You can find your build number in the changelog.php file in your joomla! root.

Next comes @@ -87,7 +87,7 @@ which tells us that the change will starton line 87 of the file.

Finally we see the code. The old line 87 has a – in front of it and the new line 87 has a +.

The new version of the line will replace the old line in the file.

Of course most patches are much more complex than this, but they really just are repeated instances of this structure.

So if you saw this patch file and wanted to fix your version of Joomla! all you would need to do is find line 87 of gmail.php and make that change. So if someone tells you “There's a patch on the tracker” what they are saying is that you can go download the patch and apply it to your version of Joomla!. However one thing to keep in mind is that if your version does not match the version in the code repository it is possible that that patch will not work because it depends on or impacts other parts of the code.

Now, if you're contributing a bug fix as opposed to just reporting an issue, the ideal is to submit a patch file that you have tested. However, if you can't do that, at least give this information:

* The complete names and paths of any files changed
* The line numbers of the changes
* The old and new versions of the changed lines

However, making a patch file is even better and is not complicated if you install a subversion client such as Tortoise or the Subclipse plugin for Eclipse.

Filing bugs and issues

2008-09-04T07:16:18Z

Masterchief:

[[Category:Bug Squad]]
{{review}}

== Reporting bugs ==

To report a bug in the Joomla! bug trackers, you need to create an "artefact" (''Editor's note: joomlacode.org uses the American spelling "artifact", but our policy is to use British/Australian spellings throughout the documentation.''). Once the artefact is created, the developers will check the validity of it and act accordingly.

=== Register an Account at joomlacode.org ===
[http://joomlacode.org/gf/account/?action=UserAdd Register]

=== Access the Joomla! development bug tracker. ===

*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=32 Joomla! 1.5 Bug Tracker]
*[http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemBrowse&tracker_id=5782 Joomla! 1.0 Bug Tracker]

=== Check to see if the bug you want to report is already reported. ===

A series of filters display the artefacts. Make sure Priority is set to "Any", Assignee to "Any" and Status to "Any", other filters to nothing. Mouse over the title of the artefacts to check their contents. If the issue you are experiencing is not already reported, click on the bottom-right Button "Add new Tracker Item".

A new screen will display and there, the more information you give, the easier it is for the developers.

Fill as many fields as you can.

* [[Priority]] : Use the default "Medium" except if you know the code enough to make another choice.
* PHP : Choose the version you are testing on. You can find this information by clicking the Menu "Help"->"System Info" in the Administrator back-end of Joomla!.
* Estimated Time : Leave this blank.
* Build : Type here the #SVN number if you know it, or Nightly Build date, or Version used if using a Released version.
* Browser : Self-explanatory.
* Database : The version of MySQL is also available in "Help" -> "System Info".
* Status : Leave this to "Open".
* Percent Complete : Leave this blank.
* Category : This one is more tricky. Use "Administration" if you do not know better.
* Customer : Use "User" if the issue is in front-end, "Developer" if the issue concerns an extension you are developing, "Administrator" in other cases.
* Web Server : The version/server type is also available in "Help" -> "System Info".

=== Provide a summary ===

Describe in a few words the issues you are having. It is generally a good idea to use existing artefacts as examples if this is your first time reporting a bug.

Examples:

* Front-end: Warning such and such.
* Back-end: Unable to save article when "nameofplugin" is published.

Note: Take care to be descriptive in your summary as this is the first thing the developers will see when they are perusing the tracker for something to fix.

=== Provide details about the bug ===

This is the most important part of reporting the bug. Describe here step by step how you got the error you are noticing.

The more details, the better.

Examples:

A. When I enabled "nameofplugin", no article can be saved. These are the plugins enabled at the same time. SEF is on (or Off). My site is in a sub-folder. I also remark that... etc. Files such and such are the issues IMHO (if you know what you are talking about).

B. Back-end. Clicking on "menu_name" Menu. Page opened is blank. Any other menu works OK. etc.

C. Back-end. Content -> Article Manager (The -> means you click on a submenu). Editing a non-categorized Article. Section dropdown does not display the sections available (or Editor is going over the right column for parameters, or Can't save article after changing a parameter [describe parameter], etc.

D. I have such an such issue when doing this and that. By changing this code [code proposed] in file [name and hierarchy of file], line(s) #, the issue looks solved on my settings.

=== Add an attachment to your report ===

To better describe the issue or/and propose a fix, you can add attachments to the artefact you are creating by using the "Browse" buttons at the bottom of the screen.
A screen capture of the page(s) concerned helps a lot. If you can, try to optimise the size of the image through an image editor.
If you know what part(s) of the code base to change, a patch [patches] or a full file where your changes are WELL shown will help the developers to solve the problem quicker.

=== Finish and send in the report ===

You will receive an e-mail confirming that you posted the artefact. When someone comments or asks for supplementary details or solves the issue, you will receive a notification e-mail and may reply if needed.

=== Extra tips and tricks ===

Well-written bug reports are incredibly helpful. However, there's a certain amount of overhead involved in working with any bug tracking system, so your help in keeping our ticket tracker as useful as possible is appreciated. In particular:

* Do read the [http://docs.joomla.org/FAQs FAQ] to see if your issue might be a well-known question.
* Do search [http://joomlacode.org/gf/project/joomla/tracker/ the tracker] to see if your issue has already been filed.
* Do ask on [http://forum.joomla.org/index.php/board,199.0.html testing forums] first if you're not sure if what you're seeing is a bug.
* Do write complete, reproducible, specific bug reports. Include as much information as you possibly can, complete with code snippets, test cases, etc. A minimal example that illustrates the bug in a nice small test case is the best possible bug report.
* Don't use the tracker system to ask support questions. Use the [http://forum.joomla.org/ Joomla! forums], or the [irc://irc.freenode.net/joomla #joomla] IRC channel on freenode for that.
* Don't use the trackers to make large-scale feature requests. We like to discuss any big changes to Joomla!'s core on the [http://forum.joomla.org/index.php#6 developers forums] before actually working on them.
* Don't reopen issues that have been marked "not a bug". This mark means that the decision has been made that we can't or won't fix this particular issue. If you're not sure why, please ask on developer forums.
* Don't use the tracker for lengthy discussions, because they're likely to get lost. If a particular artefact is controversial, please move discussion to [http://forum.joomla.org/index.php#6 developer forums].

== Reporting security issues ==

Report security issues to security [at] joomla [dot] org. This is a private list only open to long-time, highly trusted Joomla! developers, and its archives are not publicly readable.

In the event of a confirmed vulnerability in Joomla! itself, we will take the following actions:

* Acknowledge to the reporter that we've received the report and that a fix is forthcoming. We'll give a rough timeline and ask the reporter to keep the issue confidential until we announce it.
* Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases.
* Determine a go-public date for announcing the vulnerability and the fix. To try to mitigate a possible "arms race" between those applying the patch and those trying to exploit the hole, we will not announce security problems immediately.
* Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of Joomla! but in some cases it may simply be patches against current releases.

Testers

2008-09-04T07:15:20Z

Masterchief:

[[Category:Bug Squad]]
{{Tester profile}}

* [[Patch submission guidelines]]
* [[Filing bugs and issues]]
* [[Testing Checklists]]
* [[Automated testing]]

== Reference Pages ==

Peruse all pages in the [[:Category:Bug Squad]] category.

When creating a new page, ensure you place the following marker at the top of the page so it is included in the category list:

<pre><nowiki>[[Category:Bug Squad]]
</nowiki></pre>

If you locate other articles you thing that are relevant to developer, please add this marker to those pages.

Category:Coordinators

2008-09-04T07:13:49Z

Masterchief: New page: Pages that are useful for coordinators, team leaders, global moderators and the like (anyone in a leadership or supervisory role).

Pages that are useful for coordinators, team leaders, global moderators and the like (anyone in a leadership or supervisory role).

Joomla:Release procedure and checklist

2008-09-04T07:12:05Z

Masterchief:

[[Category:Bug Squad]]
[[Category:Coordinators]]
[[Category:Development]]

There is a general checklist when a version of Joomla! is released. Keep in mind that a major release differs a lot from a [[Minor Release]] or even a [[Maintenance Release]]. The checklist here describes the steps that need to be done for (at least) [[Maintenance Release]] and [[Minor Release]].

== Release checklist ==

It depends on the [[Development Cycle]] when the checklist is triggered. A release can be done during every stage of the [[Development Cycle]], it does not matter if you release a beta or a stable version, this is a general checklist that can be used when releasing a new version of Joomla! The checklist starts when it's decided to release a version:

=== Preparation phase ===
# Communication pre-release: check with all Working Group Coordinators for status
# Communication pre-release: check with Lead Developers for status
# Communication pre-release: inform Bug Squad and Development Team of upcoming release
# Decision: when the above has positive result, set a date and time for release
# Communication pre-release: inform Global Moderators about upcoming release
# Communication pre-release: check availability and assign release tasks to Core and work-group members.
# Close trunk on predefined date and time (Development Coordinator, also sends an e-mail to development list).
# Image for front page download module, has to be modified for the release.
# Contact foundation work group for creation of Front page announcement.
# Determine release name

=== Pre-execution phase ===
# Apply latest translations (need to be delivered by translation work group).
# Create test package.
# Offer test package to testers: [[Bug Squad]] members, [[Development Team ]] members, translation members
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.

=== Execution phase ===
# Change version information.
# Enable install check.
# Add entry in CHANGELOG.php file
# Package build.
# Offer test package to testers: [[Bug Squad]] members, [[Development Team ]] members, translation members
# If problems are found during this stage, go back to fix the problem. Use the [[Joomla! Maintenance Procedures]] and repeat until tests are performed successfully.
# Add package to joomlacode.org
# Publish announcement on joomla.org and the forum, change download module image and link
# Make static copy of front page with announcement to be used if server load becomes critical.

=== Finalization phase ===
# Tag SVN.
# Un-freeze the trunk, send e-mail to work groups and mailing lists ([[Development Team]] and [[Bug Squad]]).
# Undo install check.
# Change content on joomla.org and dev.joomla.org (see pages to update)
# Update MD5 checksum information
# Update nightly builds to reflect new release

=== Pages to update ===

#Global:
#* [http://developer.joomla.org/code.html Developer Code] (Nightly links)
#1.5:
#* [http://www.joomla.org/content/blogcategory/57/111/ Latest Release] (Administrator Latest Version Check)
#* [http://docs.joomla.org/Joomla_1.5_version_history Version History]
# 1.0:
#* [http://dev.joomla.org/content/blogcategory/21/86/ Current Status]
#* [http://www.joomla.org/content/blogcategory/32/66/ Latest Release]
#* [http://www.joomla.org/content/category/5/34/78/ Changelog]
#* [http://www.joomla.org/content/category/5/39/95/ MD5 Sums]

=== Communication ===
For boiler-plate communication messages, see [[Release Communication Templates]].

Testers

2008-09-04T07:07:44Z

Masterchief:

{{Tester profile}}

* [[Patch submission guidelines]]
* [[Filing bugs and issues]]
* [[Testing Checklists]]
* [[Automated testing]]

== Reference Pages ==

Peruse all pages in the [[:Category:Bug Squad]] category.

When creating a new page, ensure you place the following marker at the top of the page so it is included in the category list:

<pre><nowiki>[[Category:Bug Squad]]
</nowiki></pre>

If you locate other articles you thing that are relevant to developer, please add this marker to those pages.

Joomla! Maintenance Procedures

2008-09-04T07:06:05Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]

Once a major/minor release has reached the Stable phase in the [[Development Cycle]] the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the [[Development Team]] when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the [[Bug Squad]]. It is important to understand the way we think about a [[Maintenance Release]] because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.

Once a release has been declared stable ([[Maintenance Release]]), all bugs and artifacts are to be tracked in our official [[Tracker]] on the Joomla! GForge site: [http://www.joomlacode.org]. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

The maintenance procedures have the following stages :
* [[Reporting issues]]; We keep track on the open issues in our [[Tracker]] but issues can be reported in two ways: from the forum or directly into the tracker. A description of the process of [[Reporting issues]] is available (click the link).
* [[Resolving issues]]; Once an issue is confirmed, there are several ways it can get solved. First members from the [[Development Team]] can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch. A description of the [[Resolving issues]] process is available (click the link).

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the [[resolving issues]] process. In maintenance releases we work with patches, and within the [[Development Cycle]] of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of [[Development Cycle|Release Candidate]].

Minor Release

2008-09-04T07:04:29Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]
Minor Release Number (X.'''Y'''.Z) - An increment of the minor number usually indicates a significant change in functionality. Moderate to high level of backward compatibility with previous minor increments.

In minor releases we try not to alter the API, only additions to the API can be implemented when new logic is incorporated within the code base.

Major Release

2008-09-04T07:04:17Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]
Major Release Number ('''X'''.Y.Z) - An increment of the major number generally indicates a major rework or rewrite of the code base (framework level). Is most likely incompatible with prior major releases.

Currently Joomla! has released the following major releases:

* 1.0.x - code base derived from Mambo 4.5.3
* 1.5.x - major rewrite of the codebase, parts of Joomla! 1.0.x still reside in the codebase

Version Strategy

2008-09-04T07:03:56Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]
Joomla! release versioning follows a numerical convention comprised of three numbers: Major, Minor and Maintenance. The version is presented in the major.minor[.maintenance] format.

* [[Major Release]] Number (X.Y.Z) - An increment of the major number generally indicates a major rework or rewrite of the code base (framework level). Can be incompatible with prior major releases.

* [[Minor Release]] Number (X.Y.Z) - An increment of the minor number usually indicates a significant change in functionality. Moderate to high level of backward compatibility with previous minor increments.

* [[Maintenance Release]] Number (X.Y.Z) - An increment of the maintenance number usually indicates bug fixing within the minor release and possibly small enhancements and limited new features. Fully backward compatible with previous maintenance increments.

Maintenance Release

2008-09-04T07:03:37Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]
Maintenance Release Number (X.Y.'''Z''') - An increment of the maintenance number usually indicates bug fixing within the minor release and possibly small enhancements and limited new features. Fully backward compatible with previous maintenance increments. Maintenance releases strive to stability and bug fixes.

A full description of the [[Version Strategy]] and the release versioning is available.

Development Cycle

2008-09-04T07:02:13Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]
[[Image:montano_wheel.png|right]]We have adopted a three phase development cycle. The three phases are:

* Alpha Phase; refactoring and Development.

* Beta Phase; Testing, Documenting and Fine Tuning.

* Stable Phase; Stabilization, Public Information, etc.

These three phases are also known as the Opening, Mid-Game and End Game among project managers. As you can see each phase has a different main focus, focus in the Alpha phase is on Development but shifts to Documentation and Testing for the Beta phase and finally to Public Information in the Stable phase.

== Alpha Phase ==
The Alpha phase of the development cycle is when we decide on what the goals are for the next release. This is by far the most important part of the process and is done in complete consultation with the community through the submission of public [[White Papers]]. The acceptance of papers sets the functional requirements for all the goals in the release.

This is a time for fixing more complex issues that have arisen from the previous version, for implementing new features and functionality, and for dropping parts of the code that have been previously earmarked for removal, or deemed to be no longer necessary.

During this time the development trunk will be in a state of flux and break from time to time. Several Alpha releases may be made to allow the user and third-party developer community to comment on the progress of the work in terms of the goals set.

By working closely with third party developers as we transition from the Alpha to the Beta phase we hope to be able to provide all necessary information and support to ensure that their extensions are compatible with future versions of Joomla!

== Beta Phase ==
The Beta phase of development indicates a major milestone in the development cycle. At this phase we move from pure development towards testing and documentation. From a development standpoint, focus shifts from implementation to stabilization. At this point community input is extremely important and we increase our outwards communication towards third party developers. Together we analyze and solve breakages, improve performance and finetune the API where necessary.

This stage of the process signifies several things:
We are now framework feature complete.
Documentation effort on the API begins.
Third party backwards compatibility testing on the framework begins.
Core extension refactoring and user interface changes begins.

== Stable Phase ==
During the stable phase we release one or more release candidates. At this phase code base is considered stable and secure and any final bugs are taken care of as they come to our attention. It is during this phase of the development cycle that the software is packaged and released. Most attention goes into promotion and public information.

Control over the code base from the release is delegated from the [[Development Team]] to the [[Bug Squad]]. During this stage the [[Joomla! Maintenance Procedures]] are in place.

Joomla! Maintenance Procedures

2008-09-04T07:01:46Z

Masterchief:

[[Category:Development]]
[[Category:Bug Squad]]

Once a major/minor release has reached the Stable phase in the [[Development Cycle]] the processes and procedures for development change. The most immediate thing to notice is that the development is no longer driven by the [[Development Team]] when the Stable phase is reached. As soon as the major/minor release is declared stable all future development on that release is driven by the [[Bug Squad]]. It is important to understand the way we think about a [[Maintenance Release]] because one of the things that our community depends upon is stability. Stability is born of a rigorous testing process and accountability. This document will outline the procedures and processes for maintaining a Joomla! major/minor release.

Once a release has been declared stable ([[Maintenance Release]]), all bugs and artifacts are to be tracked in our official [[Tracker]] on the Joomla! GForge site: [http://www.joomlacode.org]. Having a single place for confirmed issue tracking provides us all with a simple system of accountability.

The maintenance procedures have the following stages :
* [[Reporting issues]]; We keep track on the open issues in our [[Tracker]] but issues can be reported in two ways: from the forum or directly into the tracker. A description of the process of [[Reporting issues]] is available (click the link).
* [[Resolving issues]]; Once an issue is confirmed, there are several ways it can get solved. First members from the [[Development team]] can work on solving the issue, but also community members can send in patches. The general way of working is: create patch, test patch, commit patch. A description of the [[Resolving issues]] process is available (click the link).

The maintenance procedures implement the Quality processes for Joomla!. This process differs only during the development stage of a major release or a minor release in the [[resolving issues]] process. In maintenance releases we work with patches, and within the [[Development Cycle]] of a major release or a minor release developers will fix issues directly in the trunk until the codebase reaches a stage of [[Development Cycle|Release Candidate]].