I was told in the JBS mailing list that this should be in this tracker instead of the CMS tracker, so I copied it from http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26606 - I hope it's correct that way.

Some example files are available in the CMS tracker item.

--copied description below--

I have an extension of type "file" (), which uses files and
folders within the "fileset" tag.
Like this:
   <fileset>
      <files target="somefolder">
         <file>somefile</file>
         <file>someotherfile</file>
         <folder>somesubfolder</folder>
      </files>
   </fileset>

In the extension zip archive the two files and the somesubfolder (with some
content) are in the same folder as the xml manifest.

When trying to install the extension it will always raise a notice on
"[path to joomla]/somefolder/somesubfolder" existing already. The
message is 'JLIB_INSTALLER_ERROR_FILE_EXISTS', which is raised in
JInstaller::copyFiles() in libraries/joomla/installer/installer.php:1352. No
matter how often the folder is deleted manually, it will always exist before
the copyFiles method is called.

I'll provide you with an overview of my debugging steps so you can either
confirm or falsify my result.
I was able to trace this bug back to the file adapter located in
libraries/joomla/installer/adapters/file.php. The install method makes sure all
target folders exist, and creates them if not (lines 142-168 of file.php). The
list of folders is built in the method populateFilesAndFolderList in the same
class/file. In lines 592-602 the folder tree of the target attribute is added
to the list, which works fine.
Starting in line 618 the files to copy are added to an array. I believe the bug
is located this section: In line 628 the filename is added to the folderlist, if
it's a folder (by checking the tagname in line 626). All folders in the
folderlist array are created in line 152 of file.php. The main installer class
doesn't need this folder, as it's gonna copy the whole folder, though.

The bug seems to be removed by just commenting/removing line 628 of file.php
(and also 627, as it becomes dead code).

Doing this works fine as far as I tested so far.

Specifically, the following lines in /libraries/joomla/database/table/content.php are problematic (according to Louis Landry): 247, 253, 266. Thanks to Louis for tracking this down at Joomla!Day South Africa 2011 with me.

Cheerio,
Ryan

Sorry for the long explanation here, but it probably makes the problem clear enough:

When having admin views like the module edit page, you have the JForm elements on the right. These are different fields.
The different xml files that are used to create these (some of module itself, some of core, etc) can have an addpath to include extra field files.

So far so good. But, if there are field files with the same file name, things go haywire...

Now there is a possibility to call on these field types with prefixes, to prevent duplicate class names.
Like in my case I have a type="nn_categories"
This will act on the class JFormFieldNN_Categories in the file categories.php in the addpath location. Note, it doesn't look for nn_categories.php but for categories.php

So my thought is that the function that loads the files from the different addpaths shouldn't stop at the first filename that matches (categories.php), but should look for the file that actually has the correct classname (JFormFieldCategories vs JFormFieldNN_Categories vs JFormFieldXXX_Categories)

So there is a problem when 2 extensions (plugins/whatever) are involved in creating the form.
Each with their own addpath and with their own extra field files.
So the first could use type="a_categories" and the second uses type="b_categories".

However, Joomla only loads the first categories.php. So only the first JFormFieldA_Categories is initialized. And not the second JFormFieldB_Categories - causing all b_categories fields to default to a default text field.

Essentially I think the problem is in file: \libraries\joomla\html\parameter.php in the loadElement method.

Instead of looping through all dirs and including all files that match (maybe double checking for duplicate classnames), it simply does a:
JPath::find($dirs, $file)
Which returns the path of the first file that matches....

It should do a while loop through the dirs, checking if the required class exists in the condition... Or whatever better solution there is...

