CodeIgniter Forums

double last record when using foreach($query->result() as $item)

2008-07-26T11:41:39Z

I have something like that

in $query is simple select * from table

foreach($query->result() as $item)
{
    $content .= $this->load->view('contact_element_show', $item, true);
}

when I check the result its double last row from table.

Is it a bug?

I use CI 1.6.3

Regards

Is it a bug at $this->input->post function ?

2008-07-24T12:44:21Z

hmm ... I am not sure this is a bug or not. Let me try to explain what happened here.

http://codeigniter.com/user_guide/libraries/input.html


$this->input->post('some_data', TRUE);

I was trying to run through XSS filter by setting 2nd parameter to “true”.

Somehow the XSS filter convert or encoded my string to other encoded characters which trigger a sql error due to using diff. encoded in the same string.

If you enter “�” at input text field and submit, you will get the other encoded character.
like http://en.wikipedia.org/wiki/Ê

Please let me know if you need other information. :D

Quotes in mime type when uploading

2008-07-23T08:52:19Z

Hello,

When trying to upload a file, the mime type is not recognized because of quotes under FF3 (itworks under IE).

I have already filled a bug report:
http://codeigniter.com/bug_tracker/bug/problem_in_mimetype_recognition_under_ff3/
And I have been prompted by Derek Allard to start this thread.

To illustrate the problem, I have setup a pristine Code Igniter 1.6.2 on
http://michael.doubez.free.fr/index.php/test

The test is trying to upload a file with .bin extension with FF3.
The controller used (more or less) is:
http://michael.doubez.free.fr/test.txt

The output of:
echo $this->upload->display_errors();
echo ol($this->upload->data());
is
<<<
The filetype you are attempting to upload is not allowed.

1. test.bin
2. “application/octet-stream”
...
>>W
See the quotes in the mime type reporting.

Note: I have changed my mimes.php file
‘bin’ => ‘application/octet-stream’,

Cheers

Model class- and member naming

2008-04-21T03:16:23Z

L.S.

The following fatal error is what i get in at least CodeIgniter 1.6.1, perhaps it’s present in older versions but haven’t tried it.

Fatal error: Cannot access private property Test::$test in /home/markus/public_html/brochureselectie.nl/trunk/sys/libraries/Model.php on line 69

This is produced when some model attempts to set a classvariable with the same name, like the snippet below.

class Test extends Model {

    private $test = NULL;

    public function __construct() {
        parent::__construct();

        $this->test = 'TEST';
    }

    public function getTest() {
        return $this->test;
    }

}

?>

I’m unsure whether or not this is an existing and an already reported bug, although a search for model related issues did not result in any bug alike.

Any thoughts on this one? It should not be a problem to have ambiguous naming within some class. This could also cause dynamically generated errors when some code using __set() methods to dynamically assign new variables to the scope.



class Test extends MY_Model {

    //private $test = NULL;

    public function __construct() {
        parent::__construct();

        $this->test = 'TEST';
    }

    public function getTest() {
        return $this->test;
    }

