If someone has a recommendation on the best method of configuring this for multiple domains (not subdomains) on a cloud host, I'd appreciate the pointer.
In this case, I mean not shared web hosting in the VPS sense (one server, many customer sites) but web farm or web cluster (your site on many servers).
Sorry about the hijack, but you're not on Rackspace, are you? Wordpress sites there have been getting hacked quite a bit lately, it looks like they have a security issue.
I use this exact method (and a subdirectory, not a subdomain install) to run multiple domains off on a WP 3.0 installation on cheap, shared, GoDaddy hosting. No apache config editing whatsoever.
I haven't tested this with 3.0, but I had a dedicated IP for my WPMU installation. If the site is configured in the WPMU panel, it would work, without any Apache config needed.
Our startup runs on WP3 and the ability to allow multiple domains. Feel free to email me at [email protected] or add me on Skype: eisokant. I think I can give you some pointers.
Sorry for the shameless self-promotion, but I'm just about done with Head First Wordpress (http://www.amazon.com/Head-First-WordPress-Brain-Friendly-Cr...). It covers Wordpress 3.0 (although not the MU integration) and I've tried to make it more about using Wordpress as a content management system. This is exciting news from the WP team and there are a ton of cool new features in this release--my favorite being the menu admin and custom header images.
Come on guys -- it's been a while. We oversee or advise on blogs for basically every major media site (CNN, WSJ, NYT, IHT, TechCrunch, GigaOM...) as well as running WordPress myself (and WP.org) for 7+ years and have never had an application level exploit. If WP was really as insecure as you suggest, all of the news sites would look like 4chan.
It's possible to run WP in a secure manner. Just because some people don't doesn't mean you can't. It doesn't require crazy wget hacks, just updating. You can even automate it with SVN.
If anyone has questions or would like best practices for running WP in a secure manner, I'd be happy to answer them, here or over email -- [email protected].
You should make running WordPress securely a thoughtless process. The best practices should be clearly explained to every single user who downloads/installs it.
Sure -- the simplest way to keep it secure is just keep it updated.
To this end we work with numerous third-party hosts to help them update their customers, and have invested significantly in a notification and upgrade system for 10k+ plugins, 1k+ themes, and of course the core software. This was a particular PITA because runs on so many platforms with wildly different constraints and configurations. We blog, tweet, and email 200k people whenever there's a new release and offer free help on our forums to anyone who is stuck. Someday we might even offer auto-update in core just like many hosts already do.
My comment was more aimed at the HN audience which might want pro tips for staying updated or more defense in depth. For example I have a cron job run `svn up` on my site every morning which keeps it up to date whether I'm in front of my computer or on a beach sipping mai tais.
What I suggest for most folks is to tie it to a stable branch, that way you get overnight fixes but nothing potentially backward-incompatible. When a major release comes out, you need to svn switch to the new branch.
Many folks in the WP community, including myself, svn up to trunk. I wouldn't recommend that for the general public, but I think it's only broken my site once in the past year and I fixed it by running svn up again. If I was smarter I would script it to svn up, check the site, revert if it was blank. WP.com syncs to WordPress trunk pretty regularly, as well, sometimes daily depending on where WP is in its release cycle or if we have to do any database migrations.
Has Automattic or wordpress.org published anything like the various guides found across the internet? I know you offered to email, but it would be great to see something published that is tested and comprehensive.
I've seen this page before but actually thought it to be fairly basic. What about topics such as moving wp-config.php outside of public_html, renaming the wp-admin folder, and automattic's position on some of the various 3rd-party security plugins?
One thing I don't understand, is why I can't access the admin over SSL if the Wordpress ___domain isn't the Apache SSL ___domain? For example, I can't go to https://example.com/domains/mydomain.com/wp-admin/ without getting a failed redirect. This is a major annoyance, as I can't set up another SSL site on the server without leasing another IP.
Moving wp-config.php outside of the public html folder is easy. Just do it. WordPress checks the main root level and one level above for it automatically. No configuration needed.
Renaming wp-admin is not currently possible. This is slated for future versions though.
And the reason WordPress doesn't use relative URLs is because it uses a rewrite system for most of the site. With the permalink system, most of the URLs don't actually exist as real directories, but are simply indicators to tell WordPress what sort of things you're looking for. Now, I grant you that this is not the case for the admin side of things, which uses direct links to files and the like. Those links there, however, are relative.
However, the reason the admin redirects to the right URL is because of the secure cookie handling. Cookies in WordPress are carefully controlled as to which URLs they are sent to, they're not just indiscriminately sent to the whole site. If you're using SSL Login and Admin, then the login cookies are only sent to the SSL side of things, and only to requests in the admin directories, etc. Other cookies are sent to the normal non-SSL side, which will identify you for login purposes, but not allow you administrative access. All this careful cookie handling means that the correct ___domain must be present for everything to work. It can't work through some other ___domain that it doesn't know about.
Moving wp-config.php out of public_html is mentioned on that page, section 9. I think renaming the wp-admin would probably break more than it protects.
Don't get me wrong, I love WordPress. And I can't stand Joomla. But Joomla works completely off relative URL's so it doesn't have to know it's ___location. The links work no matter what ___domain you put it on. You can access the CMS through example.com/~myusername/domains/joomladomain/ or myusername.example.com/domains/joomladomain/ or joomladomain.com/ and it will for fine every way. Which means SSL will work without a dedicated IP address. This would be awesome.
Iiiinteresting. That sounds terrible... but awesome.
I didn't know it was happening tonight. Maybe. We'll see. I've been on a roll with Hackety Hack lately, and I want to make sure I have a few hours to put in.
Whoa, someone else from Pittsburgh? I've been looking for hackers/tech culture around Pittsburgh and haven't managed to find too much so far. I think I will check this out tonight.
There are events pretty much every month, but I haven't made any in a while this will be my first Refresh Pittsburgh all year. Make sure ya say hello to this guy: http://bit.ly/9jELdY (me)
Might want to add RefreshPittsburgh, Devhouse Pittsburgh and Dorkbot Pittsburgh to the events calendar, too.
Just because there aren't as many known exploits for MT doesn't mean it's more secure than WP. That's the same argument used when people say Apple software is more secure than Microsoft software. Yet if Apple software was used by more than 90%+ of businesses, it's likely more people would attempt to (and possibly find ways to) hack it.
Security aside, MT has lots of issues -- performance (or lack thereof) being one of them and bad upgrades being another. After the third time an upgrade broke some sites I manage, I gave up and migrated some sites to WordPress and some to Drupal. Have yet to come across the same issue.
Considering there was code added/changed during the "code sprint" the morning after Wordcamp SF while y'all were likely hung over, I'll take that bet ;-)
If I win, you have to drop everything and fix the backtick code bug on bbpress.org
ps. I also consider the bet won if there is a major issue posted on TRAC within a week, even if you delay a bugfix release.
It seems that Wordpress and Drupal are growing closer and closer to each other. Drupal is still more powerful though, even-though it's more complex to get up and running with. From a developer point of view they can be equally as awkward to develop for.
Hopefully the settings to enable Mu functionality isn't easy to get to, or else millions of people are going to upgrade and turn that on because they think it'd be cool and "I'm sure other people want to blog on my site!" and then get spammed to hell by parasite hosting spammers.
No user interface for the multisite/multiuser functionality appears until a constant is set in the configuration file. So most users will never see it, and those who do really wanted to. :-)
It's hidden a bit, you have to enable it in the config file, and of course it still requires subdomains and such to be properly configured. I expect this to make not much difference for WordPress users, but should be night and day for people who were running MU.
I've found this: http://blog.mixu.net/2010/05/17/setting-up-multisite-wordpre...
Which references this: http://www.interconnectit.com/840/wordpress-3-0-multisite-wi...
These assume you can edit your Apache conf, and many cloud hosts don't support that.