Vanilla 1.1.9 is a product of Lussumo. More Information: Documentation, Community Support.
Kohana version 3.0.2 has just been tagged and uploaded. Get it while it is hot!
Some links of interest:
Please report all new issues against v3.0.3.
Edit: 3.0.2.1 has been released. Users of Auth, ORM, and PHP 5.2 are affected.
Great!
Just lack of v3 docs is between me and happines.
Nice work @shadowhand ..
@leorik - There's also lots of great content in the userguide and lots of people contributing to the unofficial wiki. There should be more than enough to get you going. If you have any questions I'll bet you can either find the answer on the forums here, or if you ask someone will answer pretty quickly.
lol apparently it took you 1.25 hours.
Most excellent. Thank you.
@Olly lol yeah the time things are always funny. Look! we are only 2.5 hours away from 3.1.0!
this update seems to break my images and stylesheets. not sure why yet.
@riverrunner: Updating Kohana shouldn't have any affect on static files. Try entering the URL of the stylesheet/image directly and see if any errors occur.
Posted By: shadowhandEdit: 3.0.2.1 has been released. Users of Auth, ORM, and PHP 5.2 are affected.
Can you please elaborate a little bit about this? Or any link with more information of how users are affected will be welcome.
Thanks,
Nano.
Edit: 3.0.2.1 has been released. Users of Auth, ORM, and PHP 5.2 are affected.
Issue #2362 was reported, which had to be fixed immediately. In addition, the Auth and ORM submodules were not updated, so several fixes that had been marked as closed were not actually present in the initial 3.0.2 release, which also had to be corrected immediately. This minor fix was also included, which was supposed to be made before 3.0.2 was packaged.
@shadowhand
Thanks for the details. I think I found a bug. This new function called _parse_type database/clasess/kohana/database.php doesn't return the right length for all data types.
protected function _parse_type($type)
{
if (($open = strpos($type, '(')) === FALSE)
{
// No length specified
return array($type, NULL);
}
// Closing parenthesis
$close = strpos($type, ')', $open);
// Length without parenthesis
$length = (int) substr($type, $open + 1, $close - 1 - $open);
// Type without the length
$type = substr($type, 0, $open).substr($type, $close + 1);
return array($type, $length);
}
The decimal data type has a comma on the length definition (ie. decimal(6,3)), thus this line should not return only integers.
$length = (int) substr($type, $open + 1, $close - 1 - $open);
I think removing the (int) part fixes the issue:
$length = substr($type, $open + 1, $close - 1 - $open);
Should I file a bug?
Thanks,
Nano.
Edit: This bug triggers an error when the function list_columns is called at orm/classes/kohana/database.mysql.php because the offset 1 does not exist (only integer part was returned).
case 'decimal':
list($column['numeric_precision'], $column['numeric_scale']) = explode(',', $length);
Should I file a bug?
Yes, please.
I think I found some other bugs:
BUG 1)
On file orm/classes/kohana/orm.php
public function list_columns($details = FALSE)
{
// Proxy to database
return $this->_db->list_columns($this->_table_name, NULL, $details);
}
return line should be:
return $this->_db->list_columns($this->_table_name, $details);
There is no function list_columns at the database module with 3 parameters, thus $details is never used.
BUG 2)
The object returned by list_columns (at least here database/classes/kohana/database/mysql.php) now is an array of associative arrays (previous version just returned the name of the columns), thus, the variable _table_columns from function reload_columns at orm/classes/kohana/orm.php
public function reload_columns($force = FALSE)
{
if ($force === TRUE OR empty($this->_table_columns))
{
if (isset(ORM::$_column_cache[$this->_object_name]))
{
// Use cached column information
$this->_table_columns = ORM::$_column_cache[$this->_object_name];
}
else
{
// Grab column information from database
$this->_table_columns = $this->list_columns(TRUE);
// Load column cache
ORM::$_column_cache[$this->_object_name] = $this->_table_columns;
}
}
return $this;
}
will have the array of associative arrays (not an array of column names) which throws errors when setting values (column names are the array indexes in the form of 0,1,2,3,4 etc).
Then:
1) Should Database::list_columns still return just the names of the columns (I guess this will break some code)? or
2) the ORM should massage the returned array and set the proper names from the array of associative arrays returned? or
3) Create a new function list_column_names and return just the proper names (not sure if it should be a proxy function as well or just for ORM)?
I am towards option 3.
BUG 3)
At the function reload_columns from orm/classes/kohana/orm.php the following line is missing after
$this->_table_columns = $this->list_column_names(TRUE);
$this->_table_columns = array_combine($this->_table_columns, $this->_table_columns);
Thanks,
Nano.
@nanodocument: You don't have to post the bugs here first, you can just create issues as you find them. And thanks for helping! :)
@shadownhand
Alright, I'll do. Sorry, kind of new to reporting issues.
Thanks,
Nano.
Posted By: shadowhand@riverrunner: Updating Kohana shouldn't have any affect on static files. Try entering the URL of the stylesheet/image directly and see if any errors occur.
Yes I get...
throw new Kohana_Request_Exception('Unable to find a route to match the URI: :uri',
when entering static file direct in URL. i updated to php 5.3.1 at the same exact time (duh) so that could be a factor.
hmm well to solve it I had to copy the media action and media route from the userguide module to my application template. unless I am crazy this was not needed before.
@riverrunner: Is there a reason that you aren't serving your media files directly? Unless you have a good reason for it, you shouldn't pass your media files through PHP.
I don't want to do that but since I updated k3 is trying to find a route for the media files I have this in my template but it no longer works
if ($this->request->action === 'media')
{
// Do not template media files
$this->auto_render = FALSE;
}
Sounds like your .htaccess is broken.
Good work Shadowhand (and others).
ok I'll just make one more comment on this in case someone else runs into this. for some reason prior to this update I was able to keep media folder inside the application folder and things worked (images and css) - but now the media file needs to be on the same level as the app folder. maybe i was doing it wrong in the first place.
here is what I am trying to do which worked before the update. application folder is off somewhere else and you look for an image or a stylesheet in it but if not found it finds it in the main module. this way you can replace an image or stylesheet in the main module by sticking it in your app folder. I didn't change my .htaccess or anything just the core files. it was pretty sweet but now I am perplexed.
so for now I'll run media through a controller so I can have this behavior.
@riverrunner: The userguide module would have allowed that before this update, but it was an undocumented bug... or in your case, a feature.
Congrats, can't wait to check it out! Thank you for the all the awesomeness!
@shadowhand: Ah I finally understand! in 3.0.1 with the usermodule active my module/application was using its route and media action without me knowing it. I am not so perplexed any more. thanks and keep up the good work.
1 to 26 of 26