kcargile

@raphaelber,

I was able to work around this problem by changing the email address for the user no longer showing up in the Subscibe2 list and then changing it back.

After the first save to the profile in question, the user will magically appear in the drop-down.

HTH

-k

Virme,

We recently explored a similar approach for one of our websites. It turns out that this problem is more difficult to solve than first appears…

Our application was a bit different, but the general idea was the same: combine comments and posts into one list and display them as such. You are correct — this render’s the built in paging useless. You’ll have to roll your own to make it work.

Doing this isn’t a trivial task, since you must to track the offset of two separate lists, and query accordingly. There are a few ways to do this, for example using the PHP session or (yikes) tacking parameters onto the querystring. In our case, however, manually building the paged URLs (e.g. …/page/3) broke permalinks, and resulted in a 404 when the page number was higher than the total number of active posts. This could probably be fixed (hacked), though I suspect you’d have to tinker with the WP core, which should be avoided.

That aside, doing this introduces another, more serious issue: tracking these offsets assumes that the user enters the list on the first page. If someone comes in an external link to, say, page 3, you have to calculate the offsets for all the previous pages before you can build paging navigation for page 3. Not a huge problem until you have hundreds of pages of content and thousands of readers. The potential to generate an immense amount of database traffic here is pretty high.

In our case, we ultimately modified our design approach to better mesh with WP’s limitations.

HTH

-k

You’ll need to check the plugin page to see what filename it’s using for the Sitemap file. It’s typically something like /sitemap.xml.

-k

Make sure you double check the other core WP files — I found that there are several that use this syntax that will need to be adjusted.

-k

Ok, I’m seeing the same thing. You may have an invalid XSL document associated with your sitemap file. Not an uncommon issue…

Login to the admin section of your site. Go to Settings -> XML-Sitemap and look for the “Include an XSL stylesheet” textbox in the advanced options. If there is a value entered here, remove it (the textbox should be empty, this is ok) and then click “Update Options” at the bottom of the screen.

When the page reloads, click the “rebuild the sitemap” link in the Status section near the top of the page.

Give it a few minutes to rebuild, and your error should go away.

Not necessarily. It may just be your browser complaining about the format of the XML file. What browser are you using?

I’ve been working on a WordPress importer to handle exactly this situation. I’ve posted the first release, along with some notes about the general CS to WP migration process here:

https://www.bettersoftwarenow.com/2008/08/02/migrating-community-server-to-wordpress/

-k

||| Kristopher Cargile
||| https://www.bettersoftwarenow.com

I ran into the same problem getting WP 2.6 up and running at ReliableHost. The issue is related to a bug in how IIS7 handles PHP relative paths.

Once you’ve successfully installed WP, change the following in /index.php:

change:

require(‘./wp-blog-header.php’);

to:

require(‘wp-blog-header.php’);

Upload your changes and you should be able to successfully browse both public-facing and admin sections of the site now.

-k

||| Kristopher Cargile
||| https://www.bettersoftwarenow.com