kohana / core Goto Github PK

Now URL::site() use rawurlencode only if UTF8::is_ascii($path) is FALSE. Why? I suggest always encode uri. For example space is ascii and should be encoded!

I've been toying with the idea of implementing a dependency injection container for kohana using pimple. I was wondering what you guys think.

The first option is to make a module implementing pimple. And the other is implementing it into kohana core.

I like the option of the module but it would be better if other modules could use it for their own dependency management. That would mean it should be in core or atleast always included and loaded first as a module.

@enov @acoulton @shadowhand what do you guys think?

If an internal request throws an uncaught exception, Request_Client_Internal will act differently for:

• HTTP_Exception - Calls get_response() which is just a shortcut to ::response().
• Exception - Calls ::_handler() which calls ::log() and ::response().

Bottom-line: HTTP_Exception's aren't logged.

• What's the reason for not using _handler() in both situations?
• What's the purpose of get_response()?

The Text::user_agent method needs test.

The Encrypt class does not have unit tests.

• 4836 Add case jpe for switch in function _save_function() on modules\image\classes\Kohana\Image\GD.php, let's match config/mimes.php array map
• 4835 My ORM
• 4833 Problem with folder structure?
• 4806 Invalid query with "":"" as alias in SQLite DB"
• 4797 Userguide,.htaccess

In Kohana/Core.php:990, the error_handler() function throws ErrorException (not HTTP_Exception), which leads to Kohana_Exception::_handler() manually creating a response with a status of 500, bypassing both the HTTP_Exception_500 and generic HTTP_Exception handlers.

public static function error_handler($code, $error, $file = NULL, $line = NULL)
{
    if (error_reporting() & $code)
    {
        // This error is not suppressed by current error reporting settings
        // Convert the error into an ErrorException
        throw new ErrorException($error, $code, 0, $file, $line);
    }

    // Do not execute the PHP error handler
    return TRUE;
}

Look at 3.2.3 tag.

From packagist
v3.2.3 reference: 3025781 2014-03-05 17:43 UTC BSD-3-Clause

But inside tag all code in kohana 3.3 naming style with first upper case letter!

Please fix, i'm can't install kohana/core for 3.2 with this error

I will introduce my proposal with quote

my opinion there is no place for other standards, because PSR exists and if any framework will invent and follow own code style - PSR has no meaning in that case.
PSR is for all php code, no matter which library or framework used.

