About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.


PHP Easter Eggs

I can never remember the PHP Easter egg strings, so I'm putting them in my blog. This probably isn't news to anyone, but here they are for reference:

  • PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 - PHP Credits
  • PHPE9568F34-D428-11d2-A769-00AA001ACF42 - PHP Logo
  • PHPE9568F35-D428-11d2-A769-00AA001ACF42 - Zend Logo
  • PHPE9568F36-D428-11d2-A769-00AA001ACF42 - Easter Egg

Here's an example usage:

http://php.net/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

The current Easter egg is Zeev's dog Scotch:

It used to be Stig's dog Nadia (thanks to Ilia for confirming this):

Here's another:

If you've been using PHP for a while, you probably remember this picture of Thies:

The logo displayed on a phpinfo() page uses the PHP logo string except on April Fool's Day (01 Apr), when it uses the Easter egg string instead, giving some people quite a surprise.

These strings are useful for determining whether a particular URL is a PHP resource. For example, 37signals (the creators of Ruby on Rails) use PHP for their web site:

http://37signals.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

They also use PHP for the web sites of Basecamp, Backpack, and even Ruby on Rails.

Note: If you want to find these in the source, they're in ext/standard/info.h. If you want to disable them, set expose_php to Off.

About this post

PHP Easter Eggs was posted on Sat, 04 Feb 2006. If you liked it, follow me on Twitter or share:

31 comments

1.Ian Van Ness said:

Does that really mean that 37signals use PHP for their site, or does it just mean that they have the PHP module active in their Apache install?

Sat, 04 Feb 2006 at 22:48:58 GMT Link


2.Chris Shiflett said:

Hi Ian,

Yes, it means they use PHP. These strings only work on PHP resources. I could have been a bit clearer by including the filename in the URL:

http://37signals.com/index.php

If you try these strings on a URL that isn't PHP, they won't work, even if the web server has PHP support.

Sat, 04 Feb 2006 at 23:10:56 GMT Link


3.Chris Shiflett said:

By the way, I see you live remarkably close to me. Many of my favorite restaurants are on 5th.

Sat, 04 Feb 2006 at 23:18:26 GMT Link


4.Davey Shafik said:

uh-oh, Ruby on Rails has been exposed. I guess they wrote the original site in PHP whilst developing RoR, which is understable.

Still, I saw the video, so if RoR is as cool as they make out, it should only take them 15 minutes to re-write it. Right?

- Davey

Sun, 05 Feb 2006 at 03:32:14 GMT Link


5.Joe said:

Wow. Why in the world would DHH be using PHP instead of ROR for their front pages?

Sun, 05 Feb 2006 at 05:55:19 GMT Link


6.Mike Naberezny said:

...because he gets a lot of hits and he's smart enough to use the right tool for the job?

My guess is that they needed to do some very simple things like includes and used a few tiny PHP scripts to do it because they needed high performance.

Sun, 05 Feb 2006 at 07:00:25 GMT Link


7.Joe said:

Actually, the right tool for the job would be Rails' caching, which is quite capable of high performance.

Sun, 05 Feb 2006 at 07:11:33 GMT Link


8.Mike Naberezny said:

This still requires loading the Rails base, which is a large body of intrepreted code. For high volume, the equivalent 4-5 lines of PHP for simple things like includes will always be much higher performance.

Ruby-on-Rails isn't the solution to every problem and liking it doesn't mean you have to frown on PHP. There will always be a large place in the world of PHP, especially for simple things that need to be fast. It's nice to know 37signals is pragmatic enough to recognize places where PHP makes more sense and apply it.

Sun, 05 Feb 2006 at 07:36:32 GMT Link


9.Ivo Jansch said:

Isn't that kind o fa leak? Apparently, my php sites can output stuff that I'm either not aware of and also that maybe unwanted.

Sun, 05 Feb 2006 at 09:01:54 GMT Link


10.Rob Allen said:

The 37Signals guys have commented before that there's no business value at the moment for them in reinventing the wheel for their support site/forum.

I'd guess that their home page falls into the same category.

PHP is a remarkably flexible language when it's cost-effective for a minor script on a static page and also cost-effective for a significant web-based application.

Sun, 05 Feb 2006 at 09:33:43 GMT Link


