I have a php application that relies on several classes to function properly. If I take one of the application's class files
/my/folder/class.php
then move it somewhere else
mv /my/folder/class.php /my/other/folder/class.php
then in its place inside of
/my/folder/
I create a symlink to it called class.php via
ln -s /my/other/folder/class.php /my/folder/class.php
I would expect my application to be unaffected, but instead this is breaking it. I know the symlink is valid since at the command line I can do
nano /my/folder/class.php
and everything looks as I would expect it to. Am I missing something fundamental about the behavior of symlinks, and/or how apache or php processes them? Is it changing the working directory or $_SERVER['DOCUMENT_ROOT']? I can not figure out why this would have any affect on my application.
I am using Apache server in CentOs.
Thanks!
The only difference would be if you are using require_once or include_once and you are mixing the symlink path with the real file path. In this instance, the X_once is going to think those files are different and load it twice (which will of course cause problems if you define any classes or functions).
Would probably need an actual error message to guess any further.
Related
I'm looking through the documentation, but I'm not seeing any option to change the working directory used when running tests.
I'm using PhpUnit as it's included in Laravel. I want to be able to run vendor/bin/phpunit from my project's root directory, and have it run using the /public directory as the working directory.
I tried running ../vendor/bin/phpunit from the /public, but since the phpunit.xml file isn't in the public directory and I don't want to specify my config file path every time, that won't work.
Is there something I can add to my phpunit.xml file to tell it to run tests using the /public directory as the "cwd" (current working directory)?
Based on the feedback I received in the comments and the documentation, I determined the following:
It's probably not possible to change the cwd that phpunit uses by default (well, it's possible in PhpStorm, but not the command line without writing some kind of wrapper script)
Code that depends on being run from a specific directory is not a good idea.
What I had was some code in one of my classes like this:
$var = file_get_contents("../some_file.json");
This works fine -- until you try to add unit tests. The web server runs using the /public directory as the cwd, while phpunit will run using the root directory.
Rather than trying to force phpunit to always use a particular cwd (/public), I decided it's probably best to remove relative paths from the code that rely on a consistent cwd. So the line above becomes:
$var = file_get_contents(base_path("some_file.json"));
I didn't want to change production code that was already working just to get some tests in place, but this change seemed insignificant enough. (and it's an improvement anyway)
Well, you'd have to do the actual chdir in PHP, but you can define a bootstrap script in the XML (<phpunit bootstrap="./bootstrap.php">) and have that change the working directory.
Alternatively, you can put a setUpBeforeClass function into your test class that changes the working directory.
I'm trying to use the Composer autoloader located at vendor/autoload.php. However, I can't seem to figure out how to get to the root of the project, from which I could then navigate to vendor/autoload.php. I'm having to specify the relative path in each file (i.e. ../../../vendor/autoload.php). This seems like a very nasty way to get to the autoloader, since this path will be different depending on how deep the file is.
Is there a way to get to the root directory without specifying a relative path, or do I need to go up x parent directories in every file?
PHP has no way of knowing what the "root of the project" is. You could have any number of directories on your disk, with files called vendor/autoload.php in several of them, and only you know what's special about the "project root". So ultimately, the answer is no, there is no way.
However, note that you only need to include the autoloader in files which aren't themselves included or autoloaded. The autoloader is something you load once, as part of the configuration / bootstrapping of your code, and it then loads whatever classes it needs wherever they're referenced.
So the way to limit the mess of different levels is to structure your project carefully. For instance:
Route all requests via one or two "routers", such as a single "index.php" file. Use Apache mod_rewrite or the equivalent in Nginx etc to make all URLs actually load this script, and then in the script work out what code to run based on the URL. You can use libraries such as nikic/FastRoute to translate the URLs into functions to call, which will then be autoloaded.
Use different PHP files, but all in a reasonably flat directory structure, so that they all have to "climb" the same number of levels to reach the project root.
The same principle applies to use in command-line scripts or any other kind of application: limit or structure the "entry points", because only those need to know where to load the autoloader.
If you already have some kind of config file loaded on every request / script run / unit test / etc, it might be sensible to put the require_once 'vendor/autoload.php'; line in there. Like the configuration, the autoloader is "global state" that you want to just set up once and then forget about.
I know how to convert php file into phar file.
$phar = new PHAR('app.phar');
$phar->addFile('file1.php');
$phar->addFile('file2.php');
I thought it can be useful only for converting POPO to PHAR.
My question
Is it possible to convert entire Zend framework 2 web application to PHAR file? if yes, then How?
(or)
How to package Zend framework2 web application into a package? (except .zpk(zend studio package file) file format)
Updated: creating Phar from entire application
create-phar.php
$basePath = /path/to/;
$path = /path/to/application;
$phar = new Phar ('project.phar');
$phar->buildFromIterator(new RecursiveIteratorIterator(new RecursiveDirectoryIterator($path)), $basePath);
$phar->setStub("<?php
Phar::webPhar('project', 'public/index.php');
include 'phar://project/public/index.php';
__HALT_COMPILER();
?>");
index.php
<?php
include 'project.phar';
?>
Question:
When i run index.php it do not redirect to actual public/index.php file instead it shows blank page on the browser. How can I resolve this problem?
Thanks in advance
I deploy phorkie as a .phar file.
There are some things to consider:
Pack up all files in the .phar - php and static asset files (js, css, png, jpg), too. I use phing to do that. Do not forget the dependencies.
You need a stub file that runs Phar::webPhar() which takes care of sending out HTTP headers
Write your own .htaccess rewrite rule interpreter, because Phar::webPhar() does not do nice-path resolving on its own. I did that already.
Manually take care of sending out caching headers for static files
Hope that you (or your users) don't run into one of the Phar::webPhar bugs:
Symlinked files
No HEAD, PUT or DELETE support
Redirection loop with FPM (already fixed in git)
Hope that your user's web server handles .phar files (it will not; neither Debian nor Fedora ship that configuration)
Hope that the user's web server is correctly configured to handle .phar files with PATH_INFO appended (/path/to/file.phar/foo/bar.png), like in http://p.cweiske.de/122
Getting phorkie running from the .phar took me the evenings of two weeks. Now that it basically works it still is not a drop-phar-and-play solution, because the default configuration of web servers just doesn't play nice with .phar.
I use CloudControl for hosting and I would like to set up a server (possibly with load balancing support) to host piwik for all of my websites. The only problem is that the only writable directory CloudControlled allows you to access is defined by $_SERVER['TMPDIR'].
Is it possible to modify piwik to use this directory for all of its file-writing needs?
And also will I run into any issues with using load balancing? Something like automatically generated reports being generated by each node behind my load balancer since they're not aware of each other?
The idea is to keep this change for your system even when you update.
This is easy to do: create a bootstrap.php inside the piwik main folder.
This is the content of said file:
<?php
define('PIWIK_USER_PATH', $_SERVER['TMPDIR']);
You can double-check this: in index.php, you should see that it checks for a bootstrap.php file in the same folder. It's included when available, and this allows you to do little customizations and keep them even when you update. E.g. I've run piwik from svn for the past three years or so and have some custom changes in there.
There's far too much code for me to be able to confirm this works, but the constant PIWIK_USER_PATH seems to be used as the base root for file io. With that in mind, editing index.php, around line 23, which is originally:
if(!defined('PIWIK_USER_PATH'))
{
define('PIWIK_USER_PATH', PIWIK_DOCUMENT_ROOT);
}
To something like:
if(!defined('PIWIK_USER_PATH'))
{
define('PIWIK_USER_PATH', $_SERVER['TMPDIR']);
}
Might work - but then what happens when it's trying to read a file in its original location? Since this is a temporary directory, however, it may not be viable, in which case an approach using override_function or a similar method, paired with a persistent storage (your database), might also work - by overriding file functions with a database load/save routine; obviously this opens up another can of worms of biblical proportions, thus, my final recommendation is for you to get another less restrictive host.
I am trying to get into PHP app deployment with Capistrano. I have two config files that I need to be "edited" depending on where I deploy it. It's basic stuff like database name and root url (Codeigniter). Can I make Capistrano edit specified automatically? Let's say I want to edit the following in the file /system/config/edit.php:
$test = '';
// edit to
$test = 'Hello World';
Thanks,
Max
What I generally do in this kind of situation (even though I don't use Capistrano) is to have several config files commited to source control.
For instance :
config.php for development machines
this file is the one that's always used by the application
config.testing.php
config.staging.php
config.production.php
And when deploying the application to the server, I just have to copy the file corresponding to the current environment to "config.php" -- as this one is the one that's always used by the application.
It means that I have to do a file copy during the build process, yes, but :
it means there is no need for any search and replace, that can break
it also means every config files are commited to SVN (or whatever source control software you are using)
If your configuration files become too complex, and duplicate lots of stuff, you can think about having one "default" config file, that's always included, and sub-config files that only define what depends on the environment.
What that, what I said before still stands : just include the "default" file at the begining of each other.
My Unix is knowledge isn't quite up to scratch so I can't quite get the syntax perfect for what you want. However, Capistrano allows you to directly use the Unix command-line by invoking :run_method within your configs.
The Capistrano code might look something like the following:
run "grep -R --files-with-matches '$test = "";' /system/config/ | xargs perl -pi~ -e 's/\$test = "";/$test = "Hello World";/'"
I would check up on that find and replace function working as expected before implementing it live though.
If you need any more help, I'd recommend checking out the Capistrano Handbook, it should answer most of your questions.