12 ms·

Facebook PHP Source Code from August 2007

319 points by scapbi 13y ago

pearjuice 13y ago
I really hope they cleaned that mess up or I feel very sorry for all the developers at Facebook. >ini_set('memory_limit', '100M'); // to be safe we are increasing the memory limit for search >tpl_set('simple_orientation_first_login', $get_o); // unused right now >// We special case the network not recognized error here, because affil_retval_msg is retarded. >all those undocumented(?) random error codes >mix between ternary operators and regular if/else statements with no logical choice between one or the other >no auto loading whatsoever Seeing as this is from 2007, there is hope.
- Kiro 13y ago
  What's wrong with increasing the memory limit?
  - dxm 13y ago
    That's an abnormally high memory limit for what should be a simple request.
  - iand 13y ago
    A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
    - Kiro 13y ago
      It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?
      - nwh 13y ago
        I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?
        robryan 13y ago
        They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.
        nwh 13y ago
        That sounds grossly ineffective. Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.
        encoderer 13y ago
        Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum. If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes. Based on your comments in this thread you're out of your depth, man.
        nwh 13y ago
        I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.
        AaronIG 13y ago
        I think Kiro meant 500, as in the HTTP status code, due to PHP running out of memory, not 500MB.
      - nilved 13y ago
        Yes
      - mratzloff 13y ago
        Guess what happens when a lot of people search.
    - blowski 13y ago
      It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.
      - Kiro 13y ago
        It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.
        asdasf 13y ago
        It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.
        MichaelGG 13y ago
        By that logic, no one runs any programming languages, since they all get translated to x64 or other instruction sets.
        asdasf 13y ago
        That makes no sense at all. The function in question sets the memory limit for the PHP interpreter. A specific piece of software. Facebook does not use that specific piece of software.
        MichaelGG 13y ago
        Your comment was ambiguous then. It sounded like your logic was "they don't run PHP because they wrote their own implementation"... which is still running PHP. I think you meant to say they're not running the normal PHP interpreter, so that particular functional call might not be implemented (but it could be, still...).
fela 13y ago
line 72: // Holy shit, is this the cleanest fucking frontend file you've ever seen?!
- mproud 13y ago
  My favorite line, too.
triton 13y ago
This is quite neat compared to the average shitfest people leave inside wordpress templates. I had to unpick a whole 200 page intranet written with wordpress and buddypress (which stinks) recently and rewrite it as a non-wordpress site as it's hit the inevitable hack brick wall. It's now an asp.net mvc app on Azure. There's hardly any code in it now and a the page response times are down at 50ms rather than 1500ms! One query per page vs 400 as well.
- FireBeyond 13y ago
  Exaggeration is the mother of ... well, something. An entire intranet functionality with one SQL query per page. Right, okay...
