harpshot

Indeed, but in practice I don’t need the email if I’m letting comments appear without moderation (unless I’m worried I might need to hurry and delete one, in which case I should be requiring moderation in the first place). I need the email to let me know a comment’s been submitted and is awaiting moderation. Otherwise, I don’t know it’s there unless I go the whole nine yards and log in, go to the edit page, and check to see if there’s anything waiting in the moderation queue. Still think it’s a bug? I’m still not sure. What I do know for sure is that after installing tonight’s CVS, the author’s name has disappeared from all the posts! Now that looks like a bug for another thread!

Thanks for checking. At least I know it’s not just me! The flip side is that if I *don’t* specify that moderation is required (so that comments “appear” or are “posted” immediately), then I *do* get email notification about new comments.

If you’re running apache, open your httpd.conf and find a parameter that sets 30 second time-out and change it to 60. I’m not at a machine with apache on it right now, and can’t tell you the section or exact wording, but if you just look for a time-out value of 30 seconds you’ll probably find the right one. I don’t remember if there’s more than one but I only changed one. As I recall, it was pretty obvious when I found it, way back when…
Firewalls sometimes cause it, too, but I haven’t had to turn off the firewall since I changed the time-out in httpd.conf.

TG: Those are not available on my General Options page, at least on the installation I can access from work at the moment. I haven’t updated it from CVS for about a week. Near as I can remember, though, my sandbox at home, which is updated through April 25 CVS, doesn’t have those settings, either. Now that you mention it, though, I seem to recall seeing those in an earlier version.
2f: I wasn’t prepared to call it a bug, because of the semantics. We have at least two words at play under “Discussion Options”: “posted” and “appear”, plus perhaps “publish” and “submit”. Technically, if “posted” means “appear” as in “published”, then a comment awaiting moderation hasn’t been “posted” and shouldn’t generate an email. But if a comment that’s “posted” is supposed to mean one that’s “submitted” but awaiting moderation, then an email should be sent. Hence my confusion as to whether the behavior I’m seeing is correct or incorrect in the eyes of the developers.
I’ll play with it a little more this evening and post it as a “bug” if I think I can justify it. I didn’t want to get in the way in a different thread if this is the design or just a quirk in my installation. Also, I generally assume developers are checking *all* the topics in the beta discussion section.

This seems like fodder for inclusion in the WP documentation, with advice about how to economize our content and/or features to minimize the risks of suffering either a dotCanada axe or a Dreamhhost ceiling. I’m starting to worry whether I’m sitting on a WP time bomb with my web host. Or, is this just part of the development phase, with memory efficiency to be ironed out by the time 1.2 is released?

Hmm, shades of dotCanada, but DreamHost’s reaction was rather more civil. FWIW, the data I see at bottom of your page says “55 queries 4.967 seconds”. Seems significantly higher than most WP sites I visit. Beyond that meager observation, I can’t help but I’m anxious to see what develops.

Although hardcoded as wp-images/smilies, the database contains the full path. What happened in my case was that somehow, after running upgrade.php, index.php got added into the path, i.e. localhost/blog/index.php/wp-images/smilies. When I went into database and deleted “index.php” from the path, the smilies came back, of course.

An excellent explanation, FD, in conjunction with Jerry’s. If you’re on a hosted server and don’t have access to httpd.conf, would that go in a .htacess file (if you couldn’t get the admin to modify httpd.conf)? Fortunately, I haven’t run into the problem you guys had, but this seems like good stuff to learn about.

If this helps, your divider line goes to the top when viewed in my IE6, but not in my Firefox. Also, your Blogger version looks like a loose Doctype triggering quirks mode and so looks the same in IE6 and Firefox, whereas I think your WP version Doctype is triggering standards compliant mode, and so you’re running into some cross-browser issues. I hate when that happens. Good luck.

You were customizing index.php, I assume? You say that * some* of the changes were made “using that handy little “Template” tab…. “. But, if you did all the editing online, what were you using besides the built-in WP template editor to edit index.php?

All in a day’s work. And half a night. Hmm, wonder what this note says that my wife left on her way out the door…

Well, I think I found the problem.
Here’s what post.php says at lines 304 and 306:
304 if (empty($comment_status)) $post_status =
get_settings(‘default_comment_status’);
306 if (empty($ping_status)) $post_status =
get_settings(‘default_ping_status’);
But here’s what it should say, I assume:
304 if (empty($comment_status)) $comment_status =
get_settings(‘default_comment_status’);
306 if (empty($ping_status)) $ping_status =
get_settings(‘default_ping_status’);
It fixes my problem, anyway. Looks like it’s been that way a long time. In the past, I always just hit the “publish” button, anyway, so it didn’t matter. When they made the “publish” button invisible if the article was already “published”, I had to use the “save” button and that’s when a previously latent problem became manifest. I guess most people default to “ping”, so nobody else noticed. Or, I don’t know, I’m very amateur at php, maybe there’s some other reason it works for me now. But it works. I feel better.

No. You you should see a nice administrator’s page, probably ready to
write an article, but where you’ll select tabs to do things like post,
edit, set options, etc. You’ll know it when you see it.
Now that I’m home on the PC w/ my WP installation, I can duplicate your experience by deleting the index.php file from the /wp-admin folder. Your main, or default, index file should be index.php (probably not index.htm as you mentioned earlier) in your root (/htdocs) folder. But you should also have another index.php file in the /wp-admin folder. It’s a small file, about 300 bytes. If you don’t see it there, extract it from your wp zip file.
If that’s not it, then Jerry’s suggestion about your httpd.conf file may be where to turn next. However, TG who posted above was betting that the necessary /wp-admin/index.php file is missing, and so am I.

Barry – The file wp-login.php is in the “wordpress” directory (or whatever your main blog install directory is called), not in the wp-admin subdirectory. Your browser seems to be looking for login.php in the wrong directory (wp-admin) and, not finding it, is displaying a unix style view of the wp-admin directory, if I’m understanding you correctly. I can think of some possibilities, but they depend on your OS and server setup. Maybe if you provide more details about your installation somebody can help. I’m not presently near the computer with my WP install. All I can suggest from where I’m at is that maybe your directory structure or contents got messed up somehow. Or your “main” index.php ended up in /wp-admin subdirectory replacing the small index.php that’s normally there and just does a little re-directing.

Specifically: in my db, a published article contains the value “publish” (without the quotes) in post_status field of wp_posts table. When I retrieve that article in the edit screen and click the “save” button (with or without actually editing anything), and then look at the db, the post_status field is now empty. Something in, I presume, post.php is changing $post_status from ‘publish’ to ‘ ‘, even though the radio button remains ticked for “publish”. Unfortunately, my limited php abilities leave me unable to figure out why, despite my best efforts. <sigh>