Also developers IDE must be configured to PSR formatting by default (it's already in PhpStorm and NetBeans with small changes)

I think Kohana community should change their mind.

• @seyfer

It's quote from Issue of one Kohana module which follow Kohana code style.
So I decide to make contribution and found, that it's hard to me to read and edit (with IDE) code with no usual PSR-2 formatting. I'm discuss it with module owner and there is my proposal for Kohana community.

Let's move to PSR-2 standard for braces, spaces and etc formatting.

I've been using "HTML::chars($username);" to clean the strings passed in the form.

$values = Arr::map('HTML::chars', $values);

DB::insert('database', array_keys($values))
    ->values($values)
    ->execute();

In data recovery I do this:

    public static function chars_decode($value) {                
        return html_entity_decode($value, ENT_QUOTES, Kohana::$charset);
    }

    $values = Arr::map('HTML::chars_decode', $values);

Thus Remove all characters HTML-escape suspects. To me it seems quite useful.
Could the method "chars_decode" is in the core.

I propose kohana/core gets split up into multiple modules, here are some basic siggestions (the actual packages can be properly discussed in this issue):

• kohana/log
• kohana/config
• kohana/validation
• kohana/i18n
• kohana/session
• kohana/router
• kohana/view
• kohana/helpers

These packages will all have independent versioning of one another and begin their stable release at 1.0.0. They will be required by kohana/kohana and enabled by default in the bootstrap. They will all implement Koharness and use travis-ci so they can be tested in isolation.

Modularising Kohana will be a huge benefit as any part of Kohana can be removed and switched if it's not needed by the application. Modules can properly define what they actually depend on instead of just specifying kohana/core. After splitting up Kohana into modules we will find that we no longer need a kohana/core package.

The only backwards incompatible changes to be made by users should be to simply add these new modules to their bootstrap in place of kohana/core. Kohana will still function exactly as if they were all in the same repository.

Route::set('admin', '((/(/)))')
    ->subdomains(array('admin'))
    ->defaults(array(
         'controller' => 'welcome',
    ));

Route::set('default', '((/(/)))')
    ->defaults(array(
        'controller' => 'welcome',
    ));

site.com/controller/index // 'default' route
admin.site.com/controller/index // 'admin' route

What about the subdomains of the form "sub1.sub2.site.com"? To consider both the subdomain as one or disassemble them?

We should start thinking about implementing namespaces in Kohana and it's modules but also decide on a vendor / prefix.

Like \Kohana\<module>\<class>

Also enable users to namespace their own application. And point the routes to the namespace.

What do you guy's think? (Typed this on my mobile so keeping it short)

As per comments on #572:

#572 (comment)
#572 (comment)

it's more like ucword() behaviour, except we specify delimiter.

I am not be able to get the current route using kohana.
Getting the current action, controller, directory works perfectly, but what happened to route? could you fix this?

Thank you.

Request::current()->route();

public function route(Route $route = NULL)
{
if ($route === NULL)
{
// Act as a getter
return $this->_route;
}
// Act as a setter
$this->_route = $route;
return $this;
}

#563 introduced a composer require-dev for mikey179/vfsStream to allow virtual filesystem tests of the log writers.

Unfortunately this breaks the builds for the other modules (eg https://travis-ci.org/kohana/image/jobs/97191751) because those builds include all the kohana/core tests (to check the module hasn't broken anything in core, I guess) but don't pick up the require-dev dependency from this package. Similarly, the kohana/kohana build is also going to fail for the same reason.

I think the best solution is to require mikey179/vfsStream in kohana/unittest - the same way we handle phpunit, so it's always present in development environments for any module that has a require-dev on kohana/unittest.

Alternatively we could modify the test suite to check if vfsStream is present and skip those tests if not.

Thoughts?

Hope everyone is doing well.

I'm wondering if we can come up with a better way of combining values than to use array_merge(). Obviously one might argue that the query builder should not be used when inserting 30,000+ rows at once, but it definitely could be if we sorted the values() method.

Any thoughts? Or is the general consensus "Don't use query builder for inserting large data sets"?

I ended up extracting the code from values() and keeping the query in a string, meaning I could avoid array_merge().

FYI - I can't find a profiling site that allows me to use such a large data set to prove my case, but here is some info below

9,999 BASIC arrays being added to ->values():

With array_merge / func_get_args() = 5.6 Seconds
Using foreach and $this->_values[] = $values; = 0.14 Seconds

Now obviously you can imagine how that scales up when you're inserting user profile rows which might have a lot of data.

Current

class Database_Query_Builder {
    private $_values = array();

    public function values(array $values)
    {
        if ( ! is_array($this->_values))
        {
            throw new Kohana_Exception('INSERT INTO ... SELECT statements cannot be combined with INSERT INTO ... VALUES');
        }

        // Get all of the passed values
        $values = func_get_args();

        $this->_values = array_merge($this->_values, $values);

        return $this;
    }   
}

Proposed

<?php
class Database_Query_Builder {
    private $_values = array();

    public function values(array $values)
    {
        if ( ! is_array($this->_values))
        {
            throw new Kohana_Exception('INSERT INTO ... SELECT statements cannot be combined with INSERT INTO ... VALUES');
        }

        // Get all of the passed values
        $values = func_get_args();

        foreach ($values as $entry)
        {
            $this->_values[] = $entry;   
        }

        return $this;
    }   
}

I propose the removal of all direct access checks placed at the start of all classes:

<?php defined('SYSPATH') OR die('No direct script access.');

This check makes classes unusable in other non-kohana projects without first having to define 'SYSPATH'. This line of code doesn't conform to the DRY principle since it's repeated a no end of times throughout the kohana core. This removal will make classes that little more cleaner and be another step towards removing all global state.

To still prevent people from accessing class files directly; index.php (or a symbolic link) could be placed in a public folder, or a htaccess file could be used.

Change detecting urls starting with // in HTML::script, HTML::style and HTML::image + support data-scheme in HTML::image
#667

This is a placeholder issue for all Issues reported for version 3.2.3 in Redmine that were not fixed in version 3.3.3.

A new issue will be created and linked here, for each item below, with its title and description from Redmine.

The letter R is prefixed to the Redmine's issue number to avoid confusion between the issues of Github.

If you want to take an issue, drop me a line here, so that I assign it to you.

Hopefully we get through this and have a good 3.3.3 release :)

Hello!

Hope this is not repetitive I couldn't find this discussion anywhere else.

• What are the plans for 3.4?
• what's the current status?
• how can we help to move it forward?

Thanks!

Release and branching plan (thanks to @enov)

• Release 3.3.5
• Review and restructure outstanding Github issues and PRs
  • Restructure milestones, rename 3.4 milestone to 4.0
  • Review and close all issues and PRs that are no more relevant
  • closing any that are redundant, out of date or not of high enough quality to merge
  • merging any bugfixes that are backwards compatible so that they can be in 3.3 and 4.0
  • merging any breaking changes that are close enough to complete to go with the upcoming breaking 4.0 release
  • assigning any longer-term breaking changes (including issues that nobody's started working on yet) to a new 5.0 milestone
• Merge 3.3/develop to 3.4/develop
• Create a master branch based on 3.4/develop
• Delete all 3.*/develop branches
• Delete all other unwanted branches
• In the master branch fix all occurrence of 3.4 with 4.0
• Fix composer required versions in master
• Update kohana/koharness script for new branch naming structure
• Update Travis scripts to make the tests pass
• Write new CONTRIBUTING guidelines reflecting branching changes
• Do above steps for all Kohana modules
• Create a 4.0.x branch based on the master branch
• Change the version and the codename on a separate commit in that branch
• Release by tagging v4.0.0-beta1
• Update kohana-ci scripts for new branch naming structure (optional)
• Do above steps for Kohana modules that have BC braking changes, no need to newly release those who are not changed

See Redmine issue R3552 http://dev.kohanaframework.org/issues/3552

To be able to test the classes better and to avoid hard dependencies where's not necessary.

This would be a big task, at first it would be a good idea to refactor the most important parts, such as Request/Response, Route, etc.

I was trying to find a way to get PUT request with Kohana.
I realized that this is already available in L1368

the Controller simply:

    parse_str($this->request->body(), $put);

Maybe it would be interesting to have a custom method as:

$this->request->put();

Not that the current way of hard work.

Hello, there is an issue with HTML::anchor

It doesnt allow you to use "?key=value" for href. The function always prepends a leading slash. It's because it uses internally URL::site. May be its there that it shold look for a leading '?' and do not prepend the slash.

$_POST is depracted but it is still used in Request class.
docs: http://php.net//manual/pl/reserved.variables.post.php
class: core/classes/kohana/Request.php

Request->uri()
and
Request->url()
should return original (not decoded) URL like in $_SERVER['REQUEST_URI']

URL should always be correct (rawurlencoded).

When i pass to Kohana:
http://example.com/welcome/index/one%20two
then $this->request->url(TRUE) returns decoded URL:
http://example.com/welcome/index/one two (with space between 'one' and 'two').

I think only Route parameters (directory, controller and action too) should be rawurldecoded, not entire URL.

Its important when I reuse current request URL, for example:

$this->request->redirect($this->request->uri());
<a href="<?php echo Request::current()->url(); ?>">Link</a>

It should be done for initial, internal and external request, and it is related to #630.

Summarizing:

1. Request URL and URI should NOT be rawurldecoded for all kind of requests (initial, internal and external request).
2. Route parameters should be always rawurldecoded for all kind of requests (initial, internal and external request). See #630.

The current implementation of Arr::map() does not pass the $keys array on to itself when doing the recursive call. The result is that $callbacks is applied to every element in sub-arrays, not just to the fields specified in $keys.

For example:

Arr::map('strip_tags', array(array('foo' => '<p>bar</p>', 'bar' => '<p>baz</p>')), 'foo')

Returns

array
  0 => 
    array
      'foo' => string 'bar' (length=3)
      'bar' => string 'baz' (length=3)

The 'bar' element here should have been untouched.

I can issue a pull request and add unit tests for this if someone tells me in which branch this can best be fixed :)

Hello,

Hope I can explain this correctly ;)

