Is this a new blog? How many posts do you have so far? How many posts have you configured in the admin panel (App Settings \ General \ Display Options \ Posts/Days per page)... If you've set that number to, say, 8, and you only have 5 posts on the blog so far, then the PREV | NEXT arrows aren't going to appear until the 9th post has been made...

jj.

The City in Evo skin in the [url=http://skindemo.b2evolution.net/a.php?skin=city_in_evo]demo[/url] doesn't show the previous :: next link either. But Jibberjab is right, once you have enough posts it will turn up. If you want to be sure nothing is broken, try another skin (for testing purposes).

If you don't like the links not showing up, change in the _main.php of city_in_evo this line:

<?php 
// navigation links for multi-post pages
posts_nav_link();

to this line:

<?php 
// navigation links for multi-post pages
posts_nav_link( ' :: ', '#', '#' );

Good luck

The blog is several months old so I have enough posts.. I will try changing the code. Thanks! I'll let you know what happens.

Hmm.. I tried and it's still not there.. can you tell me if this is wrong?

<?php } // --------------------- END OF POSTS LOOP -------------------------- ?> 

<p class="center"><strong>
	<?php  
// navigation links for multi-post pages 
posts_nav_link( ' :: ', '#', '#' );  
	?>
</strong></p>

<?php // -------- START OF INCLUDES FOR LAST COMMENTS, MY PROFILE, ETC. --------

Gerri,

Can you try your blog in another skin and see if the links are there. I am not at home, so I am not able to test things myself. In general, you can pick the code from a skin that does what you want it to do.

Good luck

Ut oh.. something is wrong somewhere. It doesn't show up in any skin.

Are there enough posts on the page that you are watching? Make some test posts to get to the required minimum for a <next> page. It may be you made enough posts in the previous month but they don't show on the page you're watching because your posts are scattered in different blogs / categories.

if it helps any, the blog is here:

http://www.absolutelytrue.com

I have thought about upgrading, but Im scared because I'm not a very technically competent person when it comes to these types of things.

Thanks, it helps to see the blog.
I have two questions:

1) <deleted>
2) what does it say in the backoffice: App Settings ->General -> Display Options -> Posts/Days per page
3) what does it say in the backoffice at: Blog Settings -> Blog URL (or similar) Is there a stub file active or is your blog called through index.php?

Regarding 3) both ways allow you to show a fixed number of posts on a page and that way it will never exceed the number needed to generate a <next> link.

If it helps :

1) it's not skin specific and happens with the default skins ( http://www.absolutelytrue.com/?skin=wpc_default )
2) it respects posts per page ( they appear to be "by days" ) ( http://www.absolutelytrue.com/?posts=2 )
3) it totally ignores $paged = 2 ( http://www.absolutelytrue.com/?page=1&paged=2 )

Personally I'd reupload the whole of your inc folder again, you've definitely got something awry

¥

Here we go Afwas:

2) Display options
display unit > days
posts/days per page > 5
Archive Mode > daily

3)
Hmm.. on "all" it is set this way:
Blog folder url>
Relative to base url
explicit reference on index.php is checked

But then on what I have labeled "Home Page" it is:
Blog folder url>
Absolute URL: http://www.absolutelytrue.com/
and 'automatic detection by index.php' is checked.

I think I have never had any clear idea about these settings....

Yabba:
I reupped the entire inc... still no dice :(

Thanks to both of you for your help. I'm clueless.

How difficult is it and how long would it be expected to take to upgrade to the latest stable version? I was trying to hold out until 2.0 when I will be pulling my hair out with a new skin.. but it seems like this might be the only solution here?

Just one more go: change Display Options > type to "posts" (was "days").

Updating is not as hard as it sounds :)

What I did when I upgraded (from 0.9.12 to 1.10.2) was to install a testing copy using the same server structure as my live blog (same folder levels, subdomains, etc) and a copy of my live blog's database. This allowed me to test the entire automated upgrade procedure (which worked fine, by the way) and just as importantly to tweak the test blog to get it to run exactly as I wanted it to without affecting the live site. Once that was done and everything on the test blog was running as I wanted it, I

1. Renamed the database in the test blog's _basic_config.php to the original database name and credentials
2. Made a backup copy of the live database (to preserve any new posts/comments that had been made during the testing process and, well, because it's always good to have a backup, or 3)
3. Emptied the entire hitlog table from the live database
(I guess step 2 and 3 can be reversed to save some space in the database backup file)
4. Made a zipfile of the entire test blog, including its /install/ folder and uploaded it to the root folder of the live blog
5. Created a folder called '0-backup' in my blog's root folder
6. Put up a temporary redirect in my .htaccess from my blog to my main site for all IP's except mine, with a message there saying the blog would be back up soon
7. Deleted the entire hitlog from the live blog's database
8. Moved all of the live blog folder's contents (including all subdirectories) EXCEPT for the zipfile I just uploaded, into the 0-backup folder
9. Extracted the zipfile I uploaded, which recreated the blog structure (now including any/all tweaks and hacks I set up while it was the testing blog
10. Ran the upgrade procedure option which allows the database upgrade via the /install/ folder
11. Deleted the /install/ folder and the zipfile I uploaded and verified all CHMODs where necessary
12. Removed the .htaccess redirect

End result... fully back up and running with all tweaks, hacks, layout adjustments, everything in place.. in just under 20 minutes of blog downtime. The point is to set up and configure the entire new blog on your own time, without your users having to see the process. Do it in parallel, and then just swap it over...

I might have forgotten a step here or there (I don't have my upgrade instruction log in front of me right now) but you get the idea...

Hope someone finds this useful...

jj.

Afwas : AHHHHAAAA... changing the display from days to posts did the trick! Thank you!!!

I really do appreciate everyone pitching in to help me!

jibberjab - thanks for the instructions, they will definitely come in handy. I'm still considering an upgrade and your detailed instructions will certainly help ease my mind.

One more question. I use PhpMyAdmin, can you tell me exactly what settings to use when I back up the database?

Thanks so much!

In CPanel there is an option for "backups"... Clicking on that link should give you, among other things, a list of the databases in your account. Simply clicking on the name of the database will give you a GZipped copy of your database (which can be unzipped using WinZip or WinRAR). There's also a way to export the entire database directly from phpMyAdmin but I've never done it that way.

If you need to, you can send the GZipped database file to your hosting provider and they can restore it, in the even that something goes wrong.

As others here have said, upgrading is really not as scary as it seems going in. Once you've done it you'll be wondering at what you were so worried about. :)

jj.

I have Plesk instead of CPanel :( I don't know why my host won't use CPanel... so I'm pretty well stuck with using PhpMyAdmin

The reason I get nervous is because my host pretty much charges through the nose for anything I need them to do.. so I try to avoid it if there's any way I can :)

In Plesk you should be able to go to:
Plesk Control Panel -> Domains -> domainname.com -> Back Up.

I guess this backs up the entire domain, but inside that backup file you'll have the database as well. You could always download that entire file and then extract the database and save it in its own, separate, zipfile, and delete the rest.

To backup restore from phpMyAdmin, this link might help:
http://php.about.com/od/learnmysql/ss/mysql_backup_3.htm

Most people here will tell you to empty the hitlog table before you do a backup, since the hitlog is usually the largest table and the data won't transfer over to a newer version of b2evo anyway. At least, mine didn't when I tried it during my testing stages going from 0.9.12 to 1.10.2.

jj.

Oh thank you so much for the information!

I really appreciate you being so helpful!