rustindy

https://www.ripe.net/perl/whois?searchtext=83.245.62.34 seems to be accurate.

If your host is using PHP 4.0 with MySQL 4.1, then TextPattern won’t work either with that same fix applied. It has nothing to do with WordPress itself.

Matt: having read the link to Trac that you posted, and the link within that page, I’m not sure which way to go with it. On one hand, it makes sense to modify the upgrade-schema.php file and simply remove the DEFAULT declaration from the necessary fields, but I wonder if it’s more “proper” to modify the INSERT queries in WP to adhere to the database schema. The first option is easier, though it still doesn’t fix all the bugs. The second option is, to my mind, the better one since it means that all of the INSERT queries will be well-formed against the schema. Any input would be appreciated. I already have WP2.0 installing properly under PHP 5.1 and MySQL 5.0 with both methods, although commenting doesn’t work yet.

Matt: I’m sure not *every* PHP app that uses MySQL is broken, but so far it seems that most are. SMF (forum software), for example, is only slightly broken – only a couple of queries were malformed, and a patch was available something like 2 hours after the problem was noticed. phpBB, on the other hand, breaks horribly every time PHP or MySQL get upgraded, and this time was no exception.

In the case of WP, much of it still works to a fair degree. I’ll do what I can over the weekend.

Arg. Fine, I’ll lay off the opinionating and simply use facts. I warn that it is far less colourful reading.

On the PHP4 to PHP5 change: the error that most commonly broke PHP apps was the allow_call_time_pass_reference setting. In the PHP ini file, since 4.0-ish, it has stated clearly that having that turned on would *not* be supported in the future. This was an override behaviour that was being deprecated in future versions (and clearly noted as such), but was still taken advantage of extensively by many (or possibly most) PHP devs. So WP broke if this was turned off (the default value as of 4.1 or thereabouts). The fix is easy, and it was done for *most* projects (including WP) very quickly.

On the MySQL 4 to 5/strict change: this is simply (mostly) a matter of properly inserting rows into the database. Strict mode simply changes many warnings into errors. There is no other behavioural change that affects WP (that I know of), since 5.0x is primarily a feature-addition/bug-fix version. This error is the only one I see in both 1.5.2 and 2.0B2 (and SK2, incidentally). Turning strict-mode off corrects the problem. Again, how hard is it to write valid SQL? I’ve written a *lot* of SQL for MySQL, SQL Server, and Oracle, and I’ve never seen this error before. Just make sure the inserts are valid (based on the table schema), and this problem goes away.

So yes, I would like to see this bug fixed. If I have time this weekend or during the week, I’ll grab the latest from SVN and see if I can do it myself. I’m not all that educated in PHP, but I’ll give it a go if no one else will.

Sorry, but it’s really bugging me.

By “hundreds”, I do mean hundreds. A google for the error message itself turns up thousands of results, and every single PHP app I’ve tried with MySQL 5/strict has broken, most of them to the point where they simply won’t function.

Yes, WP works for millions of people using anything but MySQL 5/strict, no argument there. But all of those previous versions of MySQL (possibly excepting 3.x, since I haven’t personally tested it with WP) give warnings, while 5/strict gives errors (which is, technically, the proper behaviour).

Effectively, this means that all of these PHP apps are not coded properly. I know it’s strong language, but if you turn warnings into errors and things break that badly, there is no other conclusion to draw. And as far as I can tell, that is *all* that strict-mode does. With strict-mode turned off, everything works just fine ?? Except that a bunch of warnings are generated by MySQL.

Matt, I am always civil here. But this issue has happened more than once. When people (and hosts) started moving to PHP5, the same damn thing happened, and we were told to downgrade. This was not because there was a bug in PHP5, but because the code took shortcuts it shouldn’t have, and when the bug was fixed, things broke. This is the same thing that’s happening with the switch from MySQL 4 to 5. And there’s no reason for it, aside from either bad or lazy coding.

