Joomla! Developer - Developer Blogs

Joomla 1.6 Alpha 2 Released

ken.crowder@joomla.org (Kenneth Crowder) — Sun, 25 Oct 2009 19:09:00 +0000

The Joomla project is pleased to announce the immediate release of Joomla 1.6 alpha 2. This release contains many new features requested by the community; most notably, ACL. Other features are listed below as well as what you can expect in the future for Joomla 1.6.

This is an alpha release. It is intended to be a developer/hobbyist preview and is not intended to be used on a production web site.

Feature patches for 1.6

Wilco.Jansen@joomla.org (Wilco Jansen) — Wed, 04 Mar 2009 22:01:26 +0000

On January 25th we reported back from the development coordinator summit. A lot of people noticed that we created three new development-related, publicly-accessible mailing lists for the Joomla development community. The most important reason for us to open up in this way is to attract more developers and enable them to help out with core development. As it is very tempting to start providing us with all kinds of patches, we wanted to explain what it takes to submit a feature patch. Before you fire any questions at us, please make sure you read the full article and also the link to the feature patch policy document.

Bug Fixes vs Feature Patches

What's the difference between a bug fix and a feature patch?

Bug-fix patches have been accepted for more than a year now via the Joomla Bug Squad and serve to fix issues with existing features and systems. These patches can be attached to the Joomla 1.5 bug tracker when you submit a problem. For more information see the Reporting Bugs policy.

Feature patches, on the other hand, are for adding or changing functionality to any Joomla version (note submissions for 1.0 will not be accepted due to the approaching end-of-life for that version). Feature patches could be as significant as whole extensions (like a Comments component), or they could be as small as adding a new argument to a method in a Joomla Framework class.

Revisiting the 1.6 Road Map

First of all it is important to understand the road-map for Joomla 1.6. During the recent Development Summit we resolved what would comprise the Alpha version of 1.6. These features must be complete before the alpha can be released. The features are listed below along with their current state of completion:

Implement a new JForm library package [complete].
Implement a simple way of providing translation in JavaScript [complete].
Implement new controller dispatchers for more robust request routing [complete].
Implement a new access control system that needs to at least emulate what is in 1.5, allow adding of new groups and access levels, and allow you to set new "view" rules for at least articles [nearly complete].
Implement and standardise several new event triggers [in progress].
Implement a JContent class that will be used by content plug-ins and views [in progress].
Upgrade to Mootools 1.2 [in progress].
Finish the new extension updater work [in progress].
Menu manager re-work -- added since it's broken in 1.6 [in progress].

After we release the alpha, each beta release will be time-boxed (we hope that not more than four are required). The following is a list of the features highly desired for the final distribution. Each of these features will need to be complete in order to be included in a beta release. Some of these features will make it in the alpha, but none will prevent the alpha from being released if they are not ready. Overall we will need significant help from the Joomla development community to complete any of these features:

