I have a situation in the office. For development, i have been using the built-in web server that comes with PHP 5.4.
My problem is, on my local machine, it works like a charm but on the staging server, request uri length becomes a problem.
Staging server is: Ubuntu 12.10 32 bit.
PHP Version is
PHP 5.4.14-1~quantal+1 (cli) (built: Apr 11 2013 16:59:23)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans
php.ini files are the same with the ones in my local.
I tried to recompile the PHP but still no luck. I have a simple php code to test as;
<?php
echo $_GET['q'];
?>
but when the request is too big (around 1447 chars like index.php?q=blahblah...) Built-in web server fails and just gets ....endofstring as request. So returns a 404.
I Know that every web server has a request url length limit, but while an identical request to my localhost (ubuntu 12.04, again php built-in server) works, there should be something that i miss.
Any suggestions or clues where to look for the problem?
Related
I'm trying to call json_decode(). I'm using a shared Hostgator server. I have already checked some other questions on StackOverflow regarding "json_decode"
After ssh-ing in, php -v outputs the following:
PHP 7.4.16 (cli) (built: Mar 9 2021 17:55:07) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v10.4.5, Copyright (c) 2002-2020, by ionCube Ltd.
and when I search the PHP modules using php -m it does appear to have the line
json
in the output
Try this:
Create a file in the servers web root called phpinfo.php and add the following to it:
<?php
phpinfo();
?>
Go to phpinfo.php in your web browser to confirm that JSON is installed, and that the web server is using the same version of PHP as the CLI version.
I'm using XAMPP version v3.2.1 and here's the output of php -v:
PHP 5.4.19 (cli) (built: Aug 21 2013 01:12:03)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
I want to set up Zero-Configuration Debugging with PhpStorm, so I followed all the steps (I think) and tried to launch a PHP file with breakpoints placed on it. But for some reason, when I open / refresh the page, it doesn't detect the breakpoint at all, nor it shows the incoming connection screen in PhpStorm.
I validated my setup here:
and I'm using https://github.com/BrianGilbert/xdebug-helper-for-firefox Firefox plugin.
I just want to simply debug my local PHP website as I browse through it, what am I doing wrong?
You are using PHP 5.4. Please, for the love of god, upgrade. This, and Xdebug's 2.2, haven't been supported for half a decade. Neither PHP 5.4 or Xdebug 2.2 are supported any more, and not for a very long time.
I am having connection difficulties with PHPStorm 8.x and remote XDEBUG running on a nginx server, wherein XDEBUG doesn't terminate upon cancelling the HTTP Request during a site reload or navigating to a different url.
The issue occurs sporadic, sometimes quickly turning the Debug-Listening button on and off helps terminating and breaking anew at a preset breakpoint.
PHPStorm has been continuously upgraded to the latest version since 8.0. PHP/XDebug are used in the following versions, on an nginx server:
PHP 5.4.36-1~dotdeb.0 (cli) (built: Dec 19 2014 22:51:27)
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans
The PHP> Debug Settings in PHPStorm are set as follows:
Any help or pointers are highly appreciated.
I have an CodeIgniter project, everything was fine when I worked on my local machine.
When I have uploaded the project to server suddenly controllers stopped working except the default controller. I have burned a few hours of searching the problem and have found that my controllers and models does not works because their file name was not with capital letter.
Example:
controllers/test.php - does not works
controllers/Test.php - works
The same is with models, I think that it is configuration issue of apache or something.
I have :
Ubuntu 14.04
Server version: Apache/2.4.7 (Ubuntu)
PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
Any ideas?
It's not a configuration issue. It's not an issue at all - just how most Linux file systems work.
Under Windows, and depending on an install-time configuration, on Mac OSX too, there's no distinction between 'test.php' and 'Test.php' - it's the same file.
With UNIX-style file systems on the other hand, you can have both 'test.php' and 'Test.php' in the same directory.
It might've worked for you under CentOS and Debian in the past, but that's because you've used older versions of CodeIgniter, which used to look for all-lowercase file names.
CodeIgniter 3.0-dev, which you are using now, requires that all class filenames start with a capital letter. This is explained in the upgrade instructions.
I recently updated my linux mint via the automatic updater. I had the problem, that it did not execute php scripts. After re-installing libapache-mod-php5 some php started to work. Yes, just some, as phpinfo() is executing properly, but another php file, which works correctly on other machines, and was working on mine too, is now producing the following error in resopnse to an $.ajax call: status: parsererror errSyntaxError: Unexpected token <. what happens is it returns the php file without executing it, even though it executes other php files.
My configs are the following:
Server version: Apache/2.4.6 (Ubuntu)
PHP 5.5.1-1~precise+1 (cli) (built: Jul 22 2013 07:33:14)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies
The problem was that after the update the php.ini got overwritten and it was not interpreting shortcode. The solution is to set
short_open_tag=On
in the php.ini as suggested here.