nilsjuenemann 13y ago
I remeber these days. I worked at this time for studiVZ - a german social network (still exist, but nobody is using it anymore) and this leaked was caused by a misconfiguration in their Apache setup. In 2008 studiVZ was sued by Facebook. They said we theft their PHP, CSS/JS "code". (http://techcrunch.com/2008/07/18/facebook-sues-german-social-network-studivz/ http://techcrunch.com/2008/07/18/facebook-sues-german-social...). Indeed, the first version of studiVZ was inspired by Facebook. Our founder had seen FB in 2005 the first time in the US, but it wasn't possible to use the service without a .edu eMail account. That was the decision to make a local clone. But the real story behind the lawsuit is a bit longer. In december 2006 Facebook tried to acquire studiVZ the very first time. This picture with two of the studiVZ founder and some people from FB's management team is from this time: http://img-a4.pe.imagevz.net/photo3/f3/9a/ce37499d84437cb744c1dbce2a78/1-cfd8a99fbccfa5cc.jpg http://img-a4.pe.imagevz.net/photo3/f3/9a/ce37499d84437cb744... But FB hadn't the amount of cash to aquire the company. The Holtzbrinck Publishing Group aquired studiVZ later for 85 mio. € In 2008 (before the lawsuit) FB tried the second time to acquire studiVZ - this time for 4,8% of shares! But this deal didn't happend - unfortunately.
- kayoone 13y ago
  Cool, i remember these days as well. Indeed it very much looked like StudiVZ just used FBs css filed and changed some colors.. It was a typical german clone success story. Dariani did a lot of questionable things but sold in the right time before the downfall of VZ. I didnt really like it, they basically did nothing in terms of innovation that FB did, it had the same features for years. Later they had a half-assed app platform that never really took off. It was just a blatant rip-off like so many german startups, sadly.
  - nilsjuenemann 13y ago
    We had to solve scaling issues most of the time. VZ was running on a multi-tier platform with services written in Java, PHP, Erlang, C++ and Python. 17 million users with around 25 billion requests per month (without static content)... Some numbers from 2010: - 60.000 req/s (without static content) - 2.5 mio. memcache ops/s - 300k queries to the database tier We've built that platform with a team of around 20-30 engineers and we had to solve the scaling stuff first - before we could add new features to the platform. Today it's easy to store 3 billion files (photos). You could easily use S3, but 2007 these services didn't exist or most of the cloud services just started with their services.
javis 13y ago
When I see code like this, I'm always amazed that I can actually read it and (kinda) understand what it's doing. I always expect code like Facebook's to be so finely tuned and advanced that it'd be completely uninteligable to those outside the company and not an expert in the language.
- Kiro 13y ago
  In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.
  - nwh 13y ago
    Doesn't quite hold true once you get done to hand written and optimised binaries though. There's no way of making assembly easily readable to everyone, no matter how relaxed the developer.
    - moconnor 13y ago
      Hand-written assembly can be just as readable as any other language. See https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/01%20POP%20Source/Source/FRAMEADV.S https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/m... for a good example!
  - moconnor 13y ago
    Or over-generalized with the logic split up and hidden in the interactions between a dozen (sub)classes.
    - oneeyedpigeon 13y ago
      Or under-generalised with the logic duplicated in a dozen places, ever-so-slightly differently
- Joeri 13y ago
  Actually, a large codebase can be reasonably expected to live 20 years. Over that time with a lowish 10% turnover you'll replace the entire programming staff twice, so the understanding people have of the code is not just hearsay, but hearsay of hearsay. The sheer size of the codebase (facebook has tens of millions of lines of code) means that practically speaking you can't program your way out of a corner once you get there. That is (partly) what killed facebook's competitors. The solution to all of this is to be ruthless about simplifying code. The goal of new code should first and foremost be to be maintainable. Clever code is the enemy of scaling a programming team. Not that you don't need clever code, but you isolate it and protect it and make sure the average team member doesn't have to look at it.
Kiro 13y ago
I don't think it looks that bad. It's clean and easy to understand.
deleted 13y ago
[deleted]
a1a 13y ago
I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.
- pestaa 13y ago
  ... unless your users actually care about messages being delivered, whatever being reported as saved being truly saved, et cetera... There is a whole world out there where people want to rely on software to do what it says it does. I know Facebook can live in its own bubble and get away with every possible stupid bug a messy PHP spaghetti causes.
  - Encosia 13y ago
    I remember listening to an interview with Markus from Plenty of Fish, where he essentially said that he didn't worry too much about site errors because most unsophisticated users would attribute them to things like their ISP, browser (if they knew what that was), or their own error more often than to the site itself. Personally, I can't bring myself to not care like that, but it seems to have worked pretty well in the early days of many now-popular sites. Especially in 2007, when Facebook was still in real competition with MySpace, moving as quickly as possible was probably much more important than a few messages dropping through the cracks.
    - pestaa 13y ago
      I must admit my comment was unneccessarily bitter, but my observation is completely different. Many friends and family members are now seeing data loss on Facebook weekly at least. I wouldn't call them tech savvy either, yet they can attribute the issue to Facebook, after having learnt the simplest basics of how the web should actually work.
      - jafaku 13y ago
        That's probably by design. Would you prefer one unimportant message lost here and there, or be able to handle 1/1000 of the current traffic to make sure every single message is delivered?
jwdunne 13y ago
Hehe, these lines made me chuckle. // Holy shit, is this the cleanest fucking frontend file you've ever seen?! ubersearch($_GET, $embedded = false, $template = true); In all seriousness though, I wonder how much of this was written by Mark Zuckerberg?
- jonknee 13y ago
  With the header "@author Mark Slee" on that file, I doubt much if any.
- filipedeschamps 13y ago
  I don't know why, but I always love comments more than code itself.
alecsmart1 13y ago
This looks weird in search.php (line 89): if($user 0 && !is_unregistered($user)) { return $user; }
- RossM 13y ago
  This is either a syntax error or a HipHop idiosyncrasy (was HHVM in use in 2007?) $ php -r '$user = null; if ($user 0) { echo $user; }' PHP Parse error: syntax error, unexpected '0' (T_LNUMBER) in Command line code on line 1
  - vezzy-fnord 13y ago
    I don't think even HPHPc was around in 2007. Development didn't begin until 2008, IIRC.
- TazeTSchnitzel 13y ago
  I'd hazard a guess that should be: $user <> 0 Which, of course, would not display if someone had originally pasted this code straight into an HTML page without escaping it. EDIT: Looks like it would show up. I wonder, then, if the <>s has been stripped. Some poorly written websites do that.
- deleted 13y ago
  [deleted]
EGreg 13y ago
This is why I was saying evented webserver code is better. Look at how much I/O is happening one after the other. The latency could be greatly reduced by doing things in paralel and waiting until all the promises resolve.
- camus 13y ago
  requiring scripts in PHP in not "IO". There is not much IO happening in these script.
m0th87 13y ago
Does anyone else remember the friend graph visualization feature facebook used to have? It was an oddity, both because it seemed like a strange but useful feature, but also because it was a perl script. One time I clicked it and got the source code to the file instead of the graph. It's somewhere on one of my hard drives, but it seems wrong to leak, especially since it has database credentials hard-coded into it.
- TazeTSchnitzel 13y ago
  I wonder if it was based on the code Zuckerberg used for the Java friend graph he had on his homepage prior to Facebook. Could you perhaps censor the credentials and release it?
  - m0th87 13y ago
    I am not a lawyer, but even with censored credentials this seems like a bad idea. Especially since my profile is not exactly anonymous. Any Facebook employees want to get me a green light? :)
    - jeff_facebook 13y ago
      Hi, I'm Jeff from the Facebook legal team. We were discussing this today and decided it's fine for you post it. Go right ahead.
    - KatherineJMoses 13y ago
      uptil I looked at the receipt which had said $9272, I didn't believe that my mom in-law woz realie bringing in money in there spare time on there computar.. there friends cousin haz done this 4 only about eighteen months and recently cleard the mortgage on their place and bourt a great opel. additional info ========================== http://WWW.WORKS23.COM http://WWW.WORKS23.COM
