harpshot

In my sandbox, hitting the “save” button after editing an already published article seems to clear the “post status”, giving it I guess a null value. Anyhow, it un-publishes the article. Go back to the edit screen, select the article for editing, and it comes up with the “post status” radio buttons all cleared. The edit was saved, though. At this point the “publish” button is visible (as it should according to what you’re saying). I can leave the “post status” radio buttons clear, or tick the “publish” status, either way I have to hit the “publish” button in order for the article to show up on the blog. Ticking the “publish” radio button and then clicking the “save” button doesn’t do it, it remains unpublished.
This is a 1.2 install with the latest CVS files. Could there be something left over in the db from the old discarded options of previous versions that’s running interference? BTW, I’m running Apache 1.3.27 (win32) with php 4.2.3. Unless you have another suggestion, I’m inclined to see what happens if I start over with a new database.

Heh, the ugrading and scripting changed my gmt offset and after I re-set it to -6 I can’t post comments on account of the 10 second warning. Thought I could beat it by deleting all the wp cookies, but I either missed one or the effect is tied into the db. Guess I’ll have to wait 6 hours and 10 seconds. ??
Meanwhile I’m pondering why, in the context of global communications, it’s necessary or even desirable to have anything stamped, logged or displayed in anything other than GMT (or UT). When I see a post that says March 22, 2004 at 03:45 PM that’d be, where? Without specifying the time zone it doesn’t tell me anything particularly useful. As usual, though, I’ve probably missed some important point.

Hmm, better but still funky. Writing a new article and publishing works fine. To edit, the article opens in edit screen with no publish button visible. Choices are “save & continue” or “save’. If I hit “save & continue” the screen is refreshed to show the preview and the “publish” button appears and I can publish. But, if I hit “save” then the article goes into limbo and does not display in “view site”, even though the status button for “publish” was selected. Have to go and find it in the list of articles and click on “edit”, and when it loads into the edit screen none of the radio buttons are selected, but the “publish” button is visible and when clicked publishes the article, even though no new editing is done. The end result seems to be you have to “save & continue editing” before you can “publish”. Perhaps this is intentional? If so, I’d suggest also hiding the “save” button, and maybe change the label from “save and continue” to “preview and continue”.

That has me venturing into the unknown, which hasn’t stopped me yet. Is this how to handle it: first back up db then (1) copy and paste the script into the query window in phpmyadmin and hit “go”, OR (2) copy and paste the script into a php file (i.e. script.php) and open in browser?

@techgnome: I didn’t realize anybody might use a March 30 CVS file for anything besides 1.2 alpha. Nor did I realize that there was more than one beta release to which this “Beta Discussion” section applied. My apologies. And I guess some people might think “go live” is synonymous with production site, but to me it means being internet accessible via URI as opposed to just running on my localhost PC accessible only to me. My apologies for misleading anyone.
I was going to ask whether you might be able to help, despite my shortcomings, but I see that Alex was nevertheless able to get straight to the problem. Developers like these are why, after a month of experimenting with CMS’s, and narrowing things down to WordPress and TextPattern (which is making great strides lately), WordPress is the one I’m “going live” with in the hopes that my testers will confirm my opinion that it’s worthy of a production site.
@alex: Thank you! I’m going to have a look as soon as I’m done here. Trying to follow along when y’all make fixes like that is teaching me a lot.

Looks like they added a conditional statement maybe to hide the publish button if “post status” is not set to “publish”, but it doesn’t work right, in my installation, anyhow. If you’re using the March 30 version of edit-form-advanced.php and not having this problem, then I think the process of debugging starts to look very daunting, indeed.

Went back to March 23 version of edit-form-advanced.php which took care of the problem. Will do a compare later, I’m wordpressed out for awhile!

Well, during the 5 days that passed since I posted, I somehow managed to get past the time-out issue on my local PC test installation. Don’t know why, other than dumb luck. Even practiced doing a new install and everything went fine, including posting comments. Ready for host server. Uploaded everything and did an install. Comments wouldn’t work. The install failed to create the comment_date_gmt field in the comments table. So I ran upgrade.php. Same result. Debated whether to go back and start over with the earlier version of install.php (the present one is brand new CVS). Instead, I added comment_date_gmt manually. Now comments work.
So, for whoever needs to know about these things, something in the CVS in the last couple of days results in failure to create comment_date_gmt field in the wp_comments table, using either install.php or upgrade.php.

There’s a little more about it here: https://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
I think I recall from some HTML newsgroups (i.e. comp.infosystems.www.authoring.html) that a person might be able to do something with mod_rewrite (or was it .htaccess?) if you’re enabled for those and can’t get relief from your host admin. The concensus also seemed to be that most sites should just be written for html 4.01 doctype (partly to avoid this very problem), unless xml is actually needed for functionality objectives, which it probably is for certain blogging features. I’ve also run across some discussions that this issue can result in the site getting overlooked by google, but I wouldn’t go so far as to vouch for that myself. Until now, I’ve been writing most everything in html 4.01 strict w/ css2.0.
Good luck with your host admin. Some are admirably responsive, others are…. well, don’t get me started.

You folks have lost me with all that rewrite stuff, but in regard to the original post (about error with the calendar), I could offer this, though I gotta think somebody else has already fixed it:
template-functions-general.php line 343 reads:
$thismonth = ”.zeroise(intval(substr($m, 4, 2), 2));
but probably should be:
$thismonth = ”.zeroise(intval(substr($m, 4, 2)), 2);
Moving that paren two places to the left worked for me.

I don’t know much PHP, but I found the following, moved the errant paren, and the error went away for me.
template-functions-general.php lines 342-343 read:
} else {
$thismonth = ”.zeroise(intval(substr($m, 4, 2), 2));
should be:
} else {
$thismonth = ”.zeroise(intval(substr($m, 4, 2)), 2);

Same here, after upgrading from 1.0.1 to March 8 nightly. Ver 1.0.1 didn’t have the error. The page displays the proper archive posts for each month, but the calendar doesn’t change to the proper month.

OK, better now. In case it hasn’t been mentioned before, turn off firewall to run upgrade.php on localhost PC. Also, anybody run into this: Missing argument 2 for zeroise() in /wp-includes/functions-formatting.php on line 241? It echos on page loaded from archive link (i.e. index.php?m=200402), instead of the name of month (or else it’s covering it up but I don’t think so). I’ve looked at the function but as mentioned before I don’t know enough PHP to debug it. It wasn’t there before upgrade. Is now. I haven’t searched forum yet but thought I’d mention it while here ’cause you three seem pretty clued in.
Thanks for earlier guidance. It helped. Sleep now. Search tomorrow…
HarpShot

Um, yes. Disregard my previous post. There was an excellent reason I couldn’t tell the difference. Ah, er, please don’t ask. Is there a smiley with dunce cap?

The variety of approaches that arrive at the same end is both interesting and reassuring. I downloaded the March 8 nightly and unzipped into a directory. I backed up my blog directory. Then I used a sync program to copy all “newer” files from the March 8 directory to the blog directory. This left the “customized” files like css, index.php, config and some others intact. I did *not* run install.php or upgrade.php. The blog works fine. In fact, I can’t tell any difference, which seems ideal. Of course, this was on my PC localhost, as I didn’t want to risk the real site without a rehearsal. So I reckon I’ll double-check the files that *weren’t* updated, to be safe, and upload to web server. Unless anybody can say whether running upgrade.php does something else that’s important. ???