Why ?
public static function write($file, &$buffer...

We can't have this code:
JFile::write('somefile.php', 'text');

Fatal error: Cannot pass parameter 2 by reference...

In doing conversion work on Finder, I've run into an issue with JDatabaseQuery building DELETE queries incorrectly. The index function is assembling the below query as "DELETE FROM t.*,jos_finder_taxonomy AS t...", causing the index process to error out.

Unless I've misunderstood based on how I've read the code, I would expect the query to be sent as "DELETE t.* FROM jos_finder_taxonomy AS t..."

$db = JFactory::getDBO();
$query = $db->getQuery(true);
$query->delete('t.*');
$query->from($db->quoteName('#__finder_taxonomy').' AS t');
$query->join('LEFT', $db->quoteName('#__finder_taxonomy_map').' AS m ON m.node_id = t.id');
$query->where($db->quoteName('t.parent_id').' > 1');
$query->where($db->quoteName('m.link_id').' IS NULL');
$db->setQuery($query);
$db->query();

I was told in the JBS mailing list that this should be in this tracker instead of the CMS tracker, so I copied it from http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26607 - I hope it's correct that way.

--copied description below--

When uninstalling an extension of type "file", folders listed in the
manifest file won't be deleted (for example like in previous bug
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26606

• actually fixing the previous one is required to be able to get a fully
  uninstallable extension). This behavior makes it impossible to reinstall the
  extension without deleting the folders manually.

Deleting the files and folders listed in the manifest file is handled in
libraries/joomla/installer/adapters/file.php lines 466-505, to be more specific
starting in line 485. Files are deleted instantly, folders are added to an array
to be deleted later. Anyway, before the folder gets deleted it is checked
whether it's empty (line 500-503). As the files in it are never deleted (which
is impossible, as they are not listed anywhere) the folders will remain.

A quick fix would be to delete the folder in any case, without checking if it's
empty. This behavior would match e.g. the removal of a component, where both the
admin and site folders are removed completely.

Hi
It is impossible for me to update a table with JTable and assign a null value for a field.
I think the problem is the processing of data in the bind () function of Table.php, more precisely in the foreach loop, at:
if (isset ($ src [$ k])) {
$ this-> $ k = $ src [$ k];
}
If the value is null, the assignment will never happen.

I need to put a null on a foreign key without any error FOREIGN_KEY_CHECKS

I tried replacing
if (isset ($ src [$ k]))
by
if (isset ($ src [$ k]) | | (is_null ($ src [$ k]) & & array_key_exists ($ k, $ src)))

and it works for now.