11.Luke Welling said:

Before Ivo or anybody else gets into a lather over the implications of this, keep in mind that there is a well documented way to disable PHP exposing its existence.

In your php.ini change

expose_php = On

to

expose_php = Off

As well as its documented function, removing the PHP credit from the header, it also disables the easter egg.

Presumably if the RoR people were embarassed to be using PHP, they would have at least done the obvious and changed the filename extensions of their web pages. If they were embaressed and vigilant, they would presumably have also found the expose_php setting.

Sun, 05 Feb 2006 at 13:17:29 GMT Link


12.Joe said:

Mike Naberezny - Rails' page caching DOES NOT require loading of any Ruby code. They're straight-up static files, which don't get any faster.

Furthermore, in production environments, code is loaded ONCE with fastcgi/scgi.

Sun, 05 Feb 2006 at 19:06:39 GMT Link


13.Mike Naberezny said:

With Ruby-on-Rails' caching, the request has to go all the way through ActionPack before the cached content is served by Rails. That's a whole lot of Rails code (hundreds and hundreds of lines) that the Ruby intrepreter has to execute only to grab a static file in the end. My point wasn't the time it takes to load the Ruby interpreter itself or even compile all the Rails code into Ruby bytecode, it's executing all that Rails code every request.

On every request, PHP still goes through the same execution process but it has a very large advantage here of not needing to execute any kind of framework code at all. An embedded include() in the HTML is all the engine tokenizes and executes, and that is a native language construct performed by compiled C code. This is extremely fast.

PHP powers Yahoo!, the world's most trafficked website, for these reasons. Here's an interesting presentation from Michael Radwin of Yahoo!:

http://public.yahoo.com/~radwin/tal...oo-zend2005.pdf

For a handful of pages that are almost entirely static HTML, like the ones on the 37signals website, you don't need a whole framework like Ruby-on-Rails. Solutions like Apache SSI or a few lines of PHP include() are a lot simpler and will always be much higher performance. This is the same reason why I highly doubt you'll ever see really high traffic websites like Yahoo! or the adult industry move from PHP to Rails.

I think Ruby-on-Rails is a nice system for developing small- to medium-scale web applications. For dirt simple tasks like we're talking about and raw performance, it can't compete with PHP and isn't designed to do so. PHP was built from the first day to excel at this kind of work.

It's all about knowing your tools and where to apply them. Be pragmatic enough to keep a big toolbox and apply each tool where it is most appropriate. Otherwise, you are only limiting yourself and the potential for what you can do.

Sun, 05 Feb 2006 at 22:49:43 GMT Link


14.Chris Shiflett said:

Very funny, Davey. :-)

As Luke mentions, expose_php controls this, as I mentioned at the end of the entry. I guess I could have made this clearer, but I really just wanted to put these Easter egg strings in my blog, so I could easily find them. I actually use them sometimes to see if someone is actually using PHP when the file extension doesn't make it obvious.

Thanks for the details about Rails's caching, Mike.

Mon, 06 Feb 2006 at 01:11:36 GMT Link


15.Joe said:

Mike - Read my last post again. With page caching it DOES NOT have to load any Ruby, Rails, or other code.

Mon, 06 Feb 2006 at 03:19:53 GMT Link


16.Mike Naberezny said:

