10 reasons why WordPress is a better starting point for a project than you thought, even though you’re an advanced PHP developer

I didn’t quite mean to make this a “top 10″ list, but it did work out to 10 items, and it’s indeed a list.

UPDATE: I didn’t make a few points clear originally, so let me add some context here.

The impetus for writing this post was of 3 weekend projects that never got off the ground because I got bogged down with the setup. I was familiar with the framework I was using, it gave me all the tools I needed to get the project going, and as I started building my functionality I started realizing I needed X, Y and Z to keep going. So I grabbed packages (some I was familiar with, others less so, but all were modular and would fit right in with the framework I was using) and spent a bunch more time getting them connected and playing nice with each other, realizing I needed to modify my database schema to support certain features from those packages, etc.

By the middle of weekend #2 I still hadn’t really started coding what I wanted to work on. During the following week I had a bit of an epiphany that everything I’d spent a bunch of time doing to get my project started using simple, existing modular components that were easy to plug in and use already existed within WordPress. At the start of weekend #3, I started fresh with a WordPress install and just started coding the thing I wanted. I just never realized how much time I spent wrangling modules and components before.

Google App Engine provided a similar feeling. At the time I started playing with App Engine it didn’t support PHP, so I used Python, and I was able to just start coding. Users, permissions, access, etc, were all taken care of. The only thing I was mildly annoyed with was that I couldn’t find any existing themes, but it wasn’t too time consuming to grab a WordPress theme and make it work with Jinja2. Having to define my routes was a little annoying / time consuming too. I realized that WordPress would have made even those two things inconsequential, but they weren’t burdensome. But I digress.

Any CMS or Framework can do most of this stuff. The point isn’t that only WordPress does it, nor is WordPress necessarily the best at it. The point is just that WordPress already has these building blocks in place so when you just want to get your idea out there, there’s a bunch of stuff you just don’t have to deal with.

  1. User management and roles.  Has a fully functional user system available, and easy to hook into or customize.  So much better than rolling your own.
  2. Database structure and abstraction/access.  Fully functional database abstraction layer, and supports custom data types (just imagine custom post types are your default storage engine, not “posts”; and custom taxonomies are your relationships).
  3. Control/Admin panel.  WordPress has an admin panel “for free”. Easy to add pages, customize who can see what, etc.  This includes a fully-customizable user experience and WYSIWYG editor already present, which can be easily attached to anything.
  4. HTTP client.  WordPress has a pretty smart HTTP client, and can handle a lot of situations (mostly encountered by shared hosts).  It’s no Guzzle but it’s very reliable, and functions as expected under most normal circumstances.  It even allows non-blocking requests (these are asynchronous but may still trigger handlers on failure/success, just not in the same process or request).
  5. Scheduled tasks.  WP Cron leaves a lot to be desired, but it’s there, and it (mostly) works, and having even a half-assed solution pre-built beats building your own half-assed solution that you’ll never get around to finishing.
  6. Cache client.  With automated fallback if no persistent cache is available.
  7. Route management / pretty URLs / SEO URLs are already present, and works by default when implementing custom pages, post types, taxonomies, and kind of archive or detail page..
  8. Pretty much everything has an observer pattern built-in.
  9. Search.  Like scheduled tasks / cron, WordPress search kind of sucks out of the box, but it’s there, and plugins (+ the observer pattern for searches) are available to allow you to search using any kind of actual search engine you want. But again, it’s at least got a “good enough” search already available until you implement an improvement.
  10. It’s “legacy” code, and ugly, but that doesn’t mean your code has to be.  There’s nothing to stop you from writing modern PHP code for your classes and themes.  (Except that WordPress can be a little weird about namespaces, due to the way the observer pattern is implemented.)   Incidentally, it’s improving.  Thing is, these are things you just have to deal with when your software has millions of users and requires backwards compatibility, and also so that your software can reach hundreds of millions of users in the first place.
20131201-123817.jpg

Johnny Cash — Everybody Loves a Nut

Fantastic album. It’s hard to find an actual pre-90s Johnny Cash album, most are compilations. There’s not much more to say for the music, it speaks for itself. I mean, it’s classic Johnny Cash.

Found this while out shopping for Record Store Day Black Friday releases (pretty much the only Black Friday shopping I don’t feel guilty for doing). I couldn’t pass it up. It looks to be an original release, judging by the wear on the sleeve. The record itself has some pops and scratches but the vinyl looks very clean and unmarked. The cover was painted by Jack Davis (you know his work even if you don’t realize it).

The title song, among others, was written by Cowboy Jack Clement (RIP), who produced some of the Sun studios tracks on U2′s Rattle and Hum (among many, many other notable things). I bought this album alongside the most recent U2 single. One of the U2 tracks he recorded was Woody Guthrie’s Jesus Christ; I also got Mermaid Ave, a series of albums where Billy Bragg and Wilco record a bunch of Woody Guthrie songs (lyrics without music to be precise). Funny how things sometimes tie together.

20131201-121334.jpg

U2 — Ordinary Love (single)

The A side is great. Reminds me of Electrical Storm, in that it is well written and easy to listen to on its own, catchy and interesting. I liked the production values, and then I read it was produced by Danger Mouse. Cool beans.