I am testing https://github.com/open-classifieds/openclassifieds2 on PHP 7 RC 4, with Kohana 3.3.4.

Found an error on the pagination module (fixed) but while testing I made a typo on the file, provoking an exception / parseerror.

Seems a Type Hinting issue. I have fixed it for now just by replacing "Exception $e" for just "$e" on the functions declarations found at file https://github.com/kohana/core/blob/3.3/master/classes/Kohana/Kohana/Exception.php

Not really elegant but for now working. I guess Exceptions work different on PHP7? and we receive a ParseError? http://php.net/manual/en/class.parseerror.php

Let me know if I can help more. Also not sure which milestone should be assigned, but I guess this should be addressed at 3.3.X branch.

If we find any other issue while testing PHP7 we will open a new ticket. Thanks.

This is a feature I found handy while using Laravel.
Instead of having to inject the before method of controllers it could be nice to define route filters somewhere and assign them to the routes that need them (including a global route filter).

There's an added bonus for module developer that could bundle them, leaving them optional to use by other developer (instead of hardcoding them in a base controller).

http://laravel.com/docs/routing#route-filters for details

***edit
This would be for milestone 3.4 obvisously (forgot to add that to this ticket)

At this stage, discuss common issues.

My version
PSR-1, PSR-2, Namespaces
Separate classes (Router and Route).
Remove dependency (Kohana::cache, URL::site, Arr::get).
Fix and optimize methods (compile, uri, matches).

Route:
Сlass simplified for convenience and speed up: only one filter for the route, removed setters (properties sets at create). In most cases this is enough,if necessary, you can extend class.

I'm thinking of opening a new PR on the Kohana core to implement namespaces on all classes and another to move out the Cascading Files to a different repository for backwards compatibility.

This would at least more Kohana Forward to namespacing and make it more compatible to the PSR-4 standards.

I wanted to give a heads-up that I want to do this and was wondering if you people think this would be the right direction to go in.

This will most likely end up in a Kohana 3.5 version since it's mostly backwards compatible.

The discussion in this ticket is related:
#571

@acoulton @enov @lenton @shadowhand would this be appropiate?

In classes/Kohana/Core.php

line 235: Kohana::$magic_quotes = get_magic_quotes_gpc();

In documentation:

get_magic_quotes_gpc() - Returns 0 if magic_quotes_gpc is off, 1 otherwise.

In public static function sanitize($value)

line 440: if (Kohana::$magic_quotes === TRUE) - will not be executed

Proposal: Kohana::$magic_quotes = (bool)get_magic_quotes_gpc();

I am not sure if this is a good idea, so I want your input here.

kohana/kohana#31 has made the core to be loaded in Kohana::modules(), which makes the function __ unavailable for Kohana_Exception.

We can either test its availability in Kohana_Exception or deprecate/replace __ with I18n::__.

We can still leave __ available for standard views, maybe it will be just an alias for I18n::__. __ can be defined in bootstrap or we can keep it where it is now.

I don't know if I am making sense. You input is appreciated. Thanks!