Flat files in the document root (Rails' page caching vs. action or fragment caching) are no different than building HTML offline and uploading to the server. Looking at their site again, I agree that it appears to be a good candidate since it's pretty bare. For pages that are totally static (not "mostly static"), this is always the best option.

However, there's some shortcomings to the Rails implementation of full page caching to consider. For example, GET and POST variables will go to the static HTML page and never get seen by Rails unless special .htaccess rules are written. More importantly, it breaks down quickly because it doesn't work as soon as any tiny bit of the page needs to change. Most sites do something very simple like display your username and a logout button on every page, even if the content is mostly static. In these cases, you're back to the original point.

Mon, 06 Feb 2006 at 06:21:21 GMT Link


17.Joe said:

Do you even use Rails, Mark? What are you talking about GET and POST vars going to static pages? Routing takes care of caching pages with GET vars, and why would you cache pages that are POST destinations...

Mon, 06 Feb 2006 at 07:32:34 GMT Link


18.Mike Naberezny said:

http://scottstuff.net/blog/articles...ion_with_params

Mon, 06 Feb 2006 at 08:14:16 GMT Link


19.Raevel said:

Still... does the fact that http://37signals.com/index.php works mean they use php, or might they have a mod_rewrite? index.php is common so I'm guessing it could be useful to rewrite it to the real index file just in case? Might be a long shot, but hey!

Mon, 06 Feb 2006 at 12:23:47 GMT Link


20.Nico Edtinger said:

For me it's much easier to just look at the headers instead of looking for the UID for the image link. You even get the exact version of PHP a site is using - i.e. 37signals:

X-Powered-By: PHP/4.3.5

Both, the header and the easter eggs, are turned on and off with the expose_php option.

Mon, 06 Feb 2006 at 12:27:16 GMT Link


21.Darren said:

I like the comment about every page request requires ruby to be loaded!!! I'm not an expert but even I read _some_ of the documentation.

Btw does PHP have builtin page caching now?

Mon, 06 Feb 2006 at 12:29:04 GMT Link


22.Chris Shiflett said:

Raevel, yes, it means they use PHP. Even if they wanted to create a file called index.php that wasn't really PHP, it wouldn't display the Easter egg when passed that string. That's the point - only PHP does that.

Nico, the Server and X-Powered-By headers only describe the web server's capabilities and are no indication that a particular resource necessarily uses PHP.

Darren, keep reading. :-) Mike provided a link that might help.

Mon, 06 Feb 2006 at 13:58:05 GMT Link


23.Reiner said:

Use the right tool for the job. PHP for the simple Things in Life, and RoR for advanced Applications :-).

Mon, 06 Feb 2006 at 16:40:25 GMT Link


24.Chris Shiflett said:

Reiner, you might be interested in this:

http://shiflett.org/archive/190

I understand your excitement for Ruby on Rails, but your blind loyalty and hollow rhetoric does not promote it. More importantly, good applications are built by good developers, not technologies.

Mon, 06 Feb 2006 at 16:50:06 GMT Link


25.maximus said:

37signals are using Python as well. Chris what are you trying to prove?

You wasting time, instead of working on Zends framework a.k.a vapourware.

I wonder how much code have you actually written at that point? http://blog.joshuaeichorn.com/archives/2006/01/09/zactiverecord-cant-work/.

Tue, 07 Feb 2006 at 00:13:57 GMT Link


26.Chris Shiflett said:

Maximus, go troll somewhere else. Your deduction skills are poor if you think the point of this entry has anything to do with RoR.

Tue, 07 Feb 2006 at 00:39:38 GMT Link


27.Nico Edtinger said:

No Chris. You're right with the Server header. But the X-Powered-By is only send if a resource is served by PHP. You can see it on your own page here. Only /archive/191 has a X-Powered-By header. All of the CSS stuff or images doesn't.

You could also read the source - it's in main/main.c in php_request_startup(), thus as long as PHP is not used for serving a resource the header is not set.

Wed, 08 Feb 2006 at 15:22:27 GMT Link


28.Chris Shiflett said:

Good point, Nico. Thanks.

Wed, 08 Feb 2006 at 16:46:16 GMT Link


29.Antonio Ognio said:

Hey, Chris ain't trying to prove anything other than they are actually using PHP for their homepages for some reason. It's all of it. I guess is is not any goog PR to do it counting on the obvious reaction of many people but hey, it at least proves that PHP is quite good to at least make it there and not get urgently removed in favor of their own thing.

Mon, 13 Feb 2006 at 05:42:16 GMT Link


30.Jason Garber said:

I asked the good folks over at 37signals about their use of PHP. They responded, "We've been running PHP on our web sites since 2000 or so to do simple includes. It simple, it works, everyone knows how to use it, so there's no reason to change."

Makes perfect sense to me.

Tue, 27 Jun 2006 at 03:50:21 GMT Link


31.Jenn Weller said:

Wow, this is honestly an eye-opener, an eye-popper, an eye-something! I know it makes sense that anybody using Ruby would use Php for other things, but I mean THE CREATORS? Is like God drinking tap water.

Jenn

Ruby on Rails Professionals

Fri, 07 Dec 2007 at 22:31:25 GMT Link


Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.