- minifig 13y ago
  managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not list the creator as harvard // keep track of tuna contexts // Merman's Admin profile always links to the Merman's profile // NOTE: ok, at this point we know we are going to display the full // page, so it is time to do a PHATTY PHATTY MULTIGET of all the shit that // we are going to need to make this page, or at least the most common things // Clear fire if desired
lifeformed 13y ago
How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...
- MitziMoto 13y ago
  Sounds like it was an "accident". The web server served up the source code rather than compiling the PHP, which someone then saved.
- bouk 13y ago
  I think it was a glitch in Apache that made it spill out the sourcecode
- 0x0 13y ago
  It can happen if you upgrade Apache and/or mod_php, and for some reason mod_php fails to register for .php files without being a fatal startup error. Then apache will serve the .php files as plaintext. It's one of the things that make one-off .php scripts easy to deploy (just chuck it into the webroot). With a little effort, this can be mostly prevented: let the webroot .php file just do an ' include("../outside-webroot/actual-script.php"); '
- vezzy-fnord 13y ago
  Another possibility is some quirk in the file permissions, .htaccess or some other configuration file, which could lead to vulnerabilities like HTTP verb tampering. It may have been more subtle, but of a similar nature.
- smsm42 13y ago
  They misconfiguring apache to serve php as text file instead of being processed by php engine. One missing line in apache config can do that. It didn't last long, but of course people saved every bit that was leaked this way. Which is mostly entry points of course.
conradfr 13y ago
I don't remember from the site at the time what "monetization_box.php" would have been doing. Also, my style of comments seem so tame and lame now :)
deleted 13y ago
[deleted]
ErikAugust 13y ago
Pre-PHP 5.3 -> Right off the bat: no namespace support, no closures, no surprises there I am a bit surprised about the lack of OO though...
elwell 13y ago
From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue)." Does anyone know what he is referring to when he says this can happen via high load?
- smsm42 13y ago
  It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the idea tha Facebook is a high load site (true) and they couldn't just have made as obvious screwup as misconfiguring a production server (false) so it must be apache/php bug that happens only in high load sites (false)
  - nikcub 13y ago
    this was a real issue, here is the bug: https://bugs.php.net/bug.php?id=26810 https://bugs.php.net/bug.php?id=26810 there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.
    - deleted 13y ago
      [deleted]
    - smsm42 13y ago
      That issue was fixed 3 years before (Jan 2004) and from what I can see only happened in configs which use +x bit or config values to turn php engine on and off, and didn't really depend on load on these too much either - it's just load made it more probable you will hit the right sequence in the same process randomly, but if you know what to hit, it could be done on any load. So it would be correct to say "there was a bug 3 years ago which in certain configurations made mod_php serve source after certain sequence of requests". It was never happening just "due to high load", as far as I can see. And as far as I know (and nobody so far presented any evidence to the contrary, AFAIK) Facebook case had nothing to do with it anyway. It would be really weird for Facebook to run random 3-years-old PHP in production too.
elwell 13y ago
index.php line 130: foreach($upcoming_events as $event_id = > $data) { Space between "=>"...
mkhalil 13y ago
Anyone who calls this bad/spaghetti code hasn't seen bad code.
joshaidan 13y ago
I like the variable naming in the code. It's good that they didn't use one/two letter variables that span more than five lines of code. Short, meaningless variables names--used for things other than index values is one of my big pet peeves. I had to use somebody else's code as the base for a project and it was full of two letter variables that didn't mean anything. Gave me a big headache working on it.
- tannerc 13y ago
  Seriously, some of these variables are named so elegantly it's actually a little surprising. Beginning developers could learn a thing or two looking over code like these (even though it's now clearly outdated and likely defunct). I've been programming for half a decade and my naming conventions are still horrid.