For greater flexibility i think that is the right way.

Remove Route::cache() and compilation uri at create roure. Add lazy load for Route::$_route_regex in Route::matches():

    protected function route_regex()
    {
        if (empty($this->_route_regex))
        {
            $this->_route_regex = Route::compile($this->_uri, $this->_regex);
        }

        return $this->_route_regex;
    }

    public function matches(Request $request)
    {
        // Get the URI from the Request
        $uri = trim($request->uri(), '/');

        if ( ! preg_match($this->route_regex(), $uri, $matches))
        {
            return FALSE;
        }

Need extend or replace method Kohana::shutdown_handler() for adding handlers for other classes (__destruct() is sometimes unstable).

As example my class ShutdownHandler.

Hello all!

This is a proposal to enhance the Kohana I18n system to allow look up with keys while at the same time keeping the strings that needs to be translated in full and in its default language within the views.

There has been numerous discussions regarding whether to store the identifiers or the whole strings within the i18n dictionary folder. Both approaches have their advantages and disadvantages. This is to propose declaring both (identifier/key and whole string) in the View, like so:

__(['welcome_text' => 'Welcome to my site, this is a very long welcome message that you might not want to use it as key in your dictionary files']);

Then in the dictionary file you set:

return array (
    'welcome_text' => 'Բարեւ, բարեւ բարեւ ․․․',
);

I have a tentative code that makes this work, it just changes I18n::get and it is fully compatible with string only version we have already. This works whether you use identifiers, whole strings or an array of both, as described in this proposal.

    public static function get($string, $lang = NULL)
    {
        if (!$lang)
        {
            // Use the global target language
            $lang = I18n::$lang;
        }

        // Load the translation table for this language
        $table = I18n::load($lang);

        // Return the translated string if it exists
        if (is_string($string))
        {
            return isset($table[$string]) ? $table[$string] : $string;
        }
        else if (is_array($string))
        {
            // get the first key value pair from the array
            $val = reset($string);
            $key = key($string);

            // return translation based on the key
            if (isset($table[$key]))
            {
                return $table[$key];
            }
            // return translation based on value
            else if (isset($table[$val]))
            {
                return $table[$val];
            }
            // translation not found, return value
            else
            {
                return $val;
            }
        }
    }

References:
http://blog.mixu.net/2010/11/11/kohana-3-i18n-tutorial/
http://forum.kohanaframework.org/discussion/comment/24814/
http://forum.kohanaframework.org/discussion/comment/41757/

File:
https://github.com/kohana/core/blob/3.3/master/classes/Kohana/Request.php

Function:
public function url()

Support for PHP 5.3, 5.4, 5.5, 5.6 and HHVM

The tests for Debug::dump occasionally fail with:

There were 3 failures:
1) Kohana_DebugTest::test_var with data set #0 (array('foobar'), '<pre class="debug"><small>array</small><span>(1)</span> <span>(
    0 => <small>string</small><span>(6)</span> "foobar"
)</span></pre>')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
 '<pre class="debug"><small>array</small><span>(1)</span> <span>(
     0 => <small>string</small><span>(6)</span> "foobar"
+    5425148641218 => <small>bool</small> TRUE
 )</span></pre>'
/home/travis/build/kohana/core/tests/kohana/DebugTest.php:46
/home/travis/build/kohana/core/vendor/kohana/unittest/classes/Kohana/Unittest/TestSuite.php:51
2) Kohana_DebugTest::test_dump with data set #4 (array('foobar'), 128, 10, '<small>array</small><span>(1)</span> <span>(
    0 => <small>string</small><span>(6)</span> "foobar"
)</span>')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
 '<small>array</small><span>(1)</span> <span>(
     0 => <small>string</small><span>(6)</span> "foobar"
+    5425148641218 => <small>bool</small> TRUE
 )</span>'
