I faced today a strange problem wich I cannot explain.
The Environment:
Ubuntu 16.04
Nginx 1.10 with php-fpm
php 7.0.8
So I migrated from a hosted server with apache and php5 to this new Server.
The first tests were successful. The page was running and seemed to be fine.
Then I encountered the Problem, that some pages couldn't be called. The HTTP response was 200 but the page was blank.
Chrome told me net::ERR_CONTENT_DECODING_FAILED
I found out, that the difference between working pages and the blank pages were, that the non-controller echoed json_encode() at the end;
This is my controller:
public function some_controller()
{
$result = ["test" => "abcde"];
echo json_encode($result);
}
This will end with net::ERR_CONTENT_DECODING_FAILED
This is my workarround:
public function some_controller()
{
$result = ["test" => "abcde"];
echo json_encode($result);
exit();
}
So following is unclear:
Why I have to exit() my controller now?
What is CI doing after a Controller function is passed?
Why was that working with Apache and PHP5? What could be the difference now?
Thank you all
I found the problem by myself.
After installing php7.0-xml the issue went away.
But can anyone tell me why the xml module is required for JSON responses?
Maybe its not the JSON, it is codeigniter wich needs the XML Module (After the controller is passed)?
Related
I just pushed a Laravel website onto a shared hosting. Copied the public folder to the /www, changed the index.php to reflect the path change and configured my .htaccess, etc.
At first I was simply getting an error, telling me that Page::findBySlug() returned null. Checked again with dd(), was and still is null.
FrontendController#index is looking like this
public function index($slug)
{
$page = Page::findBySlug($slug);
$pageTemplate = $page->templates->first();
return view('frontend.pages.index', compact('page','pageTemplate'));
}
and after toying with dd() for a while, it now sends me to the custom 500 unless it's supposed to pull the slug from db, in which case I get a custom 404.
EDIT: I pulled the same version of the app but with it being already installed (instead of rolling with composer instal) from the testing platform and it simply works so I doubt it has anything to do with the hosting. I'd still appreciate an answer given that I'd like to do it the correct way. Is there anything I should setup slugs-wise after running a fresh install?
What am I missing here? Thanks.
Try $page= Page::where('slug',$slug)->first();
Try to update your php veersion to 7.0 .
Fixed by php artisan route:clear.
Apparently route:cache wasn't the way to go.
I'm trying to install codeigniter bonfire. After clicking the install button on the create username screen, it takes a few moments and then it loads this page. I watched some tutorials on how to install bonfire so I know this isn't what I should be seeing.
Regardless, I updated the RewriteBase to /bonfire/ as it says..and now I'm getting this error when I try to go to localhost/bonfire/index.php
Parse error: syntax error, unexpected 'yield' (T_YIELD), expecting
identifier (T_STRING) in
/opt/lampp/htdocs/bonfire/bonfire/application/libraries/template.php
on line 305
Here's the code at line 305
public static function yield()
{
$output = '';
if (self::$debug) { echo 'Current View = '. self::$current_view; }
self::load_view(self::$current_view, NULL, self::$ci->router->class .'/'. self::$ci->router->method, FALSE, $output);
Events::trigger('after_page_render', $output);
return $output;
}//end yield()
I found this link on bonfire forums explaining the error.
Bonfire forums link
It says to use PHP 5.4 and that's what I'm using. My operating system is Linux Zorin and I'm using lampp, so I'm not sure if this could be a permissions issue.
thx in advance and please let me know if you need more info.
a bit late but hopefully help.
You can change the name for static function yield in cibonfire, something like this:
public static function yield()
to:
public static function yield_content()
this works perfectly to me.
I think in the LAMP the version of PHP is 5.5 + Something. IN PHP 5.5 there is a function name as yield so you have to downgrade your LAMP PHP version to 5.4 or modify in the Bonfire file system.
For change in Bonfire You can Go through this link and your problem has been solved.
https://github.com/illuminate/view/commit/d37abcecc7d79d00bf5f22b134d152ca765f26b2
You can also Review this link Laravel 4 syntax error out-of-the-box
We are working on a project which is build upon Codeigniter 2.
All was working great untill we updated the Apache httpd from 2.2.21 to 2.2.24. The PHP version is still the same (5.3.25).
For building views we use the Template library from Phil Sturgeon.
A controller function could look something like this:
public function index(){
if($this->_is_logged && $this->_is_super){
redirect('/start', 'refresh');
}else{
$this->template
->set_partial('page_header', 'web/template/page_header',$this->data)
->set_partial('page_footer', 'web/template/page_footer')
->set_partial('page_notifications', 'web/template/notification_view',$this->data)
->set_layout('minimum')
->build('start/authenticate_view');
}
}
After the update this causes a 500 Internal server error ...
However, when adding an echo before the ifstatement like this:
public function index(){
echo $this->_is_logged.' '.$this->_is_super.' -- test --'.$this->data;
if($this->_is_logged && $this->_is_super){
redirect('/start', 'refresh');
}else{
$this->template
->set_partial('page_header', 'web/template/page_header',$this->data)
->set_partial('page_footer', 'web/template/page_footer')
->set_partial('page_notifications', 'web/template/notification_view',$this->data)
->set_layout('minimum')
->build('start/authenticate_view');
}
}
The page gets build as it should with the values from the echo at the top of the page.
We allready downgraded the Apache httpd to 2.2.21 and everything worked again without changing any code. So we are sure it has something to do with the Apache version. Maybe it has to do with code used in the Template library, or some strange other thing... ?
We are running up against the walls on this one.
Is there anyone who had the same issue, knows what the problem might be, ... You would be our hero forever :)
Additional info:
We use DataMapper ORM for CI models
cPanel-version: 11.36.1 (build 6)
OS Linux
A 500 error should record an error in your error logs unless you have set it not to. try putting a htacess file in the root with something like:
php_value log_errors 1
php_value error_log /var/www/.....php-error.log
then replicating the error and seeing what is output to the log. As you say it will be to do with some conflict with apache but a 500 error is just too generic to solve.
We found the problem.
There was a forgotten Library we had used in an early state of the project to log messages and data in FirePhp.
Removing this file and a call to one of his functions in our base controller solved the internal server error.
After following the user guide instructions found here: http://ellislab.com/codeigniter/user-guide/general/cli.html I'm unable to run the test script via command line.
My controller located at /var/www/mysite/application/controllers/
class Tools extends CI_Controller {
public function message($to = 'World')
{
echo "Hello {$to}!".PHP_EOL;
}
}
In my browser I can access
http://mysite/tools/message/ben
And the function correctly outputs "Hello ben"
From terminal I should be able to run:
$ php index.php tools message "Ben"
My terminal should print: "Hello Ben"
However I get the following error:
PHP Fatal error: Class 'CI_Controller' not found in /var/www/mysite/system/core/CodeIgniter.php on line 233
My server is pretty standard; ubuntu LAMP. Codeigniter is pretty standard too and I have no problem running non CI scripts via command line
My PHP binary is only located in /usr/bin/php <-- This post suggests an issue running CI directly from usr/bin/php, however I'm not operating a shared PHP service, and I don't see why this would make a difference to how PHP executes a CI script.
Any help or just an indication on how to debug this would be greatly appreciated.
Thanks in advance.
Solved! (partly) the issue was CodeIgniters error logging.
In application/config/config.php, I modified the following config property:
$config['log_threshold'] = 0;
This disables logging, and allows $ php index.php to execute.
If anyone can explain why CI only shows this error on CLI PHP - might help anyone else who has this issue and needs it resolved with error logging on.
To solve error "Class 'CI_Controller' not found" try going to Application -> Config -> database.php then check the database details like hostname, username, password and database.
To Mijahn:
I had this same problem, and after about two hours of tracing through code to figure out the problem, it seems that there is some sort of conflict with loading the CI_Controller when utilizing the native PHP load_class function.
I worked around this issue by making the following changes to the Common.php file (hack, I know).
//$_log =& load_class('Log');
require_once('system/libraries/Log.php');
$_log = new CI_Log();
My logs then where created exactly like I wanted. Hope this hack helps.
This site says to run codeigniter from the command line, one must set the $_SERVER['PATH_INFO'] variable.
$_SERVER['PATH_INFO'] is usually supplied by php when a web request is made. However, since we are calling this script from the command line, we need to emulate this small part of the environment as a web request.
The answer provided in this Stack Overflow post worked for me.
Within system/core/CodeIgniter.php, on around line 75, change:
set_error_handler('_exception_handler');
to...
set_exception_handler('_exception_handler');
Other users have reported that this gave them a better backtrace with which to debug the underlying issue, but for me, this actually removed the problem altogether.
I have a Magento 1.6.2 site hosted on 1&1. Because of certain installed extensions I must have support for PHP version 5.3, but sadly the available options with 1&1 are PHP 5.2 or something they call PHP Dev. A quick phpinfo() shows that this is in fact PHP 5.4.
My problem is that when I'm set to 5.4, the Categories page of the backend throws a 500 error. Rolling back to 5.2 fixes the issue, but that breaks my product pages. In the short term I can handle having to swap between them, but this is obviously unacceptable for a long-term solution when the site is handed to the client.
Can anyone suggest where this incompatibility might lie, and what steps I might take to fix it? My biggest impediment is that the hosting is on a shared server, and so I am not allowed to look at the Apache logs.
Update:
As per CCBlackburn's suggestion in the comments, I have tried to track the point that the error originates from, but I have to admit that I don't really understand the results I'm getting. The URL of the categories page looks like this:
example.com/index.php/admin/catalog_category/index/key/blahblah
I presumed that Mage_Adminhtml_CatalogController would be the place to start looking, but a Mage::log() call as the first line in indexAction() failed to write to the log.
I decided to move up the inheritance and cut into the constructor, and so added the following to Mage_Adminhtml_Controller_Action:
function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array()) {
Mage::log('construct pre');
parent::__construct($request,$response,$invokeArgs);
Mage::log('construct post');
}
This was better, as the first log call wrote to the file, but the second did not.
Next I moved up the inheritance again, and modified the constructor of Mage_Core_Controller_Varien_Action as follows:
public function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array())
{
Mage::log('request: '.$request);
$this->_request = $request;
Mage::log('response: '.$response);
$this->_response= $response;
Mage::log('pre set action');
Mage::app()->getFrontController()->setAction($this);
Mage::log('post set action');
$this->_construct();
}
The problem is that none of these log calls do anything. This has me stumped, as surely calling parent::__construct(); from Mage_Adminhtml_Controller_Action should execute at least one more log call before it does anything. Unless the issue exists with the incoming values, but I don't know how I can check/debug that?
I have faced the same problem under OSX Lion in Google Chrome and Apple Safari with Magento 1.7 and PHP 5.4. Suddenly Magento Category admin started giving 500 Errors and I had no clue what was happening. It seems it's a problem with PHP 5.4. At first I thought it was XDebug causing this error. Then I disabled XDebug and the problem was still there. It is weirder than weird that it works with Firefox!
My solution was to downgrade to the latest PHP 5.3, however this has now been fixed as of PHP 5.4.3.