Implement unlimited depth categories (but not multi-mapping).
Refactor the user management system and make it more extensible (eg, allow custom user fields).
Implement a comments system (including pings and track-backs).
Implement queued redirects (allows you to, for example, return to the previous page you were on after you edit something).
Refactor parameters and make them more extensible (for example, plugins could allow you to add additional custom parameters to articles).
Finish MVC-ing the Administrator components (we need lots of help here).
Implement CAPTCHA helpers for any form.
Implement systems whereby external authentication systems, such as LDAP, can map to our new Joomla user groups.
Re-implement the ability to select multiple categories for some views in com_content (was in 1.0, got dropped in 1.5).
Implement a database driven installation log.
Refactor JError.
Examine the PDF generation system in detail and see if we can make it work properly (otherwise we will look at dropping it if we can't make it work well).
Localise the Invalid Token messages.
Drop the Polls component because the quality of that extension is pretty bad and there are much better third-part alternatives available.
Convert all layouts to semantic, XHTML Strict.
Convert of ini-based "params" fields to use JSON instead of INI format (huge technical and performance improvements). Note, the language files will remain in INI format.

It is important to understand that we will focus on the features listed above. There are no doubt lots of ideas for what could be implemented, but it is very important to understand that this is the list of features we will focus on. The features that make it into the final Joomla 1.6 release will depend upon what the Joomla Development Community contributes. Since some these features are already being worked on, we strongly advise everyone to post a message to the Joomla general development mailing list before you start working on something. If you're not already a member, please apply.

The policy document handles all details, just read the policy document on the development site for those interested in committing back to the project...let's stick to the code and make good things happen!

Feature Patches

mamboblue@gmail.com (Andrew Eddie) — Fri, 13 Feb 2009 22:23:21 +0000

The Joomla code-base is used by millions of people around the world and we care a great deal about the quality of the code we release. While code quality is not an exact science we do require that code contributions to Joomla should be understandable, robust and complete.

Patches should be understandable.

Your patch should be understandable. If we can't work out what it does then it makes it very difficult to evaluate, and even more difficult to maintain in the future.

The code must follow our coding style guidelines.
The code must use the Joomla Framework API. Do not submit patches that make direct calls to mysql_query() when the JDatabase library should be used for example.
Patches must be submitted in unified diff format. Subversion generates unified diff patches natively so you should be able to use your favorite subversion client to create the patch. More information can be found on the Joomla! documentation wiki on the Learn more about patch files page.
The code must be well commented. There are no hard rules for comment requirements other than to make sure you have doc-blocks where appropriate and that you have comments to explain non-trivial code blocks.
Note the section of the subversion tree as well as the revision number your patch was created against.

Also, please discuss your work on one of the development mailing lists before submitting it. The maintainers can help you determine if your work is an architectural fit with the code-base and also provide general guidance. Following these guidelines will help to ensure that everyone can understand your work and will increase the chance of it being added to the core code-base.

Patches should be robust.

As robustness can be interpreted in many ways, we would like you to test the patch thoroughly before you submit it. Testing features with several browsers and in multiple server environments is also good practice to ensure that it works for all Joomla supported platforms. Make sure to follow security best practices as well so that the code is as secure as we can make it.

Patches should be complete.

Something we also like to see is completeness. We will not accept feature patches that are half done, or where certain aspects of the feature are not functioning properly. Please make absolutely certain that all features are completed, tested and documented before you submit them.

Technical Requirements

You must be aware of the minimum technical requirements for the version of Joomla for which you are submitting a feature patch.

See http://www.joomla.org/about-joomla/technical-requirements.html

How To Submit A Feature Patch

Once you've actually done all the hard work of creating and testing your work, submitting the patch is quite easy. Register on Joomlacode.org so you can submit the feature patch on the Joomla 1.6 feature patch tracker.

Choose a descriptive patch title.

Please pick a good title for you patch. Thinks like "Cool new feature" are not helpful when reviewing the patch. Choose a reasonably descriptive name that tells us what you are modifying, for example:

"Add Save and New toolbar function to all Administrator components"
"Back-port JController::getInstance method from 1.6 to 1.5"
"com_content layout override for section view to provide a book table of contents like format"

Provide as much supporting information as possible.

It's a good idea to include as much supporting information and references as possible, such as links to mailing list discussions, forum posts, and so on. You did start a discussion on the mailing lists about your feature didn't you?

Inform the development mailing list.

When you submit a feature patch, send a short mail to the relevant development mailing list to let everyone know about your work. This will serve as the thread for people to comment on and review your patch. You can either use the thread previously created to discuss your work or start a new one.

How Your Patch Gets Reviewed

Once your patch is submitted it will be reviewed by your peers. The decision for what is accepted lies with a group of core maintainers and the development coordinators. For non-trivial patches expect conversation about your work and be ready to explain your ideas.

Your patch is given a status of "Under Review".

When your patch is first submitted it has a status of "Open". Once a maintainer has looked at your entry in the feature patch tracker, he or she will set the status to "Under Review" and assign the patch to him/herself so that it is obvious who is responsible for patch review.

An explanation of the different status states for a patch are as follows:

Open - The patch has been submitted, but has not yet begun the review process. This is the default status for every feature patch when submitted to the tracker.
Under Review - The patch has been picked up by a maintainer for review. This is the the point in which discussions would take place on the relevant development mailing list and code review would take place.
Denied - The feature patch has been denied. A short description of the reason can be found in the description field and a short notice will be posted on the mailing list where applicable.
Accepted - The patch has been accepted and is scheduled to be committed to the core code-base. Time to start partying!
Implemented - The patch has been committed to the core code-base and is now part of Joomla. When you update your copy of the subversion tree you will see your patch incorporated and your name added to the credits file.

Your patch will be assigned a priority.

Upon being set to "Under Review" status by a maintainer, your patch will also be given a priority. The priority state helps maintainers process patches more efficiently in line with our goals and missions for the given release.

An explanation of the different priority states for a patch are as follows:

High - This is a patch we consider very important and should be reviewed as a priority.
Medium - This is the default setting for any newly submitted patch and just means that your patch is in the general pool for consideration.
Low - This is a patch that we think would good to include in a future version of Joomla, but is not necessarily a target for this release.

Please note that the priorities do not necessarily mean that reviews will happen faster. It just affects the nominal order in which we devote resources to reviewing them.

Your patch will be discussed.

Once under review, your feature patch will be discussed on the mailing list by your peers and reviewed for code quality, understandability, robustness and completeness by the assigned maintainer. A minimum of two maintainers are required to sign-off on a patch for it to be accepted, but the number of maintainers involved in review of your patch may vary depending upon the complexity and size of the submission.

A decision will be made.

After your patch has been sufficiently discussed a decision will be made about its acceptance. If it is accepted it will be placed in the commit queue and its status will be adjusted accordingly in the tracker. If it is denied a short reason will be given and its status will also be adjusted accordingly in the tracker. Whatever the decision a follow-up email will be posted to the relevant mailing list describing the decision and reason.

Licensing

The Joomla code-base is licensed under the GNU General Public License (version 2 or later). When you submit a patch to the Joomla code-base you agree to license your changes under the GNU General Public License.

Copyright

Individual contributions to the Joomla code-base are copyright their respective authors. Open Source Matters, Inc. holds the copyright on the combined Joomla code-base. Copyright notices are respected for any existing work incorporated into the Joomla code-base.

Attribution

When you submit a patch that modifies or extends existing code that is accepted by the maintainers, an entry into the credits file will be added for that release. Entries in the credits file will also be added for new and replacement libraries or extensions.

Get Involved

Joomla is a great and growing open source project, and we are passionate about our values of freedom, equality, trust, community, collaboration and usability. Getting involved in our development community will help you hone your skills, help us reach our goals and more importantly help ensure Joomla remains the best platform for digital publishing and collaboration into the future.

Getting involved is as easy as joining one or more of our public mailing lists. Join the list(s) that best suit your interests and become a part of the community today!

Joomla General Development

This list is for discussing general topics surrounding Joomla development. If you have questions or ideas about how to write software on the Joomla platform this is the place to get involved.

Join the discussion: http://groups.google.com/group/joomla-dev-general

Joomla CMS Development

This list is for discussing development of the Joomla content management system. Discussions about the Joomla CMS core and its releases happen here. If you want to contribute to the next release of the CMS join us here and get started.

Join the discussion: http://groups.google.com/group/joomla-dev-cms

Joomla Framework Development

If you want to work on expanding and perfecting the platform that Joomla is built on this is the mailing list for you. This list is for discussing the research and development of the Joomla Framework and new technologies for it.

Join the discussion: http://groups.google.com/group/joomla-dev-framework

Reporting Bugs

mamboblue@gmail.com (Andrew Eddie) — Fri, 13 Feb 2009 21:49:24 +0000

To report a bug in the Joomla! bug trackers, you need to create an "artifact". Once the artifact is created, the developers will check the validity of it and act accordingly.

Register an Account at joomlacode.org

Access the Joomla! development bug tracker.

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

A series of filters display the artifacts. Make sure Priority is set to "Any", Assignee to "Any" and Status to "Any", other filters to nothing. Mouse over the title of the artifacts 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 artifacts 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 FAQ to see if your issue might be a well-known question.
Do search the tracker to see if your issue has already been filed.
Do ask on 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 Joomla! forums, or the #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 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 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.

Patches

We're always grateful for patches to Joomla's code. Indeed, bug reports with associated patches will get fixed far more quickly than those without patches. It is also important that you create a patch correctly, a patch that doesn't apply easily may be delayed until it is fixed and applies cleanly. If you are uncertain of how to do this you can read about how to create a patch.

Patch style

Make sure your code matches our coding style.
Submit patches in the format returned by the svn diff command. An exception is for code changes that are described more clearly in plain English than in code. Indentation is the most common example; it's hard to read patches when the only difference in code is that it's indented.
Attach patches to a artefact in the trackers, using the "attach file" button. Please don't put the patch in the artefact description or comment unless it's a single line patch.
Name the patch file with a .diff extension
Put the prefix "[patch] " before the title of your artefact. This will make it obvious that the artefact includes a patch.
Learn more about patch files

Happy New Year: 2009 is going to be a big one (point six)

mamboblue@gmail.com (Andrew Eddie) — Fri, 02 Jan 2009 01:07:04 +0000

2008 was certainly a big year with the release of 1.5 in January. I think this has been one of our most successful and ground breaking releases (comparable to Mambo 4.5.1 which really pushed us to a new level back in the good old days). A new stability release will come out this month marking 1.5's first year of life. But what's in store for 2009? Well, just as 1.5 up'd the standard compared to 1.0, we believe 1.6 is going to do continue the trend.

Changes in the bug squad and development team

Wilco.Jansen@joomla.org (Wilco Jansen) — Wed, 24 Sep 2008 20:38:16 +0000

Over the past three years, Joomla! development has evolved. During the split from the Mambo project the Joomla! Core Team was fully responsible for overall development. As the project grew, the Core Team realized that additional structures where required to organize everything around the Joomla! project. Mid-2006, the Joomla! Core Team changed from a "developers only" team into a team that had coordinators for several focused areas. One of the roles was the role of "Development Coordinator." I was the first Development Coordinator within the Joomla! project and we only had general ideas on how this role should be fulfilled. The role has changed over time, and is still changing as the project evolves.

Security, PHP 4 and 1.5.7

elin.waring@gmail.com (Elin Waring) — Sat, 13 Sep 2008 13:16:44 +0000

Version 1.5.7 introduced a number of security improvements. Because of the nature of the issues, the patches were not introduced into SVN until shortly before release so they only had a few hours of JBS testing. Introducing them earlier would have given the bad guys information about the vulnerabilities and the time gap between introduction and release would have given them opportunity to attack many sites. (This is the reason we also ask people not to post vulnerabilities in the forums, but rather to visit the security center and send them to the JSST privately.)

One of the fixes addressed issues when there is a redirect. A new JURI method--isInternal($url)-- was created to address this issue. This fix made changes to the controllers for user, content, polls and mailto so that they use the new method when redirecting. This fix relies on a function that is only available in php 5, not php 4. As a result you may see problems with content submission, login, mailto, and polls if you have PHP 4.

If you have a PHP 4 site we urge you to update to php 5. If for some reason you can't, add this to the end of /libraries/joomla/utilities/compat/php50x.php

if(!function_exists('stripos')) {
 function stripos($haystack, $needle, $offset = 0) {
  return strpos(strtolower($haystack), strtolower($needle), $offset);
 }
}

This fix will be applied in the normal release of 1.5.8.

However an even better solution if you care about security is to upgrade to PHP 5. I have sites on a number of hosts and some were extremely slow or made it difficult to get PHP 5, but since the end of life on August 8, they have all come around. Usually you can just submit a help ticket and the host will take care of it or tell you what to do. Since PHP 4 is no longer going to have security releases, if you want to protect your site you must switch to php 5; don't wait for a vulnerability in PHP 4 to be discovered. As we saw with the Joomla vulnerability fixed in 1.5.6, even if a threat is fixed in just a few hours, that is plenty of time for script kiddies to hack hundreds of sites. In PHP 4's case a responsible host would not apply an unofficial patch. Who knows, maybe it would get them finally to upgrade? But in the meantime, your site would be vulnerable. So submit that support ticket today.

How Joomla 1.5.6 came about

anthony.ferrara@joomla.org (Anthony Ferrara) — Wed, 13 Aug 2008 23:22:50 +0000

As most of you know, a critical security vulnerability affecting all Joomla versions below (and including) 1.5.5 was discovered on Tuesday, August 12th 2008. What most of you don't know, is what went on behind the scenes that day. A whole mass of people came together and immediately worked on all the tasks necessary to make 1.5.6 happen. Experiencing this first hand was quite amazing... Publishing a release is a process that normally has two weeks (and a team of people) devoted to it (for everything from selecting which remaining artifacts will be fixed, to translations, to clicking publish and everything in-between). This all happened in a VERY short time.

Recovering the Administrator Password

elin.waring@gmail.com (Elin Waring) — Wed, 13 Aug 2008 12:13:47 +0000

If you were unfortunate enough to be impacted by the exploit discovered yesterday, you may need to recover your admin password. Of course, you can do this in the user manager if you had another super admin account and nothing was changed in the user table. But assuming that's not the case, here are instructions for how to do it.

Here is a link to a wiki explanation of how to recover your administrator password.

Here is a video of the process made by James Ramsay as a GHOP project. Thanks James!

The Survey, 2008

mamboblue@gmail.com (Andrew Eddie) — Wed, 30 Jul 2008 09:04:15 +0000

A List Apart is calling all designers, developers, information architects, project managers, writers, editors, marketers, and everyone else who makes websites. It is time once again to pool information so as to begin sketching a true picture of the way our profession is practiced worldwide.

I encourage all Joomla! professionals to take the survey. The results from last year are also available.