| User | Post |
|
8:02 pm
20 Sep 2008
|
Andrew
Guest
| | | |
|
| |
|
|
I am trying to install SPF on a fresh install of Wordpress (2.6.2) under IIS on a Windows 2003 server (SP2, region set to UK) with PHP 5.2.6 and MySQL 5.0.51.a.
I've copied the plugin across and activated it, no problem. However when I click on the Install button I get one of these error messages:
WordPress database error: [Field 'post_content' doesn't have a default value]
INSERT INTO wp_posts ( post_type, post_status, post_title, post_name, comment_status, ping_status, post_author, post_date, post_modified ) VALUES ( 'page', 'publish', 'Forum', 'forum', 'closed', 'closed', 1 , now('Y-m-d G:i:s') , now('Y-m-d G:i:s'))
and one of these error messages for every user I have registered aside from the admin user:
WordPress database error: [Incorrect datetime value: '' for column 'lastvisit' at row 1]
INSERT INTO wp_sfmembers (user_id, display_name, pm, moderator, quicktags, usergroups, avatar, signature, sigimage, posts, lastvisit, subscribe, buddies) VALUES (2, 'test', 0, 0, 0, 'a:1:{i:0;s:1:"2";}', '', '', '', 0, '', '', 's:0:"";');
I get this with both 3.1.3 and 3.1.4.
After installation everything appears to be alright except obviously the wp_sfmembers table is empty and “Manage User Groups” page add members control doesn't list any members. I can create forums but I get the warning about them only being visible to admin because there are no members.
I'm sorry if this has already been brought up - I did a search for “incorrect datetime value” and “database error” but nothing relevant came up.
In case this was a problem with the fresh install I tested and reproduced the problem on an established Wordpress installation elsewhere (same MySQL and PHP versions, again Windows 2003 IIS).
Is this a known problem? What do I have to do to get it going?
Thanks,
Andrew
|
|
|
9:45 pm
20 Sep 2008
|
-Radio-
Moderator
| | Florida - USA | |
|
| posts 558 |
|
|
Andrew said:
I am trying to install SPF on a fresh install of Wordpress (2.6.2) under IIS on a Windows 2003 server (SP2, region set to UK) with PHP 5.2.6 and MySQL 5.0.51.a.
I've copied the plugin across and activated it, no problem. However when I click on the Install button…
[SNIP...]
and one of these error messages for every user I have registered aside from the admin user:
[SNIP...]
In case this was a problem with the fresh install I tested and reproduced the problem on an established Wordpress installation elsewhere (same MySQL and PHP versions, again Windows 2003 IIS).
Is this a known problem? What do I have to do to get it going?
Which is it?… a fresh install? or are there users?
If there are users, where are they coming from?
Are you importing users from another database?
If so was that database attached to an older version of SPF?
If so, you may have to update to SPF v3.1.4 Rather than initiate a fresh install.
|
|
|
10:46 pm
20 Sep 2008
|
Andrew
Guest
| | | |
|
| |
|
|
It's a fresh install of Wordpress with two Wordpress users - admin and a user called “test”. The SPF install reads these from Wordpress and uses them as seeds for the freshly created wp_spmembers table.
In both cases it's a fresh install of 3.1.3 - SPF hasn't been installed on either machine before. Nothing's being imported from anywhere.
When the 3.1.3 install fails I tick the box in the options for SPF to remove the database tables that it creates, deactivate, check everything's gone and then copy across the 3.1.4 files and try again - same result. This didn't come as much of a surprise - the SQL writes are in sf_upgrade_support and sf_install, neither of which are overwritten by the 3.1.4 install.
I've worked around the first SQL error by changing the code. In my 2.6.2 installation of Wordpress the table flags the post_content column in the wp_posts table as “not null” and a default value of 'null'. I'm not au fait with MySQL but on the face of it it seems to me if you try to omit that column in an insert then MySQL will try to default it to null, but that'll fail the not null test and the insert will fail. Adding a default value for that column, plus another four (post_excerpt, to_ping, pinged, post_content_filtered) to the bit in sf_install.php that tries to create the dummy posting for the forum did the trick.
I'm guessing that these five fields are new for 2.6.2 and that the install routine hasn't been tested against 2.6.2 yet?
The code in sp_upgrade_support that's failing with the SQL error on wp_sfmembers is in sf_build_members_table. I don't know what the cause of it is but sometimes the lastvisited column winds up as empty. At first I thought it was because I'd never logged in as the test user, but after logging in and visiting the site the “sflast” value is still null for the test user and not-null for admin. Anyway it doesn't matter - it's obviously unsafe to assume it will never be null, which is what the current code is doing, so I just changed it so that it inserts null if the lastvisited value is null or the date if it isn't. That did the trick.
|
|
|
|
|
This is both worrying and strange. Let's start with the wp POSTS table. A column can't disallow null and then have a default of null. That is somewhat absurd! But if something here has been changed then you are quite right that I need to look into it. I have successfully installed the forum into a WP 2.7 development system without any DB problems so I am wondering if this is anything to do with the fact that it is MySQL running on IIS which is not a configuration I am able to test.
So - you seem to be suggesting that with a little data mangling you have managed to install it which is good of course. All I can really promise at the moment is that I will create a completely new 2.6.2 system and give it a try. But to be honest, if 2.7 works fine I rather suspect so will 2.6.2 and IIS might end up being the only factor that is different.
|
|
|
11:34 pm
20 Sep 2008
|
Andrew
Guest
| | | |
|
| |
|
|
I think it's unlikely to be anything to do with IIS - IIS is just a conduit for the PHP stuff, it won't influence how Wordpress creates its tables. I think the null default values are just indicating that no explicit default has been specified and that you need to supply values for those fields in your inserts. The existing code already fills in most of the text fields so I just added those extra five fields to the end and wrote empty strings to them. I don't know what previous versions of Wordpress had in that table but I'm guessing those five fields are probably new, or perhaps Wordpress has recently taken to flagging them as not null.
I did notice that SPF creates all of its tables as MyISAM tables whereas the Wordpress tables are InnoDB. I setup MySQL to allow both. Perhaps if Wordpress is creating MyISAM tables it doesn't flag all the columns in wp_posts as not null?
|
|
|
11:42 pm
20 Sep 2008
|
-Radio-
Moderator
| | Florida - USA | |
|
| posts 558 |
|
|
ok… sorry in advance if this insults you… but I am no fan of the IIS or windows platforms and the under-engineered / over complicated hastle that is required when being forced to choke an otherwise perfectly good computer, on any Microsoft product… And I mean that from the heart…
I read your procedures in the posts above, and as anyone familliar with Microsoft .NET procedured would, you over complicated the steps involved, to ruin what might have been a perfectly good instalation.
- Upload the files from the SPF v3.1.3 into your Plugins directory on your server.
- Activate SPF in the Plugins Tab on your Wordpress Dashboard.
- Navigate to the new Forums Tab on your Wordpress Dashboard and click the INSTALL Button.
- Wait for the page to refresh and tell you that the install is complete. (This completes the creation of the default SPF database Tables.)
- DO NOT DELETE THE TABLES JUST CREATED - YOU NEED THEM
- Click the button to navigate to the Forums settings pages and set up your forum.
Upgrading is a different process and should ONLY be done AFTER you have made at least one post in your new forums.
- open the .zip file for the 3.1.4. upgrade into a new folder ON YOUR COMPUTER… not on Your Server…
- Open and read the README file.
- Upload the individual files, one at a time, to the locations specified in the README file… be sure to over-write the old files… DO NOT DELETE the files…
Wordpress it's self is not supported on IIS… Without full support for the wordpress core, there would be no way for us to effectively trubleshoot your Installation… That being said, we can semi-diagnose your dificulties but can not effectively test or guarantee the work…
There MAY BE some errors spouted out by your server while these installation procedures complete. It has been our experience that the errors mean little, if anything at all, and can be ignored until or unless you or your users experience the errors while using the fully installed forums.
|
|
|
11:51 pm
20 Sep 2008
|
-Radio-
Moderator
| | Florida - USA | |
|
| posts 558 |
|
|
and seriously… the fact that you were in the database AND mucking around the core code in the wordpress core and or in the SPF plugin is REALLY disturbing…
The whole system, WordPress core, SPF, and all the rest, is designed to be installed and utilized by someone with a high school education… The areas you were delving into were areas that most College Graduates shouldn't go near…
|
|
|
|
|
I didn't actually say it had anything to do with IIS. I said maybe the MySQL on IIS behaved differently.
Also - WP does not create innoDB tables. It creates whatever your defaults are for the database and most usually they are MyISAM. The forum specifies MyISAM for the SFposts table because only MyISAM tables support the FULLTEXT index which is used for the search.
And it still does not explain how the post_content table can on one hand disallow null but have a deafult of null !!!
|
|
|
1:54 am
21 Sep 2008
|
Andrew
Guest
| | | |
|
| |
|
|
Radio - I think you might be jumping to conclusions before reading the whole post. I wasn't trying to describe how I upgraded from 3.1.3 to 3.1.4. I was describing the steps I took to bring everything back to a level playing field before trying to test 3.1.4.
“The whole system, WordPress core, SPF, and all the rest, is designed to be installed and utilized by someone with a high school education… The areas you were delving into were areas that most College Graduates shouldn't go near…“
I'm a programmer by day. It is hard to fix code without going near it.
Yellow Swordfish - the reason the code is working for you is because either (a) you're on a version of MySQL before 5.0.2 or (b) you're not running your MySQL 5 installation in strict mode. I am running in strict mode, which enforces data types and 'not null' flags. I've just disabled it, re-ran your original 3.1.3 install and it worked, despite the implicit writes of null to not null columns and empty strings to date columns.
You can read the manual on the flag here:
http://dev.mysql.com/doc/refman/5.0/en/constraint-invalid-data.html
The setting is applied by default with MySQL's Windows installer when you go for the “this is a new installation” option.
|
|
|
|
|
So in a way I was right!
I am running 5.0.20a here and it seems to me that 99% of hosts are still sadly on older V4 versions. I will look into this more deeply however and thanks for the info.
|
|
This forum is currently locked - access is read only
Forums