This is platform issue of : [ joomla Joomla! CMS Issue Tracker Item #25431] JUserHelper::getProfile does not return a profile (trackeritem-25431)
At line 222 in libraries/joomla/user/helper.php

$data->id=$userId;
$results = $dispatcher->trigger('onContentPrepareData', array('com_users.profile', &$data));

[#26568] Missing return in modeladmin.php. Thanks Jacob. (lib change)

In most cases beforeRenderModule info is useless - it has a minimal time and negative memory usage:
Application 1.907 seconds (+0.001); 11.05 MB (-0.014) - beforeRenderModule mod_hellome (Hello Me)

The debug info actually becomes unreadable, afterRenderModule is more informative is really useful.

Because JTable::getInstance() could return false (e.g. if an extension unfortunately registers a user.php file for it's own table object) the line "if (!$table->load($id))" could cause a fatal error.

To solve it (at this point) change the line to "if (!$table or !$table->load($id))"

But, of course, best solution would be if JTable::getInstance() could handle different classes stored in files with same name (in different folders).

Thanks,
Hoffi

(also submitted on http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26628)

https://github.com/joomla/joomla-platform/blob/master/libraries/joomla/database/table.php#L1419

Looks like old code - there is no $obj defined in the canDelete method

http://code.joomla.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26694

I wanted to bring this to people's attention since this was a patch that was committed in February to the trunk but is not showing in the platform or trunk now. Further, the code has just been left as commented (as in the original commit). Not really sure if this was a good solution because I don't know if even though the code is not used in the CMS it might not be used by some other application in which case it would be better to make it conditional.

if you try to format an empty string, you'll get an odd result

$return = JHTML::_('date', '0000-00-00 00:00:00', 'Y-m-d H:i:s');
echo 'Formatted date: '$return;
#Formatted date: -0001-11-30 00:00:00

here you can find a link back to the tracker:
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26575

We can't change the query elements and get information about the current query.
For example, I need to check if a specific table was joined - but can't read protected variable $join.
Inheritance from JObject will allow to use get() and read/modify data with set().

Hello,
Using JPlatform 11.2 in CLI mode, I have the following error if the file to delete does not exist:
PHP Fatal error: Class 'JRequest' not found in / home / web / www / JPlatform / libraries / joomla / session / session.php on line 453
And if I include the class JRequest (I'm in CLI mode ???), errors are displayed in the terminal with all the call stack.

Ok, I have to check if the file is present but it's still a little annoying.

JError is going into an infinite loop in a number of situations, specifically:
when the database is missing http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26550
and if there is no error page available.

See http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26459 in CMS issue tracker. This issue has been patched in CMS, needs patch in platform. Thanks.

I would expect loadnextrow and loadnextobject in database.php to walk tru the result set.

However the cursor is reset for each call to the function ( like loadrow returns the first row indeed)

    $regex = array('#[^A-Za-z0-9:_\\\/-]#');
    return preg_replace($regex, '', $path);

For general purpose use we need to be more permissive than that. Particularly, we should at least allow folder names with periods in them.

(From http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25676)

In line 1235 of libraries/joomla/installer/adapters/component.php, there is the
following line (when building a menu):

// If the install fails, exit and roll back changes
if (!$table->setLocation(1, 'last-child') || 
    !$table->bind($data) || 
    !$table->check() || 
    !$table->store()) {
     // Install failed, rollback changes
     return false;
     }

I suggest changing this to:

// If the install fails, exit and roll back changes
if ( !$table->setLocation(1, 'last-child') ) {
    JError::raiseWarning(1, $table->getError());
    }
if ( !$table->bind($data) ) {
    JError::raiseWarning(1, $table->getError());
    }
if ( !$table->check() )  {
    JError::raiseWarning(1, $table->getError());
    }
if ( !$table->store() ) {
    JError::raiseWarning(1, $table->getError());
    }

Each of these functions produces very useful error messages which are being discarded the way the code is current written. This addition would be very helpful to help extension developers debug their component installation problems.

-Jonathan

P.S. Although Sam feels that this is not the long-term approach he advocates for error handling, I still feel that something needs to be done on this particular section of code sooner rather than later to make it easier for extension developers to debug their code!

I am willing to do a fork to change this as I suggested above as in interim measure until a more effective long-term solution is implemented. Just let me know. -Jonathan

Follow up comments from the Joomla issue tracker:

Submitted By: Samuel Moffatt
Adddate: 2011-04-24 21:37:31
You don't need to split it out though, just add the JError::raiseWarning before the return as it stands now. The || will halt execution at the first failure and drop into the false. All you're doing is duplicating what it does now.

In general with 11.1 we're moving towards more logging than the way JError behaves at the moment. I'm not quite sure what that looks like for the installer as it already has a message infrastructure in place of its own that you could set.

Submitted By: Andrew Eddie
Adddate: 2011-08-12 21:44:32
Please raise this issue on the Joomla Platform issue tracker
(https://github.com/joomla/joomla-platform/issues), including a link back to
this page, or fork the Platform, make the appropriate changes and issue a pull
request.

Thanks. Closing issue.

Submitted By: Elin Waring
Adddate: 2011-08-14 09:09:46
I'm going to leave this closed since Sam seems to be suggesting a different
approach that could perhaps be solved partly with documentation.

We need to make sure (for this time only) that we merge relevant platform changes from the CMS into the tree to keep things aligned.

See Joomla Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=26437

The Template install adaper always update and overwrite the template.

In templateDetails.xml:
the update tag is not set
method is install
overwrite is false or not set

But the adapter force an upgrade

The issue is on
$updateElement = $xml->update
Access an (non set) property on JSimpleXML is a JXMLElement object, too.
That means the check "is_a($updateElement, 'JXMLElement')" is always
true.

I started keeping a branch with some of the deprecated code removed to get a feeling how much it is and I thought it would be a good idea to run unit tests on that to see what breaks. So here goes the first one, I'm sure more will turn up once this one is fixed:

Fatal error: Call to undefined method JXMLElement::getAttribute() in /Applications/MAMP/htdocs/joomla-platform/libraries/joomla/form/rules/options.php on line 43

see
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=24549
http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25663

As of commit ianmacl@9d7e34c

JPlatformTest::testIsCompatible.testIsCompatible with data set "wrong" 0.005464 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "empty" 0.005964 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "null" 0.005483 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "itself" 0.005449 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "version 1.5.22" 0.005445 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "version 1.7.0" 0.005435 1
JPlatformTest::testIsCompatible.testIsCompatible with data set "version 11.1.0" 0.00545 7
JPlatformTest.testGetLongVersion 0.565237 7
JPlatformTest.testGetShortVersion 0.006641 7

The 1s and 7s at the end are test ages. The first few just broke, the others have been broken for 7 commits.

(from http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26420)

Test Instructions:

1. Log in back end as admin/super-user
2. Create a new test group and corresponding access level derived from 'Registered' (do not add Super-user to the new access level).
3. For debug output, edit libraries/joomla/user/user.php and add the following line of debug code to line 357 (after first 'if' statement in getAuthorizedViewLevels() function): echo "USERLEVELS: ".implode(',', $this->_authLevels)."
   ";
4. Edit an article and notice the lists of access levels permitted. Cancel editing.
5. Edit the admin/super-user account and make it a member of the new test group. Save.
6. Edit an article again and notice that you are not in the new access level.
7. Log out and log back in. Edit an article and notice that NOW the new test access level has been added to the list.
8. Don't forget to remove the debugging code!

Summary

user access levels cache not updated when user added to a new group

Details

When a user is edited and is the groups that they are in are changed so that thier viewing access levels change, the cache in the user object is not invalidated or updated. Only logging out and logging back in will force that change. This could be very confusing since you expect to see changes you make to membership, etc, take place immediately.

Note: Elin Waring said that is cache-refresh problem is also an issue when a user changes their timezone. In order for it to take effect, you must log out and log back in. I have seen this issue as well.

good day!

was missed in the code else {...} block

...so if ZIP-file was opened is not correct, then still will be return true;

I think -- need to do:

https://gist.github.com/1253521#file_0001_fixed_zip_open_fail_actions.patch

or

https://gist.github.com/1253520#file_0001_fixed_zip_open_fail_actions.patch

thanks in advance!

Unit tests were recently committed for this class. The tests demonstrate that on 32 bit systems the method does not work because the byte total overflows.

I'm currently getting this error while trying to run the unit tests against the master branch
Fatal error: Class 'JTable' not found in /home/jonnathan/www/joomla-platform-fork/libraries/joomla/database/table/user.php on line 20

I think that better have this method as:
public function &getItem($id)
{
if (isset($this->_items[$id])) {
return $this->_items[$id];
}

$result = null;
return $result;

}

test instructions:
com_media with configured 'image_path' as a 2+level directory (ie. media/Pliki).
bug doesn't occur when image_path configured to 1-level directory (images)

details:
JFormFieldMedia has a hardcoded method to compute $folder variable by stripping first directory in the image path value and a filename.
$folder variable is then passed in a query 'folder='.$folder when calling com_media component

fix:
file libraries/joomla/form/fields/media.php, line 97: replace
array_shift($folder)
by
array_diff_assoc( $folder, explode('/', JComponentHelper::getParams('com_media')->get('image_path', 'images')) );

this will strip configured image_path in the $folder array
sorry for not adding Pull request, I'm in a process of learning git

Joomla platform gives a PHP strict error on the frontend and backend - which prevents login.

Error:

Strict Standards: Declaration of JDate::setTimezone() should be compatible with that of DateTime::setTimezone() in /Users/amystephen/Sites/j17/libraries/loader.php on line 201

By changing the JDate::setTimezone declaration from

public function setTimezone(DateTimeZone $tz)

to

public function setTimezone($tz)

Both are compatible so the error goes away.

When installing JFoobar using the tar.gz option, it was discovered that the language files located in:

media/components/administrator/components/com_jfoobar/media/components/site/components/com_jfoobars/language/en-GB

and

media/components/components/com_jfoobar/media/components/site/components/com_jfoobars/language/en-GB

are not copied to the destination (which is the same on the destination site, absent the media/components portion of the path.)

When the tar.gz file is manually unzipped into the tmp folder => it can be installed using the "Install from Directory" -- the problem only manifests when installing using the tar.gz file directly.

Also - I was able to isolate the problem to the JArchiveTar::extract method, it doesn't appear that these files are recognized as type of file or folder in the loop. But, I'm stumped as to why.

The JFoobar tar.gz can be used to demonstrate this problem. https://github.com/Niambie/jfoobar

The issue was reported Niambie/jfoobar#6

Issues wrong html entity encoding charset for PHP < 5.3.3

Saving article from frontend launches onContentAfterSave() event where $context is 'com_content.form', backend launches this event with 'com_content.article'.

Frontend ContentModelArticle class declares its context as:
protected $_context = 'com_content.article';

But JModelAdmin doesn't use this value and uses this as context for all events:
$this->option.'.'.$this->name

I.e for JModelAdmin::save() method we have:
$dispatcher->trigger($this->event_after_save, array($this->option.'.'.$this->name, &$table, $isNew));

So saving article from frontend gives wrong context - 'com_content.form' instead of 'com_content.article'

If you use the raw document type in your component and have the caching turned on, it will generate a fatal error because it tries to call the method "getHeadData" which is of course not defined in JDocumentRaw:

"JDocumentRaw::getHeadData() in /srv/www/htdocs/joomla16/libraries/joomla/cache/cache.php on line 502"

I don't know if I can work around this issue on my (component developer) side or if this better should be fixed in the library by making a check if this method exists.

Changing line #501 in libraries/joomla/cache/cache.php from:

if ($loptions['nohead'] != 1) {

to:

if ($loptions['nohead'] != 1 && method_exists($document, 'getHeadData')) {

would probably solve the issue.

There are changes made on library/cache/cache.php which cause problems:

The function JCache::_getStorage() uses $this->_handler but $_handler is declared as static. Using self::$_handler instead of $this->_handler is good but not enough. Because $_handler is initialized with array() (Why?) the check isset(self::$_handler) is always true so $_handler never gets an JCacheStorage instance. So an empty array would be returned by _getStorage() which would cause a fatal error in caller on e.g. $handler->getAll() (because $handler is array()).

Please check if making $_handler static is correct and why it is initialized with array() (it is expected to hold an JCacheStorage object in normal use-case).

Thanks,
Hoffi

(also committed on http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=26627)

Also on Joomlacode.org: Joomla! CMS Issue Tracker > [#26455] Fatal error when caching view.json.php or other non-html

Caching goes well with html, but not with view.json.php ... Cache throws error
then when trying to call JDocumentJSON::getHeadData();

On Joomlacode.org I included a patch in which the controller of the component only activates workarounds when using 'html' as viewType. Maybe someone's got a nicer solution?

http://joomlacode.org/gf/download/trackeritem/26455/66681/controller.diff

Formatting the session id for storage should be the responsibility of the underlying storage engine, not the session manager. Applying MD5[or any other form of hashing] has the possibility of creating the same hash for different id's - thus granting one user access to another's account. Maintain uniqueness of id as long as possible by not hashing it, and let engines format them further if they need to and note the security risk,

I think that someone forgot to resolve a conflict before commit
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/html/toolbar/button.php#L41

Joomla! CMS Issue Tracker item #25835, was opened at 2011-05-08 01:52:57

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=25835

Hello,

The description of the function is:

• Static method to get an instance of a JTable class if it can be found in
• the table include paths.

But this is not working currently in case of multiple tables have the same type: example: User (table will have different "prefix" but same "type")

Explanation:

If you have several includepaths, it's possible to have "user.php" in several includepaths not just in one,

but the current code is using JPath::find to return the fullpath to "user.php", but this function stops looking for user.php on the first path with user.php.
So if the user.php that you want to load is not in the first path of includepaths, the getInstance will returns "false".

Examples:
includepaths:
[0] administrator/components/com_mycomponent/tables/
[1] libraries/joomla/database/table/

these two directories contains user.php.

In getInstance fuction :
if ($path = JPath::find(JTable::addIncludePath(), strtolower($type).'.php')) {

This code will only return path :
administrator/components/com_mycomponent/tables/user.php

so the table JTableUser is no more working !!!!

To fix that:

table.php:

if ($paths = JPath::findAll(JTable::addIncludePath(), strtolower($type).'.php')) {
// Import the class files.
foreach($paths as $path) {
require_once $path;
}

//Call findAll instead of find, so all paths that have user.php will be returned

path.php (new function)

public static function findAll($paths, $file)
{
$fullnames = array();
settype($paths, 'array'); //force to array

           // start looping through the path set
           foreach ($paths as $path) {
                   // get the path to the file
                   $fullname = $path.'/'.$file;

                   // is the path based on a stream?
                   if (strpos($path, '://') === false) {
                           // not a stream, so do a realpath() to avoid directory
                           // traversal attempts on the local file system.
                           $path = realpath($path); // needed for substr() later
                           $fullname = realpath($fullname);
                   }

                   // the substr() check added to make sure that the realpath()
                   // results in a directory registered so that
                   // non-registered directores are not accessible via directory
                   // traversal attempts.
                   if (file_exists($fullname) && substr($fullname, 0, strlen($path)) == $path) {
                           $fullnames[] = $fullname;
                   }
           }

           // could not find the file in the set of paths
           if (count($fullnames) == 0) {
                   return false;
           } else {
                   return $fullnames;
           }
   }

I found out this issue and it might be related to this one @ joomlacode.org as well...

What I can see is that I somehow are logged on to the administrator and have no modules at all, so no menu and toolbar. Navigation is impossible.

Can you reproduce/confirm this issue?

Is it related to this problem in Joomlacode.org? http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=25069

I started receiving the error in my component:
Fatal error: Cannot redeclare class JCacheController in /libraries/joomla/cache/controller.php on line 20

This was also reported from other users:
http://forum.joomla.org/viewtopic.php?p=2591974

After investigation I found the issue: class JCacheControllerCallback calls:
jimport('joomla.cache.controller');

The issue is that actually JLoader::import() registers class JController but not JCacheController to \libraries/joomla\cache\controller.php, so cache controller class is loaded again once the JController is required.

In JModellist the cache is queried with if (!empty($this->cache[$store])) {

But in some cases the value in the cache is zero and so mistakenly threated as
not set. So the function gets executed and (in case of getTotal()) will cause
redundant database queries. In my case I noticed it while watching the log and
wondering why a query is submitted 3 times!

So I suppose empty() should be replaced by unset()

See also: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=26116

hi, so for i still get 4 errors when i run the tests:

1) JTableNestedTest::testStore
DateTime::setTimezone(): Can only do this for zones with ID for now

2) JTableNestedTest::testPublish
DateTime::setTimezone(): Can only do this for zones with ID for now

3) JTableNestedTest::testGetRootId
DateTime::setTimezone(): Can only do this for zones with ID for now

4) JLogEntryTest::testDefaultValues
DateTime::setTimezone(): Can only do this for zones with ID for now

the error is in the JDate::format function.
infact at line 338 there is this method

parent::setTimezone($this->_tz);

i made some tests, but it seems that these errors happear only on those tests, overall it's working fine.
any help?

Not sure what to do about this one. The method returns a value $ai that has not been used.

Would help fix it but I am not certain how, or if it's a real problem.

Since MD5 is no longer recommended for cryptographic use, some hosts use the SHA-1 algorithm, producing a longer session ID. The Joomla DB schema should be changed to prevent this - the assumption that the session id is always 32 characters in length is false. With PHP 5.3 there are far more hash functions available to generate the session id. And people can use their own method for generating session ids instead of PHP's built in functionality. Even 40 bytes is not enough - I had a case, where the hash was 52 bytes long.

So changing the column length for sessionid in #__sessions to 64 bytes should solve the problem.

We need generated API documentation for 11.2 release.