rohanpai 13y ago
A startup with spaghetti code of this stature will NEVER be successful.
lucasnemeth 13y ago
People just call this spaghetti for superficial reasons, they don't see objects and they don't see current PHP practices used in 2013. But it is readable and maintainable code. We're out of context, and there is nothing there to assume lack of quality. Some people mistake code with literature, objectively speaking this is not bad code.
whalesalad 13y ago
The code looks pretty clean. I dig the two-tab spacing as well, but perhaps that was done after the fact. Anyhow, not sure if this makes any difference or not but i'm curious as to why true PHP constants are not used, and instead regular variables in all caps like $PARAM_INT are used. Anyone know why this might be? I ask because one of you PHP-gurus might inform me that there are certain use-cases where a true constant is not wise. An example below: param_get_slashed(array( 'feeduser' = > $PARAM_INT, //debug: gets feed for user here 'err' = > $PARAM_STRING, // returning from a failed entry on an orientation form 'error' = > $PARAM_STRING, // an error can also be here because the profile photo upload code is crazy 'ret' = > $PARAM_INT, 'success' = > $PARAM_INT, // successful profile picture upload 'jn' = > $PARAM_INT, // joined a network for orientation 'np' = > $PARAM_INT, // network pending (for work/address network) 'me' = > $PARAM_STRING, // mobile error 'mr' = > $PARAM_EXISTS, // force mobile reg view 'mobile' = > $PARAM_EXISTS, // mobile confirmation code sent 'jif' = > $PARAM_EXISTS, // just imported friends 'ied' = > $PARAM_STRING, // import email domain 'o' = > $PARAM_EXISTS, // first time orientation, passed on confirm 'verified' = > $PARAM_EXISTS)); // verified mobile phone
- eksith 13y ago
  I'm not a PHP-guru, but it's entirely possible that they're playing around with some background configurations that would make performance tweaks in some sections of the code difficult if they're defined variables. I guess this is an implementation of a semi-defined variable. It should probably be noted that there may be a tiny bit of performance improvement when calling isset instead of defined when checking for variable set. I'm not sure if that's one of the considerations since it would definitely be a case of premature (and ultimately pointless) optimization anywhere else, but since it's Facebook, they may have gone that far to squeeze every bit out of it they can.
- dools 13y ago
  They might be simple input validation filters created using the create_function() function which allowed you to create anonymous functions of sorts in PHP prior to 5.3. You can't assign an anonymous function to a constant. An alternative would have been to include a big switch statement in the param_get_slashed() function but since the same validators are used in a bunch of places it seems cleaner to use anonymous functions and have each function that uses them loop through and call each function passing the parameter named in the array key in as an argument
jmadsen 13y ago
There seems to be, here & on the "interverse", a battle on whether it will be more more hip to call this spaghetti code or to call it clean code. I don't see very much debate on whether or not it is GOOD code. It isn't good code. It is cleanly written, especially for the time. But all the noise about how bad it is isn't "hipster" talk - this is 400+ lines of completely unmaintainable code; which is why it isn't part of the current code base. As soon as they got some money & started trying to make it do more, they wised up and dumped it
fingerprinter 13y ago
The comments on github are akin to 'my eyes! they bleed', but tbh, this is actually quite readable and I imagine wouldn't be all that hard to maintain. I haven't touched PHP since about 2007 and it seems like it would be pretty easy to jump in and start making changes and edits. It is well templated, seems to use variables well and not have too many (if any, didn't look all that closely) hard-coded values. I've seen much, much worse in "cleaner" languages than this. As a side note. I learned a lesson in my early 20s that has served me well to today. Shipped code always wins. I was a huge proponent (and still am) of good code, well architected blah blah blah. But, in the end, if your code never sees the light of day, it doesn't matter. I saw this when I took over a team responsible for care and feeding of a product originally written by the founder of a company. This company had just secured a series B on the original code (still). The product was ugly, the code was terrible, it was slow, it wouldn't scale, couldn't be configured and really couldn't be maintained. However, it got the company moving, got a series A & B, secured the first customer, and a second. It basically created a runway to build the thing right that wouldn't have been available had it not gone live.

319 points by scapbi 13y ago

I really hope they cleaned that mess up or I feel very sorry for all the developers at Facebook. >ini_set('memory_limit', '100M'); // to be safe we are increasing the memory limit for search >tpl_set('simple_orientation_first_login', $get_o); // unused right now >// We special case the network not recognized error here, because affil_retval_msg is retarded. >all those undocumented(?) random error codes >mix between ternary operators and regular if/else statements with no logical choice between one or the other >no auto loading whatsoever Seeing as this is from 2007, there is hope.

Kiro 13y ago
What's wrong with increasing the memory limit?
- dxm 13y ago
  That's an abnormally high memory limit for what should be a simple request.
- iand 13y ago
  A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)
  - Kiro 13y ago
    It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?
    - nwh 13y ago
      I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?
      - robryan 13y ago
        They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.
        nwh 13y ago
        That sounds grossly ineffective. Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.
        encoderer 13y ago
        Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum. If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes. Based on your comments in this thread you're out of your depth, man.
        nwh 13y ago
        I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.
        AaronIG 13y ago
        I think Kiro meant 500, as in the HTTP status code, due to PHP running out of memory, not 500MB.
    - nilved 13y ago
      Yes
    - mratzloff 13y ago
      Guess what happens when a lot of people search.
  - blowski 13y ago
    It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.
    - Kiro 13y ago
      It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.
      - asdasf 13y ago
        It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.
        MichaelGG 13y ago
        By that logic, no one runs any programming languages, since they all get translated to x64 or other instruction sets.
        asdasf 13y ago
        That makes no sense at all. The function in question sets the memory limit for the PHP interpreter. A specific piece of software. Facebook does not use that specific piece of software.
        MichaelGG 13y ago
        Your comment was ambiguous then. It sounded like your logic was "they don't run PHP because they wrote their own implementation"... which is still running PHP. I think you meant to say they're not running the normal PHP interpreter, so that particular functional call might not be implemented (but it could be, still...).

