Tag: PHP

wp-config.php and standalone scripts

WordPress plugin architecture is great and it provides developers with a lot of flexibility.  But once in a while one needs to write a standalone script that should use some of WordPress settings.  For example, a script that would have the same database credentials as a WordPress instance.  This sounds simple unless you look at the bottom of the wp-config.php file.  There’s that:

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

That means if you are to include wp-config.php in your standalone script, you’ll get the whole WordPress thing loaded and fired up. On one hand, that’s cool because now you can use WordPress functions and objects. But on the other, it’s not. Sometimes you just need the configuration only.

The work around is trivial.  Modify wp-config.php file like so:

if (!defined('WP_CONFIG_ONLY')) {
    /** Sets up WordPress vars and included files. */
    require_once(ABSPATH . 'wp-settings.php');
}

Now, in your standalone scripts, you can do the following:

define('WP_CONFIG_ONLY', true);
require 'wp-config.php';

And you’ll only get WordPress configuration without any extras. If you don’t define the WP_CONFIG_ONLY constant before loading the wp-config.php, then all will work as before.

CakePHP 2.1.4, 2.2, and a pick into 3.0

There’s been a stream of good news from the CakePHP headquarters recently.  If you are as slow as me on catching up with these things, here is a quick summary.

  • CakePHP 2.1.4 has been release, and that’ll be the last release for the 2.1 branch.  It’s time to move on.
  • CakePHP 2.2 stable has been released, and that’s what you should be using for your projects.
  • CakePHP 3.0 has been mentioned, so if you are interested in contributing early, here is your chance.

CakePHP 3.0 will take a few month to develop.  Mainly, the work is focused around the following:

  • Drop support for PHP 5.2.
  • Add and improve support of PHP 5.4+.
  • Reorganized CakePHP classes to use namespaces to avoid collisions with other libraries and classes.
  • Improve bootstrapping for better control by developers.
  • Rewrite the model layer to support more drivers, object mapping, richer API, etc.
  • Rewrite the routing to work faster and be more flexible.

Overall, it looks like some really healthy activity in CakePHP project.

The python of PHP bashing …

Apologies for a somewhat misleading title.  I just thought it was funny and appropriate.  This post is nothing but a link to yet another blog post discussing all things broken in PHP.  Or is it?

Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia.

I’ve been there, done that.  I’ve posted a few times on this blog and elsewhere my “appreciation” towards PHP.  I am one of those who doesn’t like the language.  Yet, I am one of those who programs pretty much entirely in PHP to the extent of completely forgetting all the other languages I once knew and used (hi, perl!).

Indeed, PHP has a number of shortcomings – it is inconsistent, unpredictable, unstable, and probably even insecure.  That’s all well known.  It’s a pain to use and even with that, it’s pretty much a de facto standard for web development these days.

As a working programmer I often hate and despise it.  Yet, as a technology guy and a big fan of the web, I love it.  With all its cons and ugly side effects, it did accomplish something.  It brought a lot of people into web development.  And those people have created a whole lot of cool things, which they otherwise couldn’t.  This feeling of remote appreciation is similar to my feeling of appreciation for Microsoft Windows and a bunch of related programs.  As “broken” as they were, they helped to bring a lot of people into computers.  Some of those people learned better ways.  Some brought the money that the industry always needs to grow and push the limits.  Some just provided an inspiration for others to solve certain problems.

Regardless, of whether you like PHP or not, if you are using it, you should know the downsides.  And for that the article above is a really good source.

PHP 5.4.0 released

These days, it is hard to imagine a web developer or an advanced web user who is not involved with PHP somehow.  For all of you folks, there are some good news – PHP 5.4.0 has just been released.  Of course, it will take a bit until it is well tested and pushed to most hosting companies, but you should take a brief look at the changelog to make sure you know what to expect.  Some of my favorite changes are:

  • Long-awaited removal of many configuration options: register_globals, register_long_arrays, allow_call_time_pass_reference, magic_quotes_gpc, etc.
  • Long-awaited removal of some confusing session-related functions: session_register(), session_unregister(), and session_is_registered().
  • Change of default_charset from ISO-8859-1 to UTF-8.
  • Added Traversable iterator in mysq_result for MySQLi.
  • Plenty of performance improvements and memory optimization.
  • Plenty of bug fixes.

Also, have a look at the migrating from 5.3 to 5.4 document.

The permanence of temporary

I came across this little story about the Gmail logo.

How many times have you been told not to leave something for the last minute, but when you did, it actually turned out better than expected? Well, Gmail’s logo was the product of this situation — it was designed by Dennis Hwang (who’s responsible for most of Google’s doodles at the time) the night before Gmail launched. Former Google designer Kevin Foxtells the story on Quora: “The logo was designed literally the night before the product launched. We were up very late and Sergey and I went down to his cube to watch him make it.”

The last minute bit reminded me of something else.  A few years ago I was involved in a project with a rather hectic release plan.  There was too much work to do, not enough organization, and the deadline appeared much sooner than expected.  The team was in the office pretty much since Friday afternoon and it was already just after 11pm on Sunday night.  Everyone was stressed and exhausted, and we thought that the painful release of the project was just about done.

It was then that we got a report from the support department that something is wrong with our outgoing emails.  And the problem was that they weren’t going out much.  Clients submitted forms and were told to expect activation / verification email with code.  And those emails weren’t coming for a while already.

It was then that we realized that in all the chaos we actually completely forgot to implement that bit functionality.  There was nothing there that was sending emails.  Oops!

I kicked everyone out of the room, locked the door and wrote a very quick Perl script.  I spent not more than 15-20 minutes.  We just needed something really quick to get the mail queue out of the way.  We would rewrite it properly next day, when the dust settles a bit and everyone is rested and thinking clearly.

Can you guess when we actually rewrote it?  One and a half years later!  That’s  right!  Something as temporary as that lasted and did the job for almost two years.  Turned out that the job I wrote it to do on the first night was pretty much the job it would be doing 24×7, and there was no need to even update it.  It supported templates, multiple languages, and pre-configured attachments based on the template and language.  And it was efficient enough, since when I was writing it we already had a few thousand messages in the queue and I wanted to send them out as quick as possible.

Even later, when the rewrite happened, it wasn’t for any new functionality, but for better integration with the rest of the project.  After all, it doesn’t make much sense to have a single standalone Perl script in the project that is completely written PHP.  It was ported almost verbatim.

Every time I tell this story, especially to my Russian friends, I keep hearing the same response: “Nothing is more permanent than temporary“.  You build something to last for years and it gets destroyed, redesigned, and rebuilt every 6 month.  You throw something together to get you through the day and that lasts a century.

The Gmail logo reminded me of that.  Designed on the night before the release, the logo is still here…