Blog by Sumana Harihareswara, Changeset founder

13 May 2014, 15:24 p.m.

Dipping My Toes Into PHP

Hi, reader. I wrote this in 2014 and it's now more than five years old. So it may be very out of date; the world, and I, have changed a lot since I wrote it! I'm keeping this up for historical archive purposes, but the me of today may 100% disagree with what I said then. I rarely edit posts after publishing them, but if I do, I usually leave a note in italics to mark the edit and the reason. If this post is particularly offensive or breaches someone's privacy, please contact me.

This week, alumni like me get to spend time at Hacker School. Since I work on MediaWiki-related documentation and I've never programmed in PHP before, I decided to start understanding just enough PHP to be able to read it better. Jordan Orelli from Etsy, a fellow alumnus, was kind enough to give me several pointers, and to especially help me understand how a PHP programmer's experience differs from my experience as a Python programmer.

I have learned, for instance:

  • The PHP REPL (command-line interpreter/environment) is not as verbose/helpful as, say, the Ruby and Python ones. You get to it by doing php -a at the command line.

  • For people like me who want a reasonably recent PHP and are on Ubuntu, apt-get install php5 is a good way to install PHP.

  • PHP is a templating language that - in its design - kind of always implicitly assumes that it's in the context of an HTML page. For instance, by default, it autoescapes HTML characters such that output from a bit of PHP will be suitable for including in an HTML page. And within an HTML page, serverside, you might have something like
    <p><?php echo "I am leet!"; ?></p>
    which the server will execute, thanks to something like Apache's mod_php plugin, and then send to the browser as the HTML
    <p>I am leet!</p>

  • What I as a Python programmer would call a dictionary, PHP folks call an associative array.

  • PHP is completely single-threaded. This is why you never have race conditions in PHP! Every time you execute PHP within mod_php, you execute it within a sandbox just for that HTTP request! And that means that "the global namespace" really means "the global namespace for the current HTTP request" so "global" sort of has a different meaning, and thus I understand better why people are more okay with using "global" variables and the "argh, global data is bad" aversion is weaker in the world of PHP programming.

    But you also cannot share state this way! So you should use caches & the database & job queues & other persistence layers.

  • A lot of the time, you want a pretty URL for the user to see, like , but the work is being done by app logic in, say, index.php plus query parameters, e.g. . So, if you're using Apache, mod_rewrite uses the .htaccess &/or .htdocs files (need to double-check this), which contain just a giant list of "if this then that" regexes, to rewrite the URLs of HTTP request headers.

  • Many things in PHP are inconsistent or unintuitive, and it's not your fault if you don't get it. For instance, some method names have underscores and some don't, and the pattern isn't intuitive.
Much thanks, Jordan! This is all oversimplified for clarity, etc., etc. I think next up I am going to try to understand a bit of PHP syntax, and the role of PEAR.


Christie Koehler
14 May 2014, 16:42 p.m.

I did PHP development for a long time and am happy to answer any questions you might have.

PEAR is the main package manger/repository. PECL is a subset/fork of PEAR that includes mostly compiled extensions. My most recent experience is that you're much more likely to install PECL extensions than non-compiled libraries from PEAR, particularly if you're using an existing framework.

Also, be sure to checkout Xdebug. Better error messages, actual stack traces, etc.

14 May 2014, 19:28 p.m.

You have clarified and delineated things I was fuzzy about with regard to PHP, despite the fact that I've been writing it for fourteen years. This is part of why I've long said you would be a formidable programmer.

Regarding the last item in your list, particular "it's not your fault:" CORRECT.

C. Scott Ananian
21 May 2014, 19:01 p.m.

There exist better REPLs for PHP, but it is true that they are really a part of PHP culture (sadly). I like boris ( although it has a nonsequitor name and I frequently can't remember what it's called when I need it.

I mentioned this to you on IRC, and you mentioned, "the script maintenance/eval.php in MediaWiki provides a basic PHP interpreter with MediaWiki objects and classes loaded. (so says )" which is another useful REPLy thing and one I didn't know of before. Thanks!