fela 13y ago

line 72: // Holy shit, is this the cleanest fucking frontend file you've ever seen?!

mproud 13y ago
My favorite line, too.

triton 13y ago

This is quite neat compared to the average shitfest people leave inside wordpress templates. I had to unpick a whole 200 page intranet written with wordpress and buddypress (which stinks) recently and rewrite it as a non-wordpress site as it's hit the inevitable hack brick wall. It's now an asp.net mvc app on Azure. There's hardly any code in it now and a the page response times are down at 50ms rather than 1500ms! One query per page vs 400 as well.

FireBeyond 13y ago
Exaggeration is the mother of ... well, something. An entire intranet functionality with one SQL query per page. Right, okay...

nilsjuenemann 13y ago

I remeber these days. I worked at this time for studiVZ - a german social network (still exist, but nobody is using it anymore) and this leaked was caused by a misconfiguration in their Apache setup. In 2008 studiVZ was sued by Facebook. They said we theft their PHP, CSS/JS "code". (http://techcrunch.com/2008/07/18/facebook-sues-german-social-network-studivz/ http://techcrunch.com/2008/07/18/facebook-sues-german-social...). Indeed, the first version of studiVZ was inspired by Facebook. Our founder had seen FB in 2005 the first time in the US, but it wasn't possible to use the service without a .edu eMail account. That was the decision to make a local clone. But the real story behind the lawsuit is a bit longer. In december 2006 Facebook tried to acquire studiVZ the very first time. This picture with two of the studiVZ founder and some people from FB's management team is from this time: http://img-a4.pe.imagevz.net/photo3/f3/9a/ce37499d84437cb744c1dbce2a78/1-cfd8a99fbccfa5cc.jpg http://img-a4.pe.imagevz.net/photo3/f3/9a/ce37499d84437cb744... But FB hadn't the amount of cash to aquire the company. The Holtzbrinck Publishing Group aquired studiVZ later for 85 mio. € In 2008 (before the lawsuit) FB tried the second time to acquire studiVZ - this time for 4,8% of shares! But this deal didn't happend - unfortunately.

kayoone 13y ago
Cool, i remember these days as well. Indeed it very much looked like StudiVZ just used FBs css filed and changed some colors.. It was a typical german clone success story. Dariani did a lot of questionable things but sold in the right time before the downfall of VZ. I didnt really like it, they basically did nothing in terms of innovation that FB did, it had the same features for years. Later they had a half-assed app platform that never really took off. It was just a blatant rip-off like so many german startups, sadly.
- nilsjuenemann 13y ago
  We had to solve scaling issues most of the time. VZ was running on a multi-tier platform with services written in Java, PHP, Erlang, C++ and Python. 17 million users with around 25 billion requests per month (without static content)... Some numbers from 2010: - 60.000 req/s (without static content) - 2.5 mio. memcache ops/s - 300k queries to the database tier We've built that platform with a team of around 20-30 engineers and we had to solve the scaling stuff first - before we could add new features to the platform. Today it's easy to store 3 billion files (photos). You could easily use S3, but 2007 these services didn't exist or most of the cloud services just started with their services.

javis 13y ago

When I see code like this, I'm always amazed that I can actually read it and (kinda) understand what it's doing. I always expect code like Facebook's to be so finely tuned and advanced that it'd be completely uninteligable to those outside the company and not an expert in the language.

Kiro 13y ago
In my experience code become unitelligable not because it's fine tuned and advanced but because it's messy and rushed.
- nwh 13y ago
  Doesn't quite hold true once you get done to hand written and optimised binaries though. There's no way of making assembly easily readable to everyone, no matter how relaxed the developer.
  - moconnor 13y ago
    Hand-written assembly can be just as readable as any other language. See https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/01%20POP%20Source/Source/FRAMEADV.S https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/m... for a good example!
- moconnor 13y ago
  Or over-generalized with the logic split up and hidden in the interactions between a dozen (sub)classes.
  - oneeyedpigeon 13y ago
    Or under-generalised with the logic duplicated in a dozen places, ever-so-slightly differently
Joeri 13y ago
Actually, a large codebase can be reasonably expected to live 20 years. Over that time with a lowish 10% turnover you'll replace the entire programming staff twice, so the understanding people have of the code is not just hearsay, but hearsay of hearsay. The sheer size of the codebase (facebook has tens of millions of lines of code) means that practically speaking you can't program your way out of a corner once you get there. That is (partly) what killed facebook's competitors. The solution to all of this is to be ruthless about simplifying code. The goal of new code should first and foremost be to be maintainable. Clever code is the enemy of scaling a programming team. Not that you don't need clever code, but you isolate it and protect it and make sure the average team member doesn't have to look at it.

Kiro 13y ago

I don't think it looks that bad. It's clean and easy to understand.

deleted 13y ago

[deleted]

a1a 13y ago

I think there is a valuable lesson to be learned from this piece of spaghetti. I can't quite formulate it from the top of my head. But it's something like: if you wanna be rich, don't waste your time being pedant - your users couldn't care less.

pestaa 13y ago
... unless your users actually care about messages being delivered, whatever being reported as saved being truly saved, et cetera... There is a whole world out there where people want to rely on software to do what it says it does. I know Facebook can live in its own bubble and get away with every possible stupid bug a messy PHP spaghetti causes.
- Encosia 13y ago
  I remember listening to an interview with Markus from Plenty of Fish, where he essentially said that he didn't worry too much about site errors because most unsophisticated users would attribute them to things like their ISP, browser (if they knew what that was), or their own error more often than to the site itself. Personally, I can't bring myself to not care like that, but it seems to have worked pretty well in the early days of many now-popular sites. Especially in 2007, when Facebook was still in real competition with MySpace, moving as quickly as possible was probably much more important than a few messages dropping through the cracks.
  - pestaa 13y ago
    I must admit my comment was unneccessarily bitter, but my observation is completely different. Many friends and family members are now seeing data loss on Facebook weekly at least. I wouldn't call them tech savvy either, yet they can attribute the issue to Facebook, after having learnt the simplest basics of how the web should actually work.
    - jafaku 13y ago
      That's probably by design. Would you prefer one unimportant message lost here and there, or be able to handle 1/1000 of the current traffic to make sure every single message is delivered?

jwdunne 13y ago

Hehe, these lines made me chuckle. // Holy shit, is this the cleanest fucking frontend file you've ever seen?! ubersearch($_GET, $embedded = false, $template = true); In all seriousness though, I wonder how much of this was written by Mark Zuckerberg?

jonknee 13y ago
With the header "@author Mark Slee" on that file, I doubt much if any.
filipedeschamps 13y ago
I don't know why, but I always love comments more than code itself.

alecsmart1 13y ago

This looks weird in search.php (line 89): if($user 0 && !is_unregistered($user)) { return $user; }

RossM 13y ago
This is either a syntax error or a HipHop idiosyncrasy (was HHVM in use in 2007?) $ php -r '$user = null; if ($user 0) { echo $user; }' PHP Parse error: syntax error, unexpected '0' (T_LNUMBER) in Command line code on line 1
- vezzy-fnord 13y ago
  I don't think even HPHPc was around in 2007. Development didn't begin until 2008, IIRC.
TazeTSchnitzel 13y ago
I'd hazard a guess that should be: $user <> 0 Which, of course, would not display if someone had originally pasted this code straight into an HTML page without escaping it. EDIT: Looks like it would show up. I wonder, then, if the <>s has been stripped. Some poorly written websites do that.
deleted 13y ago
[deleted]

EGreg 13y ago

This is why I was saying evented webserver code is better. Look at how much I/O is happening one after the other. The latency could be greatly reduced by doing things in paralel and waiting until all the promises resolve.

camus 13y ago
requiring scripts in PHP in not "IO". There is not much IO happening in these script.

m0th87 13y ago

Does anyone else remember the friend graph visualization feature facebook used to have? It was an oddity, both because it seemed like a strange but useful feature, but also because it was a perl script. One time I clicked it and got the source code to the file instead of the graph. It's somewhere on one of my hard drives, but it seems wrong to leak, especially since it has database credentials hard-coded into it.

TazeTSchnitzel 13y ago
I wonder if it was based on the code Zuckerberg used for the Java friend graph he had on his homepage prior to Facebook. Could you perhaps censor the credentials and release it?
- m0th87 13y ago
  I am not a lawyer, but even with censored credentials this seems like a bad idea. Especially since my profile is not exactly anonymous. Any Facebook employees want to get me a green light? :)
  - jeff_facebook 13y ago
    Hi, I'm Jeff from the Facebook legal team. We were discussing this today and decided it's fine for you post it. Go right ahead.
  - KatherineJMoses 13y ago
    uptil I looked at the receipt which had said $9272, I didn't believe that my mom in-law woz realie bringing in money in there spare time on there computar.. there friends cousin haz done this 4 only about eighteen months and recently cleard the mortgage on their place and bourt a great opel. additional info ========================== http://WWW.WORKS23.COM http://WWW.WORKS23.COM
