Welcome Guest, Not a member yet? Register   Sign In
CodeIgniter 3.1.1 Released
#11

(10-26-2016, 02:59 AM)Andryshok Wrote: This my admin panel return 404 page. This is a bug. I return 3.1.0.
Route adress my_domain/admin    - return 404 page
Default controller name for my admin panel is 'Index.php' - in version 3.1.0 - it's works

Index is, and has always been a reserved name.
This is not a bug.
Reply
#12

good job thanks
Reply
#13

Thank you very much
Reply
#14

(10-23-2016, 05:00 AM)Narf Wrote:
(10-23-2016, 04:59 AM)gxgpet Wrote: The Session has been changed (including docs), making id from ci_sessions be varchar(128). Shouldn't be that mentioned in the changelog?

No.

Since the field changed from 40 -> 128, that suggests to me that the id can now be bigger than 40 characters.  In an existing system, how is there not a risk of a truncation error, resulting in session failures?  It would seem that the changelog (or upgrade instructions) need to instruct you to increase the size of that field.  Why is this not an important detail?  If this isn't a concern, then why would the field have been increased?
Reply
#15

(10-27-2016, 08:06 AM)justanotherprogrammer0 Wrote:
(10-23-2016, 05:00 AM)Narf Wrote:
(10-23-2016, 04:59 AM)gxgpet Wrote: The Session has been changed (including docs), making id from ci_sessions be varchar(128). Shouldn't be that mentioned in the changelog?

No.

Since the field changed from 40 -> 128, that suggests to me that the id can now be bigger than 40 characters.  In an existing system, how is there not a risk of a truncation error, resulting in session failures?  It would seem that the changelog (or upgrade instructions) need to instruct you to increase the size of that field.  Why is this not an important detail?  If this isn't a concern, then why would the field have been increased?

You know, it is reasonable for one to ask if we didn't just miss something, but I did already confirm that it is not by mistake and one would think that should be sufficient. Apparently not.

That was done to allow increased lengths on PHP 7.1.
There are no existing applications running on PHP 7.1.
Because PHP 7.1 is not yet released.

Now, there turned out to be a bug in that logic and in order to fix it, we now have to allow increased lengths on established PHP versions, so we'll mention it in the 3.1.2 upgrade instructions. But changing the field size does nothing for existing applications on 3.1.1.

Is there a stone left unturned still?

Please excuse the passive-aggressive response, but if you try to read between the lines so hard, the changelog entry mentioning PHP 7.1 should've explained all that.
Reply
#16

(10-27-2016, 09:09 AM)Narf Wrote:
(10-27-2016, 08:06 AM)justanotherprogrammer0 Wrote:
(10-23-2016, 05:00 AM)Narf Wrote:
(10-23-2016, 04:59 AM)gxgpet Wrote: The Session has been changed (including docs), making id from ci_sessions be varchar(128). Shouldn't be that mentioned in the changelog?

No.

Since the field changed from 40 -> 128, that suggests to me that the id can now be bigger than 40 characters.  In an existing system, how is there not a risk of a truncation error, resulting in session failures?  It would seem that the changelog (or upgrade instructions) need to instruct you to increase the size of that field.  Why is this not an important detail?  If this isn't a concern, then why would the field have been increased?

You know, it is reasonable for one to ask if we didn't just miss something, but I did already confirm that it is not by mistake and one would think that should be sufficient. Apparently not.

That was done to allow increased lengths on PHP 7.1.
There are no existing applications running on PHP 7.1.
Because PHP 7.1 is not yet released.

Now, there turned out to be a bug in that logic and in order to fix it, we now have to allow increased lengths on established PHP versions, so we'll mention it in the 3.1.2 upgrade instructions. But changing the field size does nothing for existing applications on 3.1.1.

Is there a stone left unturned still?

Please excuse the passive-aggressive response, but if you try to read between the lines so hard, the changelog entry mentioning PHP 7.1 should've explained all that.

With a response like this to the original question, I wouldn't have had to doubt.  I'm sorry to have further bothered you on it, I just needed to be confident my applications wouldn't break if I update the framework.  Thank you for the clarification and your work on the framework!
Reply
#17

(10-27-2016, 09:31 AM)justanotherprogrammer0 Wrote: With a response like this to the original question, I wouldn't have had to doubt.  I'm sorry to have further bothered you on it, I just needed to be confident my applications wouldn't break if I update the framework.  Thank you for the clarification and your work on the framework!

You're welcome, and don't mind me that much ... just take a note. Smile
Reply
#18

Thank you to the  development team!
Reply
#19

(This post was last modified: 10-31-2016, 08:50 AM by bfedderm. Edit Reason: supplying more info )

I'm running into errors due to the changes made to the Upload Library.  This happens on two Windows servers with PHP: one is running PHP 5.5.16 and the other is running PHP 5.5.34.  When a file upload is initiated via a form, the page gives a generic 500 message with zero error message logged in the PHP error log.

I think it is due to changes in the _file_mime_type function, but I am going to do an exhaustive test to see if I can get you more information.

After digging into this...the error relates to the removal of this:  if (function_exists('finfo_file')) { }.  If the php_fileinfo.dll is not initiated, the function now bombs out due to the removal of that contingency.
Reply
#20

(This post was last modified: 11-18-2016, 12:42 PM by svennd. Edit Reason: issue resolved )

After the upgrade to the 3.1.1 version a controller named "log" does not work anymore.  The route gives a 404.

PHP Code:
$route['log/(:num)'] = 'log/log/$1'

the code in log :
PHP Code:
// default handler
public function index($location_id false) {
    
$this->log($location_id);
}

public function 
log($location_id false) {
// code

I'm stunned. Ill report back when I have found a solution. (PHP 7.0.12)

// issue resolved updating to 3.1.2
There where changes in b/system/core/Log.php from 3.1.1 to 3.1.2 this seemed to be related to this issue. 3.1.2 seems to work fine.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB