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.
Related
I have tried to configure ionCube Encoder on my Windows 10 PC running PHP 5.6.8 but without success. After downloading the encoder zip file from ioCube Loaders
I copied the "ioncube_loader_win_5.6.dll" to "C:\xampp\php\ext". Then I updated my php.ini file to loaded the encoder
[ionCube Loader]
zend_extension="C:\xampp\php\ext\ioncube_loader_win_5.6.dll"
and restarted apache, but when I test it from then command prompt using "php -v", it does not load. See my result
php -v
Failed loading C:\xampp\php\ext\ioncube_loader_win_5.6.dll
PHP 5.6.8 (cli) (built: Apr 15 2015 15:07:09)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
I also tried setting it up using the loader-wizard, but it did not work too. Anyone with useful information will be of great help right now.
Thanks
This Post is old but it might help other people. You have just to replace to dll. I had the same problem when using the 64bits dll. Replacing it with the x86 dll did the tric
I'm having a lot of trouble trying to get the php for a soap wsdl request working. I came across wsdl2phpgenerator which sounds like it generates the code for the service you want? Problem is I can't figure out how to use it. I'm running WAMP on my local machine. How do i install and use, the instruction don't seem to make a lot of sense to me.
I guess you use windows when you use WAMP.
You should not run the wsdl2phpgenerator through apache. You need to run it on the commandline.
step 1:
First open the CMD and type:
php --version
If the cmd prints something out like :
PHP 5.4.19 (cli) (built: Aug 23 2013 00:51:43)
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
go to step 3:
step 2: add php to windows env path:
https://stackoverflow.com/a/9546345/1210773
use the path to your own php installation
after this run step 1 to validate php is correctly setup
Step3: run wsdl2phpgenerator
move the cmd to the wsdl2phpgenerator dir and run wsdl2php
I found some examples in the wsdl2phpgenerator documentation:
https://github.com/wsdl2phpgenerator/wsdl2phpgenerator/wiki/ExampleUsage
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?
I have the Acquia Drupal stack 7.4.4 - which is using PHP 5.2.17 installed on an OSX 10.6.8
Drupal's PHP Stack:
User [~/]> php -v
PHP 5.2.17 (cli) (built: Jun 30 2011 12:12:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
OS X's PHP Stack:
User [~/]> /usr/bin/php -v
PHP 5.3.4 (cli) (built: Dec 15 2010 12:15:07)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
As seen the Xdebug binary for PHP 5.2 downloaded from http://code.activestate.com/komodo/remotedebugging/ is correctly loaded with PHP 5.2.17 This is also verified with phpinfo.
The purpose for my questions is to reach a stage where I can compile the xdebug.so for the Acquia Drupal stack to be used with NetBeans 7.
So - which version of PEAR / PECL is the correct one to have installed on my system, the one for PHP 5.2.17 or the one for 5.3.4 - or does it not matter?
Thanks
You need a different .so for 5.2 and 5.3 as they have incompatible APIs. A "PEAR/PECL" version makes little sense as Xdebug only uses PEAR as the installer. Just make sure you have a PHP 5.2 and a PHP 5.3 Xdebug.so. The Komodo download provides both.
Great - "Xdebug only uses PEAR as the installer" - I had, with my limited experience, been wondering if those libraries were also used within xdebug/Acquia/NetBeans while actually debugging the code. So PEAR/PECL's sole pupose is now clarified, and it also remains clear that xdebug needs to be compiled for PHP 5.2 as that is the PHP version used by the Acquia 7.4.4 stack.
Now relying on Komodo binaries, without knowing how they were derived and why they do actually work, or even worse - why my own compilations does not work - that is a possible short cut and it does work for me for the time being.
but
... neither Xdebug, Drupal, Acquia or Netbeans provides an up to date description on how to compile the xdebug on a Mac for these tools used on a OS X 10.6.8 (64-bit intel). I assume a simple but up to date and clear step-by-step-guide e.g. as bullet points would benefit a lot of developers-want-to-be ... any takers?
I've set up a project called testphp in Netbeans PHP. It has one file called Index.php. I've added to the html and have tried both run and debug.
I receive the following message from Firefox:
(URL:
http://localhost/TestPHP/index.php?XDEBUG_SESSION_START=netbeans-xdebug)
Not Found: The requested URL /TestPHP/index.php was not found on this
server. http://localhost returns "It Works!"
The virtual directory "TestPHP" does not appear to exist either. Can
someone suggest some pointers for tracking down the problem?
Ubuntu : 10.10 Apache : 2.2.16 (Ubuntu) PHP : PHP 5.3.3-1ubuntu9.3
with Suhosin-Patch Copyright (c) 1997-2009 The PHP Group Zend Engine
v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
Your project isn't actually being served by your local server. The "It Works!" output is a default page your server is outputting because there are no actual files for it to serve.
The NetBeans "Local Web Site" project configuration assumes that your PHP sources will be stored in your local server's Web documents directory.
If you look at the NetBeans docs, you'll see there's an option to make NetBeans automatically copy your project's files to the appropriate web server directory when you "Run" your project.