minifig 13y ago
managed to save a copy of several files that appeared at the time - home.php, album, group, friends, photo, profile, readmessage ... code was an interesting read, as were the comments in it: // You fucking link h4x0rs just got pwned // Shortcut out of this CRAZY expensive garbonzle // What did we come up with? // don't display the Tuna album (aid=-1) // is this group a dummy meant to populate newsfeeds? // do not list the creator as harvard // keep track of tuna contexts // Merman's Admin profile always links to the Merman's profile // NOTE: ok, at this point we know we are going to display the full // page, so it is time to do a PHATTY PHATTY MULTIGET of all the shit that // we are going to need to make this page, or at least the most common things // Clear fire if desired

lifeformed 13y ago

How did someone "expose the PHP source code"? Did they actually find a way to make the code show up client-side, or was it just someone who managed to get access to the backend stuff? The way it's worded makes it sound like the former, but that seems unlikely...

MitziMoto 13y ago
Sounds like it was an "accident". The web server served up the source code rather than compiling the PHP, which someone then saved.
bouk 13y ago
I think it was a glitch in Apache that made it spill out the sourcecode
0x0 13y ago
It can happen if you upgrade Apache and/or mod_php, and for some reason mod_php fails to register for .php files without being a fatal startup error. Then apache will serve the .php files as plaintext. It's one of the things that make one-off .php scripts easy to deploy (just chuck it into the webroot). With a little effort, this can be mostly prevented: let the webroot .php file just do an ' include("../outside-webroot/actual-script.php"); '
vezzy-fnord 13y ago
Another possibility is some quirk in the file permissions, .htaccess or some other configuration file, which could lead to vulnerabilities like HTTP verb tampering. It may have been more subtle, but of a similar nature.
smsm42 13y ago
They misconfiguring apache to serve php as text file instead of being processed by php engine. One missing line in apache config can do that. It didn't last long, but of course people saved every bit that was leaked this way. Which is mostly entry points of course.