The B side is not great. It’s an interesting take on “Breathe”, but I just can’t get past the distortion on Bono’s sibilants. It makes the song sound like filler. I get that it’s supposed to sound stripped down, like a campfire song or something, but that sibilant distortion is just so bad.

Well that’s 8GB I didn’t have before

Adobe CS4 Uninstall

Preview is better than Acrobat for my PDF needs (specifically annotations).

Pixelmator handles my current image editing needs just fine. I never found CS4 lacking in features, and Pixelmator has all the features I used, and they’re at least good enough that I can’t tell the difference in quality.

Both open faster and have a smaller memory footprint than the Adobe equivalents.

20131201-121522.jpg

Mermaid Ave, Vol 3

The latest in the Mermaid Ave series is fantastic.  Sounds like it was made to be listened to on vinyl, although that’s a bit biased since I haven’t heard this one on CD. But listening to them all in succession on vinyl, they get progressively better.  The songs are much better than Vol 2 — I like the Vol 1 songs best, and this is equal in songwriting quality.  It’s still more of the same, so if you didn’t like either of the others, there’s nothing here to change your mind. This will likely be the first Mermaid Ave album I grab when I want to put some on, unless it’s to hear some specific songs on Vol 1.

20131201-121714.jpg

Mermaid Ave, Vol 1

Sounds like it was mixed and mastered with digital in mind. Not sure how I can explain that, other than: there’s nothing special about this album on vinyl.  Guy at the record store said “it’s got that 90s production feel”, and I’m sure that’s part of what he meant.  The songs are as awesome as ever. If I had bought it on its own I would have been a bit disappointed, but the other volumes are great on vinyl, so it’s nice to have the whole set.

What I wish I knew about writing PHP and web apps when I started

Chris Cornutt (@enygma) asked on Twitter, “If you were just starting to learn about writing secure PHP apps, what would you want to know?”  While I replied via Twitter, I figured I’d post my own short list here. I’d certainly consider this a beginner’s list, but it’s the kind of basic stuff I wish I had known.

  • There’s nothing inherently secure about POST requests nor data retrieved from the $_POST superglobal. POST parameters are sent within the body of the message instead of the URL, which allows for longer key/value pairs than using a querystring, but it’s just as visible as any GET parameter.
  • Anything transmitted to/from the server is inherently readable by anybody unless you specifically take precautions, such as transmitting via HTTPS.
  • There’s no automatic/magic security or sanitization built in to most standard PHP functions nor frameworks. It’s often there, but you have to consciously use it.
  • Just because it looks like an image, responds like an image, doesn’t mean it’s an image. (Or other type of included file.)
  • 3rd party resources have access to anything on the page, regardless whether it’s visible, behind HTTPS, or obfuscated. Serving your site via SSL isn’t a magic bullet. Javscript can still access elements on the page and do nasty stuff (XSS), and you’re still vulnerable to CSRF attacks.
  • Just because something is only “visible” server-side doesn’t mean it’s inherently secure. For example, any variable can be made global, and all the data within it can be read by any PHP script or method within that script. Case in point: the widely-used Akismet plugin for WordPress includes a dump of $_SERVER in each spam check it makes. This isn’t specifically a problem with Akismet, it’s just illustrating that code can be exposing stuff you didn’t think about, and may be exposing things you didn’t realize. You can do some really evil stuff.
  • Just because you got a file from a reputable source, doesn’t mean it’s safe or good.

Some of those are web security but I didn’t know I needed to care when I started doing PHP  and web development.  I shudder to think of some of the code I wrote that’s still out there.

Related links

Aside: One of the reasons I love WordPress is that it gives you all the tools to write secure code out-of-the-box.  Other Frameworks like Zend and Symfony do, too, but they’re not as obivous.

Google News considerations

You’ll notice a few of these suggestions either aren’t practical, or conflict with other suggestions. You’ll also notice the supporting documentation is for fixing errors with Google News listings. We have noticed that adhering to these when possible produces good results, so that’s why I’m calling attention to them.

Images

http://support.google.com/news/publisher/bin/answer.py?hl=en&answer=13369

  • Make sure that your images are fairly large in size, at least 60 pixels by 60 pixels. (only applies to main article image)
  • Use images that have reasonable aspect ratios.
  • Ensure that your images are inline.
  • Ensure that your clickable images link to a URL with a .jpg or .jpeg extension.
  • Place your images near their respective article titles.
  • Label your images with well-written captions.

Article snippets

http://support.google.com/news/publisher/bin/answer.py?hl=en&answer=70752&topic=2523198&ctx=topic

  • To give users a preview of an article before clicking on it, Google News displays its first few sentences on our homepage and in search results. To determine which text to include, our crawler looks at each article’s code for body text near the headline of that article.
  • We also recommend clearly differentiating the text that makes up your articles’ author bylines and date information from the text of your articles’ first sentences. Ideally, we will only show the first few sentences of your articles under their headlines in Google News.

Article date

http://support.google.com/news/publisher/bin/answer.py?hl=en&answer=70871&topic=2523198&ctx=topic

  • Place a clear date and time for each of your articles in between the article’s title and the article’s text in a separate line of HTML. This should help our crawler correctly identify the publication date for your article.
  • Make sure to provide us with the date when the article first appeared on your site.

General

Just putting it here for reference.