This is as of PHP 5.4.0 RC6 (NEWS). Note that I didn't put in anything related to OO, as I despise the obsession with OO now in PHP and do my best to live without it.

Misc. notable changes:

• Added built-in web server that is intended for testing purpose. (Moriyoshi)
• Changed default value of "default_charset" php.ini option from ISO-8859-1 to UTF-8. (Rasmus)
• Added array dereferencing support. (Felipe)
• Added header_register_callback() which is invoked immediately prior to the sending of headers and after default headers have been added. (Scott)
• Changed http_response_code() to be able to set a response code. (Kalle)
• Added new json_encode() option JSON_PRETTY_PRINT. FR #44331. (Adam)
• Changed silent conversion of array to string to produce a notice. (Patrick)
• Removed support for putenv("TZ=..") for setting the timezone. (Derick)
• Removed the timezone guessing algorithm in case the timezone isn't set with date.timezone or date_default_timezone_set(). Instead of a guessed timezone, "UTC" is now used instead. (Derick)
• ext/mysql, mysqli and pdo_mysql now use mysqlnd by default. (Johannes) )I think this is in 5.3 though too?)
• Expose session status via new function, session_status (FR #52982) (Arpad)
• Added support for storing upload progress feedback in session data. (Arnaud)

PHP-FPM related:

• Remove EXPERIMENTAL flag. (fat)
• Added partial syslog support (on error_log only). FR #52052. (fat)
• Lowered default value for Process Manager. FR #54098. (fat)
• Enhance security by limiting access to user defined extensions. FR #55181. (fat)
• Added process.max to control the number of process FPM can fork. FR #55166. (fat)
• Dropped restriction of not setting the same value multiple times, the last one holds. (giovanni at giacobbi dot net, fat)

Removed legacy features:

• Safe mode and all related ini options. (Kalle)
• register_globals and register_long_arrays ini options. (Kalle)
• import_request_variables(). (Kalle)
• allow_call_time_pass_reference. (Pierrick)
• Session bug compatibility mode (session.bug_compat_42 and session.bug_compat_warn ini options). (Kalle)
• session_is_registered(), session_register() and session_unregister() functions. (Kalle)
• y2k_compliance ini option. (Kalle)
• Removed magic_quotes_gpc, magic_quotes_runtime and magic_quotes_sybase ini options. get_magic_quotes_gpc, get_magic_quotes_runtime are kept but always return false, set_magic_quotes_runtime raises an E_CORE_ERROR. (Pierrick, Pierre)

The project is here: https://code.google.com/p/phpreboot/

Why is this an issue? Well, for one, it's NOT A REBOOT OF PHP. It's a frickin' Java-based re-implementation of some PHP ideas and function names with a completely different syntax, and at the end of the day, it has 99.9% nothing in common with PHP.

Why do people develop in PHP? Because it is PHP. Stop trying to make PHP more like Java, more JSON-y, etc. Why did it become the world's most popular language? Besides for being easy to pick up (too easy, sometimes, which leads to a bunch of garbage and unsecure code), it got there because of what it is.

This "php.reboot" project is just trying to use PHP's popularity and function names to get people to check it out. PHP doesn't have XML/JSON/SQL style constructs (although the new array syntax sure does look like an attempt to emulate JSON, cough), it has structure - that's what "$" and ";" are for - denoting specific constructs in the language. If people don't want to develop using "$" or ";" go switch to another language that doesn't, that is already established.

I am tired of seeing blog posts and other items pop up every so often "why PHP wants to be more like Java" or "10 things PHP can learn from Ruby" - if you're trying to adapt PHP to another language, just use the other language. Period.

Some of the ideas in this project might be neat, or good; but in the end, it's not a "reboot of PHP" and stop labeling it as one.

I, for one, am excited to see things like a roadmap and making it easier for contributors to help out.

Read Igor's post here.

He hasn't setup a web-based SVN option yet (cough, cough, I bet it would be if nginx supported SVN's DAV needs ) - but you can hit it up using a native SVN client: svn://svn.nginx.org - note, I would only grab "/nginx/trunk" as otherwise you'll get a few years worth of code, if not the entire nine years.

At first I thought this was a joke, seeing the announcement for 1.0.0 - sounds like it just started. But one must remember, he's always used pre-1.0 for past versions.

Update:

MTecknology maintains a PPA and has already built a package for 1.0.0. The quick and dirty method to update:

apt-get install python-software-properties
add-apt-repository ppa:nginx/stable
apt-get update

This will provide you a handful of new packages, by default the "nginx" package is a dummy package that will provide "nginx-full" and should be the only one you really need to care about.

nginx-dbg - Debugging symbols for nginx
nginx - small, but very powerful and efficient web server and mail proxy
nginx-common - small, but very powerful and efficient web server (common files)
nginx-doc - small, but very powerful and efficient web server (documentation)
nginx-extras - nginx web server with full set of core modules and extras
nginx-extras-dbg - Debugging symbols for nginx (extras)
nginx-full - nginx web server with full set of core modules
nginx-full-dbg - Debugging symbols for nginx (full)
nginx-light - nginx web server with minimal set of core modules
nginx-light-dbg - Debugging symbols for nginx (light)