conradfr 13y ago

I don't remember from the site at the time what "monetization_box.php" would have been doing. Also, my style of comments seem so tame and lame now :)

deleted 13y ago

[deleted]

ErikAugust 13y ago

Pre-PHP 5.3 -> Right off the bat: no namespace support, no closures, no surprises there I am a bit surprised about the lack of OO though...

elwell 13y ago

From linked article "It seems that the cause was apache and mod_php sending back un-interpreted source code as opposed to output, due to either a server misconfiguration or high load (this is a known issue)." Does anyone know what he is referring to when he says this can happen via high load?

smsm42 13y ago
It is a myth. High load has nothing to do with it. However if you configure apache wrongly, it will serve .php files as text. Only connection to load is if you have one broken server among N proper ones, a number of times that the broken one is hit depends on load - I.e. on low load, it may be configured so that it is never hit at all. I guess the story about apache serving php source under high load came from the idea tha Facebook is a high load site (true) and they couldn't just have made as obvious screwup as misconfiguring a production server (false) so it must be apache/php bug that happens only in high load sites (false)
- nikcub 13y ago
  this was a real issue, here is the bug: https://bugs.php.net/bug.php?id=26810 https://bugs.php.net/bug.php?id=26810 there were many related bugs as well. it didn't get fixed for a while, and when it was fixed it was over a number of revisions and wasn't tagged.
  - deleted 13y ago
    [deleted]
  - smsm42 13y ago
    That issue was fixed 3 years before (Jan 2004) and from what I can see only happened in configs which use +x bit or config values to turn php engine on and off, and didn't really depend on load on these too much either - it's just load made it more probable you will hit the right sequence in the same process randomly, but if you know what to hit, it could be done on any load. So it would be correct to say "there was a bug 3 years ago which in certain configurations made mod_php serve source after certain sequence of requests". It was never happening just "due to high load", as far as I can see. And as far as I know (and nobody so far presented any evidence to the contrary, AFAIK) Facebook case had nothing to do with it anyway. It would be really weird for Facebook to run random 3-years-old PHP in production too.

elwell 13y ago