    public function __set($b, $c) {
        var_dump($b);
        print '

'; var_dump($c); } } ?>

The last snippet will generate the following output, possibly because __set will catch not only my assignment of $this->test but a lot more internal stuff. Please try…

Regards,

Validation in autoload PHP 4 (Fix suggested)

2008-01-16T21:05:14Z

This is an old bug… It has been reported many times, and currently it´s in the tracker with the ID 3175

The original problem is that in the view you get an empty error_string even if the validation fails.
Tracking it down, I found out that the problem was that PHP was generating a copy of the autoloaded class, so they were different in the controller class and in the loader class (where the $this variable point, inside the views).
A quick example, to show this

// system/application/config/autoload.php
$autoload['libraries'] = array('validation');

// system/application/controllers/bug3175.php
class Bug3175 extends Controller {
    function Bug3175()
    {
        parent::Controller();
    }

    function index()
    {
        $this->validation->hello_world = 'abcde';
        $this->load->view('bug3175');
    }
}

// system/application/controllers/bug3175.php
echo $this->validation->hello_world;

In PHP 4 (I´ve tested this in 4.3.9 and 4.4.7) throws a notice for the undefined variable. In PHP 5 (5.0.0, 5.1.6, 5.2.5) it prints “abcde”, as expected.

After tracking this bug inside all core I´ve finally reached to system/libraries/Controller.php, on line 87. After $this->_ci_autoloader(); I´ve added

foreach (array_keys(get_object_vars($this)) as $attribute)
            {
                if (is_object($this->$attribute))
                {
                    $this->load->$attribute =& $this->$attribute;
                }
            }

which syncronize back the references between the Loader and the Controller.

PLEASE EVERYONE, test this on all PHP versions you can and submit the result, so we can finally fix this bug…

Logging fatal errors

2008-07-22T13:45:18Z

I have CI setup to log errors, however, I’ve found that some php errors never seem to get logged, usually fatal errors. One example is if the script tries to exceed its memory limits it will die and never be logged.

What are others doing to monitor for these failures? Is there anything that can be done to get these errors into the CI log or is the only other option to just monitor the apache log as well?

Thanks,
Dan

CI Stupidly Kills GET Data

2007-01-04T04:02:48Z

One of the things I like the most about CI is that it doesn’t force you to write code in strict and specific ways.. it doesn’t shove its way of doing things down your neck… it doesn’t sneak around doing things behind your back.. you’re the coder and you can code however you like.

THE EXCEPTION: $_GET

The CI philosophy seems to be: worship the POST method and kill GET

Code Igniter User Guide

GET data is simply disallowed by Code Igniter since the system utilizes URI segments rather than traditional URL query strings (unless you have the query string option enabled in your config file). The global GET array is unset by the Input class during system initialization.

This is DUMB! It seems like this fundamental design decision was taken without any thought or it was assumed that GET vars (query string e.g. ?var1=value&var2=value ) could not coexist with the segment approach (e.g. http://localhost/ci-get-fixed/seg1/seg2/?var1=value&var2=value ).. like it had to be one or the other.

THIS IS SUCH AN ANNOYING BUG!

It’s easy to fix but the fact that CI works this way as standard is sooo stupid!

Please fix this bug and set Code Igniter free

EDIT/CLARIFICATION:

The URI segment approach is great for links but form submissions don’t work this way (without client-side scripting).

http://localhost/store/search?q=search+terms

GET and POST have different uses as defined by the HTTP standard (RFC 2616). Submitting all form data using the POST method is improper and has adverse effects.
Both GET and POST have their place.

Thread: Input enhancements - (optionally) allow GET values

Thread: IMPLEMENTED: get() method from input class, better routing without mod_rewrite, bug fix for CI_Input methods

Thread: How to create mix urls (Segment + Querystring)

Thread: GET variables gone in 1.5.1 ?

Thread: $_GET value to controller

Thread: support for less than two GET parameters within the url

Thread: Silly Problem passing variables between controllers

Thread: $_GET[] causing problems with 1.3

...
I would link to a forum search but GET variables (query strings) aren’t supported
http://codeigniter.com/forums/do_search/?keywords=query+string

CI + FireFox3 bug: Checking file type with File Uploading Class failes in FireFox3

2008-07-21T09:32:44Z

Hello .. I noticed a strange bug (I may say it’s a firefox3 bug) but code igniter can’t handle it.

The bug is in the mime type detected. Let’s say we are trying to upload a .doc file using CI File Uploading Class, it will check $_FILES[$file][’type’] and then checks if it matches mimes values of the specified mime types keys as doc|pdf ...

So the problem is that in FireFox3, (which is not an issue in Firefox 2 or opera or any other browser) the var $this->file_type receives $_FILES[$file][’type’] as “application/msword” (with double quotes) and adds backslash to be \"application/msword\".

So then the function is_allowed_filetype() checks if it maches $mime[’doc’] but since it has (\” \") match fails, and thus I get the report message that says filetype is not allowed.

My fix in my extended class is as following:

When defining $this->file_type:

$this->file_type = preg_replace("/^(.+?);.*$/", "\\1", $_FILES[$field]['type']);
$this->file_type = strtolower($this->file_type); // trim for firefox3

I simply append the following:


$this->file_type = trim($this->file_type,'\"');

With this it works.

Also I’d like to share with the community a script that I appended to the previous script that detects the file type using finfo (if it’s installed on the server) cuz detecting the file type using $_FILES[$file][’type’] isn’t a good idea as it can be modified by the user.

if (function_exists('finfo_open')) {
            $finfo = @finfo_open(FILEINFO_MIME);
    
            if ($finfo !== FALSE) {
                $file_type = @finfo_file($finfo, $this->file_temp);
                if (($file_type !== FALSE) && is_string($file_type) && (strlen($file_type)>0)) {
                        $this->file_type = $file_type;
                }
                @finfo_close($finfo);
            }
 }

So as for the bug, I hope CI developers would consider that in bug fixing of the next release.

Thanks.

$this->uri->rsegments versus $this->uri->segments: subdirectory gets lost?

2008-02-21T15:10:30Z

Hello I use the resegment(n) function to get data from the routed uri.

the problem is when there wasn a routing the VAR $this->uri->rsegments holds different data than $this->uri->segments - that seems to be wrongto me.

URI: /index.php/admin/order/1000/invoice/
//no routing defined in routes.php!

print_r($this->uri->segments);
// Array ( [1] => admin [2] => order [3] => 1000 [4] => invoice ) 

print_r($this->uri->rsegments);
// Array ( [1] => order [2] => 1000 [3] => invoice )

Database Debuging issue, error not logged

2008-07-21T03:12:04Z

When queries fail(I’m personally using AR) the database code attempts to log the exact error message. Unfortunately on some database engines(MySQL, MySQLi, etc.) once you retrieve the error message it clears the message for any future attempts to access it via included functions. This results in log messages like the following:


ERROR - 2008-07-21 03:51:13 --> Query error:

The log is missing the actual error returned from the engine. To fix this you have to use the first variable that accesses the error message, in this case $error_msg in database/DB_driver.php on line 316.

The logging attempt on line 325 calls the _error_message() function again, returning an empty string on some systems. This is resolved by changing that line to the following:


log_message('error', 'Query error: '.$error_msg);

Utilizing the earlier call to retrieve the query error string.

I have included a patch to the latest SVN revision, 1260: http://xtrafile.com/uploads/DB_driver.php.patch
-Matt