The WordPress-on-an-intranet nightmare

[UPDATE june 2009: this is solved in WordPress 2.8]
wp for dummies book coverHaving a fair amount of experience with WordPress installations and configuration, I wanted to install trusty old WP 2.5.1 on an idle desktop (winXP+xampp) at work to do some blogging on our intranet. The installation itself went smoothly (how hard can unpacking a zip-file be) but after some time the damn thing stopped working, producing nasty timeout-errors caused by a.o. wp-includes/update.php and wp-admin/includes/update.php.
The problem is that WordPress tries to open an internet-connection (using fsockopen) to see if updates are available. Great, except when you’re trying to run WordPress on an intranet behind a proxy without a (direct) connection to the internet. After some unsuccessful fiddling in multiple WordPress php-files, I ended up disabling fsockopen in php.ini (disable_functions)!

Disabling! Fsockopen! In php.ini! Just to have a working WP?

I mean, come on guys, why doesn’t WordPress provide configuration options where you can specify if and how (what type of proxy, what address to find it on, …) it should try to connect to the internet? I even made this truly amazing UI mock-up which you guys can just like copy/paste straight into your code;

_______________________________________________________________________________
How should WordPress connect to the internet to check for updates?
(*) Direct connection to the internet (default)
( ) Use a proxy:
    Proxy type:     (*) http ( ) socks
    Proxy URL:      ___________________________________________
    Proxy User:     ___________________________________________ (optional)
    Proxy Password: ___________________________________________ (optional)
( ) No internet connection available (WordPress won't be able
    to warn you about updates!)
________________________________________________________________________________

_
😉
Pretty please?

6 thoughts on “The WordPress-on-an-intranet nightmare”

  1. yeah, guess i’ve got to work on my irony-skills as well 😉
    (edited the text a bit to avoid being taken too seriously with that mock-up of mine)

    Reply
  2. Weird. you caught me on my own security rules.
    What this means, appears to be that WP needs tcp/80 acees to “anywhere” (as we don’t know which serevr s it wants to access) to operate.
    This is a very unsecure situation by itself. A server should not need explicit outside acces besides, except maybe very specific things?
    the ver fact I didn’t bump intio this problem myself proves I lack too much on focusing on security.
    The problem is that security and usability are very much opposed.

    Reply
  3. correct, but it isn’t too hard to see where the connections are pointing to when browsing through the source;
    * api.wordpress.org (for updates)
    * wordpress.org (for various widgets on the dashboard)
    * planet.wordpress.org (again widget on the dashboard)
    so in general you could say WordPress needs to be able to phone home to *.wordpress.org:80?
    if you’re running the wp-stats and akismet-plugins, some extra connections (to wordpress.com and akismet.com?) are bound to be needed as well.

    Reply
  4. correction; the dashboard widgets are off course not contacted by the wordpress-code on your server, but by some ajaxy-code in your browser when you’re looking at the admin dashboard.
    /me is a little bit stupid 😉

    Reply

Leave a Reply to frank Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.