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.
Related
Following an audit, I've been tasked to remove extraneous files from the Twig 1.x vendor directory in one of our sites. Planning on removing /twig/twig/doc, /twig/twig/test and see if anything breaks.
What about /twig/twig/ext/twig/run-tests.php, or the entire "ext" directory?
Does anyone have prior experience weeding a default Twig 1.x installation for production environments? Any assistance or advice gratefully welcomed.
The correct action would be to update your site's layout so that these files are outside your web server's document root -- then you don't have to worry about what to delete and what to leave. You probably have something like this, where your web server's document root is pointing directly at /path/to/project:
/path/to/project
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
index.php
This means anybody can directly request http://yourdomain.com/twig/twig/test/some_file.php
What you want is more like this:
/path/to/project
/public
index.php
/lib
foo.php
bar.php
/twig
/twig
/doc
/test
Then configure your web server so that its document root is /path/to/project/public. Then your application code can still include() things in /twig and /lib, but your web server won't directly serve them.
If your removing files from the vendor directory they'll come back the next time you do a composer install so this seems kind of pointless.
The files you mention (docs and test) are causing no harm other than taking up space as they are not directly called, but that's just a downside to any package management system. Like #Alex said as long as they are not publicly accessible there is no need to worry.
If you really want Twig without the extra files you could fork the project, move it into your own Git repo then reference that in your composer.json instead of the official one - but you will miss out on any updates from Twig.
We're running on Apache, so the easiest solution was to simply add a .htaccess file to the top vendor directory:
# Prevent non-local access to the vendor directory.
Order deny,allow
Deny from all
Directory structure:
/root
/vendor
.htaccess
/twig
...
/includes
...
Now the PHP scripts continue to have access, but external attempts to view anything inside the vendor directory return a 403 error.
We use CakePHP 2.7.9 and Minify plugin on a CentOS server running Apache 2.2.
https://github.com/maurymmarques/minify-cakephp
The plugin works fine and now we can minify css files like this.
echo $this->Minify->css(array('default', 'global'));
The code above generates URL like this.
http://example.com/min-css?f=default.css,global.css
And now we want to deny access to original files under webroot/css. How can it be done in CakePHP? We want to return 404 or 401 or something like that for direct URL access like this.
http://example.com/css/default.css
And now we want to deny access to original files under webroot/css
Simply don't but non public code and files into the public webroot. It's not recommended in any case. Point your minifier to the files and set its output folder to webroot.
We use task runners and keep the minification code outside of the actual app. This is stuff that doesn't belong into the application itself - IMHO.
We use php Robo and on the JS side Gulp for minification and automatically trigger the tasks on deployment. All our SCSS and JS files are outside of the webroot. We have just a few asset includes in our app code and they almost never change. Robo and Gulp have watchers that rewrite the asset files as we change them on when the app is deployed it automatically generates minified files.
first thanks for your brilliant work on Restler, I am using it for some labs at the University and so far it works like a charm, really simple and elegant framework!
I've been using Restler 3.0 RC4 successfully until I updated to RC5 today. Now I'm having problems with the HtmlFormat. Whenever I try to access any of my web services that return HtmlFormat or try to enter the API Explorer, I'm getting a HTTP 500, "Unable to create cache directory /home/xxxxxxx/public_html/concrete/api/cache/php" . Also, I see a "Warning: mkdir() [function.mkdir]: No such file or directory in /home/xxxxxxx/public_html/concrete/Restler/vendor/Luracast/Restler/Format/HtmlFormat.php on line 367" .
Do you have any idea of what could be happening? In the upgrade, I just replaced my Restler framework folder with the RC5 one, without any changes in my API itself.
I would appreciate any help. Thank you!
Most of the template formats need a cache folder to keep their compiled files so that they run efficiently
Since RC5 we create a subfolder for the template type used. Even though php templates does not need compilation Restler attempts creating php folder under the default cache location, which is cache folder located in the same folder as the index.php
In your case it is
/home/xxxxxxx/public_html/concrete/api/cache
You should update the cache folder to keep it outside the web root by adding
Defaults::$cacheDirectory = '/home/xxxxxxx/cache';
And then make sure the cache folder is writable
Then HtmlFormat will create the php/twig/blade folder depending on your template preference and add the compiled files inside
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.
I am building a website which uses Apache + PHP on port 80 for the frontend, and Node.js + Socket.IO for dynamic updates on port 3000. There are quite a few shared Javascript resources between the two and I'd like to know how I can share them.
Here's my project layout:
project/
www/ // Apache DocumentRoot
index.php
js/ // Javascript files for the HTML pages
css/
app/
App.php // All the PHP files
node/
node_modules/ // Node modules installed by NPM
app.js // Node.js application
When my PHP application generates HTML code, it needs to put some <script> tags in <head> for things like underscore.js, backbone.js, socket.io.js, etcerea. But these scripts are all somewhere in de node_modules directory.
I have seen various examples but most use Node.js to serve the HTML page as well (usually using the express framework). So, they generate script includes like /socket.io/socket.io.js. But in my case I have two servers running on two ports.
So, how can I load the proper Javascript files without manually copying things from the node_modules directory to the js directory under the DocumentRoot?
There are 2 options:
Create a symlink (pointing from www/js to node_modules)
Create an Apache2 alias in you Apache configuration file (see here)
If you have access to your Apache2 configuration, the 2nd solution is probably the better one. When going for the symlink solution, make sure you double-check the ownership of the folders if you experience problems.