Joomla! Developer Network

Joomla! Developer Network

There is always a great deal of Joomla! development activity underway and communicating with other developers in the community is essential. This site is a resource for anyone looking to build or maintain software based on the Joomla platform

Version 11.1 was tagged on 5 July 2011. This was the inaugural release of the platform following its separation from the Joomla CMS trunk.

The following pull requests made by community contributors were merged:

Commit 1 - Minor change made to JDate::setTimezone to correct PHP Strict Error Commit 2 - Remove JButton::fetchID parent class - child classes are not consistent with parameters so there is no easy way to make the parent class consistent. Since it is not used and since it only returns when executed, removing it will at least get rid of the Strict eror.

#22587 - Change modules cache lifetime to be set as intended (seconds must be converted to minutes) - Cache handler needs to use all parameters for static variable caching Also $_handler is a static variable and so can't be referenced as $this->_handler (this bug was introduced after #22587 report) - change back to self::$_handler #24285 Fix changes module caching to store only headers that changed after module was executed. Headers before and after callback are compared.

Consistent with http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=22590... This pull request focuses only on the framework changes for this feature request. Between the 1.6.3 release and the platform merge, batch processing was added to com_content. Upon my own review and testing, the code used here was applied in a manner that it could be reused throughout components that follow a category->item structure. Specific to the framework are the following changes: - JControllerForm: Function batch added - JModelAdmin: Functions batch, batchAccess, batchCopy, batchMove, and generateNewTitle added - JHtmlBatch added If implemented, changes to the CMS can be made as demonstrated via my SVN branch (mbabker).

CMS Issue: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26192 Saves a couple of cookies in the administration without loosing any functionality. Shouldn't have an BC issues.

Sorry - closed pull request 44 by mistake (I'm new to github). This new request has the getter added to the correct class (I'd cut and pasted it in the wrong class last time :( ). To avoid confusion I'll repeat my comment about setters: A setter is a good idea (but not essential) but it would allow for unforeseen eventualities. The only problem with the setter is how it would interact with JDatabaseQueryElement - i.e. which one of the elements would it be setting? You can always simulate a setter by getting the separate element groups, calling clear and then resetting the relevant element. e.g. in pseudo code: $elements = $query->where; // do something to elements $query->clear('where'); foreach ($elements as $elem){ $query->where($elem); } Perhaps the last 4 lines would be the code for the __set method?

Added different config file to JDatabaseMySQLTest to allow an independent decision by the tester on whether these tests should be run. It now requires config_mysql.php to contain the JMySQLTestConfig class to be present or the tests will be skipped.

The JDocumentRendererAtom and JDocumentRendererRSS classes are too tightly coupled for good testing right now, so I marked the tests as skipped with a todo to come back after breaking more dependencies in the code. I basically punted on these tests, after doing a minor bit of code cleanup. They're too tightly coupled with too long of a chain of static method calls to be able to test as a block right now. So I marked the tests as skipped, and left a TODO to revisit them after we've broken a few more layers of dependency.

Previously discussed here: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25251 Note: This has some small backwards compatibility consequences (e.g. if somebody chose to override either of the two classes involved) but it makes JDocument more consistent and opens up future use (head links in other types of documents).

After an extended period of silence, the Production Leadership Team is happy to announce that we are moving forward with planning, preparing, and ultimately releasing version 2 of the Joomla! Framework. Over the last several weeks, we have begun building a roadmap and vision for the next major version of the Framework and are now ready to share with the community for review and feedback.

We recently received an email from google webmaster tools with the subject line: Hacking suspected: http://joomlacode.org/

Unfortunately, it appears that joomlacode.org is infected with content spam. When we realized this, our only concern is to protect our users. This will involve taking down the service in the very near future. This is an inconvenience for project owners using JoomlaCode to host projects for, and we are truly sorry.

We are currently planning the Joomla 2.5 marketing campaign. Joomla 2.5.28 is scheduled to be released on December 10th. As part of our campaign, we are asking extension developers to write a blog (of any length) that explains 2.5.28 will be the final release of the 2.5 series. Additionally, it would be helpful for your users if you provide documentation on how to upgrade your extension within your blog post.

Here is documentation by Jennifer Gress, Tom Hutchison, and Connie Lippert to help people plan for upgrading http://docs.joomla.org/Why_Migrate. The marketing team is preparing an information pack that explains 2.5.28.

Our goal for this campaign is to work together to help the community find the resources they need for successful upgrade planning. If you have suggestions on how else we can assist in this transition, please post here.