I’m not *just* pinpointing WordPress, but of all the apps I’ve tried, it’s the one I like best. phpMyAdmin, phpBB, SMF, TextPattern, etc. *all* have problems with strict mode for the exact same reason.

I’m surprised no one realizes how serious the problem could end up being.

And I’m still asking if this bug will be fixed by the 2.0 release.

Technorati is fine, I’d imagine. I’m curious about services that would display a public link to your blog, like Pingomatic, being notified because of the default post that’s created when you install WP. Or does that notification only go out when you start creating new posts?

Actually, that does bring up a good question – does WP notify https://rpc.pingomatic.com/ when it’s installed because of the default post?

C’mon, so he didn’t know about blog functionality in modern blogwares. No need to be hard on him for it. We all have to start somewhere, yes?

Anyhow, now he knows where the options are to turn off notifications of any type that his blog will send out by default (which, as said, 99% of bloggers want turned on, which is why they’re on by default), and he’ll know better the next time he installs software he hasn’t bothered to research ??

BTW (and someone please correct me if I’m wrong), but I think a pingback only contains the blog address and a timestamp – the excerpt and body are almost certainly not part of the information sent.

In the Options screen under the Discussion tab, you can disable pings by unchecking Attempt to notify any Weblogs linked to from the article (slows down posting.).

Pings, when in the context of a blog or other CMS-style system, do not refer to ICMP pings or echo commands. A blog ping lets a site know that you’ve linked to them from your site. It’s really called a “pingback”, and sites are free to ignore them. For total privacy, also uncheck Allow link notifications from other Weblogs (pingbacks and trackbacks.) on that page, and remove any entries under Update Services on the Options/Writing page. After doing this, only sites that already know your address (or sites that get it from them) will know where your blog is.

Anyone wanna test SK2 with it? ??

Wow, no need to be so snipey.

WP currently does require MySQL and PHP, end of story. There is absolutely no reason you cannot have MS SQL Server and MySQL 4.1 or 5.0 (or both) installed on the same machine, unless memory is at a premium. If port 80 is free on one of the machine’s IP addresses, you can even install Apache for the full experience.

You have to understand that there are probably NO routines that require a vendor-specific approach in the blogware itself (with the possible exception of permalinks). However, MS SQL and MySQL have very different SQL syntax in some cases, and MySQL actually has support for a couple of things that SQL Server lacks. So to get WP to support other databases, either almost every SQL statement must be rewritten or surrounded by SELECT CASE statements, or a complete DAL must be written and all the SQL statements replcaed with calls to the DAL.

BTW, MySQL 5.0 introduced stored procedures and triggers. Give it another look if you’re so inclined, and remember that there is NO reason you can’t have SQL Server and MySQL running on the same machine.

If you can send queries directly to the MySQL database (via phpMyAdmin or MySQL Query Browser or whatever), try and connect to that database with the user information that WP is trying to use, and try creating a table (create table tblTest). Let us know if that works (this is just to make double-damn sure that the user has the necessary rights).

Multiple WP blogs can run on a single database simply by changing each installation’s wp-config.php file to have a unique table prefix, but the database host and login information remains unchanged (assuming that your MySQL login has the right to create new tables in the database).

If you have created an entirely new database for a new WP install, make sure that the MySQL login you’re using has rights to that database. If you’re positive that the information in your wp-config.php file is correct, then that might be the problem. Check your MySQL user’s rights and verify that the new database actually exists, and let us know.

I can’t really speak for anyone else, but mine’s set to “auto-detact/universal” in Firefox.

But with some of these blogs, the users are seeing new posts properly and old posts are replacing extended characters either with different extended characters, entity codes, or question marks. There doesn’t appear to be a pattern that I can make out, but since I can’t read anything other than english and bits of french, spanish and italian, I have no idea whether the eastern languages are working or not – some say yes, some say no ??