I didn't really need this to do much. The code is simple and there is no UI to manage it, but it works, and even gives you cute little X-Redirect headers to let you know if it was executed and if it found a match. It would be easy enough to take that if() out and have it check any URL (just be sure to remove the fallback )

function foo_init() {
    if(stristr($_SERVER['REQUEST_URI'], '.php') || stristr($_SERVER['REQUEST_URI'], '.htm')) {
        $old = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
        $new = db_result(db_query("SELECT new_url FROM custom_redirect WHERE old_url = '%s'", $old));
        if($new) {
            watchdog('foo', $old.' found in the custom_redirect table', NULL, WATCHDOG_INFO);
            header('X-Redirect: Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].$new, '', '', 301);
        } else {
            watchdog('foo', $old.' NOT found in the custom_redirect table', NULL, WATCHDOG_ERROR);
            header('X-Redirect: Not Found');
            drupal_goto('http://'.$_SERVER['HTTP_HOST'].'/', '', '', 302);
        }
    }
}

The table?

CREATE TABLE custom_redirect (
  old_url varchar(150) NOT NULL,
  new_url varchar(150) NOT NULL,
  PRIMARY KEY (old_url)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Enjoy. Totally could have Drupal'ed that up and made a hook_install() for the schema too, right? :p

I didn't do the math, but it would have probably taken over 10-15 hours to restore the database from the mysqldump. There's a couple easy tweaks I did not use. For one, I used --skip-opt and made my mysqldump files full INSERT statements (for verbosity and the ability to "diff" them if I ever needed to) - this was stolen from a backup script I wrote.

If you read the documentation/blogs, it says to use --opt when running mysqldump for faster imports. Well, duh! While I was at it, I also tweaked a couple other things. Right now it is moving MUCH faster. What did I do?

• On the source, I used mysqldump --opt (it seemed to dump the database faster too)
• On the destination, I set innodb_flush_log_at_trx_commit to "0" in my.cnf for the time being. This server isn't used yet, so that's safe.
• I also put "SET AUTOCOMMIT=0;" at the top of the script, and "COMMIT;" at the bottom of the script. I don't need any commits until the end, this is a fresh import.

The results are not very scientific, but here's how it breaks down so far (still in the middle of the process)

• Without these tweaks, at 107 minutes it was only at 2.2gb out of 13gb.
• Without these tweaks, at 12 minutes it was at 4.5gb out of 13gb.

I think this will save my bacon, I wish I had done this sooner and not wasted that two hours originally. Someone in #mysql recommended I look at XtraBackup, but it seemed like too much to learn and attempt my first run at it while I was having to do a  production migration.

This is cool, and I wasn't sure it actually got in a build or not, I remember it was mentioned or discussed, but sure enough, Jérôme coded it and got it in to FPM in core. So it is available to all, and he welcomes the feedback - see this thread on the nginx mailing list.

Due to limitations in the FastCGI protocol, you have to pass all the parameters you want as a single string, separated by "\n" - it's not the cleanest looking configuration, but that's how it is for now. I spitballed a different approach to it, but at the moment I believe it will be unlikely to get adopted.

If you're like me, you're probably looking for the code samples almost immediately. Here's your examples. Note that PHP_VALUE and PHP_ADMIN_VALUE are both legitimate keys, the difference being that PHP_ADMIN_VALUE does not allow the user to override the value using ini_set() - see the manual for more infomation.

Single value:

fastcgi_param PHP_VALUE sendmail_from=direct@prout.com;

Multiple values, manually line-broken:

fastcgi_param PHP_VALUE "sendmail_from=chroot@prout.com
precision=42";

Multiple values, with the \n in there to clearly call it out:

fastcgi_param PHP_VALUE "sendmail_from=chroot@prout.com \n precision=42";

More information is available in the feature request on the PHP bug tracker.

Due to the fact that their service always uses over 100 megs of RAM, and seems to continuously get stuck on certain files, I was planning on getting rid of it soon. Today's announcement made this decision even easier though, as now they've decided to go the way of other companies with tiered pricing models. With how cheap technology continuously gets, any company marking prices up really pisses me off.

So, I give a profane salute to you, Mozy, as you have now joined the ranks of companies I feel personally displeased with, and definitely will not recommend (not that I really did anyway.)

Even AT&T (one of the main companies I despise) let people grandfather in their unlimited plans, and cell networks take a lot more beating than a backup service with hard drive prices going down every day. Adding more servers to a rack is a lot harder than adding cell tower capacity. That type of "next month you'll be forced to change" does not sit well with me.

Dear Michael,

Thanks for being a valued Mozy subscriber. For the first time since 2006, we're adjusting the price of our MozyHome service and wanted to give you a heads up. As part of this change, we’re replacing our MozyHome Unlimited backup plan and introducing the following tiered storage plans:

50 GB for $5.99 per month (includes backup for 1 computer)
125 GB for $9.99 per month (includes backup for up to 3 computers)

You may add additional computers (up to 5 in total) or 20 GB increments of storage to either of the plans, each for a monthly cost of $2.00.

While this policy takes effect for new MozyHome customers starting today, your MozyHome Unlimited subscription is still valid for the duration of your current monthly term. In order to ensure uninterrupted service, you'll need to select a new renewal plan.

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">google.load("jquery", "1.4");</script>
<script type="text/javascript">google.load("jqueryui", "1.7.2");</script>