Does anyone know if it is possible to include an auto_prepend file with HipHop hhvm (latest version)?
I don't see in the options or the documentation anything about this feature.
No, there is currently no way to do this. I've love to get a pull request from you though :)
Support for auto_prepend_file and auto_append_file was added in HHVM 3.1.0 (Released 2014). These behave the same way as their Zend PHP counterparts.
If running an older HHVM version, there was (and still is) also the request_init_document setting is similar auto_prepend_file in that it executes before the main script for this request executes.
However, it has two important differences:
The RequestInitDocument will not run once before every single web request. Instead, HHVM runs request_init_document only once a longer-lived thread. The state of the virtual machine after request_init_document completed is captured in a snapshot and then restored at the start of multiple future requests, until it gets recycled and recreated.
HHVM 3.22.0 - Server Flow Documentation
It applies only to web requests, not CLI. https://github.com/facebook/hhvm/issues/1323
Related
I have been trying to run HHVM as standalone web server for multiple domains and it looks like they are switching to FCGI mode only https://github.com/facebook/hhvm/wiki/runtime-options
Is that the case or running it as standalone is still possible on production?
Yes, you should use FastCGI mode and let nginx/Apache/whatever deal with being the webserver. HHVM's old built-in webserver has been deprecated for quite a number of releases now -- I can't find the old the wiki page on its deprecation, but it's been about six months or so. This more closely mirrors how PHP is often used, and removes a whole host of complicated HHVM-specific configuration mess. Many people are already familiar with how to make nginx/Apache serve files the way they want, and so we can just keep the HHVM-specific stuff in HHVM and let the full-featured webservers do what they are good at.
The getting started guide has a very quick, basic intro to getting FastCGI set up if you're using our prebuilt debian/ubuntu packages, and the FastCGI wiki page contains all the details to get set up in some other environment.
I am building a framework where product instances use the main framework files, until there is a copy of it's own version of that file. To achieve this I have done the following:
set_include_path(MY_PRODUCT_ROOT.'/' . PATH_SEPARATOR . MY_FRAMEWORK_ROOT.'/');
So if I call include('view-users.php'); it will first look in MY_PRODUCT_ROOT for /view-users.php and if that's not found, it will then look to MY_FRAMEWORK_ROOT/view-users.php.
This procedure is working very nicely until I add files to the product root. I know that PHP/Apache is caching the includes and one would think to run clearstatcache(true); to clear any status caching. PHP likely uses file_exists inside it's include(); and thinks the new file still does not exist. I have tried restarting Apache with no effect.
Unfortunately running clearstatcache(true); does not help either. Only once I have deleted MY_FRAMEWORK_ROOT/file does it think to clear cache and try again, thus finding MY_PRODUCT_ROOT/file.
Im a little stumped, I know we need to refresh PHP/Apache's understanding of whether the file(s) exist or not, but clearstatcache(true); is not helping...
Any ideas?
UPDATE: Correction, restarting Apache seems to help now. I reiterate that this only occurs when trying to ADD a file to MY_PRODUCT_ROOT, to overlap an existing MY_FRAMEWORK_ROOT file, for customization
UPDATE: Development environment is Zend Server CE PHP 5.3.14 on Windows, Production environment Centos linux httpd, PHP 5.3+. The fact that Zend optimizer is enabled on my dev environment could have an effect, Also not using APC or any other caching scripts
Zend Optimizer+ speeds up PHP execution by opcode caching and optimization. It stores precompiled script bytecode in shared memory. This eliminates the stages of reading code from the disk and compiling it on future access. For further performance improvements, the stored bytecode is optimized for faster execution.
This is caching the file contents found in the includes, thus clearstatcache does not work. I have disabled my Zend Optimizer and it works now.
Is anyone using Magento with Apache worker MPM?
I've read conflicting reports of stability and security using worker instead of prefork, but have also read that worker is much faster than prefork.
PHP5 is thread-safe, but PHP extensions aren't all thread-safe. So it's considered harmfull to run a PHP application on a worker-mpm. And Magento is a PHP application like any other, chances are that you are using some PHP extensions somewhere (GD, Xml, etc) and that you can't test it for thread stability (really hard to test).
But what you can do is use apache as worker (really a lot more HTTP request handled, very useful for all static files), and push PHP out of Apache (so with no mod_php).
For that you will have to use PHP with fcgid or php-fpm, that is modern version of cgi to say it in a few words.
There is an IIS bug that causes problems with headers when using a CGI program, and setting a redirect to a page that returns a http 302 (Object Moved). The result is that IIS doesn't parse the headers, so if you're trying to set cookies, it's not going to work. See the KB Article
It says the solution is to start the EXE CGI with -nph (Non parsed Headers) - but I'm not really sure if it works in PHP. I tried adding it to my php file and manually building headers, but that didn't work for me..
Has anyone had this problem? Any good workarounds?
I'm not entirely sure how you're seeing this bug in the modern era.
First, Q17..., er, I mean, KB176113 was published in 1997. The examples list IIS 2.0 as the product affected, and the article itself claims only versions 3-5 are affected. Unless you're running your site on Windows 2000, you aren't using IIS5. Both the article and a bit of time in Google suggests that this problem is entirely fixed in IIS6 and later.
Second, the bug impacts only CGI scripts. If you are using PHP with IIS, then you are either using the ISAPI DLL (and if you are, I'm so sorry), or you're using FastCGI, which despite having three letters in common, is not actually CGI. Nobody has run PHP in CGI mode on IIS since...
You aren't using IIS5, are you?
Okay, if you aren't on IIS7, you might not be running in FastCGI mode. You should totally switch to FastCGI with modern PHP versions. Microsoft spent a lot of time and effort getting PHP and FastCGI playing nicely with IIS.
Third, setting cookies mid-redirect has been buggy in every browser on every platform at one time or another. Are you sure that the cookie header isn't actually being sent? Check your browser's development tools.
Prefixing the PHP file with nph-, not -nph - solved this issue for me.
e.g. nph-test.php
What are the differences between mod_php and cgi php script?
I mean, why it's better (is it?) to use mod_php instead simple php scripts, running them as CGIs?
Thanks
When using CGI : a PHP process is launched by Apache, and it is that PHP process that interprets PHP code -- not Apache itself.
In theory, a distinct PHP process has to be created for each request -- which makes things slower : Apache has more work to do to answer a request.
(Well, as pointed out by #AlReece45 in a comment, this can be made better using FastCGI)
When using PHP as an Apache module (mod_php, or mod_php5), the PHP interpreter is kind of "embedded" inside the Apache process : there is no external PHP process.
Which means :
No forking to answer a request (faster)
Better communication between Apache and PHP
Generally speaking, I would say that mod_php is the solution that's used the most.
Plain CGI requires process to be spawned for each request at the time of request.
mod_php requires you to use bloated apache instead of slick nginx or lighttpd. Besides, "better communication between Apache and PHP" mentioned by Pascal may harm apache (it harms anyone who develops in php!;-)).
FastCGI lets you separate php from the web server (possibly run it on the different host).
Also, php.net just released a vulnerability today where source code disclosure is possible if you are using mod_cgi to run PHP and your PHP version is older than PHP 5.3.12 or PHP 5.4.2.
http://www.php.net/archive/2012.php#id2012-05-03-1
Patch by upgrading or applying a mod_rewrite rule.