randybrown

Thanks, coffee2code. I’ll give that a try.

Traced this problem back to my host service. The auto updates are run as a cron task, and they had made some change there which caused cron to fail.
It’s fixed now, and all is back to normal.
Again… not a WordPress or a weblogs.com error.

Thanks. I’ve not changed anything in my WP blog, that’s why I was wondering if weblogs.com was acting up. All was working fine up to 7/10.
I’ll check with my hosting company to see if something changed there.

The key is to try to make sure that the plugins are not doing similar things or making similar queries to the database. There are a number of plugins that are very similar. It’s important to study what the plugin does to make sure there’s as little redundancy as possible.
Seven should not be too many. I have about the same number running on my WP blog and see no noticeable lag.
<rb>

Couple ideas:

1. WP has a feature to display entries by pages. So, if an entry is, say, and entire chapter, you can choose to display one page at a time. A clickable link can be displayed t take the reader to the next page.
2. During the revision process, you can change the date of the entry. So, if you need to position one entry prior to another, for proper sequence of story, you can edit it and change the submission date.
3. You can set WP up with categories and subcategories. So it might be worth thinking about having the first level categories be your “book” names, and the second level categories be your “chapter” names.

1) Yes, to use the rewrite rule I supplied, the wiki.php (I name mine “index.php” would be inside its own directory.
2) The wiki.php file is nothing more than a standard WP index.php file with the calls to the ewiki-specific goodies. Look for the link tag and place a call to your own css file there.
HTH

OK. Thanks, Liz.

In wikiwiki.php there is a call to get_currentuserinfo();. Where is this lcoated?

This uses the php-based wiki titled “ErfurtWiki”. I’ve been using this and have integrated it into my WP blog setup. I conversed with ewiki’s author and came up with a way to install the wiki so that it produces cruft-free URIs.
This is accomplished by creating a directory inside the main WP directory and storing the ewiki files in it. Don’t name it “wiki” if that is what is wanted in the URI. Then, add the following to the main WP .htaccess:

RewriteRule ^wiki/(.*)$ ewiki/index.php?id=$1 [QSA,L]
RewriteRule ^wiki$ https://domain.com/wiki/ [R=301,L]

Note: In the first line above, “ewiki” is the name of the directory where the wiki files are located.
I’m glad to see the integration wityh WP’s authentication scheme in the demo – will download and check into the details.

It does look, at least for v1.3, that the work has been focused on the underlying features; features which the average weblog user (who, it bears to remember, is probably not a programmer) will not readily see the benefits.
With the additional plugin goodies, the devs probably need to emphasize that even average users will need to upgrade — if they plan to install plugins. Plugins developed using these new additions will not work, and will break on versions prior to 1.3.
I didn’t see in Ryan’s post mention of a version checker. Perhaps now would be a good time to include this within the plugin system; no need to force non-programming users of the weblog software to figure out why the plugin they just installed is causing grief when it could/should be handled within the plugin system.
Idea:
I know there is a version variable; can this be checked by a plugin, and then the plugin automagically deactivates itself? Of course, it should let the user know it has done so….

I installed the nightly on a test site yesterday. Went through all of the admin interface and couldn’t see any differences between it and v1.2-mingus.

Thanks. Solved it myself:

// set comment and ping to true
$comment_status = 1;
$ping_status = 1;


Could someone in the know post take a little time to post an update of the types of improvements being added to v1.3? What is te overall direction of the development of WordPress.
I’m not asking for lengthy details, but I think many of us would be interested in an update.
Thanks.

I’ve been using PSPad recently to do editing and publishing via FTP. It hs a preference which allows seeing hidden files on the server and enabling this will show the .htaccess file. PSPad is available here.

>>Those civil-rights&tree-huggers&animal-rights, etc etc can stay with Hotmail and its 2 MB of space… <<
Geesh….