index.php line 130: foreach($upcoming_events as $event_id = > $data) { Space between "=>"...

mkhalil 13y ago

Anyone who calls this bad/spaghetti code hasn't seen bad code.

joshaidan 13y ago

I like the variable naming in the code. It's good that they didn't use one/two letter variables that span more than five lines of code. Short, meaningless variables names--used for things other than index values is one of my big pet peeves. I had to use somebody else's code as the base for a project and it was full of two letter variables that didn't mean anything. Gave me a big headache working on it.

tannerc 13y ago
Seriously, some of these variables are named so elegantly it's actually a little surprising. Beginning developers could learn a thing or two looking over code like these (even though it's now clearly outdated and likely defunct). I've been programming for half a decade and my naming conventions are still horrid.

rohanpai 13y ago

A startup with spaghetti code of this stature will NEVER be successful.

lucasnemeth 13y ago

People just call this spaghetti for superficial reasons, they don't see objects and they don't see current PHP practices used in 2013. But it is readable and maintainable code. We're out of context, and there is nothing there to assume lack of quality. Some people mistake code with literature, objectively speaking this is not bad code.

whalesalad 13y ago

The code looks pretty clean. I dig the two-tab spacing as well, but perhaps that was done after the fact. Anyhow, not sure if this makes any difference or not but i'm curious as to why true PHP constants are not used, and instead regular variables in all caps like $PARAM_INT are used. Anyone know why this might be? I ask because one of you PHP-gurus might inform me that there are certain use-cases where a true constant is not wise. An example below: param_get_slashed(array( 'feeduser' = > $PARAM_INT, //debug: gets feed for user here 'err' = > $PARAM_STRING, // returning from a failed entry on an orientation form 'error' = > $PARAM_STRING, // an error can also be here because the profile photo upload code is crazy 'ret' = > $PARAM_INT, 'success' = > $PARAM_INT, // successful profile picture upload 'jn' = > $PARAM_INT, // joined a network for orientation 'np' = > $PARAM_INT, // network pending (for work/address network) 'me' = > $PARAM_STRING, // mobile error 'mr' = > $PARAM_EXISTS, // force mobile reg view 'mobile' = > $PARAM_EXISTS, // mobile confirmation code sent 'jif' = > $PARAM_EXISTS, // just imported friends 'ied' = > $PARAM_STRING, // import email domain 'o' = > $PARAM_EXISTS, // first time orientation, passed on confirm 'verified' = > $PARAM_EXISTS)); // verified mobile phone

eksith 13y ago
I'm not a PHP-guru, but it's entirely possible that they're playing around with some background configurations that would make performance tweaks in some sections of the code difficult if they're defined variables. I guess this is an implementation of a semi-defined variable. It should probably be noted that there may be a tiny bit of performance improvement when calling isset instead of defined when checking for variable set. I'm not sure if that's one of the considerations since it would definitely be a case of premature (and ultimately pointless) optimization anywhere else, but since it's Facebook, they may have gone that far to squeeze every bit out of it they can.
dools 13y ago
They might be simple input validation filters created using the create_function() function which allowed you to create anonymous functions of sorts in PHP prior to 5.3. You can't assign an anonymous function to a constant. An alternative would have been to include a big switch statement in the param_get_slashed() function but since the same validators are used in a bunch of places it seems cleaner to use anonymous functions and have each function that uses them loop through and call each function passing the parameter named in the array key in as an argument

jmadsen 13y ago

There seems to be, here & on the "interverse", a battle on whether it will be more more hip to call this spaghetti code or to call it clean code. I don't see very much debate on whether or not it is GOOD code. It isn't good code. It is cleanly written, especially for the time. But all the noise about how bad it is isn't "hipster" talk - this is 400+ lines of completely unmaintainable code; which is why it isn't part of the current code base. As soon as they got some money & started trying to make it do more, they wised up and dumped it

fingerprinter 13y ago

The comments on github are akin to 'my eyes! they bleed', but tbh, this is actually quite readable and I imagine wouldn't be all that hard to maintain. I haven't touched PHP since about 2007 and it seems like it would be pretty easy to jump in and start making changes and edits. It is well templated, seems to use variables well and not have too many (if any, didn't look all that closely) hard-coded values. I've seen much, much worse in "cleaner" languages than this. As a side note. I learned a lesson in my early 20s that has served me well to today. Shipped code always wins. I was a huge proponent (and still am) of good code, well architected blah blah blah. But, in the end, if your code never sees the light of day, it doesn't matter. I saw this when I took over a team responsible for care and feeding of a product originally written by the founder of a company. This company had just secured a series B on the original code (still). The product was ugly, the code was terrible, it was slow, it wouldn't scale, couldn't be configured and really couldn't be maintained. However, it got the company moving, got a series A & B, secured the first customer, and a second. It basically created a runway to build the thing right that wouldn't have been available had it not gone live.