error404

Good to hear that, it’s been a few months since I’ve checked out 1.3. I definitely have to reexamine where the DB code is going and plan accordingly; all that’s really necessary is for all the calls to mysql_* to be pulled out into a seperate file, which can be selected in the configuration. Then it’s a comparitavely simple matter for someone to replicate the schema and port only the centrally-organized SQL.
Definitely nice to see the development team making an effort to move forward on it. SQLite support would be nice for many as well, I imagine, and I’d be willing to write it if the SQL were more centralized, even ignoring the real abstraction issues.
ADODB would be nice for other reasons, but it wouldn’t be *that* much work to replicate the features we actually need.

Definitely agree with you on that one. Fact is, the WordPress code doesn’t do any sort of DB abstraction whatsoever; and doesn’t even attempt to be database independent. I had begun designing a new database access class for the whole of WordPress, but I simply haven’t had time to go any further than a preliminary design. The developers themselves don’t seem to care about the issue and after discussing it at length, I doubt they’d be behind any sort of change in that direction. My plan was to do all of the (huge amount) of work myself, along with any supporters I could gather from the IRC channel and mailing lists, and get something working to present to them.
A good example of why DB stuff should be abstracted and as independent as possible from the start, I’d say. But hey, it’s PHP, we can’t expect intelligent design now can we :P. (I find the tagline ‘code is poetry’ at the bottom of this page slightly ironic, the WP code is not elegant nor well designed)
It’s too bad the port’s not useful to you, but it’s the best it’s going to get for the time being. I may try to get some movement going on my original idea over the winter break, but I expect to be exceedingly busy.

You guys clearly need to pay more attention ??
https://wordpress-pg.sourceforge.net/
I ported 1.2 by hand myself, and with William Carrel’s help we’ve got 1.2.1 running and have done some work on current CVS (though it’s far from working, we’re both busy). My port’s been around for a while, and linked on this board too ;).
Any donations are very much appreciated. I’m a poor student that can’t afford to renew his domains.

That would be my port. I’m not a WordPress developer, but I am hoping to help out with database abstraction in the WordPress trunk.

There are some minor security implications, but no real way to get around them short of having your own server.
With shared hosting (unless it’s been configured by highly competent professionals, which I’ve never seen on a shared hosting server) anyone else with an account on that server can access your files. It’s that simple…also, since they have an account on the same server, they can access your MySQL database with the password in the file. Since the web server process has to be able to read the file to display your blog, generally every other user is able to as well. Sometimes changing the group of the file to the same group the web server process runs as (usually nobody or www-data), and then chmodding it to 750 will work, but often it does not.
The other thing is that even if I were to somehow obtain your MySQL details, I wouldn’t be able to connect to (assuming it’s properly configured) the server since the MySQL server wouldn’t be exposed to the network. I’d need an account on the server to do that. Fact is, though, that the PHP is parsed server-side and unless there are ‘echo’ statements in it echoing your database details, it’s not going to output anything whatsoever to a user on the internet.
For most, though, these are non-issues. Most people on shared hosting aren’t knowledgable enough to attempt an attack (not to mention don’t care). The only way to be assured of your security is to have full control of the server, period. The happiest medium for most users is a virtual private server or UML session, but the cost is significantly more than shared hosting, and they take some *nix skills to manage.

The problem is that your router will forward port 80 connections that come in on the internet interface…but it won’t do the same for packets coming from your LAN to prevent some obscure routing loops and such. The simplest fix is to add your internet domain to your hosts file with the same address as localhost. That way, rather than pointing your internet domain to the internet, it’ll avoid your router and work properly from your workstation. Any other users on the internet will be routed to the correct external address.
In Windows XP, the file is located in ‘C:\WINDOWS\SYSTEM32\DRIVERS\ETC’ and would be called simply ‘hosts’. Open it in Notepad and add ‘127.0.0.1 https://www.domain.com‘ and ‘127.0.0.1 domain.com’ on seperate lines. Save the file and it should work properly.
Keep in mind that if you ever get external hosting, you’ll need to remove those lines.

That’s the plan. I’m just hoping it’ll be a lot easier in the future ;).

I started on a Postgres port of Mingus tonight. After a ton of work hacking the installation scripts (god, is that ever a mess; I’ve ignored all the legacy support as nobody should be upgrading ;)) and a bunch more work hacking the individual scripts, I’m at a point where the basic blogging functions seem to be working acceptably. If I manage to get everything (or at least most things) working perfectly, I of course plan to release it.
The working admin stuff is very minimal at this point, but I don’t expect it to take too long to get that going. Once that’s done, I’m going to go through the entire codebase quickly by hand looking for conditions that I know cause problems.
Does anyone know if WordPress has a testing suite or at least a good testing guide I might use to work with this?