Migration is Fun!

Not really. Fortunately, WordPress reads Movable Type exports, which greatly smoothed the moving of blog entries and comments, but that's just the tip of the iceberg. I've also added RewriteRules to automatically redirect from any of the old RSS/Atom feeds to the new feed, so aggregators/feed readers shouldn't have to be updated. All other old URLs just drop you on the homepage.

I've also written my first WordPress plugin and customized another, my first PHP projects ever. Oh. My. God. PHP is horrible. On the plus side, however, shell access is easy and fast, which means a lot of stuff can be done on the shell (like unzipping files) rather than with PHP.

I've also been using Ant for a lot of stuff.  There are seven multi-hosted sites that share the URL-space, but WordPress (at least the non-MU version) is designed with an install-per-blog paradigm.  Keeping seven copies of code is obviously foolish, so I've got a single vendor branch for WordPress in my SVN repo where I make my general tweaks, and then use Ant to apply any per-site tweaks (like layout stuff) as part of generating the actual per-site installation.  That way I only maintain separate copies of stuff where they're different from the other six sites, greatly easing customization.

Finally, FTP sucks.  Such a brittle protocol, even with good tools (I'm using Transmit).  In particular, synchronization and recursive deletion operations are painful.  What I wouldn't give for rsync, but unfortunately no SSH access on the host.  So I've been relegated to zipping the installs locally, uploading the archives, and then unzipping on the server because synchronization never manages to finish without dying.
Things are coming together though, and I've got a whole pile of stuff I want to blog about once I have some free time again.

6 responses to “Migration is Fun!”

  1. Matt Burgess

    Hi! I was just wondering why you felt PHP was horrible? Personally I'm a PHP programmer learning Coldfusion, and hating it, so I'm interested to hear the other side.

    What language do you normally use and what does it do that you missed in PHP?

    Oh, for the record (literally) I'm documenting my experiences with the learning process of CF at http://www.phptocoldfusion.com. A blog that looks quite remarkably like yours. :)

  2. Matt

    I agree regarding the library. A look at the Perl libraries show much of the same functionality as PHP in about 1/10th the number of functions. In many cases the functions are obvious duplicates. Adding to the ones you listed are ereg_replace and eregi_replace. The first is case sensitive. The second is not. Clearly the functionality between these two (and preg_replace, which is slightly different as it uses Perl syntax) is almost identical, and at most should be selected with arguments, rather than completely seperate functions.

    Don't compare regex_replace to str_replace, though, str_replace is NOT regex aware, that's the point. It's much faster than the above-mentioned for simple non-pattern strings, and should be used by preference.

    Even aside from functions that overlap there are some serious inconsistencies in terms of names. isset(), is_null(), empty() are three functions that do similar jobs, but have vastly different naming conventions. Surely they should be is_set, and is_empty, for example. And don't even think about "to". strtolower, nl2br? Very inconsistent.

    IMHO the function set of PHP should be renamed with standard conventions, with aliasings to the "old" names for backward compatibility.

    But that's just me.

    On the subject of "code only in blocks" there we disagree massively. You're advocating spagetti code. In fact, the entire CF paradigm seems to work towards intermingling business logic and display logic in a manner that I find personally horrifying. And more importantly, extremely time-consuming to debug. Having all relevant data sources, settings, etc, declared all in the same place makes it MUCH easier to find problem variables, etc, and in my opinion CF's use of tags to "hide" important code within reams of HTML is a very very bad thing.

    I'll tell you the two things I miss most from PHP in CF…. Ternary equations and associative arrays.

  3. Matt Burgess

    Though CF structs add some functionality that PHP doesn't support in my opinion they're not as effective. Arrays can be associative or numerical, and are accessed identically. Arrays, structs, and queries seem to me to be structurally identical, and yet are accessed in utterly different ways. You can loop through the records in a query, but not a struct. Why? The lack of a foreach() is also very sad in CF. There are ways around, but…

    It's also worth pointing out that PHP lets you create arrays much more flexibly and easier than CF.

    $orderResult = mysql_query("SELECT * FROM Products");
    while($row = mysql_fetch_assoc($result)){
    $orderArray[$row['category']][$row['subcategory']] = $row;

    That code will get the data from a products database, and sort it into category and sub category. No mess no fuss. The equivalent query/struct would be a much longer block of code.

    On your other comments I wrote an article on writing good PHP code at http://phptocoldfusion.com/?p=7#more-7, but I'll cover some of the stuff here.

    And you're right, I misunderstood what you meant with the code blocks.

    <?php if (some test) { ?>
    hello <?php echo $someVar ?>
    <?php } ?>

    You're right. That looks bad. So don't do it like that. There are lots of ways better ways to structure that. For a start, the ?php part is not actually required. Let's use short tags instead. And because it's such a simple statement, let's omit the braces as well.

    <? if (some test) echo "hello " . $someVar; ?>

    if there IS a good reason to structure it differently (such as a lot of HTML code)

    <? if (some test) { ?>
    <td>hello <?=$someVar?></td>
    <? } ?>

    Quite neat. No less so than having <cfif> tags around things. In my opinion, having conditionals that are more visible is not a bad thing. Keeping them distinct visually is important. (I have trouble seeing CF tags in Dreamweaver, because my colour vision isn't perfect, and DW's choice of red and green is not visible to me. Thank Adobe!)

    As for command{} and command: syntaxes, I'm not sure what you mean, but I suspect you're referring to ternaries. They're NOT the same thing. A ternary is a shorthand for an if/else statement.


    If the price isn't 0 print the price, else print POA (price on application). Or my <?=($i%2?'ebebeb':'cccccc')?> to print alternating line colours in a display loop. For example. Doing the equivalent in CF would take several lines. Nothing too complicated, but certainly several lines and not as elegant as that.