/home/travis/build/kohana/core/tests/kohana/DebugTest.php:124
/home/travis/build/kohana/core/vendor/kohana/unittest/classes/Kohana/Unittest/TestSuite.php:51
3) Kohana_DebugTest::test_dump with data set #7 (array(array(array(array(array('something'))))), 128, 4, '<small>array</small><span>(1)</span> <span>(
    "level1" => <small>array</small><span>(1)</span> <span>(
        "level2" => <small>array</small><span>(1)</span> <span>(
            "level3" => <small>array</small><span>(1)</span> <span>(
                "level4" => <small>array</small><span>(1)</span> (
                    ...
                )
            )</span>
        )</span>
    )</span>
)</span>')
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
                 )
+                5425148641218 => <small>bool</small> TRUE
             )</span>
+            5425148641218 => <small>bool</small> TRUE
         )</span>
+        5425148641218 => <small>bool</small> TRUE
     )</span>
+    5425148641218 => <small>bool</small> TRUE
 )</span>'
/home/travis/build/kohana/core/tests/kohana/DebugTest.php:124
/home/travis/build/kohana/core/vendor/kohana/unittest/classes/Kohana/Unittest/TestSuite.php:51

These extra elements appear to be the $marker elements added in Kohana_Debug:152 to detect array recursion which for some reason aren't being skipped.

It happens quite rarely, and so far have only seen on PHP >= 5.4.

Support for PHP 5.4, 5.5, 5.6 and HHVM

Please add rawurldecode to function param() in Kohana/Request. In KO 3.3.3 rawurlencode was added to function uri() in Kohana/Route. I suggest to add rawurldecode when we read these params.

public function param($key = NULL, $default = NULL)
{
    if ($key === NULL)
    {
        // Return the full array
        return $this->_params;
    }

    return isset($this->_params[$key]) ? $this->_params[$key] : $default; // THIS SHOULD BE DECODED
}

1. SYSPATH, APPPATH, MODPATH (EXT, KOHANA_START_TIME, KOHANA_START_MEMORY) not defined in system library. They should not be used directly in the classes (only as arguments), permissible use only in config\view\init files.
2. Does not make sense to use protection defined('SYSPATH') OR die('No direct script access.'); in class, i18n, message files.
   Why not use Kohana::VERSION instead SYSPATH?

<?php defined('Kohana::VERSION') OR die('No direct script access.');

In efforts to improve the architecture of Kohana, and move away from static global scope, I propose that we deprecate View::set_global and associated functionality in version 3.4. PR upcoming if there is consensus.

I propose that routes be set in a 'later routes overwrite' manner instead of the current 'first come, first serve'.

It's a problem for two reasons:

• It's not logically intuitive to programmers, we are used to later defined things overwriting.
• It forces modules to be loaded in the wrong (reverse) order.

When modules can be loaded in the correct order, later initialisation files (such as in application) can manipulate objects created by previous initialisation files.

I've been working on the following module to support Doctrine2 in the best way possible so Annotation, Yaml and XML:

https://github.com/rjd22/kohana-doctrine

I was wondering if it is a good idea to import this module into the kohana origanisation so we have a official replacement for the Kohana ORM module we no longer support. This would also help people decide what doctrine module they need to use and help focussing improvements on a single module.

@acoulton @enov @shadowhand what do you think?

new method for detecting
#633

This is a security issue related to kohana/kohana#74

How to reproduce:

• Set up or enable the Apache webserver's default virtual host, without a ServerName that will respond to the requests with hosts not defined in other available/enabled sites.
• Install a standard Kohana application within the host's DocumentRoot, most probably /var/www
• In Controller_Welcome alter the index action's response to

$this->response->body(URL::site('test', 'https'));

• Using a browser extension to modify headers (in my case I used "Modify Headers" chrome extension) modify a request header Host to <iframe src="about:blank" onload="alert('XSS')">
• Go to http://localhost or a locally predefined development URL

You will see "XSS" popping up.

So basically we should not blindly trust $_SERVER['HTTP_HOST'].