I have been thinking about the best way to display ads on my WordPress blog search results for a long time because there are numerous options. You could just display content ads at the top, bottom, or both locations, you could add a WordPress plugin, or you could create a custom page with Google custom search results geared for your page. I played around with the latter two options but wasn’t happy with eaither result. One of the ways to do the Google custom search results is using an iFrame and iFrames suck. Anyway I decided to add some custom PHP code to display the ads however I ran into a problem quickly which was the fact that you can only display 3 of the same ad on any one page so if you want to display ads in between each search result it would get a bit more tricky.
Previously I created an article about listing all WordPress tags on a single page however some things have changed since that time. When going back and looking at the article it looks like some of the tags have changed since that time. I do have a WordPress plugin installed called Simple Tags so take that into account when using the below directions. This plugin is recommended to provide you more control over your tags. The easiest way to display all tags is to create a blank WP page and assign a template to it that specifically lists all tags. Follow the below instructions and you will have a page listing all of your tags in no time at all.
- Add a Template Page:Add a new page called tag-cloud.php to your server in the theme directory of your WordPress installation. The location of the new file will be wordpress-root/wp-content/themes/theme-name/. You can copy the contents of the page.php file from the default theme or your theme and then make the following two modifications.
If you are running walmgr for log shipping with PostgreSQL and you see the below error in your postgresql.log file it is because you are missing the recovery.conf file. The recovery.conf file should be located in your data directory on the slave server which typically is /var/lib/pgsql/data.
CDTWARNING: archive_mode enabled, yet archive_command is not set
This means you probably have not run the below command as the postgres user on the slave server which is the command that actually generates the recovery.conf file.
Upgrading walmgr.py is easy since really this is just a python script. The most complicated part of the upgrade process will be keeping your database cluster up. Follow the below steps and you should avoid any downtime.
- Download Latest SkyTools: Visit PgFoundry to download the latest SkyTools. Issue the below command from /usr/local/src on each server.
- wget http://pgfoundry.org/frs/download.php/2129/skytools-2.1.9.tar.gz
I ran into a silly error tonight during some configuration changes for PostgreSQL that took me awhile to figure out so I wanted to share so it might save others some time in the future. In an attempt to boot the slave server in a PostgreSQL SkyTools walmgr configuration I was unable to get it operational. The server would seem like it was stopping recovery mode however I was unable to login and the recovery process was still showing. Eventually I used the verbose switch to see if I could gain more information about why it was not booting up and the output is below.
walmgr.py conf/wal-slave.ini boot -v
2009-04-22 01:24:22,949 3899 INFO Stopping recovery mode
2009-04-22 01:24:22,949 3899 DEBUG Using pg_auth file from master.
2009-04-22 01:24:22,950 3899 DEBUG Execute cmd: ‘cp’ ‘/var/lib/pgsql/walshipping/logs.complete/pg_auth’ ‘/var/lib/pgsql/data/global/pg_auth’
2009-04-22 01:24:22,955 3899 DEBUG Only single loop requested, exiting